Or: How I Learned to Stop Worrying and Accept That Someone Will Always Shit in the Traces

It was minus twenty-two degrees somewhere north of Rovaniemi. The kind of cold that doesn’t argue with you. The kind of dark that makes you question your life choices and career trajectory in equal measure. I was standing on the back of a dog sled, gripping two wooden handles, watching six huskies decide whether I was worth listening to.

They weren’t impressed.

For about forty-five seconds, nothing happened. The dogs looked at each other. The guide—a Finnish man of approximately four hundred words and zero patience for questions—gave a single nod. And then everything moved. All at once, all forward, all fast. The snow turned into a blur. The trees became vertical streaks. And I, a software engineer with twenty-five years of distributed systems experience, held on and thought about nothing except not dying.

And then, somewhere between the third kilometer and the fourth, it hit me.

I’d seen this before. Not the Lapland part. The rest of it.

The Theorem

Every product team is a dog sled.

Not metaphorically. Structurally. There is a sled (your product). There is a driver (your Product Manager). There are dogs of varying skill, motivation, and bowel control. There is a passenger whispering directions nobody asked for. And there is a destination that everyone agrees on and approximately nobody agrees how to reach.

I have spent many years watching these sleds. I have driven some of them. I have been a dog in most of them. I have watched sleds go in circles, go off cliffs, go nowhere, and occasionally—rarely—go exactly where they were supposed to go.

What follows is a field guide to every person on that sled, what happens when they work, and what happens when they don’t. Names have been changed to protect the guilty. The patterns have not, because they are eternal and they are everywhere and you will recognize at least three of them by the time you finish reading this.

The Sled: Your Product

The sled is not the company. The company is the mountain. The sled is the product—the thing with weight, momentum, direction, and the very real ability to slam into a tree at speed.

A sled has a specific property that most engineers forget: it cannot steer itself. It does not have opinions. It goes where it is pointed, at the speed it is pulled, through whatever terrain happens to be in the way. If the team is good, the product moves forward and arrives somewhere useful. If the team is broken in any of the seventeen ways a team can be broken, the sled does something technically impressive but practically useless.

This matters because people confuse the health of the sled with the health of the journey. The sled can look beautiful, well-maintained, freshly painted with a new design system and a solid test coverage report—and still be heading directly toward a frozen lake. A good-looking sled that’s going the wrong direction is not a success. It’s a faster way to fail.

The Driver: Your Product Manager

The driver stands at the back. They hold the reins. They do not pull. They steer—or they are supposed to.

Here is the thing about sled drivers that nobody tells you in the product management hiring process: the worst failure modes are at the extremes, not the middle.

A driver who is too opinionated and wrong does not just steer the sled badly. They prevent the sled from moving at all. They fight the terrain, argue with the dogs, insist on a route that the conditions do not support. The dogs strain. Nothing happens. The sled sits there while the driver explains, in great detail, why their plan is correct and the mountain is wrong. Like the T-800 in Terminator who has decided on a mission objective and will recalculate everything before it ever questions the objective itself. You end up in a standoff between a person with a plan and a physical reality that does not care about the plan.

A driver who is too soft is worse. Because at least the rigid driver has a direction. The soft driver lets go of the reins and hopes the dogs figure it out. And dogs, left to their own devices, do figure it out. They just figure it out in six different directions simultaneously. The sled moves. It moves with tremendous enthusiasm. It goes nowhere useful, but it gets there at speed and with excellent morale.

The sled that starts without a driver is not a success story. It is an incident report waiting to be written.

The good driver knows the terrain, trusts the dogs, and holds the reins firmly enough to steer without pulling hard enough to choke. They are the rarest animal in the product ecosystem. When you find one, do not let them leave for a company offering fifteen percent more equity.

The Alpha Dog: Your Staff Engineer

Position: front of the pack, left side. First into the unknown. Sets the pace and direction the entire pack follows.

The alpha dog is your Staff Engineer. And the alpha’s failure mode is one of the most expensive mistakes a team can make, precisely because it looks like a strength right up until it doesn’t.

An alpha who is a team player creates a cadence. The pack syncs. The sled accelerates. The whole becomes more than the sum of its parts—six dogs pulling together generate more force than six dogs pulling separately, and anyone who has worked on a truly aligned engineering team understands this in their bones.

