13 traits of operational excellence

Ideas are cheap, execution is what matters

Execution is where companies succeed or fail. No company will survive for long, and certainly won’t scale, if they can’t figure out how to efficiently run their business. And yet, we find that many software companies recognize the importance of improving execution, but have a hard time figuring out how to do it.

Part of the issue is cultural. In manufacturing, for example, no one denies the competitive advantage of operational excellence. The Toyota Way is a well-known example. But software engineers and even managers tend to cringe at “software as manufacturing” metaphors. While it’s certainly true that building software isn’t the same thing as mass-producing physical stuff, that doesn’t mean operations aren’t important in software. Operational excellence is a big edge to have in software, just like it is in manufacturing.

This raises an important question: how do you distinguish a software company that is operationally excellent? We’ve found that excellent software organizations are those that are constantly improving their people and their process. There are 13 key characteristics these organizations have:

People

13. Engineers with T-shaped skills

A T-shaped skill set is broad (the top of the T) and deep in one aspect (the vertical bar of the T). Often we see companies that have a collection of specialists (people with deep technical expertise) but little in the way of broad, collective skills among employees. This leads to two big problems:

• Staff efficiency: T-shaped teams are adaptable and they can pivot quickly. Breadth of skills means team members are productive even outside their deep-expertise area.
• Interfaces: Building good interfaces between components requires an understanding of the big picture. A team of all-specialists can often fail at the end of a project: the system integration and last mile phase of projects where everyone says “their part” of the solution works, but the system doesn’t work as a whole. This causes operational inefficiency or even failure.

12. A systematic process for hiring

Hiring is the most important decision companies make but shockingly, comparatively few companies have a rigorous set of principles and processes to do it. The interview phase is particularly ad-hoc in many companies, with interviewers getting little to no training in how to do that job properly and in a manner consistent with the company’s needs.

11. Clear training plans and expectations for new-hires

An engineer’s first 3 months at a company are critical. This is where you stand the most chance of setting up new hires for success. Most companies start a new software hire on a small project in a random part of the codebase to “get their feet wet”. This causes cargo cult programming, and doesn’t work nearly as well as a systematic syllabus that teaches them the big picture (the flat part of the T) as well as the deep skills and knowledge (the vertical part) needed to operate efficiently. The goal is efficiency and productivity over years, not weeks.

Finally, something that few companies think about: a new hire’s first impressions can be extremely valuable. New hires can quickly spot things that look “wrong” in the company, things that the rest of the employees can’t see by virtue of habit. This is a gold mine of potential feedback that’s seldom exploited.

10. Training for technical managers

It’s commonplace in technology to see engineers become managers with little or no training. Typically in engineering management, highly productive systems thinkers get quickly promoted to leadership positions but they’re given little specific management training. Operationally great companies, on the other hand, have tailored training for their technical managers.

Process

9. Reliable schedules with expressions of uncertainty

If you can’t produce a reliable schedule you will inevitably fail. Compared to other industries, software program management is remarkably unsophisticated. For example, most engineers and program managers aren’t accustomed to including confidence intervals and other basic uncertainty estimations in their schedules. In the agile scrum world, for example, there is a myth that development conflicts with fixed dates and hence dates don’t matter. Schedules do matter, and ignoring the issue doesn’t make it go away.

8. Continuous integration, continuous testing, regression testing

Companies that integrate and test early and often have a competitive advantage. It allows them to avoid “big-bang” integrations that often occur at the last phase of projects. Early and frequent testing ultimately helps keep technical debt levels low. If you don’t have an always-releasable mainline then you are simply deferring integration and test costs, probably until the worst possible time: your customer release date.

7. Business intelligence tools to manage operations

A software operation generates reams of data. Schedules, source control data, bug data, test results, etc. Well-run companies are using business intelligence software (Tableau or PowerBI, to name two) to manage and inspect this data. Aggregating and presenting the right business intelligence data enables informed decision making.

6. Budgets aligned to business needs and principles for planning

Budgeting is a powerful concept that is underutilized by software companies. A budget is fundamentally a statement of priorities, and budgeting engineering time is a way of expressing those priorities in a transparent way. Ask yourself: how do your engineers know which projects and activities to prioritize? If the answer isn’t clear then that’s an opportunity to use budgeting as a guide to technical decision-making.

5. Design and code reviews

When done well, design and code reviews are an opportunity to find defects early and therefore fix them cheaply. When done wrong, these reviews become bureaucratic exercises. For example, if two components of a system are highly interdependent, the easy management solution might be to enforce broad code reviews of both components for every small change. This quickly creates scale and agility problems. The best companies don’t use design and code reviews to band-aid deep system or team structural problems, they use them as a tactical tool to keep defect costs down.

4. Expressing their technical product’s value and maintenance cost in dollars

Normalizing all decisions to dollars is a powerful decision-making technique, as we outlined here.

3. A list of principles that drive decision-making

Do your managers make ad-hoc decisions, or ones based on previously established principles? Managers tend to think of principles as C-suite-level statements (“don’t be evil”), but they’re much more than that. Having consistent principles at all levels of management makes for a well run company.

2. A systematic means of making both simple and complicated decisions

If you have budgets and principles, many decisions become easy, even trivial. Here’s an analogy from real-life: having a system of laws allows for most infractions of the law to be easily decided. Only a small percentage of legal infractions actually go to trial (at the federal level, the fraction is only 10%). Ask yourself, are your highly paid managers devoting their time to resolving the toughest cases? Or are they bogged down making trivial decisions that would be automatic with clearer budgets and principles?

1. Dedication to continuous improvement

Above all, the best run companies are dedicated to continuous improvement. The word “dedicated” is more than a platitude: there has to be a process. “Running the company” is not only the responsibility of the COO and CEO, it’s everyone’s. The best companies execute better today than they executed 3 months ago, and they know what it’ll take to get better in the next 3 months.

Conclusion

Making great software is a unique endeavor. It is both the art of creating something new and the rigor of manufacturing a robust product. Above all, operational greatness is achieved when an organization simply commits to getting better. You probably already have a “can do” culture when it comes to creating a better product. Let’s apply that same mindset to creating a better organization! Learn more at our companion blog post.