5 Things I've learned as a Development Team Lead
1. Make work agreements
Working agreements might be difficult to set up - but they’re very important. I’ve learnt it helps to talk over a difficult situation with the team, and to create an agreement around it. Agreements provide two things: clarity and safety.
A situation I’ve experienced: the organization dictates that the development team should be available to support other teams. When no further agreements are made, a guideline like this invokes uncertainty for both parties: an outsider might wonder “is it OK to ask this developer for help now?”, while the developer might wonder “Will I get to working on my assigned work today?”. The guideline also invokes insecurity: an outsider might think “How do I let the developer know this is urgent?”, while the developer struggles with letting said colleague know “Now is a really bad time, can we do this later?”. In short: exactly when are developers available for providing support, and how can we prevent them from being disturbed too often?
A working agreement could help here. In the provided example, we agreed that developers are only available for questions in the afternoon. This resulted in clarity: an outsider knows “it’s the afternoon now, so I get to ask for help”, while the developer knows “it’s morning, so I get to work undisturbed”. It also resulted in security: an outsider feels “ok to ask for help in the afternoon”, and a developer knows “it’s ok for me to ask my colleague to come back in the afternoon”. Win-win.
2. Always evaluate
Whether it’s a conflict situation, a high-priority bug fix or a successfully finished project - looking back on what happened is healthy. In all cases it’s a good thing to look back on what went well and what could’ve gone better. Worst case a couple of valueable lessons are learned, and best case everyone experiences pride and a higher self-esteem.
A thing to note here is to make sure you only start evaluating when you’re actually done. I like improving processes, so I’m inclined to adjust the ongoing process to make it work better. This is risky, because adjusting an ongoing process will have more impact than expected - team members might not be familiar with the new way of working, deadlines might not be met, or new expectations might arise that aren’t met. By evaluating post-execution you ensure a) the process is not disturbed, and b) you’re adjusting the process as a team, instead of improvising solo.
3. Believe in good intentions
Your work will get very tiring very quickly when you’re expecting a hidden agenda in every sentence. It’s not that you might not get bamboozled - you probably will, and it’ll probably hurt - but it shouldn’t stop you from expecting people to be “good” by default.
I’m not saying you shouldn’t be careful. You definitely do not want to make business agreements solely on looking someone in their big blue eyes. But you do want to be forgiving. People make mistakes, forget to pay that invoice or to call you back. And usually, there’s a story there about why it happened. Treat people like humans. That being said, if someone repeatedly abuses your friendliness, cut all cords - even if they’re your best employee or your top customer. Mutual trust goes both ways.
4. Be grateful
Gratitude keeps you humble. When you’re saying “thanks” you’re aknowledging that someone helped you out - even on a small thing like getting you and your client coffee while you’re in a meeting. A grateful attitude shifts your focus from “I” to “we”. In that regard, gratitude is an essential ingredient of a team.
And what’s even better is that gratitude is contagious. One person with an attitude of gratitude can positively impact a whole team. Because people respond positively when they’re shown gratitude. Spirits will rise. People will adopt. Happiness ensued.
5. Only work on your top priorities
Planning is easy when there’s no pressure. Pressure, however, is almost always inevitable: your team has made a commitment, but other work challenges its priority. Your team might’ve committed to delivering a feature for the majority of the customers, for example, but one high-priority customer calls to see if your team could spend a couple of days on that one custom built feature from a couple of years ago. Or support engineers find the previous feature your team has worked on is still a bit wonky in some situations.
It’s situations like this where priority should be leading. Focus is essential for developers to perform their best work. You can’t do everything at once and maintain quality, time, and budget standards; so the first thing to do is to cut the cord on what the priorities are. Make the call if you’re allowed to, or escalate the situation and get the priorities clear. Is the interruption prioritized over your scheduled work, or not? Make the call with those involved, commit to it, and communicate the decision to all parties involved. You. Can’t. Do. Everything. At. Once.