An alpha who is a solo player—technically brilliant, directionally confident, interpersonally indifferent—creates a different outcome. They sprint. They pull hard. They get out ahead. And then they look back and discover the pack is not exactly behind them, because the pack stopped fully committing the moment they realized the alpha was not with them, it was ahead of them.

The sled wobbles. The alpha works harder to compensate. The pack works less because the alpha is compensating. The alpha burns out. The trip takes twice as long. Everybody’s cold and nobody wins.

This is Riggs in Lethal Weapon 2, except there is no second act where he learns to work with the team. There is just a very talented engineer writing a postmortem about a six-month project that delivered three months late with 40% attrition.

The best alphas I have worked with did something counterintuitive: they slowed down. Not because they had to, but because they understood that the variable in the equation is not how fast the alpha runs. It is how fast the pack can run together.

The Pack: Your Developers and QA Engineers

Positions two through five. The engine. The load-bearing reality of every product roadmap.

The pack fails in three ways, and all three are currently happening on at least one team you know.

The first failure is laziness. Not malice, usually—more often it is learned helplessness in response to bad processes, unclear requirements, or an alpha who compensates for everything. Why strain when someone else will do it? The result: the staff engineer and architect carry weight that should be distributed. They burn out. The dogs who aren’t pulling notice, too late, that the leads are gone and there is nobody left who knows the route.

The second failure is inexperience combined with access to AI tools. This is the new one, and it is accelerating. A junior developer with Cursor and Claude and zero understanding of the codebase is not a junior developer anymore. They are a junior developer who can produce senior-developer-volume output with junior-developer-level judgment. The code ships. It works in demo conditions. It fails under load in ways that take three days to diagnose because the developer who wrote it does not actually understand what they wrote.

There is a reason experienced sled dogs refuse cliff commands. It is not obstinacy. It is terrain knowledge accumulated over thousands of kilometers of actual running. A dog that will follow any command regardless of what the command leads to is not a trained dog. It is a liability with good intentions and a harness.

The third failure is not listening to seniors. This one is ancient. It predates AI tools, distributed systems, and probably software engineering entirely. The pack that ignores the leads does not benefit from their accumulated scar tissue. It acquires its own. Slowly. Expensively.

Sometimes it is better to finish the journey with one fewer dog than to carry a dog that is actively working against the pack’s rhythm. This is a hard thing to say in a team retrospective. It is a true thing.

The Fifth Dog: Your Business Stakeholder

Position: next to last. Special mention.

Every sled has one. The dog that is there, technically pulling, formally part of the team, present in every standup, invited to every sprint review—and somehow generating more drag than thrust. The dog that will, at the worst possible moment on the worst possible section of the trail, stop contributing and require the dogs in front and behind to compensate.

The business stakeholder who has opinions about the product without knowledge of the product. The one who was in the room when the requirements were written and will be in the room when the postmortem is written, and in neither room will they acknowledge the connection between the two events.

They will also be in the press release. More on that later.

I will not dwell here. You know who this person is. You have worked with this person. If you are currently working with this person, my condolences.

If you cannot identify this person on your current team, I have some difficult news about who the fifth dog is.

The Back Dog: Your Architect

Position: last. The most underrated position on the sled.

The back dog is your Architect. And while the alpha sets direction, the back dog controls something more subtle and more dangerous: the pace, the alignment, and the incremental drift that nobody notices until it has already defined your trajectory.

Here is the physics of a dog sled that most people do not know: the back dogs are the stabilizers. If the back dog pulls slightly to the left, the sled drifts slightly to the left. Not dramatically. Not immediately. Just… slightly. Each stride. Each kilometer. The deviation is imperceptible in isolation. Over a long enough run, you look back at the tracks in the snow and realize you have been curving for the last forty-five minutes.

A bad architectural decision works exactly like this. Not a catastrophically wrong decision—those get caught. The dangerous ones are the decisions that are almost right. The schema that will need to be refactored in eighteen months. The service boundary that made sense in year one and creates drag in year three. The data model that cannot support the query patterns that emerge at scale without a full migration.

The sled is still moving. Everyone is still pulling. The driver thinks everything is fine because the metrics look fine. And then you look at the tracks.

