Three Years at Bereke Bank: Still Learning to Be a Manager

Today, September 25, 2026, marks three years since I joined Bereke Bank

After my first year, I wrote a long retrospective about moving from engineering into management. Back then, it felt strange to spend an entire day in meetings and reach the evening without really understanding what I had accomplished.

For some reason, I did not write anything after my second year. Probably because things were starting to settle: both my expectations of the role and other people's expectations of me.

But today I reread that old post and realized that many of the problems have not gone away. If anything, the scale of those problems and questions has grown.

If my first year was about learning to stop doing everything myself, the third was more about learning to stop thinking in terms of individual tasks altogether.

The further you go, the less of the result you can touch

When you are a developer, the connection between your work and the result is fairly clear.

There is a task → you write the code → the code reaches users

When you manage one team, that connection becomes longer, but it is still easy to trace. After all, you are the team lead.

Then the number of teams grows. Separate areas emerge, along with tech leads, platform teams, shared standards, processes, hiring, people development, and dozens of initiatives running in parallel.

At some point, it becomes physically impossible to be inside everything.

And one of the main lessons of this year, I think, is that this is normal.

My job is less and less about finding the right technical solution myself. It is much more important to build a system where good decisions are made regularly without my involvement.

That sounds fairly obvious, but it took me time to accept it.

AI turned out to be a very similar story

AI has probably been the biggest theme of my latest year at Bereke.

It all started simply enough.

How do we give developers good AI tools? What should we use for development? Which internal data can we connect? Which workflows can we automate?

Essentially, the conversation was about the productivity of individual developers. But over the year, its scope changed dramatically.

If requirements remain poor, context is scattered across dozens of systems, architectural decisions exist only in people's heads, and the delivery process is not designed for agents, a model alone will not fix any of it.

So the conversation gradually moved from “AI for developers” to AI across the entire PDLC.

Then it moved one level higher again, toward the transformation of IT as a whole.

For me, the important part is not even AI itself, but how quickly a technical challenge became an organizational one.

A PoC is not yet a change

Over the past year, I have also become much more cautious about the word “implemented.”

Building a PoC or MVP is now relatively easy and almost free.

You can put together an impressive demo, get encouraging initial feedback, and launch a pilot.

But there is an enormous gap between a working PoC and a real change in how people work.

Sometimes you simply have to admit that an idea does not work the way you expected.

We have had initiatives that we shut down. We have had pilots where proving the impact was harder than we wanted it to be. Many things are still somewhere between “it works in a demo” and “we can scale it across the entire bank.”

In the past, I probably wanted to move from idea to implementation as quickly as possible. Now I sometimes spend longer thinking because I want the change to still be there a year later without manual management.

People still matter more than processes

Despite all this, I do not think management ultimately comes down to designing elegant systems.

You can draw the perfect organizational structure, RACI matrix, and decision-making process, and nothing will work.

Because people are still at the center of it all.

Over these three years, I have had to learn to trust more than felt comfortable, delegate responsibility, and stay out of a solution even when I think I know a better way.

To let people make their own mistakes.

And most importantly, to stop being a required participant in every important decision.

That is probably one of the hardest parts of moving out of an engineering role.

As a developer, you spend a long time being valued for your ability to solve difficult problems well. Then, suddenly, your job is to make it possible for other people to solve them without you.

I am still learning to be a manager

In my retrospective after the first year, I wrote that I wanted to get better at planning change strategically. It is slightly amusing to reread that now.

There is certainly much more planning involved.

But it turned out that strategy is not simply a big roadmap for the year.

For me, it is now more about choosing the few things that genuinely need to change, building a functioning system around them, and saying no to a dozen other good ideas.

It also means continuing to push a change for long enough after the initial enthusiasm has faded.

If I had to summarize my current conclusions very briefly, they would look something like this:

• A manager's results cannot always be shown in Jira
• A good system almost always scales better than individual heroics
• Priorities are, first and foremost, a list of things you have decided not to do
• Launching a change is much easier than making it last
• The further you move away from development, the more often technical problems turn out to be problems of people, processes, or the organization

After three years, I understand my work much better than I did at the beginning. But the feeling that “now I finally understand management 100%” has never arrived.

If anything, the questions have simply grown bigger.