I'm transitioning out of my current job as Tech Lead at Signavio. One action item that came out of our last retrospective was that I should compile a list of my responsibilities. That does make sense, given that I won't be around come December. However, I don't have a list of recurring activities. So, this blog post isn't necessarily about what any Tech Lead does, but what I as a Tech Lead do.
TL;DR
This time there won't be a TL;DR. If you think there is a shortcut to becoming a good leader, then you've opened the wrong article.
Do not become a bottleneck
I've heard that some people think they need to be involved in everything when they are leaders. I couldn't disagree more! You need to trust your people and let them do their jobs. Otherwise, you'll always be busy, which means you probably will never be productive.
On a high level, I need to be aware of everything that is happening around me.
- What projects are in progress?
- What's up next?
- Is the team blocked in any way?
- Is the infrastructure up and running?
- Do we need to work on any critical updates?
Because I have to make sure that everything runs smoothly, I can't get deeply involved with one topic in particular. Even if I'm working on an essential feature, I cannot wholly neglect all other aspects of my job. The result would be that I will be in a situation where I'm responsible for the most crucial feature, but I'm doing something else. That's not good!
I'm trying1 to avoid this situation by not working on user stories. Well, at least I don't pull them into the "In progress" column2. By doing so, I can still pair program with other developers, but the chances that someone is waiting for me to finish a story are pretty low.
Help others to grow and learn
If you're not helping others become better at what they do, I would not consider you a leader. Unfortunately, I also had to learn that doing so is easier said than done. Here are some mistakes I've made.
Handing out solutions like free candy
When someone asks you a question, your first intention might be to answer it. That's normal. But when you do this, you rob them of an opportunity to learn. Because solely when you get to a solution yourself, and you understand all the steps it took to get there, then you learn something. Otherwise, you might learn to ask me again the next time you face a similar challenge. And that doesn't scale!
I've come up with my own set of rules to solve problems, and I'm now trying to teach them. I'll ask questions like "What did you try already?" or "What do you know? What do you not know?". These questions should help your brain figure out the problem on its own.
If one person needs to learn something everybody can learn something
Pair programming is nice. Mob programming is better!
At first, when we ventured into a new area, the new knowledge was restricted to the one or two people who worked on the first user story. It's better than nothing, but we still needed to do the initial onboarding into the topic a couple of times. This led to different people understanding the problem in different ways and lots of rework. When a new topic is on the horizon, we have a team session upfront to make sure everyone is on the same page and understands the problem. We (usually) also start working on the topic together. This means the whole team works on the first user story. Stuff like this sounds like we're wasting much time, but I'd argue that we're saving much time because there are fewer misunderstandings and rework.
Not being aware of how I'm perceived
Not only do the things you say matter, but also how you say them. I had to learn that sometimes even exhaling too loudly could stress the other person and prevent them from learning anything. What helped me the most was learning about non-violent communication and how I can use it to make people more comfortable around me. It also helped me understand that I need to be clear about my needs because it also does not help if I get frustrated.
Also, do not disguise requests as demands.
Help people make more minor mistakes
Bugs happen. Mistakes happen. However, you can actively help your team reduce the severity of them.
When shit hits the fan, the most important thing to do is to stay calm. It never helps to start rushing work in the middle of a crisis. As soon as the crisis is over, you need to make sure it can't happen again. For that to work out, two things need to happen:
- Everyone needs to understand what happened and why it happened.
- You need to check whether a change to your team's processes would prevent the thing from happening again.
Your job is to make sure both actions are taken. You don't have to do all the explaining or propose adjustments. However, you should be the one who makes sure that these activities are taken care of.
Here is a non-exhaustive list of things our team does (and I blogged about) to avoid large scale defects.
- We do TDD as much as possible,
- we write tests that help us find and fix defects faster,
- we always get to the bottom of problems, and
- we continuously improve how we work.
Make others more productive
I've seen some people interpret this as "make any other person, inside your team, with a technical focus more productive." Unfortunately, that excludes a lot of other people that you might interact with each day. Here are two groups of people you might be excluding even though you shouldn't.
Do you help your product owner?
OK, you can ignore this part if you don't have a product owner (PO).
My team has a great PO. She tries her best to be always approachable and get as much structured feedback as possible from our customers. In the past, she also wrote most of our user stories. The issue is that writing user stories isn't necessarily what she should be doing most of her time. Why? Because she needs to both write the story and then explain it when a developer picks it up. That can be cumbersome.
We've also faced situations where stories were split in a way that makes sense for the end-user but didn't consider our system design. That sometimes left us spending more work on two stories than would have been needed if it would have been only one.
We've talked about this and restructured the process so that developers write stories themselves after we've had a session in which we made sure everyone understands the problem we're trying to solve. Our PO is the facilitator for these sessions. This way, questions are asked and answered in a larger group.
Do you integrate design into the development flow?
Admittedly, I haven't figured this one out yet.
I try to remove hand-offs as much as possible. I find the idea of a hand-off somewhat appalling because it implies that some people can think everything through and then are done. I've never seen this work.
Our designers are doing a great job. However, they are also humans and, therefore, forget things or make mistakes. When they work on a design for two weeks, then hand it over, and an engineer discovers that this will never work they've just wasted a lot of time. I'd love to see that designers and developers collaborate and work on these features together.
But... I haven't found the magic spell to make this work. What I try is to lead by example.
- I try to get our designer involved early in the process,
- I make it clear that nothing is ever set in stone, and we'll always be able to change things, and
- I try to instill a sense of incremental development in designers (I've found that some of them are somewhat resistant to that idea)
By doing the above, I hope that, over time, both designers and developers will treat each other as equals and collaborate more closely.
Reserve some room for self-reflection
Even though I might risk repeating myself, let me say that again: You should not be busy all the time. In your role as Tech Lead, you also need to reserve the room to think and reflect.
I sometimes re-read comments I made on PRs when I had a stressful day. The chances are high that my stress level leaked into my tone while writing3. If others feel bad because I had a bad day, then this sucks. Since I don't want to be that person, I try to correct my wrongs whenever possible.
Also, blogging helped me a lot this year. To write a post, I need to get my thoughts in order first. Sometimes I also need to visualize certain parts of my thought process. That allows others to look into my head, but it also helps me think about the person I'd like to be. I think while writing about goals, processes, and communication, I've also reflected on what I did wrong in the past and would like to do in the future.
This time I'd like to emphasize even more that I appreciate any form of feedback regarding this article. Please reach out to @philgiese with questions, remarks, and ideas to try out when leading development teams.
Footnotes
-
Of course, I work on the occasional user story. There is always an exception to the rule. The most important aspect is that I'm aware of what's going on around me. ↩
-
We're working with Kanban, which means tickets progress through different stages. When someone picks up a ticket to work on it, it will move into the "In progress" column so that everyone sees that work is happening. ↩