What does it take to be a great engineering manager?

‍

In this interview with Belal, we explore the journey from technical expert to engineering leader, discussing team development, business impact, the growing role of AI in software engineering, and the importance of knowledge sharing.

Discover valuable insights and lessons from his experience at agap2 and beyond!

‍

• You've worked across different leadership roles, from Solutions Architect to CTO and Engineering Manager. How have these experiences shaped the way you lead engineering teams today?

I think having the opportunity to work in different roles has given me a much broader perspective on engineering leadership.

I started taking on broader responsibilities as a Solutions Architect at Talpa Network, where I was leading the streaming platform. I was involved in improving the platform's architecture, reducing operational costs, and improving security through the implementation of Widevine DRM. That experience taught me how important it is to balance technical decisions with business needs.

Later, I became CTO at a small startup called The Burst, which focused on video streaming for children's content. That was quite a different experience because I had to wear multiple hats. I was writing code, making architectural decisions, hiring people, managing budgets, and helping shape the product. It gave me a better understanding of the business side of technology and the challenges of building something from the ground up with limited resources.

Moving into Engineering Management brought these experiences together. I could combine my technical background, business understanding, and experience building products with the people side of engineering.

Today, I don't see engineering management as simply managing engineers or making sure things get delivered. I see it as creating the right environment for people to do their best work, make good decisions, and understand how their work contributes to the bigger picture.

I think having experienced engineering from different angles helps me connect the dots between technology, people, and business.

‍

‍

• What do you believe makes a great Engineering Manager, and how do you balance technical expertise with empowering and developing your team?

For me, a great Engineering Manager is someone who can create clarity, build trust, and enable people to grow.

I don't believe you need to be the smartest engineer in the room or have all the technical answers. In fact, I think it's important to create an environment where engineers feel comfortable challenging ideas, making decisions, and taking ownership.

At the same time, I believe an Engineering Manager needs enough technical depth to understand the challenges the team is facing. I still enjoy being involved in architecture discussions, reviewing technical approaches, exploring new technologies, and challenging technical decisions.

The balance is knowing when to get involved and when to step back. I don't want to become a bottleneck or the person everyone depends on to make decisions. My job is to help engineers become more independent, not less.

I also spend a lot of time understanding individuals. Everyone has different strengths, ambitions, and areas where they need support. Some engineers need opportunities to take more ownership, while others need mentoring, guidance, or more exposure to stakeholders.

And beyond the engineering team, I think a good Engineering Manager needs to build strong relationships with product and business stakeholders. Understanding their priorities and translating business needs into realistic engineering plans is just as important as understanding the technology.

Ultimately, I measure my success not by how much the team depends on me, but by how capable and independent the team becomes over time.

‍

‍

• Looking at your latest role at bol.com, what's one challenge or achievement you're particularly proud of, and what did it teach you about engineering leadership?

One thing I'm particularly proud of at bol.com is helping change the way the teams approached delivery and prioritisation.

I noticed that we could sometimes spend too much time trying to deliver a complete solution before getting anything into the hands of users or the business. I pushed for changing that approach: delivering smaller pieces of value faster, learning from the results, and then building on top of them with additional features.

This helped us improve the team's productivity and create a better feedback loop instead of spending too much time upfront trying to get everything perfect.

Another important part was looking at the team's responsibilities. Over time, teams can accumulate services and responsibilities that no longer make sense. I worked on moving services to the teams that were better positioned to own them, or shutting them down when they were no longer needed. This helped us reduce unnecessary complexity and give the team more focus.

I was also involved in a broader business shift towards profitability rather than simply maximising revenue. For example, changing the way we approached marketing so we focused more on products that generated higher profit rather than just the products generating the most revenue.

What these experiences taught me is that engineering leadership is not always about solving technical problems. Sometimes the biggest impact comes from challenging the way we work, simplifying things, and making sure engineering effort is aligned with what actually matters to the business.

‍

•AI is rapidly changing how engineering teams work. How are you incorporating AI into your own workflows and those of your team, and where do you see its biggest opportunities and challenges?

