4 hacks for lazy team leads

Published on 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!

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.


  • 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.


  • 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.


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.


  • 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


  • 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.


  • 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


  • 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.


  • 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


  • That team members will try to game this to avoid work they don’t like :) (Hiring problem imho)
Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨ https://usemiller.dev/dev-shell

Read more articles like this one...

List of article summaries


Flexible work is here to stay but you should choose an emphasis

Note: This was written in August 2022 and I assume things will change quickly. It will be interesting to look back in a couple of years to see how much of this article is still relevant!

Most tech organisations were forced to change to remote during lockdown but haven’t explicitly changed their office attendance policy.


Hiring engineers in a candidate-driven marketplace

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!


How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.


Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.