I’m a lazy team lead. I like to ‘free up’ as much time as possible at work. I run away from ‘busy work’ like it’s on fire. Here are four rules of thumb I use to decrease the amount of time I spend doing some management stuff so I have time to think and work on more valuable things.
Note: There are no shortcuts for knowing what’s happening with each of your team members and their work and then giving them appropriate, timely feedback or help and encouragement where necessary. That’s the job!
Also note: Some of these things are not suitable at certain times and maybe not for folks that are brand new to their roles.
I’d love to know if there are any similar tips from other leaders out there!
1. The 50% allocation rule
Treat the work streams entering your team as only one task per two developers. This way you don’t have to micromanage people and time for specific tasks.
I don’t mean literally have developers pair everyday on specific code or anything. Just that at a high level, don’t assign a project to just one developer if at all possible.
If the work requires one developer and there are no unforeseen issues, and no one is absent for during the work you’ll finish faster (almost always a good thing).
With two developers they will have shared context and can get through code reviews faster than someone without the context. Even for shorter tasks there are always other things to be done than just code the thing. This allocation also gives developers some slack to think and to learn new things.
But in particular now they own their own scheduling so you don’t have to.
Benefits
- You don’t have to spend hours of your time making sure each task is resourced. Let the team of two do that themselves.
- You never really have to worry about risks like vacation or sickness blocking the work.
- You get knowledge transfer and better quality code
- You can build amazing rapport.
- The team members have breathing room for training, learning, cleaning up the code after themselves and reporting.
- Two people actually get through work really quickly once they get going. It’s not much different to two people on separate tasks in parallel.
Dangers
- You may be seen as slow on estimates compared to peers if they aren’t following this pattern. Communicate what you’re doing to the people that care. Remember you still have the same number of people doing the work. You are just setting expectations. And being realistic with scheduling imho.
- You need to have good people because if one of the pair decides not to pull their weight the good person can get frustrated. I believe this is a hiring problem and not a project problem though.
2. Systematize Everything
If an engineer asks you to make a decision on something. Immediately start thinking about how you can systematize the decision.
e.g.
Tester: “We should stop all development to fix bug X” Engineer: “It’s not that critical, Let’s continue. ” Both: “Well team lead, what should we do?”
What do you do?? Well you can make a decision immediately to get the team going again but think about why you have to answer this kind of question?
It is likely that the team is not aligned on what is risky, what is important. You likely need to get alignment on bug severity for your project.
Work with the team to write down the various levels of bug severity using this ambiguous case as an example and identify the appropriate response so next time they can handle it themselves.
Keep adding examples to the documentation if this question occurs again.
As a team lead you should always be actively pulling your team members to the same decision making context (level) as yourself.
In general, as a manager, you should always be trying to systematize yourself out of a job.
Benefits
- You don’t have to keep solving the same issue over and over again
- Improves team independence, self reliance and growth
- More consistent outcomes
- Decision making moves closer to the knowledge
Dangers
- Premature systematization
- Problem unsuitable or system gets too complex
- General failure where blind reliance on a system leads to undesirable outcomes
- Paralysis when there is no system and you’re not around
3. Personal success lists
Most organisations have a review on a regular cadence. The reviewer (manager) is often expected to identify all the awesome things the person did over a specific time period.
Instead you should have the person themselves keep their own list of accomplishments and just copy and paste that in to the annual review.
You can then just comment on their list.
Benefits
- They will inevitably have done awesome work that you completely missed!
- You don’t have to keep a list of accomplishments
- It lets team members with a growth mindset shine
Dangers
- If a team member doesn’t think something is an accomplishment they might not list it! Maybe they didn’t feel like it was “work” or that their personality or culture is different to others on the team. You have consider everything in context of the person.
4. Change the work, not the person
I sometimes get asked for help with a person who is not performing well at some piece of work. I heard this tip from someone a long while ago (but can’t remember who sorry!)…
It’s difficult to change the person. So try to change the work, not the person.
e.g. If someone is struggling with large tasks, can you change the task size. If someone is struggling with a process, can you change the process? If someone struggles in a team can they move to another team?
As a leader you have to ensure you don’t fall victim to the The Fundamental Attribution Error. I use “change the work, not the person” to help me initially consider the environment or processes a person is working in rather than attributing failure to the person.
Benefits
- Work and process is much easier to change
- If you work with the team to fix one of these you might find ways to avoid entire classes of work.
- You are less likely to fall victim to the The Fundamental Attribution Error
Dangers
- That team members will try to game this to avoid work they don’t like :) (Hiring problem imho)
