Working In A Crisis Is The Easy Part
Recently one of my team asked me how they were doing, and to be fair I think they’ve been doing great. The challenge though is that they started as team leader right about the time that COVID-19 hit. Working for an online supermarket, around March 2020 was definitely challenging, but in some ways it actually made things easier. When there is a fire to put out, it’s easy to know what to do next - you put the fire out! And after that? You put the next fire out!
Certainly, there are challenges for being a team leader during a crisis. Perhaps people in your team are stressed or losing their cool. You might have stakeholders shouting at you to fix things quicker. Maybe you have to take shortcuts that you know lead to technical debt, but that will get things fixed quicker.
Calming people down, and protecting your team are important skills for a team leader. Knowing when to make pragmatic technical decisions is something all developers should know. And recognising when your stakeholders are crying wolf and you can push back on fixing their fire is important. For us, back in March, it was pretty clear that this was a real crisis and we needed to do all we can to help.
Things have moved on since then, and although the world is still suffering, from the perspective of us writing software to help keep people fed, things are pretty normal. The challenge for my new team leader starts now.
With a quieter backlog things become much more uncertain. What is the right thing to work on next? How much time should we spend tackling technical debt? What direction do we want to move in with our architecture? How do you keep your team motivated? All of these are much harder to answer when there isn’t a stakeholder shouting at you to fix something.
The key thing to remember is that quieter times give you more time to think, but that you need to carry your team with you while you do it. Set up meetings to discuss architecture and tech debt, and use them to drive agreement amongst your team about what their priorities for improving your software are. Once you have broad agreement on how you want your software to evolve, it becomes easier to decide what to work on next. Can you deliver this change while also delivering customer features, or do you need to pause, refactor and then delivering customer features will become easier?
When assessing performance it’s important to remember what context you’re working in, and what it would be reasonable to achieve. If things are on fire then putting those fires out is a good achievement, but if things are calm then you should judge yourself against more traditional measures of success, such as the delivery of features, team alignment and the quality of your roadmap.
Comments