Dave Mangot

Dave Mangot

I partner with PE portco CTOs to deliver on the investment thesis by helping them change the culture of their existing org from halting to daily delivery so they can get the race going.

Process is a sign of success

“How do you scale an organization?” “How should we make sure this happens correctly?” “What are the inflection points when growing an organization?” I hear questions like these often. I’ve been part of fast growing startups, enterprise organizations, and even non-profits like Helpful Engineering which began growing by thousands of volunteers, per day!

The best part of these questions is that they are signs that the company is experiencing a problem, a good one, or anticipates experiencing one soon. Not all problems are bad problems (our sales team has too many qualified leads!), but in many cases the correct solution to problems, especially scaling problems, is process.

Just as not all problems are bad, not all process is bad. More often than not, my advice is wait.

When?

Waiting is interesting advice, but wait until when? Here are a few things to consider.

  • We know from Lean manufacturing that very often processes can introduce wait (lean calls this waste) into the system. For this reason, it’s often necessary wait as long as possible to introduce process. In the absence of burdensome processes (like handoffs), people move as quickly as the system will allow. Ever wonder why startups are able to execute so quickly? They have very few barriers, which equals very few wait states which equals less waste in the system and therefore can move very quickly. This is why so many enterprises opt for cross-functional teams. If one doesn’t have to fill out a form and wait (process) but instead can rely on an empowered team member, teams can go as quickly as the system will allow.
  • One advantage of waiting, is that the problem which we are trying to solve will be obvious. There will be no escaping it. If we wait the appropriate amount of time, the parameters that define the problem will be as clear as possible. This is not to suggest waiting until things are on fire, but instead, if we anticipate a problem at 50 engineers, it’s not useful to begin planning the solution at 10. One of the things we learn from Agile is that we should make decisions about things that are temporally proximate, but leave for later those things that are temporally distant. Why? It’s because we have more information about things that will happen soon. If we don’t have to make a decision right now about something in the future, don’t. Make the decision with the most amount of information. The same holds true for introducing process. If we wait until things will soon get uncomfortable, that gives us the opportunity to collect as much information as possible about the situation we are trying to improve, and therefore implement the most appropriate solution to the problem.
  • When implementing the process, one should try and solve the problem that directly addresses the pain being felt. This means, don’t design an elaborate process, instead follow principles from The Lean Startup, and create a Minimum Viable Product, the simplest solution that we can use to gather more information, so that we can learn and improve the process as we collect more information about the problem and solution. Sound familiar?

Guidelines

  1. Whenever possible, aim for self-service solutions. The object of a process is not to create toil, but to enable people to solve problems themselves without having to wait on another human (remember that this waiting is considered waste in Lean). Optimize for speed and autonomy and create a bias towards action.
  2. Create processes for problems you’re having now. Despite our best efforts, humans are terrible at predicting what will happen in the future. This is why most of the software industry has moved away from waterfall development processes. Who predicted a year ago that there was going to be a global pandemic that would massively accelerate digital transformation? How confident are we that engineering will scale from 6 engineers to 80 in six months? This is why Agilists say “Be agile, don’t do agile” which means that it’s not enough to just do the rituals, our organizations need to have the ability to respond appropriately to situations as they arise.
  3. When being agile we don’t have to be wedded to our changes. If we put in a process because sales was overwhelmed with qualified leads and our qualified leads are now a trickle, get rid of that process! We need to respond to the situation at hand, and just as we can respond by implementing process, when that process isn’t relevant anymore we must respond by eliminating waste, handoffs, etc. as the situation warrants.
  4. Your process will not be able to scale linearly, forever, and it doesn’t have to. Put something in place that works now, and adjust. “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” - John Gall
  5. Bear in mind stakeholders when developing a process. If a process is optimized for the benefit of one group at the expense of another, it’s unlikely that process will have a net benefit to the organization.

Examples

  • Many organizations use a ticket system to track work, implement process, etc. It’s important to make this system work well for engineers as they spend the most time there. I’ve seen far too many organizations make Atlassian Jira a tedious chore built as layers of process in the service of “producing the right metrics for management.” This type of process is appealing and deceptive. An old adage asserts: “garbage in, garbage out”. When a company makes the use of Jira too onerous, the engineers will avoid it when possible. It is much easier to figure out how to present data to executives from a rich and detailed data set, than from a sparse data set where people are simply checking whatever boxes they must, as quickly as possible, to get through the process.
  • Many infrastructure teams become overwhelmed by requests once the developers latch on to the latest trends in development like containers, continuous delivery, etc. Often the proposed solution is to create a form that must be filled out for all infrastructure requests. Instead, follow the example of Amazon Web Services (AWS) and create self service solutions that allow the developers to receive new infrastructure with speed, and at the same time, allows the infrastructure teams to ensure that what is created is uniform, labelled appropriately, monitored, and secure.

Speed Kills

Process is important in organizations. It is impossible to scale an organization to hundreds or thousands of participants without it. However, all processes are not created equal. Some processes are onerous, tedious, and deliver little value. Some processes are transparent, empowering and accelerating. Process is a sign of success!

By making decisions with the most information possible, then making deliberate small changes that allow the organization to move forward quickly and safely, we can create startup level speed, with enterprise level power.