Tech Spec Review

As the organization starts to write more Technical Specifications, you’ll eventually want a forum to discuss the key decisions. At most companies, that meeting is the Tech Spec Review.

The Tech Spec Review is a forum to review feedback on new Tech Specs, resolve open points of discussion, and flag new context to be considered before finalizing the design. Secondarily, it’s a valuable forum for keeping the wider organization aware of new and upcoming technology changes.

Goals

• Drive consistent technical decision making. Much of the value from your technology strategy comes from its consistent application, and this meeting should support consistency. The review is a particularly valuable source of problems to inform your technology strategy
• Role model good technical decision-making and discussion. Your organization will learn what good technical decision-making looks like from this meeting. Proactively coach folks giving feedback in both good (“keep doing that!”) and ineffective (“in the last meeting, …”) feedback
• Prevent teams from pursuing local maxima in ways that are misaligned with the company. For example, a given project might benefit from introducing a new database, but the cost to the company to support business continuity, privacy auditing, and so on might outweight the project’s benefits
• Avoid the Tech Spec Review anti-patterns. Don’t be a domineering review, bottlenecked review, status-oriented review, or an inert review. As a key forum for resolving technical disagreement, there are many ways for Tech Specs Reviews to fail. Avoiding these anti-patterns requires ongoing, proactive attention from the Tech Spec Review’s sponsoring leader

Agenda, Scheduling, and Scaling

The default approach here is to run them on a weekly cadence, sending out Tech Specs for discussion two days ahead of the meeting, requiring all attendees to read the specs before the meeting, and canceling meetings ahead of time when there are no specs to review.

That said, most organizations end up with a fairly custom approach to this meeting. When your organization is small, you can likely do on-demand reviews for each Tech Spec. This allows the team to get comfortable reviewing and being reviewed without the risk of “running over time” and preventing another spec from getting discussed.

As your organization grows, it will typically become hard to schedule all stakeholders into a on-demand meetings, and you’ll typically move into a standing meeting. Each standing meeting should discuss one to three reviews, depending on the size of open decisions. You can experiment a bit with format here: you might be able to review five specs in five minutes if it’s just a matter of approving unless there are any additional concerns to flag.

There are many ways to scale this meeting. Some organizations rely on asynchronous review for most specifications, and only bring “controversial” specs to the synchronous review. Some organizations hold multiple Tech Spec Reviews, sharded by area: one for Product Engineering, one for Infrastructure Engineering, and so on. Ultimately, I recommend actively experimenting with your approach based on the specific issues you’re running into with the meeting. There are general solutions, but each company uses this meeting in a somewhat different way, so adopting the standard solution may not work well for your needs.

Roles & Attendance

There are four key roles in the Tech Spec Review:

• Facilitator who coordinates the agenda and the conversation. This is generally either a Staff Engineer, a Technical Program Manager, or a partnership of the two
• Presenter who has written the Tech Spec being discussed
• Notetaker who ensures notes from the discussion are captured
• Attendees who share context, ask questions, and participate in the discussion. Some companies restrict attendance because too many folks attend and want to “demonstrate value” by asking questions, or unconstructively inject their personal preferances rather than prioritizing the organization’s perspective. Generally, I think it’s better to allow open attendance and give direct, firm feedback to those who attend unconstructively. If folks feel like they must attend to avoid bad decisions impacting their team, then you should probably consider creating more visibility into Tech Specs outside of this meeting, via either chat or email
• Sponsor who provides organizational weight to the meeting through their participation, this is generally either the head of engineering, a Staff Engineer serving as the head of engineering’s right hand, or a manager reporting directly to the head of engineering

Is it working?

Some questions to ask when considering if your current Tech Spec Review is working:

• Do you have Tech Specs coming in for review? If not, is it because the review isn’t useful? Is the review too intimidating? Are folks not sure how to submit new specs?
• Are too many reviews coming, such that feedback is slowing down execution? Is there a set of category-wide decisions you could make that would reduce the need for certain kind of Tech Specs (e.g. auto-approve specs that use the common storage and compute tiers)?
• Are reviews generally getting to the right decisions? Are the right concerns being raised, but getting rejected because the presenters don’t engage with feedback? Conversely, is it because the review lacks the necessary authority to succeed in your company?
• Are discussions generally on topic? Do some participants routinely derail discussion? How could you prevent that pattern from reoccuring?
• Do attendees enjoy attending?