Continuous Improvement with Data-Driven Engineering

Years from now, I suspect we will look back at 2018 as the year where a tectonic shift happened in software engineering.

At this point, it’s almost trite to say that every company is a technology company, regardless of the product or service it provides. Today no company can make, deliver or market its product efficiently without software.

Yet software engineering has long been a discipline where instinct and ‘gut feelings’ have been the only guides for leading improvement efforts. Meanwhile, anecdotes and narrative accounts have been the best that engineering leaders have had to communicate about successes and struggles with the rest of the organization.

Engineering built the tools and instrumentation that helped the rest of the enterprise. Now engineering is experiencing the transformation that has already benefitted Sales, Marketing, Customer Success, Finance, and the rest of the enterprise.

Today, gut feelings are being replaced with data, and the market leaders in every category will continue to be data-driven. Now it’s Engineering’s turn.

How we got here

Over the last couple decades, our industry has seen a lot of change in how we run engineering teams. In the early days, most projects used a Waterfall process.

Waterfall had certain advantages, including:

• Strong Requirements
• Solid mandate — deep enterprise buy-in from C-suite
• Came to work every day knowing what you were working on
• Ability to invest in doing things right

Waterfall’s Disadvantages

• Difficult to course correct mid-project
• Due to long development cycles and the fast pace of change in software, by the time the project shipped, the market might have shifted sufficiently that the original requirements were no longer relevant
• 18-month dev cycle makes it hard to be flexible with a quickly changing industry

Enter Agile

In the early 2000s, the Agile transformation began taking hold. With concepts borrowed from manufacturing, it helped create tighter feedback loops and solved a number of problems. Agile:

• Addressed waterfall’s rigid and slow cadence
• For the first time engineering had a voice in the conversation of what they were building
• Requirements are no longer driven 100% by “the suits”

Although Agile wasn’t uniquely meaningful for software engineering, it helped moved our industry forward. Agile has been pretty well adopted by now, but there’s this still a big problem space that it doesn’t solve for, largely because it’s out of scope for Agile…

Agile never really contemplated some of the things that come with data-driven management.

So why is data important?

The absence of data means there’s generally no level of granularity in conversations about team success — everything is binary. A feature either shipped on time or it didn’t. We made the release target or we didn’t.

This kind of binary conversation is really unfortunate.

The lack of visibility creates cascading problems throughout the workflow. And it means that what engineering teams oftentimes receive as feedback is “go faster please.” And ‘go faster’ is not a particularly useful or actionable piece of feedback.

Data lets us segment success into different areas and say meaningful things like, “our engineering team is a powerhouse in this one area, but this other area is holding us back.”

Data turns the lights on

We believe that Engineering — and particularly engineering management — has been doing a heroic job for a very long time essentially managing by feel, while most other industries are benefitting from rich, highly relevant data.

Adding data to the conversation gives management the tools they need to better advocate for their team, and to showcase team success over time.

That’s why we’re building GitPrime. We’re committed to provide meaningful feedback loops for engineering leadership and finally turn the lights on with data.