Oh no! You’ve been given a new team to lead, and they’re working on this horrible legacy code base that everyone hates! Nobody enjoys working on this code. Team members are going through the motions with no interest in what they do, repeating the same terrible patterns and either counting the days to retirement or actively looking for more exciting work elsewhere. Here are three things you can do to make things better, for yourself and for your team: 1. Identify the value being delivered.It might seem like there is none, but this is unlikely to be the case. The code exists for a reason, right? What’s it doing that makes it worthwhile to the rest of the company? 2. 80:20: Find the SMALL thing that can be improved INCREMENTALLY to make a big difference.Get the whole team involved. This can be a fun exercise. Find the SMALLEST thing that will make the BIGGEST difference, then break it down into even smaller steps, and do them. Together. One at a time. 3. Throw something away!There’s got to be at least one thing in there that nobody actually needs. Find it. Throw it away. Then throw a party and celebrate. Want to talk through technical leadership in more detail? Join the workshop!On Fri 4th July '25 in Cornwall in the UK, at 11am, I'll be running a workshop at Agile on the Beach, titled Technical Leaders for Humanity – the helpful card game. Click here for more info. Agile on the Beach countdown: |
Don't miss my next post! Subscribe to my Technical Leadership newsletter and learn a bunch of useful stuff about effective technical leadership.
Would you like to attend a talk about how to counter the fear of not being technical enough, or how we can stop making each other feel stupid, or how to make the most of diversity in the workplace? Or maybe you'd like to immerse yourself in one of my hands-on workshops... about refactoring skills, or about using TDD to wrangle AI coding, or facilitating mob / ensemble programming, or on how to handle the technical in technical leadership? Fancy spending time in Spain, or Berlin, or Paris, or...
What do you do if there's stuff you don't know? Can you ask questions? What questions should you ask? How should you ask those questions? In an earlier post, I addressed the fear of having colleagues with better technical skills than you. I suggested, "Spend time pairing with [those who know more than you]." And I added, "Handled without apology, this exercise will deepen your team members’ respect for you, rather than the other way around." I promised to explain what I meant in another post....
How will you fit through those holes? "I'm worried my current position only works at my current company. I moved up fast because soft skills come naturally for me. I prevent any office politics from affecting my devs, and they have the freedom of implementation at an execution level. But ask me to implement code for multi-threading? I am starting from 0." You are not alone When I'm running workshops with technical leadership, I see concerns like these raised repeatedly. People who started out...