_ Blog / Management

The Dangers of Scaling Development Processes Before They’re Defined

by Adam Henshall
/ August 23, 2018
Scaling development processes

Building processes for your business is a vital part of promoting quality and consistency.

We all know this already.

Processes help us determine the best ways to do things and then make sure we repeat that approach again and again and again. This makes it easier to achieve success, find problems in current approaches, and to add new people to your teams.

Having clearly defined and well-documented processes means the training and onboarding of new developers don’t need to be so micromanaged and can bring fresh developers up to the point of creating value for the business even faster.

But when is a team ready to add new members? When and how do we add people into this process in a way they can contribute? 

This all comes down to process design and its essential collaborative and critical nature.

In this article, we’ll look at:

  • The dangers of scaling processes
  • How to create the right processes
  • And how to scale those processes well

How to Scale Your Engineering Team


Dangers Of Scaling

One of the fundamental challenges a company or team may face when scaling is that it’s harder to change processes once they’re big.

By big, I mean three things:

  1. The process itself is complicated: There are loads of steps and details that cover a broad scope of work.
  2. The number of process users is high: If you want to change a process that loads of people use, you need their buy-in and you need to make sure they understand the new process and can follow it easily.
  3. The process is embedded within the organization: Processes do not exist independently of other activities or other areas of operations. You may use a specific CRM which the process is tied in to, or perhaps another department is involved in one stage of the process. You may even have a million and one automation set up to optimize the efficiency of the old existing process.

When compared to a small organization or a startup, processes for large companies are very difficult to overhaul. Iterations may not be too tough, but drastic changes present very real challenges. 


If you begin to scale with poor processes in place, you’ll cause your future self some serious headaches.

Plus, running your business in an optimized way will make you more money.

Simple as that. It can be worth taking that extra bit of time to craft structures and systems that allow you to do your best work, and allow you to grow well, in order to boost your revenue.

When I led a software development team, running projects for external clients, I made some terrible mistakes along this line.

I had a few small projects and some more long-term projects that were allocated only a few hours a week for maintenance and emergencies.

At the same time, these small projects were growing my team’s portfolio and we were lucky to have a few interesting jobs over a short period. Our entire process of selling ourselves suddenly changed.

Because of the nature of our recent clients and the kind of work we had done for them, we suddenly found ourselves competing in a different segment of the market.

It seemed everyone wanted to work with us.

This was our brief golden age. With so many big money contracts on the table, we got greedy and started to take on work we weren’t sure we could handle.

The reason we weren’t sure is that we didn’t have properly defined processes in place. We could estimate hours for a basic job, but we hadn’t analyzed previous work to gauge an average figure for how accurate our estimations were. We also hadn’t standardized review practices even though we told ourselves we were running an efficient Scrum methodology.

From being a successful small studio, we took on a range of new clients, and everything went wrong.

We couldn’t keep up with the demand.

Once one small thing went wrong, it turned into delays on other projects and then a pile up of jobs with no one taking responsibility.

Our desire to scale to make more money undermined our ability to make more money. We did it because the opportunity presented itself, not because we were really ready for it. 

It was the disaster of failed processes that led me to Process Street, to understand and learn to overcome my past failings. 


Right Way To Scale

The philosophy we have at Process Street was summed up nicely by Close CEO Steli Efti in a recent webinar.

His approach was that you should look at a process the way you would look at a product.

You start with some designs, maybe a prototype or an alpha version, and then you build your MVP.

You then work with your MVP; using it and seeing how it could be improved - what’s necessary and what’s not? 

Taking the same approach you might use for your agile development, you can build processes that have the right first principles and are then able to be validated and tested.

This iterative philosophy will lead you eventually to creating the process that you’ll scale with. 


First, build a process that works.

It can be super simple.

One common way to do this is to simply document the steps you’re undertaking when you complete a task. Write down a kind of bullet-point list of the 10 or so steps required. 

From here you can look at the scope of the process you’ve documented. Is it right that this is one process, or should it be split up into two separate processes? Should there be any next steps included in the process?

You could note down how you run your meetings:

Or the steps to do a pull request:

Once you have this initial process outline, you can follow it each time you come to complete the task. As you follow the process, you might realize there are added steps that are important to add in. Or you might notice that one of the steps could be completed in different ways - so you clarify the particular way it should be done.

