On connecting technical decisions to business outcomes, communicating trade-offs, and learning to lead without needing…
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
No spam. Unsubscribe anytime.
On connecting technical decisions to business outcomes, communicating trade-offs, and learning to lead without needing to be right.
Early in my career, I thought being good at software development was largely about knowing how to solve problems.
Understand the requirements, evaluate the available technologies, choose an appropriate approach, and build something that works.
Those skills are still essential. But as I've taken on more responsibility for delivering projects, I've realized that having a technical answer is only part of the job.
The harder part is helping other people understand what that answer means for them.
A client might ask for something that sounds straightforward but introduces significant architectural consequences. A development team might prefer a particular technology because they're familiar with it. A technically elegant solution might require more time, money, or organizational change than the business can reasonably accommodate.
When guiding a B2B website strategy or evaluating enterprise client readiness, none of these situations can be resolved through technical expertise alone.
You need to understand what the business is trying to accomplish, what constraints it operates under, and how the available technical approaches support or complicate those objectives.
You also need enough technical depth to understand the implementation consequences.
And then you need to connect those two perspectives in a way that allows people to make informed decisions.
That's what I've been thinking about a lot recently.
As developers, we're trained to look for good technical solutions.
We care about maintainability, performance, accessibility, scalability, and clean architecture. We want to avoid unnecessary duplication, reduce complexity, and build systems that can evolve.
These are important considerations. But they aren't the only ones.
Imagine working with a company whose development team is already familiar with a particular frontend framework.
You might prefer a different approach because you believe it would preserve more of the existing implementation, reduce migration work, or provide a cleaner architectural foundation.
Your recommendation might be technically sound.
But the company has other considerations.
Its developers already know the framework. It has invested in training and tooling. It wants its internal team to maintain the system after you leave. Perhaps the alternative would introduce a dependency on expertise the company doesn't currently have.
Suddenly, the question isn't simply which approach produces the cleanest implementation.
It's which approach makes the most sense for this particular organization.
That doesn't mean technical quality should be sacrificed whenever a business has a preference. It means technical quality needs to be considered alongside the organization's ability to deliver, operate, and maintain the solution. As I explore in Client Judgment vs. Preferred Technology, separating personal tool preferences from business realities is often the first test of senior engineering objectivity. When planning architecture-first website rebuilds, starting with business outcomes rather than premature rewrites saves months of coordination friction.
The purpose of architecture is to serve the business, not the other way around.
One of the most demanding aspects of technical leadership is constantly moving between the bigger picture and the implementation details.
In one conversation, you might be discussing why a company wants to replace its existing website.
Perhaps marketing teams depend too heavily on developers. Publishing content requires too many manual approvals. Product information is scattered across multiple systems. The company wants more autonomy, better governance, and a platform that can support future growth. In a structured CMS architecture review, those business tensions directly dictate whether you structure collections for developer velocity or editorial independence.
Those are business problems.
A few hours later, you might be examining whether a UI component should own its filtering state, whether its behavior can be reused across multiple pages, or whether the content management system should expose a particular configuration option.
Those are implementation problems.
But they aren't unrelated.
Consider a seemingly small decision about whether to make a page section configurable through a CMS.
From a technical perspective, you might be deciding between a reusable content block, a fixed template, and a hardcoded component. Whether you are building custom Admin UI components in Payload CMS or organizing field structures to prevent content bottlenecks, the schema design determines operational independence.
From the business perspective, you're deciding who can make changes, how much freedom they have, and whether a developer needs to be involved every time marketing wants to update something.
Too little flexibility creates operational bottlenecks.
Too much flexibility can introduce inconsistency, maintenance problems, and additional complexity for the people managing the website.
The appropriate solution depends on understanding both sides.
If you only understand the technology, you might build an elegant system that doesn't solve the company's actual problem.
If you only understand the business requirements, you might overlook technical consequences that become expensive later.
Technical leadership means being able to move between those levels and understand how decisions at one level affect the other.
This is something I personally find challenging.
With experience, you begin recognizing certain patterns almost instinctively.
You look at a proposed implementation and see where responsibilities might overlap, where an abstraction could become problematic, or where a seemingly harmless decision could create additional work later.
You might recognize the risk within seconds.
But the person you're speaking with hasn't necessarily followed the same reasoning.
They don't have your technical background. They may not know the architecture or understand why two tasks that appear independent could interfere with one another.
And you cannot simply announce your conclusion and expect them to understand its significance.
You have to reconstruct the reasoning that led you there.
Introduce the relevant concepts. Explain how the pieces fit together. Distinguish what you know from what you suspect. Describe what could happen and why it matters.
Sometimes I catch myself going too deep into the implementation details because I'm trying to make sure the other person understands precisely what I mean.
But that can introduce another problem.
The more technical context I provide, the harder it can become for someone to identify the actual decision we're discussing.
I'm learning that a useful starting point is to explain the situation, the potential consequence, and the recommendation before getting into the technical details.
For example, instead of beginning with an explanation of component architecture, Git branches, and data contracts, I might say:
"Two teams are making changes to overlapping parts of the website. That creates a risk of duplicated work and integration conflicts. I suggest we agree on ownership before continuing, so we don't spend time implementing the same things twice."
Establishing clear component contracts through Vertical Slices and Reusable Frontends ensures both groups can build against shared boundaries without collision.
The technical explanation is still available if someone needs it.
But now everyone understands why the conversation matters.
The goal isn't to make everyone understand everything you know. It's to give them enough understanding to participate meaningfully in the decision.
That requires more than choosing simpler words.
It requires listening, recognizing when someone is confused, adjusting the explanation, and creating an environment where people feel comfortable asking questions.
Communication isn't something that happens after the technical work. It's part of the technical work.
When a client asks for your expertise, you should have an opinion.
You should evaluate the options, explain their trade-offs, and recommend the approach you believe serves their needs.
But having a recommendation doesn't mean you own the final decision.
Consider a project where there are three possible implementation approaches.
One preserves the existing code and minimizes immediate development effort, but carries some technical debt forward.
Another rebuilds the implementation around a different framework, potentially improving consistency with the internal team's tooling but introducing additional development effort and regression risk.
A third takes a hybrid approach, preserving the existing design while gradually improving the underlying implementation.
You might recommend the hybrid approach.
You explain why. You describe what each alternative offers, what it costs, and which risks it introduces.
Then the client chooses the rebuild.
What happens next?
You could spend the following meetings explaining why your original recommendation was preferable.
You could treat every difficulty as further evidence that you were right.
Or you could recognize that the decision has been made and focus on making the chosen approach successful.
That doesn't mean pretending the risks have disappeared.
You still have a responsibility to identify them, propose mitigations, and communicate when new information changes the situation.
But your recommendation should not become something you need to defend for its own sake.
The objective is to help the client make a good decision, not to make sure they choose yours.
This becomes particularly important when a project doesn't unfold according to the original plan.
Imagine two teams working on different aspects of the same website.
One is adapting an existing frontend into a content management system, deciding how components should be organized and how they will receive their data.
Another is rebuilding parts of that frontend using a different styling approach.
Both teams are making progress.
Both have working implementations.
Then they discover they've been working on some of the same components independently.
There is now a risk of duplicated effort, competing implementations, and merge conflicts.
This is the exact coordination trap I describe in When Helping Creates More Work: adding hands without shared architectural visibility inevitably multiplies delivery friction instead of cutting it.
Perhaps the risk was identified earlier. Perhaps the responsibilities weren't sufficiently clear. Perhaps the additional work was intended to accelerate delivery.
At this point, determining who should have done what doesn't resolve the immediate technical problem.
The useful questions are different.
What has already been built?
Which parts can we preserve?
How much overlap actually exists?
What is the most practical way to bring the work together?
How should responsibilities be divided going forward?
Sometimes the answer requires changing your own plan.
You might stop working on a particular area, allow another team to finish its implementation, and then resume your work once the shared foundation is ready.
That may not be how you originally intended to approach the project.
But the circumstances have changed.
Continuing with the original plan simply because it was your plan could create even more unnecessary work. In How to Take Over a Frontend: A 4-Step Production Framework, I examine how preserving existing team momentum and proving parity takes precedence over asserting individual architectural dominance.
This is something I'm learning to appreciate about technical leadership: you can be confident in your reasoning while remaining flexible about the implementation.
You don't have to abandon your principles to adapt.
You have to understand which principles matter, which decisions are still open, and which constraints have changed.
Another lesson I've been thinking about is how technical decisions are actually made.
A meeting can be useful for discussing options, resolving disagreements, and establishing a shared understanding.
But a live demonstration isn't always enough to evaluate an implementation.
Someone might show you a completed page. It looks good, the interactions work, and the team has clearly made progress.
What you cannot necessarily establish from that demonstration is how the code is structured, how it integrates with the rest of the system, or whether it introduces conflicting assumptions.
Those questions require examining the actual implementation.
I increasingly prefer having the opportunity to review technical work asynchronously before discussing consequential decisions.
Give me the code, the proposed changes, the reasoning behind them, and the specific questions that need answering.
Let me examine the implementation and think through its implications.
Then we can have a focused conversation about the things that genuinely require discussion.
This isn't about avoiding meetings.
It's about making better use of them.
I also believe important decisions should be documented afterward.
A conversation can create the impression that everyone agrees, while participants leave with different interpretations of what was decided.
A written record of the decision, its rationale, the remaining risks, and who owns the next steps gives everyone something concrete to work from.
Of course, documentation alone doesn't create alignment. People need to acknowledge the decision and act on it.
But it provides a foundation for shared understanding rather than relying on everyone's memory of a conversation.
The more I work with clients, the more I realize that my responsibility extends beyond the code I personally write.
I'm responsible for understanding what they're trying to achieve.
For identifying technical risks they may not see.
For explaining the consequences of their options.
For making recommendations grounded in their circumstances rather than my personal preferences.
And for helping turn their decisions into working systems.
This doesn't mean taking responsibility for every decision or every action taken by every team.
Leadership also requires clear ownership, appropriate boundaries, and knowing when a decision belongs to someone else.
But it does mean thinking beyond your individual contribution.
A successful implementation isn't necessarily the one that most closely resembles the architecture you would have designed in isolation.
It's one that meets the business's needs, can be operated and maintained by the people responsible for it, and achieves the outcomes the project was intended to deliver.
I'm still learning how to communicate these ideas more clearly.
Sometimes I explain too much. Sometimes I assume that something obvious to me will be obvious to someone else. Sometimes I need to recognize sooner that the conversation has moved from evaluating options to deciding what happens next.
But I think that is part of developing as a technical leader.
The technical knowledge remains essential. Without it, you cannot reliably evaluate the options or understand their consequences.
But knowledge alone doesn't help a client make a decision.
You have to make that knowledge accessible, apply it to their circumstances, and remain accountable for the work that follows.
Having the answer is valuable. Helping people understand their options, make informed decisions, and turn those decisions into successful outcomes is what technical leadership is really about.
If you are navigating technical decisions, team coordination, or platform migrations:
If you are planning an upcoming replatforming or need an objective evaluation of your CMS architecture, explore my CMS Architecture Review advisory or read more on B2B Website Strategy.
