Do Less To Achieve More

Do Less To Achieve More

The key to finding the right answers is to ask the right questions

This is a story of a division in a tech company that decided that they needed to grow their team size to improve their productivity. And that too when the rest of the company was tightening the belt to save jobs. This need for growth was accompanied by the request for new office space with larger work spaces that had modern facilities, large café. better computers and networking infrastructure for 250 new engineers.

A $4 million investment plan was prepared and submitted that included a new 250 seat building on a 5 year lease.

The plan for the new building included larger work spaces big cafe with indoor sports, new computers any many other gadgets. However, the proposal was rejected as the company could not afford large investments when their share price was at all time low. The team management was asked to find other ways to improve their productivity


The reason for the request for additional hires, and thus a new building was that the customers were finding bugs in software solutions sold by this division. The bugs in the software are a common thing, but It is very damning for the quality control division to miss them and for the customer to find them.  The division was doing a root cause analysis to find out the reasons why QC was failing on this product. The root cause they found was that their software developers are overloaded and they are not able to spend enough time to write good codes. Hence the request to hire more software engineers, more testers and quality controllers and the size ballooned to 250 new employees

 While the tech company was trying to address the symptoms through fixes to the infrastructure and culture, they were neglecting to look at other parts of the system and how they all interacted together.

The simple solution: Gaps in the workflow

But looking at it from the science of workflow, it was quickly established that the answer is not in hiring more engineers. In fact, the problem is not with engineers or facilities or technology

The true problem that the workflow was not aligned and the key performance indicators for different teams were driving conflicting behaviours with the engineers.  The collaboration order was wrong between the teams and there was no mechanism to monitor the problem.

Using the science of the workflow, the whole problem was solved by optimising the workflow and aligning the KPIs across the teams. The workflow was optimised by reducing work in progress for the software developers; getting them to collaborate with technical integrators early and then creating a space and infrastructure  that supported their new workflow.

The result was a decrease in bug rate by 25% in 3 months. And they achieved that without hiring a single new engineer (in fact they had to reduce the workload of the existing engineers) and retrofitting their existing space to enable collaboration by spending a meagre US$350K