If you and your team are interacting with the process and recording your notes when you feel it is important, then you’ll have a process ready to be improved.

These process improvements should take on board the input from the whole team and iterative changes should be made.

However, it is important to also track your KPIs or other measures of how the process is performing. In treating the process like an MVP, you should validate the process as you would look to validate any product against the market or available research.

This validation attempt should not be a one-off event.

Continuous improvement (kaizen) should mean repeatedly testing and monitoring the performance of all areas of the processes and outcomes.

It’s one thing to make iterative changes to a process as you develop it, but it is another to assume that each of those changes will be an improvement.

You need to know you’re making the right calls.


How To Scale

When you feel you’ve validated your process, you’ll want to begin scaling.

But hold your horses a little. A validated process suggests:

  • You’re using the right approach
  • You’re able to improve output via improving the process
  • The team members are comfortable using the process

It doesn’t suggest that the process itself is ready to scale. There are three further things to consider before you look to scale this process: 

  1. Choose the right software for your process management
  2. Make the process detailed and actionable
  3. Automate areas of the process to save the user time

  If you want to take process management seriously, you should look to invest in specialist software to assist your attempts. Process Street is one of those options and I recommend you give it a try.

A process management software should be geared for the end user as much as, or more than, the administrator or manager who is looking to run the team. Improving the quality of the output is why we’re all here.

I’m going to link you to a whole load of premade processes which you can take, edit, and add into your operations.

I’ll give you the super short run down of how these work:

The processes below are templates that you run as single instance checklists; these can be tracked and you can see what has been completed and by whom.

When you make your processes, whether you adapt the ones below or begin from scratch, you can have short checklists for quick tasks, or long checklists with bells and whistles involving multiple different people—whatever set up you feel works best for the use cases important to your team.

And there is good reason to have complexity and depth.

Before you look to scale a process, it’s important to spell out each step within the process in detail so that it can’t be misunderstood.

My suggestion is to put the actionable elements of a process at the top of each task - or in the most visible place depending on the software you’ve chosen. Then you can put a detailed text description beneath. This way, the first few times someone does the task, they have a detailed guide. When they know what they’re doing and don’t need the guide anymore, it’s not in the way.

Having detail in your processes reduces the amount of time you have to spend onboarding new staff. It allows them to partly train themselves without too much risk of them doing something wrong.

These detailed processes will result in your new hires contributing to the project much quicker than they would if they were training for longer - an activity that normally stops them or their trainer from getting work done.

You can take a quick look at some of our internal processes at Process Street below. These were processes that originally had high error margins so we put in extra time into making them stronger. 

We decided to make them public to show people what we consider to be best practice, and how the idea of best practice changes depending on the process you need to design.

Here are two of our processes for you to look through. You can see the overview of tasks and then click into each task to see what kind of information and actionable elements we include inside each.



If you’re hungry for more, feel free to check out our internal processes.

And, seeing as we’re feeling super generous, here are some more templates that we’ve developed that may or may not interest you, depending on your day-to-day work:





I’ve talked a lot about adding to the process and making it bigger with more steps, more actionable elements, and more detail, but I don’t advise you to go creating war and peace for your staff.

People often shy away from making a process that is too big because they feel it will be intimidating to staff or it will hurt process adherence more than it helps.

These points are all true.

But I would argue size is not the most important feature. Sometimes, tasks are complicated and require complex instructions.

The real kicker is whether or not the process saves the process user time.

“If you can reduce the amount of admin that a rep has to do to complete that same process, they’re much more likely to adopt it and keep using it.” - Vinay Patankar

The same is true in every environment that processes are employed in.

It brings us back to one of the earliest points: treat your process like a product 

The same way a consumer should want to use a product and gain value from a product, so too should a process user want to use the process.

If you can build automations within process templates so that running the process and following the steps, for example, automatically updates Jira, delegates a task to a colleague, or automatically generates a report document, then your employees will love you.

You can bring automations into your business through third party tools like Zapier or make use of inbuilt automations in the platforms you already use.

Now that your process works for the company, make the process work for the team.

Once you’ve done that, you’ll have a streamlined working process that cuts waste and is easy to follow.

Now, you’re ready to scale.