Scaling technical consistency.

In small organizations, it’s easy for folks to be aware of what others are doing and to remember how you’ve previously approached similar problems. This hive mind and memory creates a consistency to decision making that correlates strongly with quality. As organizations grow, there is a subtle slide into inconsistency, which is often one of the most challenging aspects of evolving from a small team into a much larger one.

There are many different approaches to try to manage inconsistency creep. Some of the solutions I’ve seen are formalized sprints, training, shadowing, documentation, code linters, process automation (particularly deploys) and incident reviews. However, when the problem becomes truly acute, I’ve found that folks eventually reach for the same tool: adding a centralized, accountable group.

The two most common flavors of this I’ve seen are “product reviews” to standardize product decisions, and the “architecture group” to encourage consistent technical design. There are hundreds of varieties, and they crop up wherever decisions are made.

Some of these groups take on an authoritative bent, becoming rigid gatekeepers, and others become more advisory, with a focus on educating folks towards consistency. Depending on your culture and how you value consistency, there are an infinite number of approaches, and designing an effective decision making group depends on a handful of core decisions.

Positive and negative freedoms

Before jumping into design, a few words on the framing I use for reasoning about when to create a new centralized authority.

These groups typically consolidate significant authority from the broader community into the hands of a few. Many folks will feel a significant loss of freedom when you create these groups, as their zone of decision making will be newly limited. Less obviously, many folks find the creation of centralized groups to be extremely empowering. The difference? The first group is largely populated by folks comfortable with self-authorization, and the latter typically have a higher threshold for self-authorization.

This is just one example of the dynamics that play out across many dimensions when you’re considering introducing a new authority, and the most useful framework I’ve found for thinking through this is positive and negative freedoms. A positive freedom is the freedom to do something, for example the freedom to pick a programing language you prefer. A negative freedom is the freedom from things happening to you, for example the freedom not to be obligated to support additional programming languages, even if some folks would greatly prefer them.

How are you shifting freedoms, and who are you shifting them from? Particularly in cases where ownership is extremely diffuse, I believe cautiously authoritative groups do increase net negative freedom for folks with little reduction to positive freedom. That also happens to be my goal when designing a new group!

Group design

Now that you’ve decided to create a decision making group, it’s time to get into the choices!

• Influence. How do you expect this group to influence results? Will they be an authoritative group that makes binding decisions? Will you rely on the natural authority of the members you select? Will they primary work through advocacy? This, along with the particular folks in the group, will be the primary factor in how your group impacts the positive and negative freedoms of those they work with.
• Interface. How will other teams interact with this team? Will they submit tickets, send emails, attend a weekly review session? Will you be reviewing work before it launches, or previewing designs before they’re staffed? Depending on the kind of influence they’re exerting and how your company works, you’ll want to play around with different approaches.
• Size. How large should the group be? If it’s six or fewer folks, it’s possible for them to gel into a true team, that knows each other well, works together closely, and who shift a significant portion of their identity into the team. If it’s more than ten, you’ll find it hard to even have a good discussion, and it’ll need to be structured into sub-groups to function well (rotation that spreads them over time, working groups of some members to focus on particular topics, etc). The larger the group, the more responsibility becomes diffuse, and the more you’ll need to have specified roles within the group, for example a member responsible for coordinating their focus.
• Time commitment. How much time will members spend working in this group? Will this be their top priority, or will they still primarily be working on other projects? Higher time commitment correlates with more actions and decisions. Consequently, my sense is that you want time commitment to be high for areas where folks are directly impacted by the consequences of their decisions, and to be lower for scenarios with weaker feedback loops.
• Identity. Should members view their role in the group as their primary identity? Should they continue to identify primarily as members of their existing team? You’ll need a small team and high time commitment to support folks shifting their identity.
• Selection process. How will you select members? I’ve found a structured selection process to work best, identifying the requirements to be a member and also the skills that you believe will be valuable, and then allowing folks to apply. Membership in these groups often becomes an important signal of organizational status, which makes having a consistent process for selecting membership especially important.
• Length of term. How long will members serve for? Are these permanent assignments, or are they fixed terms for say six months? If they are fixed terms, are folks eligible for subsequent elections? Is there a term limit? Having tried most combinations, my sense is that the best default is fixed terms, while allowing current folks to remain eligible, and without enacting term limits.
• Representation. How representative will this group be? Will you explicitly select folks based on their teams, tenure or seniority, or will you allow clusters? Attention to this can help you avoid architecture reviews missing frontend and product engineers, as well as product reviews without infrastructure perspective.

Predictably, each of these decisions will impact the effectiveness of the others, which can make designing the group you want quite tricky. Some formats will require particular kinds of folks to staff them, and you have to design groups that will work with the folks available to participate and the culture they are participating within.

Failure modes

Before you release that email you’re writing to spin up a new centralized decision-making group, it’s worth talking about the four ways these groups consistently fail. They tend to be domineering, bottlenecks, status-oriented or inert.

• Domineering groups significantly reduce folks’ negative and positive freedoms, and become churn factories for folks. This is most common when folks making decisions are abstracted from the consequences of the decisions, e.g. architecture groups where the members write little code.
• Bottlenecked groups tend to be very helpful, but are trying to do more than they’re actually able to do. These groups get worn down, and either burn out their members or create a structured backlog to avoid burning themselves out, which ends up seriously slowing down folks who need their authority.
• Status-oriented groups place more emphasis on being a member of the group than on the group’s nominal purpose. The value of the group revolves around recognition rather than contribution, leading to folks who try to join the group for status, and the diffusion of whatever original mission the group set out to resolve.
• Inert groups just don’t do much of anything. Typically these are groups where its members have not gelled or are too busy. On the plus side, this is by far the most benign of the four failure modes, but you’re also missing out on a great deal of opportunity!

Having experienced each of these a few times, I try to ensure there is a manager embedded into every centralized group, and that the manager is responsible for iterating on the format to dodge these pitfalls.

How are you using centralized groups in your company? What have you seen work well?