My favourite discussion from the Technical Lead discussion was defining a successful technical lead, to which one of the first answers was that no-one will need you. If you are good at what you do, you can optimise yourself out of a job, or at least free yourself up to go on holiday once in a while, without anyone needing to interrupt you. Get better at getting away. This is something close to my heart, having had 3 breaks in a row interrupted due to having to make decisions for a team late on various Saturdays.
If you want the same, first you need to get in the proper holiday mindset – where you do not get any work email on your phone. If work really want you to read email on your phone, they’ll pay for it.
Once you have the mindset though, there’s a number of things you need to do to make it happen, so you can avoid webmail and phonecalls and properly relax. Thinking about your break is also a good way to build a resilient team, and a resilient project. Here’s a few things that have worked for me.
Don’t build software, build teams.
Start with the team. You won’t always have a choice of the team, but if you want to defer your job to the team, at least temporarily, you will need people in the team that you can trust, and that the rest of the team will respect, so that they can keep a steady hand. And make sure you debrief them before you go.
Don’t speak, write.
Talking is great for working through problems and sharing knowledge. But people will forget. So write it down, and then talk it through. That way there’s something to refer to in 6 months time, when they, and you, have forgotten what you did and you need to work it out again from first principles.
Automation trumps documentation.
But if you can write it in code, do. People get bored reading documentation, skipping the sections they think they know. Computers don’t know how. And run the automation regularly, so you know it’s up to date. Deploy often from scripts, not documents. Every document runs the risk of papercuts.
Delegate everything, to everyone.
In other words, don’t be the only person on the team who knows how to do something, and don’t let anyone else on the team be that person either.
Own the code, but don’t be the code.
If you practice ego-less programming anyway, this should be easy, but ego-less programming takes a lot of deliberate practice. Be proud of the code you write, but not so proud that you can’t leave it alone for a week or two. If you have build the right team, you know the code will be in as good a condition without you as it would if you were there, bar a nudge or two you can easily resolve when you get back.
Walk off. Don’t look back. If you keep checking in, you’ll send the message that you don’t trust your team, and you run the risk of micromanaging, which means your team will lose some autonomy and be less effective, which then creates a vicious cycle that you will need to get more involved. If you run the project as if you’re not needed, except in an emergency, it will run more smoothly, and you will be able to relax.
From day 1, plan for knowledge transfer, plan for delegation, and plan for everyone’s holidays, and family emergencies, and paternity leave, and for the loss of team members to other projects and companies, plan for a team that will change over time, in the short term and the long term. It’s not a matter of treating people as replaceable parts (see the last point, and trusting your team), but it is a matter of responding to change, and building flexibility in from day 1. I don’t always get it right, but the more successful I am, the better the team works, and the more I can relax.
Trust your team.
Trust them, and let them trust you. And please, please, please, don’t phone them whilst they’re away. Lead by example.