You Can't Fix It From the Bottom

Parts 1 and 2 of this series diagnosed the problems: the feature factory that optimises for busyness over impact, and the UI-first thinking that reveals organisational immaturity. But here's the reality most of us face: you can't fix organisational maturity from the bottom up.

You don't control whether your company understands what building software actually entails. You don't get to rewrite the org chart or suddenly grant engineering leadership the authority it deserves. You're not going to convince the executive team that visible progress isn't the same as actual progress.

But you can create a functional working model within your sphere of control. You can build good software even in an immature organisation, if you're willing to be pragmatic about how you navigate the constraints.

This is about survival and craft. It's about doing right by the engineering work while playing the political game well enough to keep doing it.

The Bastardised Dual Track That Actually Works

Here's the model I've used successfully: a bastardised version of dual track development that respects both the reality of where power sits and the reality of how software gets built.

The working agreement is simple:

Engineering owns everything below the waterline. We decompose the work. We make the architectural decisions. We sequence the delivery. We build the functional core: the data models, the APIs, the business logic, the performance optimisation. And we build just enough UI to give that work a form.

That UI isn't the final product. It's the integration point. It's the starting point for a real conversation about how the feature should actually look and behave.

UX has final say on everything above the waterline. Once the functional foundation exists, UX owns the refinement. They decide how it looks, how it flows, what the interactions are. Engineering is in service to that vision, but we're now working from a position of technical soundness, not toward it.

This respects the political reality: UX gets credit. Leadership sees the visible progress they crave. Caesar gets his due.

But it also protects the engineering reality: the hard decisions get made by people who understand what's below the waterline. The foundation is solid before we start decorating it.

Why This Works (And Why the Alternative Doesn't)

This model gives UX something they actually want: a working system to refine, not a theoretical spec to debate or a pig to put lipstick on.

I've heard UX people complain for years that they're only brought in at the end, after all the "real decisions" have been made. They want to be included from the beginning. And they're right that being handed a finished implementation and asked to "make it pretty" is an anti-pattern.

But here's the uncomfortable truth: if you don't have the technical chops to understand what's below the waterline, your early involvement doesn't add value: it adds bikeshedding.

You end up in long meetings about whether the filter should be a dropdown or a modal before anyone's even asked whether the database can handle filtered queries efficiently. You debate the perfect onboarding flow before anyone's built the authentication system. You workshop micro-interactions while no one's looking at the data model.

Early UX involvement is fantastic when UX understands enough about the engineering constraints to have an informed conversation. When they can say, "Given that we need to support offline mode, how does that affect the interaction model?" or "If that API call is going to take 3 seconds, we need to rethink the flow entirely."

When they don't have that depth, it's just premature optimisation of the visible layer while the foundation stays unbuilt.

The Working Agreement in Practice

So here's the deal you make, explicitly or implicitly:

"We're going to build the foundation first. We'll give you something that works. It won't be pretty, but it will be real. It will have actual data flowing through actual APIs. You'll be able to click through real flows and see real results. Then you take it and make it great. Your expertise is in the refinement, in making the interaction delightful, in understanding the user's mental model. Our expertise is in making the machine run. Let's respect that boundary."

This isn't ideal. In a truly mature organisation, UX would be embedded in the problem decomposition from the start, not to lead the implementation design so much as to keep the user in mind.

But that only works when there's mutual fluency. When UX understands enough about engineering to ask the right questions, and engineering understands enough about users to make good default choices.

In an immature org, you don't have that fluency. So you create a clean handoff point: working software. That's something everyone can see, touch, and reason about. It eliminates the abstract debates and grounds the conversation in reality.

Playing the Game

Here's the political angle you need to get right: give credit generously.

When the feature ships and it's great, that's a UX win. When leadership sees the demo and loves it, that's product vision. You don't need to fight for recognition of the engineering work. The people who matter (your team, your senior engineers, the other technical leaders) know what happened below the waterline.

Your job is to protect the space to do that work well. And the way you protect it is by making everyone else look good when it lands.

This isn't about being a martyr. It's about understanding where the power is and working with it, not against it. You're not trying to change the organisation's values from the bottom up. You're creating a pocket of sanity where good engineering can happen, and you're paying the political price to maintain that pocket.

What You Get Out of This

This model isn't perfect, but it gives you three things that matter:

First: You can build good software. The technical foundation is solid because the people who understand it are making the decisions. You're not shipping hacks and calling them features.

Second: Your team stays sane. Senior engineers aren't burning out in design-by-committee meetings or thrashing through endless UX iterations on half-built features. They have clear ownership and the autonomy to do their best work.

Third: You can sleep at night. You're not lying to yourself about the quality of what you're building. You're not rationalising technical debt as "pragmatism." You're doing the work right, even if the org doesn't fully understand why it matters.

And maybe, over time, the results speak for themselves. Maybe the fact that your team ships features that actually work, that perform well, that don't collapse under load, starts to shift how people think about the engineering process.

Or maybe it doesn't. Maybe the org stays immature forever.

But at least you built something you're proud of. And you protected your team's ability to do the same.

Conclusion: Pragmatism as a Discipline

This whole approach requires discipline. It requires swallowing your ego when UX gets the credit for your technical foundation. It requires playing the long game instead of fighting every battle. It requires being okay with the fact that most people will never see or understand the work below the waterline.

But it's the only way I've found to maintain craft in an environment that doesn't fully value it.

You can't fix organisational immaturity from your position. But you can refuse to let it destroy your team's ability to do good work.

That's not settling. That's survival.

---

This is Part 3 of a three-part series. Read Part 1: Stop Feeding the Feature Factory and Part 2: The Iceberg Problem for the full context on why these dynamics exist and what they reveal about organisational maturity.