4 hacks for lazy team leads

Published on January 10, 2020

Tagged: #management

Follow me on twitter for more posts like this

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)
Darragh ORiordan

Hi! I'm Darragh ORiordan.

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

I also make tools for busy developers. Have you ever spent a week getting your dev environment just right?

My DevShell tooling will save you 30+ hours configuring your dev environment with all the best modern tools. Get it here

https://darraghoriordan.gumroad.com/l/devshell


Read more articles like this one...

List of article summaries

#management

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!

#developer-experience

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

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.

#developer-experience

How to identify a great tech organisation before you join

No one wants to waste time working for an organisation that’s a bad fit. But how do you know a good place from a bad place until you actually work there?

It’s important to spend the same amount of time analysing a potential organisation as they spend analysing you!

During an interview process an organisation has personality testing, resumes, tech testing, behavioural testing, reference checks, bank checks, police checks and more.

If it sounds like a very one-sided process that’s because it is! But there are ways you can bring more balance and here are some important things to research before accepting any engineering job offer.