If you’re subscribed to this newsletter, it means you genuinely want to hear from me (at least in theory!) You want my writing delivered right to your inbox, instead of leaving the chance of seeing it to the mercy of this week’s LinkedIn algorithm.
I appreciate that. So I’d like to run a concept by you that I’ve had percolating for a while now.
Last year I made a post comparing two structures of engineering teams: what I called the “traditional way” of clear hand-offs and order of operations, versus a collaboration style I’ve found leads to more success. The post got some pushback, which was definitely deserved.
But I still had folks telling me they related to what I’d said about the struggles of working in a more rigid environment. There was clearly something to say there, but I didn’t have the missing puzzle piece yet.
Thanks to a comment on a recent post, I’ve found that missing piece.
I’ve come to think of my preferred collaboration structure as an engineering watershed. I grew up in western Washington state, and can’t recall a time I didn’t know that all our water eventually found its way from the mountains and forests to the ocean. A water metaphor might be a little curious for an air vehicle process, but it feels right to me.
The recent comment helped me find my ideal metaphor for the “traditional” structure: a complex of locks. The locks still move water, and that water might end up in the ocean too. But the way they operate is notably different from a natural watershed. And the more I think about it, the more I like the comparison.
I want to explain why the watershed and the locks are good illustrations of what we should strive for in our engineering projects. I hope you’ll give me feedback, whether or not you agree.
The Locks: Equalizing Understanding Between Defined Gates
In case you’re unfamiliar, a lock is a human-built device for moving vessels—ships, boats, kayaks, etc.—between bodies of water at different levels.
A single lock has two sets of gates, one at each end of a connecting chamber. A boat wanting to move from, say, one lake to another enters the lock chamber. The gates close behind it, sealing off the chamber. Water is then either pumped into or out of the chamber, bringing the internal water level equal with the destination body of water. When this is done, the other pair of gates opens and the boat exits the lock into the second lake.
I see an engineering project as a long series of connected lock chambers. For our metaphor, let’s say these locks connect a freshwater lake to the ocean, just like the Ballard Locks where I grew up in Seattle, Washington. And like the real-world locks, ours have spillways and a salmon ladder, to help control the water level and let fish return to their freshwater spawning grounds.
Each of the chambers can be an individual engineering department or team. The teams have clear communication, smoothly passing information between each group, like how the water level in each lock chamber is raised or lowered to match the level of the next.
Maybe the first chamber is the aerodynamics team, who determine the initial configuration. The next chamber is the mechanical engineers, who figure out how to fit the necessary structure inside that geometry. Each group moves to the level of the next, and equalizes the knowledge between them.
Here’s the key though: it is those gates that mark the distinct points of collaboration. There is a difference between having someone from manufacturing help review and sign off on part drawings, and a mechanical engineer sitting next to a manufacturing tech as the tech points out all the impossible-to-make features of a part on their computer screen. A design review requires the manufacturing expert to notice issues after the work’s been done, versus informing the design from the very beginning.
Sometimes there’s a sense that one team’s work is “done” as soon as they hand everything off. Information and requests for rework will still absolutely flow back to the required team, like water leaving a spillway or salmon hopping up the ladder. But that’s not a primary part of the process.
Even more importantly, this reveals the sense of ownership. Some organizations may incentivize each department or group to focus on and optimize only their contribution to the project: the aeros make the aircraft as efficient as possible, and the mechanicals just have to deal with it.
Being incentivized to only care about narrow criteria can easily lead to teams making design decisions best for their own goals, but not for the end project. They may not look to compromise with the other teams. There’s a feeling of “that’s not my job” when problems pop up later. They do their part of the work as best they can, and they wash their hands of it when it moves on.
They probably want to make a great product. But if a compromise means your annual review scores take a hit, you likely won’t be eager to allow it.
And so it goes: the water passes from lock chamber to lock chamber. The job gets done, but the process is more a loose conglomeration of groups instead of one cohesive team.
The Watershed: Ownership All the Way to the Ocean
Some of the best teams I’ve had the pleasure to work on have what I see as a “watershed” project structure. And when feasible, I think more programs should try to model it.
The definition of a watershed is a region of land where all rainfall and snowmelt eventually drains into the same body of water, like a lake or ocean. Like the locks, the water is still moved—but in a different way.
Let’s say our project watershed starts in the mountains with a small spring, or a glacier. This is the aerodynamic design work, and it forms the foundation of the project—after all, you can’t really have an airplane without an aero design.
But instead of passing between gates, here the water flows down the mountains. It encounters other streams on its way. These are the other disciplines you need for success: the mechanical engineers, the electricals, the controls folks. Every tributary drains into this river, just as the other disciplines contribute to make an aero design real.
Though it all started with the aero design, eventually no one contributor is more or less important than the others. And what’s more, no group is phased out. No one hands off their work and decides their part in the project is done. They may contribute more or less at times, but they’re always a part of the team, just as the water from a tributary is always part of the larger river.
At some point this waterway of all the disciplines’ efforts might reach a marsh. That’s the prototyping and testing process: it filters the designs through reality to find hidden issues to fix. And eventually it reaches the ocean, just like the locks complex does. The team achieves success by working in parallel until the end.
This is a core idea of the watershed visual. Every contributor has a sense of ownership of their efforts and the end product.
Done well, this provides the flexibility to make compromises that make no sense in isolation. No one insists on a perfectly-optimized aero design. The team makes allowances that slightly reduce performance, but significantly improve the structural integrity of the entire aircraft. They’re fully invested in the success of the product, and therefore the entire team.
There is no hand-off of responsibility, no gates to pass through. Consistent, ever-present collaboration leads to the best outcome. A rising tide lifts all boats.
Not every organization or project has the freedom to function like a watershed. There might be established procedures to ensure compliance with regulations or document full processes.
And honestly, large programs may have so many people involved, they need to use a locks structure just to maintain some sense of order and organization. Maybe closer collaboration is nothing special, simply the natural result of a smaller team.
But when you can encourage it, with a team with clear motivation and good camaraderie, it’s that side-by-side collaboration and full ownership of the end product that can produce the most innovative, intelligent solutions.