I've been freelance for three years now, and I admit it: I haven't had a very cohesive plan. I've been reactive, saing Yes to all the things and going where the wind blows me. Since then, I've been doing a whole series of exercises designed to help me decide what I should be focusing on - based on my strengths and previous successes. I've also been telling people this process was "nearly finished" for flippin' ages now. And that when it was finished, I would present the results to anyone who was interested. Then I realised it was never really going to be finished. So some time during the week after next (the week beginning Mon 9th June 2025), I'm going to give a high level summary of what I've been up to and what conclusions I've reached so far. 2. It'll give you a chance to vote on the date / time of the session. My plan is for the session to last an hour and a half, but I'm going to book out a two-hour time slot to leave room for general chat for the last half hour. |
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....
Oh no! You’ve been given a new team to lead, and they’re working on this horrible legacy code base that everyone hates! I can't make sense of this code... 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....