I have a lot to learn.
This is one of the thoughts that is in the forefront of my mind more often than I’d like to admit! I’m still a relatively young developer, particularly for someone in a position of technical leadership, and (in recent weeks especially) I often suffer from the worry that I should know more. I feel like I’m not developing fast enough, or able to contribute to every discussion with the perfect clarity befitting of a technical lead.
This is a ridiculous notion of course. No one knows everything all the time. Everyone is learning and while you can be honest with yourself about the fact that you do want to improve, you have to allow yourself to not feel like you have to have all the answers. Because there will always be a more talented developer than you, and a lot of times you might have them on your team!
A while ago I watched a talk by Clare Sudbery, where she discussed how she dealt with being in a position where she didn’t always have all the answers for her senior technical staff. The talk is linked below.
I really enjoyed this talk and it resonated with me a lot. I’m fortunate to work with some very knowledeable people and there are often times where I just don’t have the understanding I’d need to advise or make suggestions based off my technical expertise. As a Technical Lead, it’s easy to feel like you should have all those answers. And that can be pretty daunting. Especially when you think about just how much there is to know. The thing that Clare points out is that that’s okay!
It is not your job to know all the answers to every question that could come up. Your job as a technical lead is to bring together a group of people with varying technical ability and try to funnel that into a constructive form. You want to hire talented people who have technical knowledge! That’s a benefit to your team. And then you want to work to empower that team, with knowledge and strategies that help the team share in the expertise they have. Clare goes into various strategies for teaching and building the skills of these developers. But, sometimes, you’re going to be the one who is going to be confused, and it is important that you are open about that confusion. Because it gives other people in your team tacit permission to open up when they’re confused, which creates opportunities for your team to grow.
So what do you do when you’re faced with a situation where senior technical staff are presenting problems and solutions that you don’t feel confident evaluating?
Ask the people involved to slow down and take the time to break it into pieces. My favourite phrase for doing this is something like “Walk me through that” or “Bring me with you“. I often find myself saying these phrases in meetings, while pair programming, or just in catch ups with my team. I really like these expressions (or any similar sentiment) because they’re a way to ask your co-workers to take a step back and realize that there may need to be a deeper explanation given. It doesn’t put any blame on anyone, for not explaining things well enough, or for not making sense or anything like that. It’s just an honest admission that, for whatever reason, I’m not on the same page as someone else.
It’s a well known concept that, as you become more experienced with any skill, you internalize the basics and those actions that used to take deliberate practice and effort, just become a feeling which you act on. This is what allows athletes to make split second decisions between a huge number of techniques, and also allows creative experts to make up entirely new things on the spot that seem to fit the moment perfectly. But because of this, you often find that experienced practicitioners of a skill find it very hard to break down, in the moment, why they chose to do the thing they did. They just do it. I’ve found the same thing with talented developers I’ve worked with. They’ll often answer a question by tackling the bit that they’re wrestling with, without really considering that other people haven’t gotten to that point yet. A lot of the time, this isn’t done with any malice, or even an understanding that it’s happened. It’s just that the answer was clear to them so they skipped the step. It’s important to be mindful that this could be what’s going on, and to not get frustrated with people.
It’s usually a blessing in disguise! As soon as you recognize that, that means there’s an answer to a question in the room and you can help everyone around you get to it. Even if you, as the technical lead, understand the same thing as your experienced developer, this is a great opportunity to say something like “Walk me through that”. In my experience, even if you are on the same page (and I’m often not!), there will be at least one or two people who would appreciate being brought up to speed but feel like they’d just be getting in the way of they said anything. Getting those knowledgable people to take a step back and bring people along can be a great way to help the team move forward together. It can also be a great way to challenge people, without creating a hostile environment. Earnestly asking someone to bring you to where their head is at, even when there’s frustration in the room, can be a fantastic way to convey that you’re honestly trying to work towards a consensus, and push things forward in the best way possible.
So the next time you find yourself in a situation, for whatever reason, where you are missing something, maybe give “walk me through that” a try.
I’d love to hear thoughts, phrases, and techniques on dealing with the moments where you don’t feel like the expert. How do you feel when it happens to you? Feel free to drop me a comment or message me, I’d love to hear from you!