When I tell new people I do tech advisory for my day job at parties, a question that often pops up is: why this or that service is so crappy. Why have we yet to figure out how to build working services?

Often, people seem to expect the reason to be technological. That there is some hidden magick that is so hard to pull off that we constantly fail at it. And while there is a technical part to the answer, blaming the tech is more of a cozy excuse than the real reason. We expect technology to be complicated, so it is natural to make mistakes using it.

We’ve had good, stable, and easy-to-use technology to build quality services since the 90s. We’ve had (and still have) tens of such technologies. There is nothing complicated, technology-wise, involved in the case.

The real reasons are much simpler but more challenging to admit.

Building quality things takes effort and focus. It takes people and work. And when we can’t pay for the work, we erroneously think there has to be a way to cheat with technology.

As a more practical example, it can take at least a 2-3-person team to build and maintain a website for a mid-sized organization. A reasonable window size estimate for a decent site is to have a five-person team for the build and half of that for the operational phase of the site. In a five-year investment plan, the cost for just having the site can rake up to 2m€ or more — even if we use the best existing products and avoid custom code.

At the same time, a tech-savvy entrepreneur can spin up a full-featured - if a bit flimsy - web presence in a couple of weeks without any help from engineers or designers.

That’s the first challenge: how do you explain and understand the vast gap between a small-scale working solution and a medium-scale quality solution? And to identify where the first option is enough or the second is needed.

Assuming we have survived the first challenge and been able to fund and recruit a team to build the site, it’s too easy to walk into the second trap: losing focus.

Engineers and designers start to shine when they can focus on a single project. They become people who can pull off technical marvels like rabbits from a proverbial hat. It is deceptively easy for a manager to think of these people as rainmakers. Able to solve any tech-related issue, from integrations to customer authentication architecture.

It takes a lot from the team to say no to the extracurricular activities, especially if they come from the top. The team will face times when there is less work in the backlog, and it’s easy to think we’ll do it once as we happen to have some extra time.

The extra time creates an additional risk of losing focus, too. If the team seems idle for over a few days, someone will ask if they could take ownership of another site or app. To make us more “efficient”. Such “efficiency” rarely, if never, creates effectiveness.

That’s the second challenge: forgetting why teams perform in the first place: clarity of focus, trust, and autonomy — often squandering the quality of services in the name of optics.

How would I go about solving these issues? These problems are more leadership problems than technological or organizational. It’s far more vital to understand why and how we are doing things - than trying to solve which stack or tool we use to do them.

What I’d consider is:

1. Do we have a common understanding of the goals for the site or app we are building?
2. Can we map those to business metrics?
3. Are the goals and metrics understandable to management and the team responsible for the service?
4. Are we committed to the approach?

And if not — to any of the questions — are we able, and willing, to kill our darlings?