Leadership, influence and decision-making

Leading without authority

Most architects do not manage the people who build what they design. Teams report to engineering managers, priorities belong to product managers, budgets to directors. Yet the architect is expected to make sure significant decisions are made well and kept true across many teams, which is the core responsibility described in Section 1.4. The gap between responsibility and formal authority is the defining condition of the job, and closing it is a matter of influence.

John French and Bertram Raven's classic study of social power (1959) distinguished bases of power that come with a position (legitimate authority, the ability to reward and the ability to punish) from those that belong to a person (expertise and referent power, the respect and identification others feel); Raven later added informational power, the ability to bring facts that change minds. Architects rarely hold much positional power, and when they do, using it is costly: a decision imposed by rank is complied with, not owned, and the people who disagreed stop telling you about problems. Durable architectural influence rests almost entirely on expertise, information and relationships.

This is not a soft skill bolted on to technical work. A sound design that nobody adopts has the same effect as no design at all, and a mediocre design that teams understand and support often outperforms a brilliant one they work around. The rest of this section treats influence as a set of practices that can be learned: building trust, facilitating decisions, handling conflict, communicating upwards, growing other people and avoiding the traps that groups fall into.

Building trust and credibility

David Maister, Charles Green and Robert Galford's The Trusted Advisor (2000) offers a useful model. Trust grows with credibility (you know what you are talking about), reliability (you do what you say), and intimacy (people feel safe raising difficult things with you), and it shrinks with self-orientation (the sense that you are serving your own interests, such as being right, looking clever or protecting your design). The model's insight for architects is that self-orientation sits below the line: it divides everything else. An architect who is brilliant and dependable but visibly needs to win every argument is not trusted.

In practice, credibility is built in small, visible ways. Be right about small things before asking to be trusted on big ones. Stay close enough to the code to understand its real cost: write the spike, review the pull request, sit in on an incident review. Say what you do not know and how you would find out. Follow through on every commitment, especially the dull ones. Give credit publicly and take responsibility for your own mistakes, also publicly. Explain the reasoning behind every principle so that people can apply it in situations you did not foresee.

Trust also depends on the climate around you. Amy Edmondson's research on psychological safety, beginning with a 1999 study of work teams, found that teams in which members believe it is safe to admit mistakes and challenge others learn more and perform better. Architects shape that climate more than they realise. Reacting to bad news with curiosity rather than blame, inviting objections explicitly (what would make this fail?) and thanking people who raise them are what make it possible to hear about a flawed design while it is still cheap to fix.

Facilitating decisions

Many architecture arguments are really arguments about process: who gets to decide, who must be asked and how disagreement will be settled. Settling decision rights before discussing the substance removes much of the heat. Section 11.4 described the advice process, in which anyone may make a decision provided they seek advice from those affected and those with expertise; other organisations use an architecture review forum, a named decision owner per domain, or role charts such as RACI. The specific mechanism matters less than its being known in advance.

Within whatever decision rights apply, the architect is often the facilitator: the person who frames the question, makes sure the right people and evidence are present and steers the group to a decision that sticks. Different decision methods suit different situations, and choosing the method deliberately is part of the job.

Two methods are often confused. Consensus seeks a proposal that everyone actively supports; it builds strong commitment but is slow and gives any one person an effective veto. Consent decision-making, developed in Gerard Endenburg's sociocracy in the Netherlands from the 1970s, adopts a proposal unless someone raises a reasoned objection that it would cause harm or move the group backwards. The question changes from do you all agree? to can anyone not live with this, and why? A phrase from sociocratic practice captures the threshold well: good enough for now, safe enough to try. Consent works particularly well for two-way-door decisions, which can be revisited as evidence arrives. The IETF's rough consensus, described in Section 4.8, is a close relative.

When agreement cannot be reached, someone must decide, and it should already be clear who. Disagree and commit, also discussed in Section 4.8, asks people to argue their case fully before the decision and to support it fully afterwards. It works only if the disagreement was genuinely heard, the dissent is recorded (in the architecture decision record, with its reasons) and there is an agreed signal that would reopen the question.

Conflict and organisational politics

Organisational politics is simply how groups with different interests, limited resources and their own careers reach decisions. It is not a corruption of architecture work but its environment. Ignoring it does not make an architect principled, only less effective. The tools from earlier chapters apply directly: the stakeholder map and power/interest grid from Section 1.5 show who is affected and who can block, and the trade-off records from Section 1.6 make positions visible.

Roger Fisher and William Ury's Getting to Yes (1981) remains the most useful guide to principled negotiation, and its four ideas translate directly. Separate the people from the problem: the payments lead is not obstructive, she is worried about card data. Focus on interests, not positions: we must not use Kafka is a position, we cannot take on more on-call load is an interest that several designs could meet. Invent options for mutual gain before deciding. Insist on objective criteria, agreed before options are compared. Their idea of the best alternative to a negotiated agreement (BATNA) is useful too: knowing what happens if no agreement is reached tells everyone how much the agreement is worth.

Kenneth Thomas and Ralph Kilmann's conflict-mode model (1974) describes five ways of responding to conflict, according to how much weight you give to your own concerns and to the other party's. None is always right; the skill is choosing deliberately rather than falling back on habit.

Some practical habits help in every case. Never surprise a stakeholder in a public meeting with a proposal that affects them; talk to them first, one to one (Japanese organisations call this preparatory consultation nemawashi). When escalation is needed, escalate together: both parties present the disagreement and the options to the person who can decide, rather than each lobbying separately. And keep disagreements about designs separate from judgements about people, in what you say and in what you write.

Communicating with executives

Section 4.8 covered tailoring a message to its audience and leading with the answer. Executives deserve a little more attention, because they hold the budgets and the authority that architecture work depends on, and because architects most often lose them by explaining too much and asking too little.

Frame every topic in the terms executives already manage: revenue, cost, risk, time to market, customer experience, regulation and people. Bring options rather than a single plan, each with its cost, its risk and what it gives up, and say which you recommend and why. Quantify where you honestly can, and say how confident the numbers are; a range with a stated basis is more credible than false precision. Be explicit about the decision or support you need from them and by when. Prepare for the question what would you do if this were your money? And never let an executive learn of a serious risk first from someone else.

Senior people are often less interested in how a system works than in whether its owners are in control of it. Showing that risks are known, owned, measured and being reduced (for example through an architecture risk register or the fitness functions of Section 11.3) builds more confidence than any diagram. Section 11.8 shows how to put architecture work into the form executives use to compare investments: the business case.

The architect elevator

Gregor Hohpe's The Software Architect Elevator (O'Reilly, 2020) gives the most memorable picture of this work. Large organisations are like tall buildings. In the penthouse, executives set strategy and budgets; in the engine room, engineers build and run the systems; many floors of management sit in between, and information passing through them is filtered and distorted on the way. Hohpe's architect elevator rides between the penthouse and the engine room, carrying information in both directions: taking strategy and its reasons down to the people building systems, and taking technical realities (constraints, risks, costs and options the business did not know it had) up to the people making strategic decisions.

Hohpe's point is that the architect's value lies in connecting the floors. An architect who stays in the penthouse becomes an ivory-tower strategist whose plans ignore what is technically possible; one who stays in the engine room becomes a respected expert whose warnings never reach the people who could act on them. Riding the elevator well means changing language and level of detail at each floor without changing the substance, which is exactly the audience skill of Section 4.8 applied to a whole organisation.

Growing other architects

An architect who makes every significant decision personally becomes a bottleneck, and the organisation's architectural capability leaves with them. Growing others is therefore part of the role, not an optional extra. It helps to distinguish three activities. Mentoring shares your experience and advice. Coaching asks questions that help someone reach their own answer, which builds judgement faster. Sponsoring uses your credibility to give someone opportunities: recommending them to lead a design, putting their name on the proposal, inviting them to the executive meeting.

Practical techniques include pairing on designs and reviews, letting less experienced engineers write the ADR for a decision and reviewing it with them, running architecture katas (Section 11.2) as practice, delegating decisions within stated guardrails, and narrating your reasoning aloud during design discussions so that others can see how trade-offs are weighed rather than only the conclusion.

Many organisations now offer a technical career path parallel to management. Will Larson's Staff Engineer: Leadership beyond the management track (2021) popularised the term staff-plus for staff, principal and more senior individual contributors, and described four common archetypes from interviews with people in those roles. Tanya Reilly's The Staff Engineer's Path (O'Reilly, 2022) organises the work around big-picture thinking, executing large projects and levelling up the engineers around you. In her 2019 talk "Being Glue", Reilly also drew attention to the coordinating work (unblocking people, writing the missing document, noticing the gap between teams) that keeps projects alive but is often not rewarded in promotion; architects should notice who does it and make sure it counts.

Decision traps revisited

Section 1.6 listed the individual biases that distort architectural decisions: anchoring, sunk cost, groupthink, résumé-driven development, hype and confirmation bias. Leading decisions among groups adds traps of its own, which come from status, fatigue and organisational momentum rather than from individual reasoning.