Dear technical lead

I don’t know how you got your promotion, but I hope you’re a little scared. If you’re not, there’s a good chance that your arrogance will be your downfall.

If you got the job because you want what’s best for the team and the project, then congratulations and welcome to your new challenge.

Your job is still to produce the best product you can, but your toolkit has expanded. It’s no longer just about the code you write, it’s about helping the team produce the best product. It’s about developing processes, building a framework for everyone to work in, whether technical, social, procedural, ethical, anything that’s required.

You’re not doing it alone. You need a good relationship with your PM, your product owner, whatever role your company has.

Relationships are key to your new role. One-to-many when discussing the strategy for the project to the team, and one-to-one discussions with the developers and the stakeholders. Those relationships are the key to your expanding toolkit.

Learn about your team, what are their motivators, strengths and weaknesses. Give them autonomy to work, but be aware of what choices walk the trade-off between upskilling the team and delivering the best product sooner, because upskilling the team helps you deliver vNext, so your horizon has to be beyond this sprint.

Be a mentor.

Be decisive, even if others disagree. And stand by your decision until a better one emerges.

The next project you work on is likely to be the best learning experience you’ve ever had. Enjoy the opportunity. Seek and take advice.

Listen.

You got this.

Advertisement

Sometimes the greatest challenge of leadership is making your boss understand what you do all day

Everyone loves a maverick. The one who bends the rules, who gets the job done. Who leaves fireworks in his wake (it’s always a man) and doesn’t mind breaking a few chickens to make an omelette. The people who rescue the projects in a tailspin, who shout loud and carry a big stick.

What happens to the projects without fireworks? The sysadmins that don’t have to explain why they got breached? The project managers who don’t have to explain why they went over budget? The developers who aren’t in the office past midnight fixing bugs? The people who aren’t visible because they fix the problems before they become visible?

I grew up watching Formula 1 with my dad, in the era of Senna and Mansell. Senna was fiery, pushed the car to the limits, exciting to watch. Mansell was controlled, steady, hitting the right line, and easing the car in as if it was on rails. Senna looked like the hardest worker, but Mansell broke his run of world championships.

If you’re competent, if you get the job done, then people believe that your job must be easy. It’s not easy to beat a triple world champion. Sometimes you need to anchor your achievements in advance, so people understand the challenge in hindsight, especially if you are marginalized in the workforce such that your achievements are minimised.

The Difficulty Anchor

Hey underrepresented folks in technical roles! Performance review season is upon us. I want to take a few moments to remind you about some practical tips that can help you be evaluated more fairly in this and future seasons.

— Mekka *My Mask Protects You* Okereke (@mekkaokereke) August 9, 2018

It’s even harder once you move into any management role, success is due to your team (and be damn proud of that success), but failure falls squarely on your shoulders. If you don’t have a strong sense of your own self worth, it can hollow you out, and leave you with nothing but a thick skin.

Take on extra responsibilities, be the consistency for the team when the powers above you are a maelstrom of confusion and musical chairs. And nothing happens.

Remove obstacles and no-one sees them.

Anchor your team’s success. Quiet, dependable successes make everyone on the team happy : no drama, no overtime. But it can be hard to show the work behind the scenes that makes it look so smooth.

