The problem with transparency

Increasing the transparency of business goals will increase the motivation of the engineers.

They will also come up with more creative solutions.

A few years back, I took the lead on a project shielded from the business side. The dev team received a feature list and built in isolation.

They were slow, unmotivated, and focused on the technology.

The reason? They didn’t fully grasp the ‘why’ behind the project, the context and purpose that could have significantly increased their output.

So I went to the basics.

Why are we building this? What’s the business case for it? Do we still want it if it takes two years and costs 1,5m EUR?

We had some painful conversations. And in the end, we canceled the project.

It did not make business sense.

To avoid these situations, have the business conversations early.

What outcome are we trying to achieve? What is the ROI of what we’re building? How can we cut scope but still deliver on value?

My approach here is to explain the business case to the engineers. If I can’t do that, we must do more research before touching any code.

It sounds basic. And yet, I’ve seen projects in big companies that were happy to spend a few million on a project without a clear return.

What’s the problem with transparency? It leads to difficult conversations— and sometimes, canceled projects.

But in the end, it’s still worth the trouble because it can save you from disaster.

P.S. Did you ever had to work on a project with unclear business outcomes? Let me know how you’ve navigated that.

P.P.S. Welcome to the new members. We’re slowly growing, and I got some great initial feedback. I’m excited to hear your feedback! If you’re curious about older posts. you can find them on https://daily.pelc.cc. 🙏🏻

Best regards,

Taj