I'm quite passionate about AI, and I prefer to learn by building and experimenting rather than just following the latest trends.

Outside my day-to-day work, I've been building Echo3s, a product that turns PDFs and books into AI-generated audiobooks. It involves several AI components, including character identification, voice assignment, and text-to-speech orchestration. Building it has given me practical experience with production GenAI workflows, model capabilities, quality evaluation, and cost optimisation.

At bol.com, I also had the opportunity to contribute to the AI transformation within the engineering organisation. One of the things I focused on was helping engineers get started with tools like Claude Code, organising knowledge-sharing and training sessions around the basics, and showing how we could improve our existing ways of working using AI.

I think the biggest opportunity is not simply using AI to write code faster. It's rethinking parts of the software development lifecycle: how we explore problems, design solutions, write code, test, review, and maintain software.

But I also think there are challenges. We need to make sure engineers understand what AI generates rather than blindly trusting it. Code quality, security, maintainability, and architectural decisions still require engineering judgement.

My approach is to encourage experimentation, give people practical examples, and help them understand where AI genuinely adds value. I don't think AI will replace good engineering teams, but I do think teams that learn how to work effectively with AI will have a significant advantage.

‍

‍

• What advice would you give to engineers who aspire to move into leadership roles, and what's one lesson you wish you'd learned earlier in your career?

I would tell them that moving into management is a completely different challenge from being a senior engineer. Being technically good is important, but it is only one part of the job.

I also think middle management is probably one of the hardest positions in an organisation because you're constantly balancing different expectations.

On one side, you need enough technical knowledge to understand your engineers, challenge technical decisions, and help them solve complex problems. At the same time, you're responsible for delivery, priorities, deadlines, and making sure the team is moving in the right direction.

Then there's the people side: coaching engineers, supporting their career development, dealing with difficult situations, and helping everyone grow.

And on top of that, you need to understand the business, work with product and other stakeholders, manage expectations upwards, and make sure your department is aligned with the wider organisational direction.

You're basically switching between all these roles throughout the day. Somewhere in the middle of all that, you also need to make sure you don't lose yourself, your focus, or your own development.

My advice would be to understand that the transition isn't about becoming a more senior engineer with additional responsibilities. It's about learning a completely different set of skills. Communication, prioritisation, empathy, business understanding, and the ability to make decisions through other people become just as important as your technical expertise.

One lesson I wish I'd learned earlier is that you cannot do everything yourself, and you shouldn't try to.

As engineers, we're used to solving problems by getting involved and doing the work ourselves. But as a manager, that mindset can actually become a limitation. Your success comes from helping others solve problems, making the right decisions, and creating an environment where the team can succeed without depending on you for everything.

You need to learn to let go of some control, trust people, and accept that sometimes the best thing you can do is step back.

‍

‍

• Beyond your client responsibilities, you've also shared your AI expertise with colleagues at agap2. How important is knowledge sharing to you, and what do you value about being part of the agap2 community?

Knowledge sharing is something I genuinely enjoy. I think one of the best ways to learn something is to try to explain it to someone else.

With AI, things are moving so quickly that it's easy for people to feel overwhelmed or unsure where to start. I had the opportunity to help colleagues at agap2 through internal knowledge-sharing sessions, where I shared some of my experience and gave practical demonstrations of how AI tools can be used.

This was something I did because I wanted to contribute and help the organisation make better use of the technology, beyond my responsibilities on the client side.

I believe there's a lot of value in sharing experiences between people who work on different projects and in different organisations. Someone might have already faced a challenge that another colleague is just starting to explore, and sharing that knowledge can save a lot of time and help everyone improve.

What I particularly value about the agap2 community is having that opportunity to connect with people beyond my immediate team and client environment. I see it as a two-way relationship: you share what you know, but you also learn from other people's experiences and perspectives.

For me, being part of a professional community shouldn't just be about the project you're assigned to. It's also about contributing to the wider organisation and helping the people around you grow.

‍