There’s a moment in most cross-functional projects that looks, from the outside, like progress.
The design is mostly there. The copy is mostly there. The direction feels right. A few open questions remain, but nothing feels blocking. Everyone in the room can sense that the thing is almost ready to become real.
And then someone asks the question.
“How do we move faster?”
It’s a reasonable question. It’s asked in good faith, usually by someone senior, usually by someone who genuinely cares about the work. And yet it is, almost always, the moment the project starts to go wrong.
Not because speed is bad. Speed is often exactly what’s needed. The problem is what the question does to the room. It shifts the conversation from what are we building to how much of it can we skip, and it does so at precisely the moment when the cost of that shift becomes invisible to everyone except the people who will have to absorb it.
This essay is about that moment, and about what it reveals about how cross-functional teams think about craft.
To see why, you have to look at what actually happens when a design that looks 95% done arrives at an engineering team.
Inside the 95%
When a designer looks at a nearly-finished design, they see something recognizable. The hierarchy is resolved. The tone is landing. The narrative flows from block to block. The work of making the thing feel right is mostly done, and what remains is polish, the kind of refinement that a skilled designer can do quickly once the bones are in place.
When an engineer looks at the same design, they see a different object.
They see a dependency graph. They see the six decisions that haven’t been made yet, hiding inside things the design treats as settled. They see the four places where this component will need to behave differently on mobile, and the question of whether the mobile behavior is a variant of the desktop behavior or a fundamentally different pattern. They see the block that looks like a simple card but will need to render three different content types with three different interaction models, and they’re trying to figure out whether those should be one component with variants or three components that share a visual language. They see the animation that isn’t specified but will need to be specified, and the loading state that no one has thought about, and the error state that no one has thought about, and the empty state that no one has thought about.
They see the question of whether this block becomes a pattern the team will reuse across twenty other pages, in which case the API needs to be designed carefully, because mistakes will propagate, or whether it’s a one-off, in which case the pattern can be simpler but they need to be sure it actually won’t get reused, because one-offs that get reused are the single most reliable source of technical debt in the world.
They see all of this, and then someone tells them the design is 95% done.
What the engineer hears is that 95% of the design work is done. Which tells them almost nothing about how much of the engineering work is done, because the engineering work is a different thing, and it hasn’t started yet.
This is a description of what engineering craft actually is. It is the work of taking something that feels resolved at one level of abstraction and making it resolved at every level of abstraction, including levels that the person who created the original artifact was not required to think about, and often could not have been expected to think about. It is a deep and specific form of thinking, and it requires time that looks, from the outside, like delay.
Every craft has this property: the people inside it see things the people outside cannot. What I am describing is not engineering seeing more than other disciplines. It is what happens when disciplines work alongside each other without ever fully entering each other’s depth, when each craft becomes invisible to the others, and the cost of that invisibility lands somewhere it shouldn’t.
Why the invisibility is structural
The invisibility is a structural feature of how cross-functional work is organized.
Design work is legible. You can see it. A finished design is a thing you can look at and evaluate. The craft is visible in the artifact. When a designer has spent three weeks refining hierarchy and tone and flow, the output of that work is a document anyone can open and feel.
Engineering work is largely invisible. The artifact is a running system, and the craft is in the decisions that shaped the system, decisions that are invisible by definition because the whole point of good engineering is to make the right decisions feel inevitable in retrospect1. When a team ships a component that works beautifully, the work that went into making it work beautifully is erased by the fact of its working. You can’t see the architectural choices. You can’t see the edge cases that were handled. You can’t see the thirty decisions that were made quickly and correctly because someone had built up enough context to know which option was right.
The asymmetry matters because it shapes who gets to have their work respected as craft by default and who has to argue for it. Designers don’t usually have to explain to engineers why their work takes the time it takes, the artifact does the explaining. Engineers routinely have to explain to designers, product managers, and executives why their work takes the time it takes, and the explanation is hard because the thing they’re describing is invisible.
If a team doesn’t actively correct for this asymmetry, the team that produces invisible work will systematically be treated as the team whose work can be compressed.
The shock absorber
Here is the pattern that produces the worst outcomes in cross-functional work.
A decision space opens up. There are trade-offs to be made. Some of them are hard, which features to cut, which ideas to let go of, which ambitions to defer. These decisions are uncomfortable because they require someone to say no to something they care about.
The team has a choice. They can make those decisions together, in the room, while the cost of each option is still visible to everyone. Or they can defer the decisions, keep the scope, keep the ambition, keep everything that feels important, and let the decisions get made implicitly later, by whoever is the last line of defense before the thing ships.
The last line of defense is almost always engineering.
This is how you get a team where design finalizes, then engineering “figures it out.” Where the trade-offs that weren’t made explicitly in the planning conversation become trade-offs that engineering makes implicitly under deadline pressure, between features and polish, between correctness and speed, between doing the work well and doing the work on time. Where the scope stays ambitious because no one had to say no to anything in the room, and then the engineering team absorbs the impossibility quietly, through longer hours and deferred hygiene and quality corners that get cut invisibly.
This is the shock absorber pattern. One discipline absorbs the uncertainty that the whole team should have shared.
When it works, it looks like heroism. The team ships on time (ish), the ambitious scope is preserved, and the engineers who absorbed the cost are praised for their hustle. The praise is real and they feel seen, and the pattern is reinforced.
But even when the shipping is working, the damage is happening. The engineers who absorbed the first round of uncertainty are not recovering between rounds, they’re being asked to absorb the next round too. The platform hygiene that got deferred during the heroic quarter is still deferred, and the cost of deferring it is compounding. The trade-offs that got made implicitly under deadline pressure were not the same trade-offs that would have been made explicitly in the planning conversation, and the system now contains those implicit decisions as invisible debt. The engineers themselves are a little more tired, a little more cynical, a little more likely to leave.
And the next time the team produces a heroic quarter, the bar gets reset. The heroic output becomes the new baseline. The next ask is measured against the last delivery, and the last delivery was unsustainable, so the next ask is also unsustainable, and no one notices, because no one is tracking the gap between what the team is delivering and what the team could deliver at a pace that didn’t consume reserves.
This is how good teams break.
What craft-respect actually requires
Respect across disciplines is not a matter of tone. It is not about being nice to each other in meetings, or using the right language in Slack, or remembering to thank each other for good work. Those things matter but they are the surface of the thing, not the substance.
The substance is this: respecting craft across disciplines means making decisions in the rooms where they can still be made, with the people who will bear the consequences, before those decisions become invisible.
In practice, this looks like a few specific things.
It looks like engineering being in the room when scope is being set, not receiving the scope as a completed artifact. Not because engineers need to approve the scope, they don’t, but because the cost of each element of the scope is information that should shape the scope, and that information is only available if engineering is present for the conversation.
It looks like the “how do we move faster” question being followed immediately by “what are we choosing not to build.” Speed without de-scoping is not speed, it is compression, which is the same output for a higher cost, and the higher cost gets paid by whoever is closest to the deadline.
It looks like treating engineering estimates as the output of a function, not as an opinion to be negotiated. When an engineer says a thing takes six weeks, the useful response is not “can it be four”, the useful response is “which inputs to your estimate are the most flexible, and what does the work look like at each input level.” The first response treats the estimate as emotional. The second treats it as a model.
It looks like recognizing that when a team runs hot to hit a date, the running-hot was not free, and planning the next period accordingly. A team that sprinted last quarter cannot sprint again this quarter without paying a compounding cost, and the cost compounds regardless of whether anyone is paying attention to it. The only way to avoid the cost is to plan deliberate recovery into the next period.
None of this is about slowing down. It is about producing the best work a team is capable of over years instead of quarters, which requires understanding that craft has a pace, and the pace is not infinitely negotiable.
What this is really about
The argument I am making is not a soft one. The shock absorber pattern – the compounding cost, the heroic baseline that quietly destroys the teams that produced it – is the difference between organizations that build great work sustainably and organizations that build great work once and then wonder why they can’t do it again.
The best teams I have been part of were the ones where no discipline had to absorb what the others chose not to decide. Where designers, engineers, marketers, and strategists sat in the same rooms when the trade-offs were live, and made them together, with full visibility into what each choice would cost and who would pay the cost.
They were not always the fastest teams – although when you take the long view, they almost always are. They were the ones whose work got better over time.
That, to me, is what respecting craft across disciplines actually means. Not tone. Not politeness. Not saying the right things in Slack. It means building the kind of cross-functional practice where no one’s craft is ever treated as the shock absorber, because every discipline’s work is understood to have depth, and every discipline’s depth is understood to have a cost, and the costs are shared in the open instead of absorbed in silence.