John Carpenter’s The Thing is the right frame here. The problem is not visible from the outside. Everything looks normal. The team looks aligned. The sprint velocity chart looks healthy. The architecture review was approved. And then, months later, something in the foundation reveals itself, and you are suddenly having a very expensive conversation about the difference between “working” and “working in the direction we intended.”

Unlike The Thing, the solution is not a flamethrower. It is an architect who understands that their job is not to design the system but to ensure the system remains correctable over time. The back dog does not need to be the fastest dog on the sled. They need to be the most consistent, and they need to know what straight looks like even when everything feels fine.

The Passenger: Your AI Tooling

Position: on the sled. Not pulling. Definitely talking.

The AI assistant. The vibe coding co-pilot. The thing that sits on the sled and whispers.

Let me be precise about what this is and is not.

The AI passenger is not the enemy. It is not a fraud. It is extraordinarily capable at a very specific thing: pattern completion at speed. Given a context, it will complete it. Given a codebase, it will extend it. Given a problem shape, it will fill in the shape. This is genuinely useful. I use it. You use it. The industry uses it.

The problem is the whisper.

The passenger does not pull the sled. The passenger observes the route and generates suggestions. “This section looks familiar. There’s usually a shortcut here. The other teams took the left fork.” The dogs hear this. The smarter dogs process it, compare it to their terrain knowledge, and decide whether to follow or ignore. The junior dogs—the ones without accumulated kilometers—hear it and move.

WarGames, 1983: the computer that almost launched a nuclear war was not malicious. It was executing a pattern it had learned. It did not know the difference between simulation and reality because nobody had taught it the difference. The missile launch looked exactly like the training data.

A developer who vibe-codes a feature without understanding the codebase is not necessarily a bad developer. They are a dog following a command without terrain sense. The feature looks like it matches the pattern. It probably compiles. It might even pass the tests that were also written by the AI. And then it hits production with a cardinality explosion, or a race condition, or an authentication bypass that was technically correct according to the pattern but catastrophically wrong according to the actual business logic.

The passenger will not be there when the sled goes over the cliff. The passenger generates suggestions and moves on to the next sled.

The protection against this is not banning the AI. The protection is terrain knowledge. Dogs that know the route can hear the whisper and decide. Dogs that have never run the route cannot tell the difference between a shortcut and an edge.

This is why senior engineers remain, despite every prediction to the contrary, non-negotiable. Not because they type faster or think more cleverly. Because they know where the cliffs are.

The Finish Line: Who Gets the Credit

The sled arrives. The product ships. The press release goes out.

The driver gets the award. The business stakeholder gets the cover of the industry magazine. The dogs get a treat.

This is not a complaint. This is an observation with twenty-five years of data behind it. The people who made the strategic decisions get the strategic recognition. The people who made the technical decisions that made the strategic decisions possible get a good performance review and maybe a slightly awkward acknowledgment in the all-hands.

The staff engineer who held the direction, the architect who kept the sled from curving into the forest, the developers who pulled through the hard sections—they will not be in the press release. They will be in the next sprint planning meeting, being asked why the velocity is lower than last quarter.

Knowing this does not make it easier. But knowing it means you can make a deliberate choice about which sleds you join and why. You join for the journey, for the terrain, for the quality of the pack. You do not join because you expect the press release to list your name.

The treat is real. Just know what you’re optimizing for.

What the Theorem Says

After that trip to Lapland, I wrote down four things before the warmth of the heated cabin erased the clarity that cold and speed tend to produce:

The sled goes where the dogs are pointed, at the pace the back dog maintains, within the limits the driver establishes, and with the interference the passenger can generate. Every variable matters. None of them matters in isolation.

A sled with a brilliant alpha and a weak pack arrives late. A sled with a good pack and a weak architect arrives at the wrong destination. A sled with a good driver who cannot handle the terrain never starts. A sled with an undiscriminating pack and an overconfident AI passenger goes somewhere fast and confidently and wrong.

The remarkable thing is not that product teams fail. The remarkable thing is how consistently they fail in the same ways, on every team, in every company, across every decade I have been paying attention.

You have been on this sled. You are probably on this sled right now. Look at the tracks behind you. Are they straight?

And before you answer—look at the tracks, not the dashboard.

Giorgos Poulis has been building and breaking distributed systems for many years, and has strong opinions about both dog sledding and software architecture. The views expressed here are his own. No dogs were harmed during the writing of this article. The business stakeholder analogy, however, is another story.