If you are a lead programmer, you are not expected to be the fastest coder. You are not expected to be very deep into the hottest tech.
You are expected to lead other programmers. That means you must be sure:
- They see what you do, and they find it interesting. Imagine a dancer doing interesting moves; people see it and they like it.
- They repeat what you do, multiplying the force you apply. People try the moves of a dancer. So you can move faster together. So you can learn something new together.
So when you start to lead, you must change your mentality from being the fastest contributor to being a force multiplier of other contributors. Imagine a team of 5 members. Four of them are 1x programmers, one is a star with 4x productivity. Total productivity is 8x. If the star lowers his productivity to 1x and invests his free time into other team members, they would become 2x pretty soon. Total productivity is 9x, 12% better. Nobody is overworked. People grow professionally and surely happy about that. Bus factor improves. That’s what force multiplier means.
Easier said than done, isn’t it? Start with a couple of my favorite tricks:
Understand the project
Spend more time reading the code than writing the code. Try to understand everything written to compose a big picture from small parts. Read all code reviews and all tickets. The next time you read something and you understand it can be improved, don’t fix it yourself. Create a task for somebody else to take. Improve your skill of formulating tasks. Try to feel how much of a difference slight changes to task description and title make. Don’t create useless work; create tasks for real improvements.
Help people in trouble
Sometimes people produce work that is much worse than your expectations. Don’t blame them, especially in public. Most of the time, they know that the quality is bad. Most of them wish it wasn’t that bad. That’s why they’re in trouble.
Carefully explain where the result can be improved. Improved! Not “fixed,” “redone from scratch because it won’t work.” Very often, people understand the problem very well, but they lack a structured approach to the solution. They run upstairs, but some steps are missing, so they fall down. Make a missing step for them or explain how to make it.
Don’t go too far by helping people
Don’t hide behind people; otherwise, they get used to you always pushing them forward. You’re expected to lead. Be in front of the group. You must be facing the biggest and scariest uncertainty. Spend a big chunk of your time explaining where you’re heading and why. Otherwise people go astray.
Don’t be afraid to ask for help. Don’t be afraid to ask junior people for help. They may lack experience but they’re smart and super motivated to help you.
Face the uncertainty
Imagine the uncertainty was a wild beast. The bigger the uncertainty, the bigger and scarier the beast. If you face the uncertainty having size of a bear, people behind you must deal with a little bit less uncertainty, maybe having size of a wolf. Your job is to transform bear-sized uncertainty into multiple wolf-sized uncertainties and hand them over to less experienced people to tame.
There’re many pitfalls I often see in teams:
- More senior people try to swallow big uncertainties as a whole. They don’t split it and deal with it by themselves. They hide the scary face of this uncertainty from team members. Doesn’t work long-term because such people burn out from overload. The rest of the team stagnates because they don’t have hard tasks to train on. Good people leave.
- More senior people split the uncertainty, but resulting uncertainties are too small. People deal with cats and never see bears. Again, the team stagnates because they don’t have hard tasks to train on.
- More senior people throw the uncertainty down ‘as is’. Sometimes they even inflate it by attaching their emotions or stating a wrong problem. Rarely works, it’s very risky. You can get an epic shot or epic fail.
Every team is unique. Understand what’s the appropriate level of uncertainty for tasks in your team.
Hint: the more strategically you think, the more uncertainty you will find and see. Read on strategy; there are many good books.
Consistently make good decisions
Don’t lie. Don’t hide information. Make data-driven decisions as often as possible. Study cognitive biases. This knowledge allows to override reflexes leading to bad decisions.
Sometimes you’re going to be completely alone. Nobody in the whole world can understand your problem but you need to make a decision. Be okay with that, work on your self-esteem.
Keep the project running
Don’t let the project stagnate. Keep it running. Do whatever it needs. Sometimes it needs very strange things. Implement features. Advertise and sell it. Create little side projects helping the main project. Make research, draw diagrams and make a presentation. Improve documentation. Make tools more pleasant to use. Talk to customers. Fix ancient bugs. There’re always things to do.