The Iceberg Problem

When you look at software through the lens of its UI, you're seeing roughly 10% of what's actually there, the tip of the iceberg sitting above the waterline. The other 90%? That's submerged. That's your data models, your API contracts, your state management, your error handling, your performance optimisation, your security boundaries, your deployment infrastructure. That's where the actual engineering happens.

But here's the problem: if your organisation can't see below the waterline, it will optimise for what it can see. And what it can see is the UI.

This creates a pathological dynamic where the appearance of progress, visible changes to the interface, becomes the measure of progress itself. Meanwhile, the deep engineering work that makes software actually work becomes invisible, undervalued, and eventually, undone.

I want to propose something uncomfortable: forcing development to march in lockstep with a top-down product/UX process is an anti-pattern that masks organisational immaturity.

It's not that product and UX don't have critical roles, they absolutely do. But when they're positioned as the drivers of the development process, with engineering as the execution arm, you've revealed something fundamental: your organisation doesn't understand what building software actually entails.

Here's an Example: "Just Add a Filter"

Let me show you what this looks like in practice.

UX comes to the team with a request: "Users want to filter the transaction list by date range. Should be simple. Just add two date pickers at the top of the page."

From the UI perspective, this looks trivial. Maybe it's a 2-point story. Add a component, wire it up, done.

But here's what actually needs to happen if you're doing it right:

Data Layer: Your current query fetches all transactions for display. Now you need to parameterise it. Do you add database indexes? What's the performance impact when users select wide date ranges? What if someone picks a range spanning three years?

API Layer: Do you add query parameters to the existing endpoint, or create a new one? How do you handle pagination now that the result set is dynamic? What about caching? Does your current cache strategy even work anymore?

State Management: The filter state needs to live somewhere. Does it persist across sessions? Does it affect the URL so filters are shareable? What happens when someone applies a filter, navigates to a detail page, and comes back? Do you preserve their filter state?

Edge Cases: What's the maximum date range allowed? What happens if someone picks dates before your system existed? How do you communicate to the user when their filter returns zero results versus when it's still loading? What about timezone handling?

Performance: Do you need to debounce the filter application? What if the filtered query takes 8 seconds? Do you need a loading state? Do you need to add backend query optimisation?

Testing: How do you test all the edge cases? Do you need new integration tests? What about the performance characteristics under load?

This isn't a 2-point story. It's a 13-point story, minimum. And if you have senior engineers who understand the system, they'll push back and explain why.

Two Paths to Failure

But here's where the dysfunction kicks in. Because the organisation can only see the UI, and because keeping developers "busy" is the primary goal, you end up on one of two paths:

Path 1: The Hack

A mediocre developer (or a good developer under pressure to "just ship it") says "yeah, no problem" and implements client-side filtering on whatever data is already loaded. It "works" in the demo. UX is happy. Product checks the box. It ships.

Then it breaks in production when someone has 10,000 transactions and their browser grinds to a halt. Or it silently gives wrong results because it's only filtering the current page of data. Now you've got technical debt that's actually harder to fix than if you'd done it right the first time, because you have users depending on the broken behaviour.

But here's the insidious part: by the time the problems surface, the team has moved on. There are ten other "simple" UI requests in flight. No one has time to go back and fix the foundation. The iceberg below the waterline is quietly cracking apart.

Path 2: The Fiddle Factory

Let's say you actually do build it properly. You put in the work, handle the edge cases, optimise the queries. It's solid engineering.

But in a UI-first culture, that's not where it ends. UX keeps iterating on what they can see:

"Actually, can we make the date picker appear as a dropdown instead of a modal?"

"Can we add preset options like 'Last 30 days' and 'Last quarter'?"

"Can the calendar highlight weekends in a different colour?"

"What if we made the filter bar collapsible to save space?"

Each of these seems small. Each burns senior engineering time. None of them move the actual business goal forward. You're spending your most valuable resource, the attention and expertise of your senior engineers, optimising the 10% of the iceberg that's visible, while the 90% below the waterline gets no love.

The work that actually matters (improving query performance, refactoring the data model, building robust error handling) never happens because it's invisible in a demo.

Why This Reveals Immaturity

Here's what makes this an indicator of organisational immaturity: a mature organisation understands that the UI is the output of engineering work, not the input.

When your process puts UX at the front, handing off "requirements" to engineering for execution, you're treating software development as a translation problem. You're saying: "We'll figure out what it should look like, and engineering will make it happen." This only works if the hard part of software is the implementation, not the design.

But that's not how software works. The hard part is the design: the architectural decisions, the data modelling, the performance trade-offs, the error handling strategies. The UI is just the surface where those decisions become visible.

When the appearance of progress becomes the measure of progress, you optimise for the wrong things. You celebrate shipping the date picker while ignoring that it takes 8 seconds to return results. You demo the collapsible filter bar while the database is buckling under unindexed queries. You pat yourselves on the back for "user-centred design" while your most senior engineers burn out fiddling with CSS.

The invisible work, the work below the waterline, doesn't get valued because it doesn't show up in sprint reviews. And in an immature organisation, if it doesn't show up in a demo, it doesn't exist.

What Maturity Looks Like

A mature organisation flips this model.

Product owns the strategic goal: "We need to help users understand their spending patterns over time." That's the why and the what.

Engineering owns the decomposition: "To do that well, we need to rebuild our transaction query layer, add proper indexing, implement caching, and then expose filtering in the UI. That's a month of work, and here's why."

UX is a partner in that process, not the driver of it. They help validate that the solution solves the user problem, but they don't dictate the implementation sequence.

This requires trust. It requires a Product Leader who can sit with ambiguity and say, "I don't know exactly what the UI will look like yet, but I trust you to figure that out." It requires Engineering Leaders who can clearly articulate why the invisible work matters and what the trade-offs are.

And it requires the whole organisation to understand that if you can only see the tip of the iceberg, you have no business steering the ship.

---

This is Part 2 of a three-part series. Read Part 1: Stop Feeding the Feature Factory to understand why keeping developers "busy" is optimising for the wrong constraint. In Part 3, we'll explore how to operate pragmatically when you're stuck in an immature organisation but still want to build good software.