During my career as an engineering manager, I encountered a class of problems that I like to call “the button problems.”

These three classes of problems demonstrate the types of pain that software teams experience when operating in the dark.

They are real-world examples that we use internally as product design touchstones, and they’re collectively referred to as “the button problems”.

I suspect some of them will feel familiar to you as well.

The Mood Button

Years ago, when I was managing a software team, we were told to build what you might call an imperial feature. Our team was handed a ticket directly from the CEO, but the only information given in the requirements were the instructions: “Build a mood button in the app.”

In absence of further detail, this is a ludicrous requirement. After spending some time asking for more detail on requirements multiple times, we were told to just “figure it out”.

One of our engineers took a run at it and, predictably, when it was delivered we were informed that we had failed. Over the course of the next several months, we took 4 runs at this feature before it was eventually killed.

The total of this cost must have been somewhere around $87k, but we had no real way to express that in terms the rest of the business could understand. I wished we had an objective way to communicate to the rest of the business — “You allocated nearly $100k for an 7-word requirement. Perhaps there’s a better way?”

What’s particularly frustrating about this sort of thing, is that it ends up being cast as a failure of engineering to deliver.

It’s maddening. And it’s the type of thing that data can solve for.

The Green Button

Now, consider another class of problem.

This time the ticket reads, “Please make all the buttons in the app green.”

In reality, this ticket is actually fine. You might expect it after a rebrand or redesign, and whoever initiated the work probably priced it at a half a day at most.

But what happens sometimes is that an engineer will pick this up and say, “well the right way to do this is to refactor the entire templating engine while I’m in here.”

Note that they’re doing this because they’re a good engineer — this is an engineer taking initiative.

The problem comes when you now have this massive delta between business priorities and engineering effort: while it’s totally worth it to have green buttons at the cost of a half day, the green buttons have not been approved at the cost of 3 weeks.

Ultimately this sort of thing is up to the manager to catch and solve for — part of what management does is make sure that engineering’s efforts line up with business objectives.

But what we hear over and over is that this is very hard without data.

Typically these issues are not caught until a sprint retrospective where the sunk cost is already enormous. The tools we have traditionally used do not provide enough fidelity to allow managers to pattern match and detect these sorts of things.

Data solves for this.

The ‘Go Faster’ Button

The final ‘button problem’ is the one where Engineering interfaces with upper management.

Without data you only have one button: the ‘go faster’ button.

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, because 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.”

One often overlooked point is that, without data, engineering is at a bit of a disadvantage with the rest of the organization. Budget allocation in the corporate world is inherently zero-sum, and when the sales and marketing departments walk into those conversations with a set of industry-standard KPIs it gives them a serious advantage.

A marketer can say, “We need more budget to cut our lead response time in half.”

Sales can say, “Give us $500k to cut 10% off of our deal cycle time.”

Today, engineering has a hard time saying anything other than “we need more people,” and the inability to frame this request as a business objective to the C-suite means that Engineering departments often get shortchanged on resources that could make a big difference.

All of these problems are costly, damaging inside and outside of engineering… and solvable.

The overall message here is that data is really about turning 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’ve built GitPrime.

And we’d be happy to show you how you can finally turn the lights on and become the engineering leader you’ve always wanted to be with data.