Picture a huge container ship arriving at the port of Leixões, in northern Portugal, late in the afternoon. The captain knows the ship better than anyone, but doesn’t know that harbor entrance the way someone who crosses it every day does: the currents, the sandbanks, the traffic coming in and out of the port. That’s why the law requires the captain to take a harbor pilot on board1, someone with local knowledge of the water and its traps.
In a genuinely dangerous maneuver, the pilot climbs a ladder hanging from the side of the ship while it’s still moving, and shortly afterwards takes the conn. The captain doesn’t leave the bridge, and remains responsible for the ship and for everyone on board.
During the maneuver, there are two people with authority over the same ship and a bridge team working with both. It sounds like a recipe for confusion, and it almost always goes well. The reason is simple: almost nothing is left to assumption.
On land, things aren’t always like this. Think of an unmarked intersection on a back road. No traffic lights, no right-of-way signs, no markings on the asphalt. Every driver arrives convinced they know who has priority: one because they’re on the wider road, another because they’re coming from the right, another because they drive through there every day. For a while, everything works. Drivers recognize each other, slow down, exchange a wave. Until the day two of them pull out at the same time and the crash is unavoidable.
Afterwards, someone asks how such an experienced driver could make that mistake. The question makes sense, but it’s also simplistic and naive. We also need to ask: what rule was actually in place, and how can we be sure everyone knew it?
Many organizations work more like this intersection than like a ship’s bridge. They ask for autonomy, initiative and judgment: “proactivity,” as we often hear. Limits and boundaries stay implicit. There are no markings on the road and no signs showing who has priority. They’re held together by proximity, routine, memories of conversations and each person’s own understanding. When a decision causes a conflict, we discover there were several versions of what was expected, and each person saw their own expectation as legitimate.
Experience helps us spot risks. Leadership helps us make limits understandable. We need both for autonomy to be possible and to survive the first mistake.
How two people steer one ship
It all rests on a few documents and a short conversation. When the pilot reaches the bridge, the captain hands over the pilot card, a sheet summarizing the ship: dimensions, draft, how she responds to the helm, which equipment is out of order. The pilot brings a passage plan: the route, the speeds, the points where the course will change, the moment the tugs come in. The international pilots’ association guidance says every job “should begin with an exchange of information between the master and the pilot”2. Within minutes, the two combine what they know and agree on the route before the ship is committed.
From then on, responsibility doesn’t change hands: “The master retains the ultimate responsibility for the safety of his ship”3. In return, IMO recommendations give the captain and the bridge team the duty to support the pilot “to ensure that his/her actions are monitored at all times”4. The captain leaves the conn to the pilot and checks every order against the agreed plan. Whoever takes the conn has duties too. Captain, officers and pilot “share a responsibility for good communications”5.
Supervision comes with a criterion, known in advance, for taking back control. According to an analysis by a marine mutual insurer, the captain is “obligated to take back the con”6 if the pilot’s orders could put the ship in danger. Taking back control has a defined reason, and the rest of the time the pilot steers.
The bridge team speaks up too. The Nautical Institute states that “The “challenge” is a key principle of good bridge resource management”7, and some training programs offer a ladder for doing it: “Ask > Suggest > Insist”8. Whoever sees a risk starts by asking, then suggests and, if needed, insists.
When the ship leaves port and the pilot climbs down to the pilot boat, the bridge is handed to the officer of the watch. For four hours, day or night, that officer keeps an eye on the course, the speed and the other ships while the captain rests. They don’t need permission at every step, because they work under standing orders that the captain and the officers sign and that are “available for consultation on the Bridge at all times”9. The same orders say when to call the captain, for instance when visibility drops below a set distance10. On one research vessel, one of these rules simply reads “CALL THE MASTER IF IN ANY DOUBT”11.
Autonomy is also earned. A captain who enters the same port often can obtain a license that exempts them from taking a pilot. Under a 1990 Portuguese regulation, that license required proof that the captain had “visited the port at least twice a month” (my translation) over the previous nine months, and kept up that frequency afterwards. It also provided for a preliminary inquiry after an accident12. The exemption rested on observable signals, was maintained through practice and was reviewed when something went wrong.
Put together, there are five things on board that make delegation safe: a conversation before casting off, written orders everyone knows, clarity about who has the conn at any moment, criteria for calling the captain, and rules for taking back the conn and handing autonomy back.
Do we really need this in tech?
On board, people’s lives are at stake. In a tech team, the worst that usually happens is a lost sprint or a broken dependency, which seems almost laughable next to what can happen at sea. But the difference works in favor of the argument. If, where a mistake can cost lives, the profession’s answer was a few clear rules, a conversation beforehand and someone keeping watch, it’s hard to justify every decision needing a signature where a mistake costs a week of work.
There are other differences. On board, the law establishes a captain, while in companies authority is often shared. The pilot is external and temporary, whereas someone given autonomy in a team works there every day, which is why the closest figure to a senior professional is the officer of the watch.
Delegation
To delegate is to agree on boundaries, and boundaries are rarely written down.
Delegating means agreeing on which decisions a person can make, within which limits, with which resources, and in which situations they need to involve others. Making that agreement explicit and revisiting it is the responsibility of both the person delegating and the person receiving autonomy.
Informality can work very well when the understanding is genuinely shared. Organizations that value speed know the pleasure of it: few meetings, decisions moving, trust between people who know each other. But informality becomes fragile, sometimes dangerous, when each person has absorbed a different idea from their colleague.
Working on a project involves several agreements
Autonomy can mean very different things. One person may understand autonomy as the freedom to decide and then inform. Their manager may expect a recommendation or a proposed solution, subject to approval. A stakeholder may believe any change depends on their consent.
As long as there’s no conflict, these differences go unnoticed. The quality of delegation shows when a hard decision has to be made, especially if interests don’t align. Even on board, where almost everything is written down, ambiguity creeps in. A Norwegian harbor pilot writes that captains’ expectations range from a role “easily confused with command to that of a pure advisory role”13.
One person, two scopes
Think of a developer working on a product. They belong to the engineering team and report to the director of engineering, who looks after tools, processes, technical quality and their career development. Day to day, they get requirements and priorities from that product’s product manager, who owns the roadmap and direction.
These are two different scopes over the same person. The engineering team is the developer’s home, and on that product the PM directs the work. Most days, this works without friction.
The gray areas show up in decisions that touch both scopes. Who decides whether the developer spends two weeks paying down technical debt instead of shipping a feature? Who decides whether they leave the product to reinforce another team? The director of engineering manages the person, and the PM is counting on that capacity to meet commitments. Neither should decide alone, and the developer shouldn’t be the last to know.
That’s why it helps more to ask who makes this kind of decision, and who needs to be heard first, than to ask who’s in charge of this person.
On board, this ambiguity is resolved before casting off: the captain and the pilot know who has the conn and under what conditions it changes hands. In teams, that conversation rarely happens.
Conversations need to be clear
An idea that gets shared can go through hypothesis, consultation, proposal and decision. If nobody names the transition between those states, one person may hear “let’s explore” and the other “it’s happening.”
On a ship, the handover of the conn is said out loud on the bridge and logged. Everyone knows who has it at any moment. In a team, that handover is rarely announced.
Ambiguity is stressful
Research on workplace roles points the same way, and it should be read carefully. A recent meta-analysis of 515 studies and around 788,000 workers concluded that role ambiguity was the most harmful stressor for most of the outcomes studied. In the lead author’s words, “role ambiguity, not having enough clarity about your work, was the most detrimental”14. An earlier meta-analysis, with 169 samples and more than 35,000 workers, had already found role ambiguity among the stressors most strongly associated with poorer performance15.
In decision management, the consultancy Bain describes the same pattern. At a carmaker that kept missing deadlines, marketing and product development each believed it was their call to decide the features of new models. The result was decisions revisited over and over, and lost sales. For the authors, the culprit is “Ambiguity over who’s accountable for which decisions”16.
When an invisible red line is crossed
What happens when the agreement only exists in each person’s head.
There are two mistakes an organization can make.
The first happens when limits only become clear after a decision or situation goes wrong. The organization ends up judging people against expectations about those limits that had never been shared.
The second happens when autonomy is read as freedom to change other teams’ direction, commitments, dependencies or scope without consulting them. In that case there’s no longer enough coordination, and trust in the whole process can break down.
Fixing only the first produces teams that decide without looking at others.
Fixing only the second produces teams that ask permission for everything.
A simple request that affects everyone
Real case: a design token system
I lead several design teams, and delegating is part of my day, just like being held accountable. One of the projects where this showed the most happened in the design system team at Namecheap and Spaceship. The business request seemed small: support dark mode. To deliver it, we had to move from simple color palettes and design decisions that could be inconsistent to a semantic design token system. Being demanding, we wanted to do it right.
The implications were huge. In code, implementing a design token system was a breaking change that required rebuilding every component and interface, and each team would have to pause its own projects to migrate to the new tokens. In Figma, every design team had to convert its palettes to the new system, or its mockups would become static and unable to receive updates. That migration couldn’t be done piecemeal, because the two systems can’t, or shouldn’t, live side by side in the product for long.
This is the kind of project where poorly agreed autonomy can go very wrong. If the design system team decided on its own, it would impose costs on the whole company without negotiating them. If every decision needed my approval, the work would be waiting on me, and I’d need the same detailed knowledge the designers were building. We needed to know and define, from the start, who decided what and when others had to be involved. At our scale, it was like entering the harbor: a huge ship, lots of people on board, a narrow channel and little room for improvised maneuvers.
Holding people accountable without precision
Mistakes will happen.
A decision can have reasonable logic and still be poorly aligned or poorly implemented. Admitting this helps avoid two easy conclusions: blaming only the person who decided, or concluding that nobody is responsible.
There have to be consequences…
Useful accountability starts by describing the conduct, the existing expectations and the possible impact. It distinguishes errors of judgment, communication ambiguity, lack of capacity and deliberate non-compliance, which may call for different responses. “There have to be consequences” doesn’t, on its own, explain what failed or how to avoid a repeat.
Some fear that looking at the context of a decision is a way of making excuses. The just culture literature knows this suspicion (“Some suspect a just culture means letting people off the hook”) and answers with a mix of trust, learning and accountability17. Amy Edmondson, who studies how teams learn from failure, gives managers a simple instruction: “Your number one job is to make failure discussable”18.
At sea, accident analysis looks at the whole picture. In November 2007, in thick fog, the container ship Cosco Busan struck the fendering of one of the towers of the San Francisco-Oakland Bay Bridge and spilled around 53,000 gallons of fuel oil into the bay. The US investigators pointed to several factors: the pilot’s performance, an incomplete exchange of information before departure, and “the master’s ineffective oversight of the pilot’s performance and the vessel’s progress.” Among the contributing factors was also the company’s failure to train the crew19. The report weighs the individual decision and the conditions in which it was made, and that’s what makes the analysis fair and useful.
Problem solved, I’ll micromanage
After a mistake, the temptation to add more layers of approval is understandable. Asking for alignment before a decision with significant impact on another team can be good oversight, and so can asking for more visibility after a failure.
The risk of micromanagement grows when review extends to low-risk decisions that had been delegated, when approvals multiply without a clear need, or when there’s no longer any condition for handing autonomy back. The distinction depends on scope, proportionality and duration. Temporary control over one category of decisions can help rebuild trust. Indefinite control over everything can hollow out the role of the person who remains formally responsible. Harvard Business Review sums up the challenge as giving people “the space they need to succeed and learn”20.
On board, taking back the conn has a defined reason and an expected end. In many teams, it happens by reflex and has no end date.
Information published, agreement unconfirmed
On board, handing over the pilot card is only the first step. Incident investigators note that, too often, it stops there: the card was handed over, but the maneuver plan was never reviewed or communicated to the bridge team21.
The same happens in teams. One way to clarify boundaries is to have an overview presentation or a document that’s accessible and agreed by everyone. It makes the change visible, but it doesn’t always confirm that the people affected understood and accepted what changes for them. Whoever proposes a change should identify the critical stakeholders and ask for a concrete answer. Whoever receives that request is also responsible for answering, raising objections and honoring the agreement. Coordination goes both ways.
If the organization only works when someone chases every person across several channels, it’s reasonable to examine the decision system. Not every failure is fixed by adding more individual communication effort.
I speak from experience. In the tokens project, we communicated through many channels: documentation, meetings with stakeholders and a company-wide presentation of the project, all the way to the handoff for implementation. Even so, some teams were surprised by the impact when it was time to migrate. Today I’d have stayed closer to the main stakeholders, to make sure they understood what it meant for them and to give them room to ask questions.
What we can do
Five moves, in time order: before, during and after the decision.
None of what follows replaces judgment. The goal is to reduce ambiguity, and any tool that creates more approvals than clarity needs simplifying. Nor am I suggesting applying everything at once. Each move addresses one part of the problem described above.
1. The conversation before casting off
The captain and the pilot agree on the route before the ship is committed. In a team, the equivalent can be a short delegation agreement.
There’s a way to make the agreement visible without writing manuals. Management 3.0 proposes seven levels of delegation: Tell, Sell, Consult, Agree, Advise, Inquire and Delegate. The starting point is that “Delegation is not a binary thing”22. For each decision area, the team marks how far authority goes and revisits those levels regularly, moving up as maturity grows. For decisions that cut across teams, Bain adds five roles: who recommends, who must agree, who performs, who gives input and who decides16.
I propose a delegation agreement that fits in a seven-row table. There’s no need to document every move. One unambiguous sentence about who decides can prevent several meetings later, and the person taking on the responsibility should also ask when their mandate isn’t clear.
| Question | Agreement to make explicit |
|---|---|
| What result is expected | Result, quality criteria and relevant deadline. |
| Who decides | Autonomous decisions, decisions subject to consultation and decisions that require approval. |
| Who is affected | People and teams whose commitments may change. |
| What the limits are | Capacity, budget, commitments and risks that can’t be taken on unilaterally. |
| When to ask for help | Changes in scope, conflicts, blockers and risks that require escalation. |
| How it’s followed up | A channel and frequency that give visibility without duplicating work. |
| How the agreement is reviewed | Review point and conditions for increasing or reducing oversight. |
Each row matches something the pilot and the captain agree on before casting off. The last one is the most often forgotten: the agreement has a review date and conditions for raising or lowering the level of oversight.
In the token system, that initial conversation set the order of the work. I delegated the exploration to the team’s designers: first they identified requirements and constraints, and only then proposed solutions. My role was just as clear. I brought architecture and development into the discussions so the proposals would be feasible, and kept every affected team informed.
2. The standing orders
The officer of the watch decides alone for hours because they have written orders, always at hand on the bridge. In a team, that role falls to the brief and to a shared record of decisions.
In my team, this agreement lives in two places. The first is the brief. In some projects designers have a lot of freedom to propose and weigh in, and in others we need to deliver exactly what was asked, and I say so from the start. The second is a set of shared documents, accessible to the whole company, where we record the decisions, action points and open questions that come out of regular check-ins. Having a single source of truth keeps the agreement from scattering across private conversations.
A good agreement can also solve two needs at once. In the mobile design system, development needed a single source and design needed two, one for Android and one for iOS. The consensus was to keep two independent Figma libraries and a third that brings them together.
3. Knowing who has the conn
Verbal precision is a cheap form of prevention. “It’s not decided yet.” “I want you to gather the needs.” “We only announce the change after this alignment.” Each sentence says what state the idea is in: hypothesis, consultation, proposal or decision.
Whoever speaks should make the state explicit. Whoever passes the information on should preserve it. If a discrepancy shows up, it’s worth reconstructing the words and the sequence before assigning intent. It’s the equivalent of announcing on the bridge who has the conn.
4. When to call the captain
On board, there are written thresholds for calling the captain and one rule for every other case: when in doubt, call.
An agreement only helps if it’s easy to apply when the decision comes up. In practice, it boils down to a few questions anyone can ask themselves before moving forward. Is this decision clearly within my agreement? Does it change scope, approved direction or commitments? Does it affect other teams’ effort, deadlines or dependencies? Is any approval still pending?
Three principles make these questions useful. When in doubt, ask your direct leadership, without stopping the work that doesn’t depend on the answer. Until a decision is recorded, flag the blocker, and it’s up to whoever has the authority to close the loop. And the path always ends in an action: carry on within the approved conditions, or keep the previous agreement.
Escalation also works from the bottom up. Just as the bridge team does with the pilot, senior professionals are expected to challenge a risky direction, first with a question, then with a suggestion and, if needed, by insisting. Silence from those who report doesn’t validate the decision of the person deciding.
5. Taking back and handing back the conn
When the captain takes back the conn, it’s for a reason known in advance, and the conn goes back to the pilot when that reason goes away. In teams, taking back decisions without saying why or until when is the shortest path to micromanagement.
In the tokens project, I had my own criterion for taking back control. There were several disagreements, and we tried to resolve them with facts and sound counterarguments. The team’s leads took the initiative on many decisions, and I moderated in some situations. I only blocked a decision when there was an impact we hadn’t foreseen or when the effort wasn’t justified by the goal.
Taking back the conn is the easy part. The hard part is the conversation that follows, when you need to understand what went wrong. In maritime accident reports, the analysis starts by reconstructing what each person on the bridge knew, saw and could do at each moment, and only then draws conclusions. It’s a good method for teams too: judge a decision by the information that existed when it was made. What only came to light later is for learning.
Picture a team that changes a shared component and, without knowing it, breaks a flow another team depends on. Before anyone talks about consequences, there are more useful questions. Was the dependency documented anywhere? Who knew about it? Was there a planned moment to validate it? If the information existed and was at hand, there was an error of judgment, and it makes sense to ask for more care. If it didn’t exist, the problem lies mostly in the system, and that’s where to fix it first.
Whatever the answer, the response should be proportional and have a purpose that can be explained: repair what broke, adjust the agreement, provide training, or increase follow-up for a defined period. Correcting a decision and supporting the person who made it belong in the same conversation, and the support can be concrete: revisiting priorities, clarifying who decides, helping repair the relationship with the affected team. Research on job demands and resources points the same way, with a nuance: in a classic study, resources such as autonomy and feedback buffered the effect of demands on burnout, but the effect held in 18 of 32 combinations tested for exhaustion and cynicism, and not for professional efficacy23. Without the means, autonomy becomes a transfer of risk.
Support also means giving the means to those who have to change. In the token migration, we used an AI translator that converted the old classes into the new tokens, and handled by hand the cases with no direct conversion. On the Figma side, the design system team trained the other teams, followed the migration and helped directly in projects to speed it up.
When control increases after a failure, three questions help keep it healthy. Which category of decisions does it cover? Until when? What signals bring autonomy back? Asking for more visibility gains legitimacy when it has a clear purpose, scope and review criteria. It’s the logic of the captain taking back the conn and of the pilotage exemption: few cases, known criteria and a planned return.
So do we always hold people’s hands?
A senior shouldn’t need rules for everything.
Agreed. The goal is to make relevant boundaries explicit and let judgment do its work. Good judgment also includes recognizing when to consult.
After a mistake, the leader has to follow up more closely.
They may have to. Follow-up gains legitimacy when it has a clear purpose, scope and review criteria.
Nobody can guarantee everyone read the information.
True. That’s why changes to commitments need confirmation from the critical stakeholders, beyond publication. It’s also necessary to press those stakeholders for an answer.
Informality makes the organization faster.
It can. The question is whether the initial speed makes up for the cost of repairing incompatible understandings.
Talking about context and support can dilute accountability.
Only if context is used to skip evaluating the conduct. A complete analysis examines both the individual decision and the conditions in which it was made.
The moment of disagreement
A team needs to know what it can decide and should be able to explain how it reached a decision that went wrong. A leader needs to set criteria and make their own criteria understandable.
After a mistake, we can clarify a boundary, fix a commitment, define the context better and improve judgment. We can also add so many approvals that nobody decides anything without permission again. Both paths offer more immediate control. Only the first preserves the team’s ability to work autonomously.
The quality of delegation is also measured in that moment: in what we do with autonomy when it produces a decision we disagree with.
In the token system, the semantic definition stayed largely with the designers. I didn’t fully agree with how deep the dependencies between tokens went. It was logical, but hard to understand and explain. Since this was a system, the choice made rational sense despite the effort needed to understand and implement it, so it stayed.
The core work was done by a small team of designers, with occasional help from others, and it affected every product in the company. Today dark mode is a standard option in all of them, with no extra effort for the teams. Accessibility and minimum contrast for text, icons and other elements are now guaranteed by the system itself. We delivered something many users had been asking for, and the system became the foundation of a more robust design system for both brands, which was later extended to mobile platforms.
At the end of the maneuver, with the ship berthed in Leixões, the pilot says goodbye and climbs down to the boat waiting below. Nobody finds the departure strange, because it was agreed from the start when and how the conn would return to the captain. That’s the kind of delegation worth building: clear on the way in, supported during the maneuver and with no surprises on the way out.
Agree before, follow along during, review after.
The opinions expressed here are my own and don’t represent the position of Namecheap or Spaceship. The examples have been described in a way that respects the confidentiality agreements I’m bound by.
Sources
Each quote is verbatim from the original source, except where marked as my translation. Only a short excerpt is shown per source.
- Decree-Law No. 48/2002 (Portugal), compulsory pilotage areas. Diário da República (official gazette)
- IMPA, Guidance on the Master-Pilot Exchange. Excerpt: “should begin with an exchange of information between the master and the pilot”. impahq.org
- International Best Practices for Maritime Pilotage, section 4.3. Excerpt: “The master retains the ultimate responsibility for the safety of his ship”. UK P&I Club
- IMO Resolution A.960, cited in Steamship Mutual and IMPA material. Excerpt: “to ensure that his/her actions are monitored at all times”. steamshipmutual.com
- MAIB, annexes to the report on the CMA CGM Centaurus (2018). Excerpt: “share a responsibility for good communications”. gov.uk
- Maritime Mutual, analysis of the CMA CGM Centaurus. Excerpt: “obligated to take back the con”. maritime-mutual.com
- The Nautical Institute, via SWZ Maritime (2023). Excerpt: “The “challenge” is a key principle of good bridge resource management”. swzmaritime.nl
- Britannia P&I, webinar Bridge Resource Management under Pilotage (2022). Excerpt: “Ask > Suggest > Insist”. britanniapandi.com
- Bridge procedures manual, University of Rijeka. Excerpt: “available for consultation on the Bridge at all times”. pfri.uniri.hr
- The Swedish Club, Bridge Instructions. swedishclub.com
- Woods Hole Oceanographic Institution, master’s standing orders. Excerpt: “CALL THE MASTER IF IN ANY DOUBT”. whoi.edu
- Ordinance No. 268/90 (Portugal), pilotage license. Diário da República (official gazette)
- Halvard Grøneng, Bridge resource management, a pilot’s perspective, Gard. Excerpt: “easily confused with command to that of a pure advisory role”. gard.no
- Sawhney et al. (2026), A meta-analytic review of 60 years of role stressor research, Journal of Vocational Behavior, 167. Excerpt from the lead author, in an interview: “role ambiguity, not having enough clarity about your work, was the most detrimental”. HCAMag · DOI
- Gilboa, Shirom, Fried and Cooper (2008), A meta-analysis of work demand stressors and job performance, Personnel Psychology, 61(2). Abstract at Lancaster University
- Paul Rogers and Marcia Blenko (2006), Who has the D?, Bain & Company / Harvard Business Review. Excerpt: “Ambiguity over who’s accountable for which decisions”. bain.com
- Sidney Dekker, Just Culture. Excerpt: “Some suspect a just culture means letting people off the hook”. Taylor & Francis
- Amy Edmondson, interview in Harvard Business School Working Knowledge. Excerpt: “Your number one job is to make failure discussable”. library.hbs.edu
- NTSB, Cosco Busan accident (2007). Excerpt: “the master’s ineffective oversight of the pilot’s performance and the vessel’s progress”. gCaptain · Professional Mariner · NTSB
- Rebecca Knight (2015), How to Stop Micromanaging Your Team, Harvard Business Review. Excerpt: “the space they need to succeed and learn”. hbr.org
- CHIRP, Correspondence: Incidents Under Pilotage. chirp.co.uk
- Management 3.0, Delegation Poker & Delegation Board. Excerpt: “Delegation is not a binary thing”. management30.com
- Bakker, Demerouti and Euwema (2005), Job resources buffer the impact of job demands on burnout, Journal of Occupational Health Psychology, 10(2). DOI