Stop Buying Nice Presentations Instead of Real Impact

"Can you take a look at our product development? We spend a lot of money and effort, people seem busy, but somehow we are not getting the results we expect."

There can be many reasons for this. Sometimes the architecture is bad. Sometimes the team is struggling with technical debt. Sometimes requirements are unstable, testing is weak, priorities change too often, or the company simply expects more work than the team can realistically deliver.

But a few of my recent engagements showed a different pattern, and I found it slightly frightening. The stakeholders were engaged. The engineers were engaged. People were working their asses off. There was no obvious lack of effort anywhere. And the projects were still struggling.

When I started looking more closely, the problem was not some mysterious disaster hidden deep in the codebase. Large chunks of basic governance simply were not happening.

People were doing work, but the work was not coordinated well enough. Priorities were not always clear. Decisions were made, but their consequences were not really tracked. Feedback existed, but did not necessarily make its way back into decisions. Important risks did not have an obvious owner. There was plenty of activity, but much less control over where all that activity was taking the project.

When I say "governance," I don't mean creating another committee, writing fifty pages of policy, or adding more meetings. I mean very basic things:

• What are we trying to achieve?
• Who decides what is important?
• How do we know whether what we are doing is working?
• How quickly do we find out when it is not?
• Who is responsible for correcting course?

These questions sound almost embarrassingly simple. But if nobody is consistently doing this work, the rest of the organization can be extremely busy while the project still goes nowhere useful.

That was interesting enough.

What surprised me more was what happened when I asked about the person who was supposed to be responsible for this work.

In practice, the person was occupying the position without actually doing a significant part of the job.

And when I asked the people responsible for evaluating that person why this had not been noticed earlier, the answer was often roughly:

"But that is his responsibility. We hired him for it. We pay him to do it."

Well, yes. That is what the job description says. But the existence of a job description does not mean the work is being done. Nobody owes you a result because you gave them a title and started sending them money every two weeks.

And this is where I think companies sometimes create their own problem.

They put a senior person into an important role, pay a serious salary, give that person authority, and then quietly assume that the existence of the role itself means the function is now covered. But It does not. You can hire the wrong person. You can hire a good person who is wrong for this particular problem. You can hire someone who is excellent at one part of the role and weak at another. You can also hire someone who is simply much better at presentations, executive language, and creating confidence than at actually running technology execution.

All of these things happen.

The question therefore should not be only, "How do we make sure we hire the right person?"

You cannot make sure.

A much more useful question is:

• What happens if we are wrong?
• And how will we know early?

This is the part that bothers me in some of the situations I see. Companies sometimes spend enormous effort selecting a senior technology leader, checking references, interviewing candidates, negotiating compensation, and so on. But almost no effort goes into defining how they will know six months later whether the person is actually doing the job well.

You do not need a giant KPI system for this. All you do need some observable evidence.

For product development, I would usually start with a few very simple questions.

Question 1: How long does it take to turn an idea into something running in production?

Not how quickly someone writes the ticket. Not how many story points the team completed. Not whether the sprint looked successful.

How much time passes between deciding that something is worth doing and having something real available to users? If this takes six weeks and starts becoming three months, you probably want to know why.

The number itself will not tell you the answer. It may be architecture. It may be testing. It may be too much work in progress. It may be slow decisions. It may be dependencies between teams.

But at least you know something changed and you have a reason to look.

Question 2: How many problems are stakeholders and users finding?

Again, I would not obsess over one absolute number.

Different systems have different levels of complexity, different user bases, different release frequencies, and very different definitions of what a "problem" is.

What matters is whether you know what is happening.

• Are users finding more issues or fewer?
• Are the same categories of problems repeating?
• Are serious issues being discovered after release that should have been caught earlier?
• Is the situation getting better over time?

If nobody can answer even approximately, then statements like "quality is improving" are mostly opinions.

Question 3: Do we know whether users and stakeholders are actually satisfied?

This is another one that sounds obvious until you start asking for the data.

Many organizations talk constantly about customer value, stakeholder value, user experience, and business alignment.

Then you ask how they actually know whether users or stakeholders are happier with the system than they were six months ago.

Sometimes there is no answer.

Maybe there is anecdotal feedback. Maybe someone spoke to a few users. Maybe a business executive complained in a meeting. Maybe support tickets exist somewhere.

But no one has put the information together.

You do not need an enormous research program here either. Even a simple, consistently collected signal is better than guessing.

Question 4: How do our speed and cost compare with something outside our own organization?

This one is harder, because comparisons are always imperfect.

A regulated financial platform cannot be compared directly with a small ecommerce site. A startup team and a large enterprise have very different constraints.

Still, at some point you need some idea whether your performance is reasonable.

If your team takes nine months to deliver something similar companies usually deliver in two, "but our environment is special" is probably not enough explanation.

The same applies to cost.

Internal improvement is good, but it is possible to improve from terrible to merely bad.

Frameworks such as Evidence-Based Management and DORA give useful starting points for thinking about these questions. I would not copy their metrics mechanically, because the useful set depends very much on the company, the product, and the problem you are trying to solve.

The important part is not having a fashionable dashboard.

The important part is having enough information to notice when reality stops matching the story being told inside the organization.

For example:

• We hired this person to improve delivery. Did delivery actually improve?
• We increased engineering spending by 40%. Did anything important become faster, more reliable, or more valuable?
• We reorganized the department. What changed afterward?
• We invested heavily in quality. Are users finding fewer problems?
• We say stakeholders are happier. Did anybody ask them?

Those are not complicated questions.

But they force the organization to separate activity from results.

There is another reason I like this kind of measurement, and it is not about catching bad managers.

It also protects good ones.

I have seen the opposite situation as well: a technically strong leader is doing sensible work, the team is improving, risks are going down, delivery is becoming more predictable, but the person is not particularly good at executive theater.

From the board's point of view, that can be surprisingly difficult to recognize if nobody has agreed on what improvement should look like.

Then the person with the better presentation can easily appear stronger than the person who is actually improving the machinery.

This is not a good way to select technology leaders.

So yes, hire experienced people. Pay them well. Give them enough authority to actually do the job. Do not micromanage them.

But before you hire the next pleasant guy in a nice shirt who speaks beautifully about technology, spend another hour asking a different set of questions:

• What should become better if this person is actually doing the job well
• How are we going to see it?
• What would tell us that we made a mistake?
• And how soon could we know?

This is also one of the things I do for companies as a part of my RobustAgile consultancy.

I help determine which metrics make sense in their particular situation, how to collect them without creating a reporting circus, and how to use them to understand what is actually happening.

Not abstract metrics because somebody put them into a framework.

Metrics connected to a specific problem, a specific organization, and specific decisions.

Because if you hire someone to steer the ship, it is probably worth checking from time to time whether the ship is actually going where you intended.