It’s not just a dev problem, a good sys admin is invisible, designers struggle to prove their worth (How to Prove Your Design’s Value – Hack Design
https://hackdesign.org/lessons/57-how-to-prove-your-design-s-value?utm_source=newsletter&utm_medium=email&utm_campaign=howtoproveyourdesignsvalue ).

Market yourself. I know you hate sales and marketing, you’re happy to leave it to others, but you need to give yourself the confidence to be proud of your achievements and make sure people understand what you did. Share it with your boss and your peers (you’ll need some recognition when it comes to your appraisal). Promoting yourself is not someone else’s job. Practice it. Embrace it. Be proud.

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

As a team lead …

As a team lead you need to know your team. You need to understand people. You don’t need to second guess them, you don’t need to micromanage them, but know what motivates them. Know what they need to perform at their best.

What tools do they covet? What routines matter? Do they need precision? Do they value gym time? Do they aspire to learn?

Understand their 6 month and their 5 year plan and help them achieve it. Make sure they know the team 6 month and 5 year plan and where they fit into it, and where that fits in the company plan.

Value them, and ensure they feel valued. Listen. Give them the grace to accept that which they cannot change but be sure they know you’d change it if you could.

Change what you can. Make their lives easier. Help them aspire to your job, even if they may fear the conflicts you protect them from. Keep your head whilst those about you are losing theirs.

Be the best team you can be. Discover the greatness in everyone. Play to strengths to see them through weaknesses. Move people. Change their roles. Find your gardeners and your innovators and Train them to replace you, because for certain times they will need to. Do not become vain or bitter for always there will be greater or lesser persons than yourself.

Let go. Trust them. Trust yourself. Let them do their job so you can do yours.

But lead, don’t follow. Have strong opinions, weakly held when a better way presents itself.

Let data guide you but not be your master. Don’t trust your gut.

Don’t be a stranger and make a full commitment to your team.

And make sure everyone knows the standards.

The importance of confidence

Have you ever been given a project to deliver and thought you can’t do it? That you don’t know enough, that the deadlines are too tight?

Ever felt like panicking?

Have you been on that team, and somehow still delivered, with absolute pride in what you’ve delivered, bar a few teething issues?

As a leader, to inspire your team, you need to exude confidence. Confidence in the outcomes, and in the team. You don’t deny problems or paper them over. Hiding is a sign of weakness. But the team needs confidence to deliver and they get that from you.

If you’re not confident, don’t fake it. Revise the outcomes to a scope you’re confident in. Narrow your horizon. Get answers to your doubts, and support to conquer them. When times are tough, it’s your job to set the right expectations that the team can believe in, and deliver on. It’s your job to find a clear path through the chaos. Or it’s your job to help them pick up the pieces and move on.

These are the tests of your leadership. If the team can weather the crisis, if it can keep it’s collective head whilst all about are losing theirs, then you have earned the right to be a leader.

Be confident. But be authentic.

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

Capability and Motivation

Sure, I could do it, but why bother?

Every so often we hear stories of genius children. A levels at 3, IQ off the scale, mastered 7 languages before they were potty trained. You’ve seen those stories. But when I was a kid, the story that struck with me was about what happened when they grew up.

One guy in particular had won various competitions and was very smart, and he could do whatever he wanted. Once he grew up, he ran his own bakery. There was a suggestion in the article of how dare he waste his talent like that, as if the job wasn’t worthy, even though he was doing what he wanted.

He was capable of solving big problems, apparently. But having an aptitude for a particular set of skills isn’t enough. If you’re not motivated, you won’t be capable of achieving. Just because you wrote the last set of requirements, or you did that reporting training course doesn’t mean that’s what you want to do for the next 5 years. It’s not just an interview question. If what you’re doing now doesn’t get you to where you want to be in 5 years, you aren’t going to be at your best, unless your leader can contextualise it into your longer term goals.

As a leader, it’s not enough to know who has the skills or the aptitude. Foster motivation and Joy.

Agile : The importance of heartbeat

Scrum is built on the weekly/bi-weekly cycle. It provides a structure, a routine. It minimises surprises. You know that the planning session is on a Friday, for the work that starts on Monday, so you can get things on order on Wednesday.

It lets you see what’s coming.

It’s not about process, it’s about expectation. The more you can plan, the less you have to think about. You know when it’s coming and you can line things up in advance.

Have a heartbeat. Know what happens on a Monday, even if you don’t know yet what you’ll achieve.

Becoming a technical lead

A new year has arrived, and maybe now you think it’s time to take on a new challenge. You want to become a technical lead, or maybe you can see that your project needs one and no-one else wants it. You’re apprehensive, and unsure you’re ready. It’s OK. Everyone is an imposter.

Set yourself some stretch goals, something that seems just out of your reach. Throwing yourself in at the deep end is good practice, because you might ask your team to do it too, so you’ll be able to use your experience to help. You’d be wise to have a mentor at this point, to make sure you’re not being too ambitious, because you do want some early successes to give you the confidence you’re going to need later on.

I’ll assume you have the technical knowledge, so think about the things that set you apart, now you’re a leader. You have to guide the team to the goal, and make sure there’s a common purpose, and a team culture to follow. That’s all down to you. You have to know your team, and their strengths. You need a strategy to deal with disagreements. Read Peopleware: Productive Projects and Teams and understand that people are not interchangeable components, despite what your high-level plans might fool you into thinking. You are an individual now, your team are individuals too.

Ask questions of your peers and the community to understand what technical leadership means to them.

Learn from those who’ve done it before, and have offered up their wisdom. One of my colleagues is writing about his learning path as he goes, and there’s a lot of great information about keeping the bigger picture fresh, and understanding your team : Mike Childs – blog posts on leadership. But don’t forget to look after yourself too, as Patrick Kua explains : 5 Tips for Being an Effective Tech Lead | ThoughtWorks

Good luck on your new challenge, wherever you are.

Handling disagreements as a team

Following my code review post, I added some more thoughts regarding code reviews, but there was one comment that I wanted to come back to later:

“Social aspect: How do we handle disagreements? As a team.” – peitor

There are a number of aspects to successfully dealing with disagreements, some of which are about mitigation and avoiding the problem in advance, and others about how you deal with the problem once the disagreement has started to grow, after all, it’s hard to avoid the vim vs emacs, “that’s not RESTful”, brace placement, or other developer arguments.

Collective Ownership

The first key to avoiding unnecessary disagreements is to leave your ego at the door, because teams full of egos will fight each other to be seen. As Peopleware: Productive Projects and Teams so elegantly describes, any situation that asks developers to compete against each other, whether under performance review,or by dividing functional teams geographically, will inevitably lead to conflict and a blame culture. If you are all on the same team, with the same goal, it’s in everyone’s interest to resolve disagreements before they become conflicts.

Constructive Criticism

One of my colleagues has been writing a series on becoming a technical lead, it’s all worth a read, but his latest post, about constructive criticism, is particularly relevant to this discussion.

Constructive Criticism is a reality of doing code reviews, it’s arguably the whole point of doing them, but make sure that you are able to articulate clearly what you expected in a friendly manner, a Blame Culture is bad.

This doesn’t just apply to code reviews, but that’s an important example of where code is judged. Firstly, constructive criticism should be about the behaviour or the outcome, rather than the person (although even at that level, it’s wise to avoid abusive language if you want to avoid alienating your team, just ask Linux Torvalds), and secondly it should offer practical, achievable improvements, so that the person receiving them can use them as an opportunity to improve.

Lone Wolf

There are 2 main categories for individuals who have a detrimental effect on the team. One is the black hole who needs additional support or encouragement and sucks time away from the rest of the team, and any work they produce is marginal. They might be just a poor team player, or a square peg in a round hole (maybe they’d be great in another job on the team or in the company), but they breed resentment in the rest of the team having to compensate.

As a leader, you either need to find a way to help the person to improve and fit into the role they are doing, via mentoring, training or other means; or you need to find a role they are better suited to, by looking at other tasks that need doing.

If you can’t do either of these things, you will need to make the tough decision to get that person off your team so that the rest of the team become more productive and do not degenerate into dysfunction.

Rockstar

The other key individual threat to team coherence is the rockstar developer. The one who plays by their own rules, and always knows best. Unlike the black hole, they get the job done, but they often do so at the expense of the team.

Key traits of Rockstar code is code that doesn’t fit the rest of the team, code that is too clever for its own good, and therefore much harder to test and debug.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

• Brian Kernighan

Just like the black hole, the rockstar developer causes addition work for the rest of the team, but often leaves behind code that the rest of the team don’t understand in order to be able to refactor it. This resentment can be seen by the rockstar developer as jealousy, as their non-stick ego prevents them from taking responsibility for dysfunctions in the team, and it is clear, particularly to those outside the team, that the individual is achieving results (indeed, the rockstar often makes it very clear).

A rockstar does have many of the qualities needed to be a good developer, so long as they can be convinced to simplify and work with the team rather than steamrolling past. Unlike black holes, they are probably doing the right tasks, but need help to understand their impact on the rest of the team and any problems that result from their code, as they may have trouble accepting it.

Duelling banjos

Sometimes, there are individuals that work well with the rest of the team but not each other. Sometimes this can be caused by jealousy or resentment, particularly if one was recently promoted or given extra responsibility when they were previously equal, or one of them is more likely to have their ideas accepted by the team.

The slighted individual in this scenario needs support from the other individual and the rest of the team to accept the situation, and build resilience so they can move on, and, where appropriate, a clear explanation for why the differential occurs.

Hopefully these disagreements are on the ideas rather than the individuals, because when things get personal, it gets a lot harder for people to back away from a disagreement. However, the technology world is notorious for bug fights over little things.

Which text editor do you use? (whichever one you like, so long as you can set the format to the project coding standards)

Where do you put the opening braces? (for Javascript, always use K&R style, on the same line, for everything else, whatever the project says)

If you’re fighting over something that doesn’t really matter, ask yourself why, and if you can just agree to disagree, and accept that you’re not going to convert everyone to Dvorak.

If you see others on your team fighting, look out for Logical Fallacies that can drag the argument down into personal attacks, or unproductive sniping rather than a stimulating argument on improving the code. Be prepared to step in and separate the individuals. Give them a chance to cool down and reset, or space to think, talk and reflect.

Red eyed monster

The tired, stressed team are far more likely to argue and those arguments are more likely to get personal. Don’t overwork. Find your work-life balance.

You

You are a member of the team. Exhibit the behaviour you want to see.