Replacing 55 engineers with 4

A number of years ago I was hired at a public company as the VP of Engineering. The relatively new CEO had expertise in company turnarounds, though less specifically in software companies. The dev team was ~80 engineers. The majority, 55, were working on the legacy product.

After 2 weeks meeting everyone and getting an understanding of the situation I had my initial assessment.? Presenting to my new CEO that he could reduce those 55 engineers to just 4 and still deliver the same product value. This “cash cow” product could deliver the funding needed to drive the new market initiatives the company had planned. 51 super smart engineers could be repurposed to future developments and deliver some value where it was much needed.

Bold talk from the new guy and sounding, perhaps, too good to be true.

This was the situation. The product the engineers were working on was very mature.? Customers wanted stability and known bugs fixed. That was all they wanted, they didn’t want new features.? The engineering team was organized in two parts: new development and maintenance.? An organization approach that even IBM outlawed back in the 80s :)??

So there were 51 engineers creating new features that no customer wanted and 4 fixing bugs in the existing product.? The bug metrics were impressively sad.

• > 3000 bugs open against the product
• 200 rated P0 (P0 means drop everything and fix this) some were even coming round to their 2nd year anniversary.

An aside - the use of P0 is always a big red flag that something is wrong with the process. And planning that starts with P0 is just insane, don’t get me started :)? The subject for another post perhaps..

This was a classic case of not understanding the customer and continuing to operate the way they always had. 4 engineers were delivering what the customers wanted. 51 were developing features and generating more bugs in the process.

Engineering efficiency here had nothing to do with Lines of Code written or any of the other 20-30 metrics associated with engineering efficiency. The engineers could hit all the LOC or Checkins/week or code complexity metrics out of the park and still not be adding value. Why? Simply because they were not working on the right problems.??

The point of this story of course is that if your engineers are not working on customer value it does not matter how efficiently they churn out code.

p.s. My vindication came about 6 months later when this part of the business was sold off to a private investment company.? As part of the deal they took just a handful of engineers and other domain experts.

#team?#engineeringefficiency?#efficiency?#management?#people?#future?#engineeringmanager #softwareengineering