January 10, 2020
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!
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.
If an engineer asks you to make a decision on something. Immediately start thinking about how you can systematize the decision.
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.
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.
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.
Hi! I'm Darragh ORiordan.
I live and work in Auckland, New Zealand enjoying the mountains and the ocean.
I build and support happy teams that create high quality software for the web.
Contact me on Twitter!