I read a magnificent book this weekend. A business graphic novel. It was marvelous.

It’s called The Goal and here’s how it applies to software 👇

Click through for source

What _is_ The Goal? 🤔

First you gotta know: What is the goal of your software? The goal of your job? Your goal?

You can’t proceed without answers to these questions. Why are you doing what you’re doing?

You’ve got your quotas and your JIRA tickets and your bug reports and your task management. Your job is to move tickets from one pile to the other. From ToBeDone to Done.

Correct?

Nope.

Your job is to help the company make money. Or achieve social good. Or disrupt the taxi industry and replace it with a different taxi industry. Or to make more movies. Usually it’s to make money.

If you don’t know your goal, you should ask your manager. Their manager. Their manager’s manager … and keep going until you find someone who knows.

When you know why you’re doing what you’re doing, you can know if you’re productive.

Click through for source

Actions that move you and your company and team towards the goal are productive. Actions that don’t, aren’t.

Simple as that.

It’s not about how busy you are. It’s not about how much time you spend at the office. It’s not about how many todo items you tick off the list.

Are you moving towards the goal?

Are you efficient? 🤔

The more efficient you are, the faster you move from the ToBeDone pile to the Done pile.

You often build automations. That’s what software is for. Automating parts of the process.

Automation is always good. It’s faster and more reliable than a person. Eh … sort of.

Click through for source

Automation almost always improves productivity in one part of the system. But does it always improve the whole system? Nope.

Just because one part of the system is faster doesn’t mean the whole system is faster and more efficient. This is often difficult to realize.

You sped up part of the system, but the whole system became slower. Why is that?

A puzzle

Say you’re leading a scout troop on a hike. Who goes in front?

Often it’s the fastest kid. They race ahead and the group spreads out. When the group gets too spread out, you tell the fast kids to stop.

Slow kids catch up and just as they’re excited to get some rest you say Okay let’s go everyone’s here now.

That’s shitty.

You now have a group that’s always spread out. You’re herding cats and making sure everyone’s safe. You barely keep it all under control.

Morale is low.

The fast kids are annoyed because they keep stopping. They self-moderate with distraction. Making others wait while they’re distracted.

The slow kids are exhausted. They never get a break.

Click through for source

Instead, you should take the slowest kid, the bottleneck, and put them in front. The bottleneck sets the pace for the whole group.

Your group stays together. Everyone can keep up with the bottleneck so nobody drags behind. Lighten the bottleneck’s load and make them faster.

Now the whole group moves faster, more efficiently without distraction, and you spend less time managing it all.

👌

The bottleneck sets the pace

Your process is never faster than its slowest part. Also known as Amdahl’s law.

D’oh that’s obvious. Yet we always seem to forget.

When you’re optimizing your code, or your development process, or your company as a whole, are you focusing on the bottleneck or some random part that strikes your fancy?

When you measure productivity and effectiveness, do you focus on your tiny part, or the whole system?

That’s what I thought 😉

YOU can never be more efficient than the whole system.

If you are, you’re just creating overhead. Overhead is expensive. Stop working and go help the bottleneck.

If you’re starved for work, you’re just idling. Idling is expensive. Stop idling and go help the bottleneck.

Click through for source

Remember, time lost on a bottleneck slows everyone down. Your whole company. Do everything you can to make your bottleneck faster.

Click through for source

How to identify the bottleneck?

Bottlenecks come in many shapes, forms, and sizes. They show up in your development process, they happen in your company, they also lurk in your code.

Especially when you move beyond writing code and start designing systems. You’re like a plant manager. Managing systems feeding outputs into other systems’ inputs.

So how do you find a bottleneck?

Easy.

Where is WorkToBeDone piling up? Where does a process keep waiting for its inputs?

The place in between, that’s a bottleneck.

A bottleneck struggles to keep up with its inputs and inventory piles up. Queue sizes grow. Costs skyrocket. You’re paying for too much storage.

A bottleneck struggles to deliver fast enough for later processes to stay busy. You’re running computers and people when they have nothing to do. That’s wasteful.

Slow down 🖐

The solution is to slow down.

Yes that’s right. You gotta slow down.

Why are processes before the bottleneck working at full capacity? There’s no point. You’re just filling the queue.

Instead, have them slow down. Maybe even stop when the queue ahead is too full.

Why are processes after the bottleneck working at full capacity? There’s no point. They’re throttled by output from the bottleneck.

Instead, have them slow down. Maybe even turn off when there’s nothing to do.

Maybe there’s stuff you can move around?

Click through for source

Can you do parts of the process before the bottleneck? Anything that might reduce the queue going into a bottleneck?

Is there other stuff your speedy processes can do? Something to keep productive while they wait for the bottleneck’s queue to clear? Or their own queue to fill up?

Team productivity over personal productivity

Click through for source

Quickest way to apply The Theory of Constraints to your personal life is to look at your team.

Are you the bottleneck? Get help.

Are you delivering features super fast? Stop and go do code reviews. Mentor.

Are you always waiting for things? While you wait, go help. Write test cases, make QA faster, do code reviews, write documentation, look at the backlog …

There’s always something you can do to make your team faster and more efficient. Even if it means sacrificing your personal productivity.

A personal hour lost is three team hours gained. ✌️

5 steps to make anything faster

Click through for source

Follow these five steps to make anything faster. Your code, your team, your company.

Identify the bottleneck, use it fully, slow everything to pace, fix the bottleneck, find the next bottleneck.

Happy hacking, 🤓
~Swizec

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.