Part 1 of the series “Theory of Constraints in software startups”
“We need more people” how often do you hear this argument from your manager?
If only we had more people, maybe a bit more time and money — we’d achieve all the targets we’ve set for ourselves. We’d finish all the projects we have committed to. Our customers would finally get what they were promised… by us.
You see the pattern? Seems like common sense is the price we have to pay to get a job as a manager. I certainly paid it.
“Newly minted manager” by Cristina Amate
After being an engineer at Productive Mobile for two years, I’ve moved into a product role. It felt confusing and messy in the beginning. Too many parties involved, too many projects to juggle. Today, one year later, I feel much more comfortable on the job. I’m far from where I want to be, but maybe principles I used will help you too.
The Big Idea
We don’t use 100% of our human capital and resources. Getting more people/money/time is like pouring more water into a leaky bucket. We should fix the leakage instead.
We can do more useful work with the same resources.
Let’s talk about what is work and where are we pouring it into.
System
We can think of a company, a team or a project as a System. It has a number of actors that interact with each other. It has its inputs and outputs. Turning inputs into outputs is the goal of the system.
Productive Mobile is a B2B software startup. Inside we have Sales, Product and Customer Success departments. And our goal is… to build software?
“Precise blueprint of a Juicero machine“ by Cristina Amate
Kinds of work
At the time I started working as a product owner we had two goals. We wanted to hit two targets with a four-people engineering team.
There was the long-term vision of customers using our product themselves. There was the reality of the day too. All of our clients were dependent on our Customer Success team. In turn, this team was struggling to use our own product to make customers’ enterprise systems mobile.
Because our goals were so distant from each other at the time, any feature we were building was simultaneously useful and a waste. Making our platform more flexible for the Customer Success team also made it less usable for common cases. Adding on-boarding features for new customers would be useless for our internal team. And who was to blame that we are not moving fast enough? Product!
I felt like that was my job to reconcile our goals. To make it work for everyone. It wasn’t. After several months as a PO, I’ve convinced senior management to make a call. There was no obvious right choice, but we made a decision.
We don’t know what’s useful and what’s wasteful work until we know the goal of the system.
Fast forward to today, we have just released a version Customer Success is so eager to use, they couldn’t wait until it gets to production. The time it takes to handle complex use cases dropped from weeks to days, sometimes hours. As a next step, we can now see a clear path to simplifying the platform for customers as well. I’m very proud of what we have achieved.
We did it by focusing on one goal.
Useful work is the work that’s turning inputs into outputs. Wasteful work is everything else.
Gym Memberships Phenomena
To find the goal of the system, we need to look outside of it. Ironic, isn’t it? The goal is defined by what the system interacts with. The purpose of a passenger airplane is not to fly, but to move people from point A to point B. Engineering department is there to make business successful, writing code is a mean, not the end in itself.
Goal has nothing to do with System’s internals. Look for it outside of the System.
A good example of a company with a goal that is well-aligned is LambdaSchool. They train people to become devs. Their goal is not “to teach”, it is to help their customers become professional developers. They only get paid if their client gets a job.
My favorite bad example is any gym here in Berlin. Their target is to sell you a membership. Basically trap you in a contract for a year or more. That’s far from what customers sign up for.
Every Agile Training shop operates in the same way. They sell trainings, workshops, time of their consultants. They sell “gym memberships”. They focus on what’s inside of their system, on things they can control. What they should be focusing on is on results for their customers.
Measurements
Once we know the goal, measurements become easy. These are the metrics we can use for the system as a whole:
- How much useful work does the system perform over a fixed period of time is called throughput of that system;
- How much work is stuck in the system but will be released at some point is inventory or work in progress;
- What are the resources spent to turn inputs into outputs is operating expenses.
Each work center (department, project stage) should only be measured against its contribution to the system’s metrics. If the work it does helps turn system’s inputs into outputs — great! If not — it’s a waste.
“Idea Man” by Cristina Amate
How good a system is performing is determined by how quickly and at what cost it can turn input into output. Actors within a system should never be measured in isolation. What matters is their contribution to system’s performance as a whole.
Here’s a good example of system measurements. I’ve asked Ed Hill, the founder of a consulting firm Synchronous Solutions, how they track success of a project. While reading his reply, think of what could be the goal of a consulting agency, what are they hired for?
Here is Ed’s answer:
“As a first step on every project, I ask the company owner (or the senior person on site) to set measurable targets. Net profits, customer service metrics, lead times, quality performance are typical examples. We also ask them to articulate metrics in areas that are not measurable like chaos levels, employee morale and leadership characteristics of key staff. We work to set a baseline on these metrics as possible. Then we track and document actual performance against those baselines. Success is measured by performance toward all the established targets, not just profits.”
An example of harmful measurements came from Ricardo J. Méndez. He has been a CTO and have founded several companies himself. Here’s what he had to say on the subject:
“In several occasions, in different companies, I’ve run into a situation where the team had to build something because sales assured us, 100%, either that a customer was demanding it or that it was fundamental to close a deal. In those cases, it turned out that they thought it could help, and they lied about it because it improved their chances. In one case, the end client not only wasn’t swayed by the feature, but actively resented it — their internal auditor ordered it rolled back.
That’s wasteful.
The reason a department feels compelled to do these things is because there is zero risk for them and it increases their chance of getting a reward. If sales’ income depends on commissions, but tech is a fixed cost (and hence has fixed income), your departments’ incentives will be misaligned. Misaligned incentives will result in waste.”
In Ricardo’s example, Sales’ contribution is measured in isolation, instead of measuring contribution to the system’s throughput. Possible better metrics could be:
- Net volume of sales for projects that require little to no modification to the product;
- Or better: Net volume of sales for projects that were delivered on time and on budget;
- Or even better: Net volume of sales for projects that hit targets set by the customer.
With metrics like this, Sales will have to collaborate with other departments and with customers. This is what we want. We want success metrics of one department to be directly correlated with success metrics of the organization as a whole.
What’s next?
The most important learning for me during that year in product was that the basic principles of engineering still apply. If a piece of code is not performing well, using a more expensive computer will only take you so far.
We don’t get better results by throwing more people and resources at the problem. What works is going back to basics. Mapping out the system, understanding its goal, its inputs and outputs. Once that’s done we can start searching for ways to improve the system.
But how do we do that? What do we change and how? I’ll talk about it in the next part of the series.
I’d like to thank people that shared their experience and useful insights with me. Their inputs are the foundation of this series. In no particular order these people are: Stefan Willuda, Ricardo J. Méndez, Ed Hill, Adiya Mohr, Conny Petrovic, Goran Ојkić.
Special thanks to Cristina Amate for the illustrations as well as her support and early feedback on the talk and articles.