DEV Community

loading...
Cover image for 80/20 Rituals: Happy Toolsday! πŸ› 

80/20 Rituals: Happy Toolsday! πŸ› 

Lee Nattress
・5 min read

I've heard both sides of the argument for the 80/20 rule with respect to software delivery. It's simple to explain, you see as developers we are supposed to work 100% of the time on the thing we are told to work on. This is often spread over several tasks, like meetings, planning, meetings, development, meetings, and meetings.

80/20 tells us that if we work 80% on the thing we are told to and 20% on something to benefit the company or project in some way. This is basically one day per 5-day working week.

To some managers and companies, this is abhorrent. It means the client gets only 80% of the developer's time but is paying for all of it, or even worse, the company pays 20% 😱

Managers in such an environment, who don't understand the power of letting creative people off the leash will often cite that developers will 'bunk off' or do nothing in their 20.

And some of them might.

In this case, you've hired for ability and not ability+culture. Developers uninvested in the outcomes of projects will not give you their all, they won't be bothered if you succeed as a business.

Emotional investment comes in these forms:

  • 1️⃣ Relationships with others
  • 2️⃣ Ideas and ideologies
  • 3️⃣ Membership of groups
  • 4️⃣ Pleasures such as listening to music and hobbies
  • 5️⃣ Development of ourselves and our careers

We need to do something with developers to give them as much and as many of these things as possible, so that their motivation is in alignment with your goals, as a manager.

There are many ways to use the 80/20 rule but this is the one I like the most:

Make anything you want, but do it as a team and have it benefit the company in some way

The idea here is that people form into two or more person teams and work together, one day a week.

Here is a visual example, in case this talk of tooling is confusing:

Alt Text

Let's assume you are in charge of a team of miners who are digging for diamonds deep underground. Every day they produce value, at a steady rate, with their pickaxes, removing the rock from the rockface and uncovering diamonds πŸ’Ž. Your research has shown that there are a lot of diamonds still in there, far into the rock. Your boss is happy because you bring them diamonds but always wants a higher quota.

In the mine, there is a room full of machinery, pipes, motors, batteries, drill heads. Just sitting there.

You don't have time to assemble them. If you stop, the boss won't is happy. They will want to know why he gets fewer diamonds, every day the miners aren't mining.

The miners tell you daily that there are better ways of doing things, and that digging by hand is inefficient. One day you take the risk and tell them to spend 20% of their time building a drilling machine. They get to work, as a team.

Initially, productivity drops. Or does it? It turns out that they weren't working 100% of the time anyway! A lot of it was meetings and having their time zapped away by all manner of interruptions.

Streamlining their time and protecting it when they are working means that the drop in productivity is not hurt much, you were just overly worried.

After a week or so, the first innovation comes from the effort. An agile response, an MVP: A sharper pickaxe.

Then a scanner to find diamonds quicker.

Then a mechanical drilling platform that can rip the diamonds out of the rock face πŸ’ŽπŸ’ŽπŸ’ŽπŸ’Ž!

Alt Text

Guess what happened to your productivity? and guess how happy your boss is? Now, guess how much your miners are invested in the project, now that they have had input and their tools and ideas are helping you produce output?

For the sake of comedy, let's call it TOOLSDAY. Let's have it on TUESDAY πŸ˜…

As a team leader, lead, or manager, it's your job to protect the developers in this time, and encourage them to build. Their projects are not for you to judge, meddle with, or change the projects and ideas they have.

Your job is to:

  • 1️⃣ Get your team working together to solve a common goal, helping and teaching each other.
  • 2️⃣ Generate new ideas, frameworks, and tools that they agree on together and can own that thing.
  • 3️⃣ Be part of something other than the team they may work with every day.
  • 4️⃣ Have an opportunity to bring their existing skills from a development-related hobby they have or something they don't use every day because it's not part of your company's toolchain.
  • 5️⃣ Learn new things, explore new and scary things, and conquer them with help always present.

See what we did there? πŸ˜‰

Here are some examples of things I've seen made in the past on Toolsday and if they benefitted the company (hint: They did, massively).

  • Tools that automatically generate code scaffolding, saving time, and automating mundane tasks.
  • Libraries that abstract away complex functions allowing complex features to be used in a simpler way, de-skilling the requirements from this point forward.
  • Re-usable component libraries so that you don't need to write the same boilerplate forms or widgets ever again.
  • 'Ted talk' type days and events to directly impart learnings and give people confidence.
  • Frameworks that speed up delivery by guiding design and development, making consistency the word of the day, and allowing things like time estimations and confidence to increase.
  • Testing templates that can be applied again and again to stop re-inventing the wheel and bring teams to one place to design.
  • Developer blogs that let teams talk about the why and say something bigger than the monotone sorrow of commit messages, to bring humanity into your projects and let people explain their decisions.
  • Internal projects that help other parts of the company directly, like tracking expenses, support requests, or anything in the company that takes people a lot of time and effort. This has a direct benefit.

Really this is about being brave and taking a risk. This is what happens when people become emotionally invested:

  • Increase in loyalty (to other people, projects, brands, employers, etc.)
  • Spending time on the subject.
  • Seeking to persuade others to also become invested.

Think it's worth it?

Get started:

  • Have your creatives and devs look at all the parts of the business and find a problem or inefficiency (it can be their own job)
  • Come up with a way to solve it
  • Find somebody to help
  • Start today (As long as today is Tuesday)

Discussion (0)