The most important thing I learned from my team lead

I worked on P.’s team for about 1 year when he decided to change job. For obvious reasons, we all were quite anxious. Some time later M., one of our lead devs took over P.’s role.

About a month or two after P. left, I had the usual one-on-one meeting with M. He asked me how do I feel about this change, and how it affected my work. I said that it was really weird, but I don’t think much changed. There were some differences, but I didn’t notice anything major. It didn’t have any serious impact on my everyday tasks and it was in fact much better than I expected. M. smiled and said that P. would be very happy to hear that, because that was his main goal as a team lead.

Back then I didn’t fully appreciate how wise and challenging that was. But having more experience now, I admire P. more and more every day and one day I want to hear the same thing about myself. That would make me very proud.

Be replacable

The principle is counter-intuitive. Everybody is unique and has different talents. We like that. Combined wisely, the differences can make the team something more than the sum of particular members. But at the end of the day, being the team or company hero really sucks. It is painful for the heros themselves and for the people around them.

Most likely, hero is the person everybody else counts on, they are the most experienced person on the team. They are chief fire-fighters and have a track record of saved projects. They are the technical people whom non-technical managers love and worship, because they get things done. They are the company’s most valued employees. Depending on the company profile, specific characteristics might change. But one thing that is constant, is that – using Lean terminology – they are the team’s bottlenecks.

The team can’t move faster than its hero. That itself might not be so bad, some teams are satisfied with moderate pace of work and there’s nothing wrong with that if business is happy. Where it becomes dangerous is when heros are so time-crunched they never have time to become replacable. They have so many fires to put down, that they never get round to showing other members how to do things, to mentor, to review, to guide and think really hard about long-term goals. If other team members are determined enough, they’ll learn anyway, but that won’t be as fast and effective as it could be. Usually that means, that we have 1 or 2 people giving their 200% and another 10 getting by with 50%.

What that means in practice?

Being replacable can manifest in different ways, depending on the role. Ultimately it means the team will be strong and effective even if you leave. They might miss you (and should!), they might lose some of your unique strenghts, but it won’t kill them and won’t significantly impact their work.

There are many small and big things that allow team to remain strong after losing one of the valuable members (even if only temporarily). For example for developers it might mean that everybody knows how to set up a new build on TeamCity and the configuration is stored in some shared location, that anybody can access if the server goes down. It means that code is of good quality and passes the ultimate quality test of WTFs per minute. It means that there’s no single module that only one person understands. It means we have some form of capturing requirements, which is more sophisticated than emails. It means everybody knows how to write tests and how to test the most important manual paths.

In short, it means there’s no task that anybody calls “not-my-job”.

How to become replacable?

There are many practices that support becoming replacable. Here I want to share those that as far were the most effective for me.

One of the universal ones, good for every role, is lightweight documentation and wikis. Have one place that anyone on the team can access. Capture all significant information there. If some page becomes irrelevant it can be easily removed. In all honesty, I’ve never heard about a place that suffered from having too much of a good documentation. But lack of it is very, very, very wasteful. Reengineering is costly, not only for software, but also for finding justification for some decisions or understanding processes.

As I learned from experience, the single most important reason for keeping track of significant decisions is that if you don’t understand why something was introduced in the first place, it’s very hard to get rid of it. People would be scared of unexpected consequences and wouldn’t be willing to take responsibility for making change. Quite often it means that the process is not as effective as it could be or that you have a mess nobody dares to clean (for example unused tools or 10-years old reports that “somebody might still need”).

Another valuable practice is knowledge sharing. Make it easy and unsophisticated, experiment with various forms. Encourage people to share even tiny things with the rest of the team. Put together a few slides or draw a diagram on a board and explain how you did your last task. Communicate the important conversation you had with a client. Tell your colleagues about the meetup or conference you attended and what you have learned.

At first, people might be reluctant (especially with presentations), they might feel like they don’t really have anything interesting to say, but be persistent, encourage, celebrate small wins and make sure everybody knows about good stuff that somebody else did. If you see that your colleague did something good, ask them to share that with the whole team. Over time, it will become an everyday practice.

Don’t be limited by job descriptions. At the end of the day, we’re one team. Maybe there are some tasks that don’t have to be performed by you. Or even better, maybe they can be rotational. Why don’t you encourage everyone to prepare and run a retrospective in turns? Maybe somebody else can clarify this vague requirement with a client? Or why don’t you work in pair with your colleague on your usual task, so the next time they can perform it on their own?


Although it seems valuable, aiming to be replacable is not a common practice. Some people might say that it’s stupid to consciously lower your market value, but I think the opposite is true. You increase your value, by being supportive of other team members and helping them become more effective. You don’t loose by sharing.

What I personally find most compelling in being replacable is that I can fully enjoy my next day off. The nice consequence of not being a hero is that nobody will ruin your holiday, no matter how serious problem your team has to face while you’re sunbathing.

If you have any other examples for becoming replacable or how it manifests, please, share them in comments. I want to learn more about this.

(Visited 82 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *