Engineering Leadership: Balancing Autonomy, Growth, and Culture with Michael Gray
- Aisha Washington
- 1 day ago
- 7 min read
Engineering organizations often want two things that appear to conflict: teams capable of acting independently and enough coordination to prevent fragmented systems. As a company grows, resolving that tension becomes harder. More people, services, and dependencies create legitimate reasons for oversight, yet excessive centralization can slow delivery and weaken engineers’ sense of ownership.
In this InfoQ conversation, Michael Gray describes how ClearBank approaches that challenge through distributed architectural decision-making, explicit boundaries, and a culture of continual learning. His broader message is that autonomy does not mean removing governance. It means designing governance so that decisions are made at the appropriate level, supported by durable context and constructive challenge.
From Architecture Approval to Architecture Advice
Traditional architecture review processes tend to concentrate authority in a small group. Teams develop a proposal, present it to a review board, and wait for approval. Although this model can create consistency, it can also turn architects into gatekeepers and delivery teams into petitioners. Decisions become tied to meetings, calendars, and the opinions of people who may be distant from the operational details.
Gray explains that ClearBank moved away from this centralized review pattern toward an architecture advice process influenced by Andrew Harmer-Law’s work. The emphasis shifts from asking a central body for permission to seeking relevant expertise before making a consequential choice.
That distinction matters. An approval process asks, “Will the authority allow this?” An advice process asks, “Whose knowledge should inform this decision, and how will we demonstrate that we considered it?” The latter keeps responsibility closer to the engineers doing the work while still exposing proposals to informed scrutiny.
Architecture decision records, or ADRs, are central to this model. Rather than treating a meeting as the decision itself, teams document the problem, relevant constraints, options considered, selected approach, and reasoning. Gray argues that these records provide more useful context than conventional meeting minutes. Minutes usually capture what people said; a strong ADR explains why the organization chose one path over another.
The long-term benefit is organizational memory. Months later, engineers can understand whether an old decision remains appropriate or whether its original assumptions have changed. That makes architecture easier to revisit without pretending every past choice was meant to be permanent.
Matching Authority to the Scope of a Decision
Distributing decisions effectively requires more than telling teams to be autonomous. People need to know which choices they can make independently, when other teams must be involved, and which matters require organization-wide coordination.
Gray describes ClearBank’s use of “decision scopes” to establish those boundaries. Decisions fall into three broad levels:
A team-level decision can be made within the team when its consequences remain local.
A domain-level decision affects several teams in a related area and therefore requires broader consultation.
An enterprise-level decision has implications across the company and must pass through a centralized advisory forum.
This structure prevents two common failures. The first is unnecessary escalation, where teams seek senior approval for reversible, local decisions. The second is false autonomy, where one group makes a choice that imposes costs or constraints on many others without involving them.
The useful principle is proportionality. A decision’s governance should reflect its blast radius. A local implementation detail should not carry the same organizational burden as a change to an enterprise-wide platform, security control, or architectural standard.
Clear scopes also make accountability more credible. Engineers can act confidently when the boundaries are understood, while leaders retain a mechanism for handling decisions whose consequences extend well beyond one team.
The Architecture Advisory Forum as a Coordination Mechanism
For enterprise-level decisions, ClearBank uses an Architecture Advisory Forum. Gray presents it as a place to collect input and establish stakeholder support rather than simply issue top-down verdicts.
This is an important difference in tone and function. A forum designed only to approve or reject proposals can encourage teams to hide uncertainty and arrive with a polished defense. An advisory forum can instead surface unresolved risks, identify affected groups, and improve the proposal before the organization commits to it.
The forum also helps distinguish consultation from consensus. Broad input is valuable, but requiring universal agreement can make important decisions impossible. The aim is to ensure that relevant perspectives are heard, material concerns are addressed, and the accountable decision-maker has enough information to proceed.
When this mechanism works, central coordination does not erase local ownership. It provides a structured way to manage cross-company consequences while leaving most choices where the practical knowledge resides.
Resisting the Feature-Factory Trap
Gray also addresses the technology industry’s pressure to “do more with less.” Efficiency is a reasonable concern, especially when budgets tighten, but its definition can become dangerously narrow. If leaders measure productivity mainly by the number of features released, teams can drift into a feature-factory mentality.
The immediate output may look impressive. Over time, however, neglected maintenance, weak developer tooling, architectural friction, and unresolved quality problems make every subsequent change more expensive. Teams lose the capacity to experiment because they are continually racing to meet the next delivery target.
Gray connects leadership directly to the response. Leaders must model continuous improvement, protect space for it, and explain its value to senior stakeholders. It is not enough to tell engineers that quality matters if every planning and performance signal rewards only visible feature work.
This advocacy becomes easier when technical improvement is connected to business outcomes. Better deployment processes can reduce lead time. More reliable systems can lower incident costs. Simplified architecture can shorten onboarding and make product changes safer. Continuous improvement is therefore not separate from value creation; it preserves the organization’s ability to create value repeatedly.
Leaders also shape culture through the trade-offs they make publicly. When they consistently sacrifice foundational work under deadline pressure, teams learn that improvement is optional. When they treat system health and learning as part of delivery, those priorities become credible.
Preserving Culture Through Rapid Growth
Growth tests culture because informal coordination stops scaling. In a small organization, people can rely on shared history and frequent direct conversation. As headcount rises, new employees arrive without that context, teams specialize, and ownership becomes less obvious.
Gray says ClearBank maintained its culture by creating clear boundaries and ownership while encouraging open communication and knowledge sharing. Its architecture advice process reinforces both goals: teams receive meaningful authority, but decisions remain visible and open to input.
This suggests that culture is not preserved by slogans or nostalgia for the company’s earlier stage. It is encoded in operating mechanisms. Who is allowed to decide? Where can someone find the reasoning behind an architectural choice? How are lessons shared? What happens when an engineer raises a concern?
Explicit ownership reduces ambiguity, while transparent decision records prevent autonomy from turning into isolation. Knowledge-sharing initiatives help people discover work outside their immediate teams and reduce dependence on a handful of long-serving employees.
The balance is delicate. Too little structure creates confusion; too much replaces judgment with bureaucracy. Gray’s approach treats boundaries as an enabler: teams move faster when they know where their authority begins, where it ends, and how to obtain advice when a decision crosses that line.
Closing the Engineering Skills Gap Through Mentoring
Gray identifies a significant experience gap across the engineering industry. Many practitioners have entered the field relatively recently, leaving organizations with fewer deeply experienced engineers relative to the number of people who need guidance.
Hiring alone cannot solve that imbalance. Experienced engineers are scarce, and recruiting them simply moves capacity between companies. Organizations must become better at developing the people they already have.
Gray highlights mentoring as a particularly effective mechanism. Its impact extends beyond a single mentor-mentee relationship. A person who gains a clearer mental model or learns a stronger engineering practice can carry that knowledge back to an entire team.
Effective mentoring is also broader than giving answers. It helps engineers learn how to frame problems, evaluate trade-offs, seek relevant advice, and communicate uncertainty. Those capabilities support the distributed decision model Gray describes: autonomy is sustainable only when people are continually building the judgment required to exercise it.
Leaders should therefore treat mentoring as real engineering work, not an extracurricular favor performed after delivery obligations are met. If knowledge transfer is essential to organizational resilience, it deserves time, recognition, and deliberate support.
Making Feedback Useful, Timely, and Safe
Autonomous organizations depend on people being able to challenge ideas. Yet a technically correct objection can still be ineffective if it is delivered without regard for context.
Gray stresses the importance of timing, setting, and approach when giving feedback. A public challenge may be appropriate when an immediate risk affects the wider group, but the same delivery can feel humiliating when the issue would be better discussed privately. Feedback offered too late may no longer be actionable; feedback offered too abruptly may provoke defensiveness before the substance can be considered.
The objective is not to avoid disagreement. It is to make disagreement productive. Useful feedback focuses on the proposal and its consequences, explains the concern clearly, and leaves room for missing context. Questions can often open a better conversation than declarations: What assumptions support this choice? Which alternatives were considered? Who else will be affected?
This interpersonal discipline is part of engineering effectiveness, not a soft addition to it. Advice processes, ADRs, mentoring, and cross-team forums all rely on people exchanging criticism without turning every challenge into a contest for status.
Leadership as the Design of an Environment
The ideas in Gray’s discussion form a coherent leadership model. Teams receive authority within explicit decision scopes. Wider consequences trigger wider consultation. ADRs preserve reasoning, advisory forums coordinate enterprise concerns, and mentoring expands the organization’s capacity for sound judgment.
Meanwhile, leaders protect the conditions that make autonomy sustainable: time for improvement, transparent ownership, knowledge sharing, and feedback delivered with care. Their job is not to make every technical decision. It is to build an environment in which good decisions can be made, examined, recorded, and improved by others.
That may be the most practical lesson for scaling engineering organizations. Autonomy, growth, and culture are not separate programs competing for attention. Properly designed, each reinforces the others: capable people make distributed decisions, transparent systems keep those decisions aligned, and a learning culture helps the organization improve as its complexity increases.
