My 2 key lessons of moving from individual contributor to manager

In December 2021 I was invited to share my experience with the tech leaders of AholdDelhaize. I shared with them how I moved from managing on practices to managing with principles. I also shared my story on how I learned the First Team concept of Pat Lencioni and how that benefited people in the teams. This blog post is based on that talk.

In 1998 I started as a developer. I was as slow starter and not the best engineer. 10 years later I moved into a tech lead role with a team of 3. I had responsibility for data warehouse architecture and development. With already 10 years of experience and a small team, this was quite manageable for me. Then I moved to bol.com where after 1 year, in 2012, I became software development manager. This was for a much larger team of about 20 people. These people were also very experienced. This required me to step up my game.

Looking back, I learned a lot. If I must choose 2 key learnings, then they are these:

Agree on goals and principles, and leave practices up to the people
Not just focus on the team you manage, but also on the team that you are member of

These 2 approaches helped me achieve results, without being involved in every detail anymore. In the 2 sections of this article, I have written a few notes on both and added some links to content that you can read.

I - Goals & principles over practices

You manage a large team of highly educated and experienced people. You do not have the time to be engaged in every detail. Also, it would be frustrating for the team members if you would be involved in every decision. It would feel like micromanagement. Besides, they would be dependent on you, which does not scale anyway, and it slows everyone down.

How do I do it?

I prefer to set goals in terms of outcomes, not so much output. For example, increase the use of a product with x% and improve the time to resolve with y%. Explain people why. People can challenge this. Then discuss how to achieve the goal or ask people to make a proposal. For example, make a certain improvement in alerting to get better time to resolve.
You need to agree in principles within which people reach the goals. Principles are very much dependent on your organisation. Examples of principles are:

Make things small over large
Use Python as a language, unless you have good reasons, but then explain first
Use proven technology over cutting edge
Etc

I recommend writing these down in a manifesto (set of principles) and engage everyone in writing that.

What if people do not come up with the best solution in your opinion? I like to apply the Situational Leadership model. I also discuss tat with people explicitly. Some people are highly experienced in a task, and they can make their own decisions. Some people are less experiences and then for example you discuss and decide together. You can be open about this.

Another way to solve this, is to let peers review proposals. This way you are not always the bad cop. For example, I often use an architecture review team (a virtual team of peers form all teams). They give each other feedback. This is also another step towards building as team that is not dependent on you.

When you do not agree on the practices that people choose, then you have one of these 3 issues:

First check if you have implicit principles on your mind that you never shared
Second check of the goals are understood well Only then get into the mode of being more directive and do explain why (Situational Leadership)

Issues with this approach

Compared to being directive and managing by practices, it is initially slow. However, in them long you built a better and faster team
People expect they can make all decisions themselves, while some need more direction (Situational Leadership), so if you are not clear about that upfront, then it leads to disappointment

II – The First Team principle

The approach above should save you some time. That is time that you do not have to spend on the team that you manage. Instead, you can now spend it on the team that you are member of. In this section I’ll explain the difference and why it is so important. This lesson I learned from Patrick Lencioni. He describes it is his book The Five Dysfunctions of a Team. It is only a short section of the book that is dedicated to this topic. Still for me it is a key concept.

The team you manage <> the team you are member of

See picture below. Imagine that you are the managers of a product development team. That is the team that you manage. The technical platform manager also has a team that she or he manages. And the same for the product manager who maybe manages a team of product owners and designers. Together they are member of a management team.

What most managers do, is that they prioritize the team that they manage over the team they are member of. This often leads to sub-optimal results and conflict. E.g., you tell your team to go left, and the platform managers tells her or his team to go right. People in both teams then get a conflict. That conflict is not their fault, but a result of you not aligning with the managers in the team that you are member of. My lesson: at least give both teams equal priority, so that you are of even more value for the team that you manage.

Topics that you typically align on with the team you manage, relate to section I: the goals and the principles.

Challenges with this

You cannot do this on your own. You need to do this together with people in the team you are manager of. Otherwise, this will not fly. Discuss this with them and your manager (who is often also their manager). Often you can use real life examples of misalignment to make your point. And explain to your manager the value of his direct reports working as a team, instead of working as a group of individuals.