Infrastructure Engineering

Book

Mon, 16 Jan 2023 07:00:00 -0700

Suggestions? Take a look at ‘Want to help?’ section on About.

This is the in-progress version of Infrastructure Engineering.

Mon, 16 Jan 2023 07:00:00 -0700

Hey folks! I’m Will Larson, sometimes known by Lethain, and this is the Infrastructure Engineering. Infrastructure software engineering impacts the professional lives of every software engineer deeply, and subtly shapes the products and platforms our companies build, but relatively little is written about running an effective infrastructure engineering organization.

Hopefully these interviews and guides will do a bit to help with that!

Tech Spec Review

Mon, 16 Jan 2023 07:00:00 -0700

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.

Related tools

Tech Spec

Related meetings

Incident Review

Other approaches to Tech Spec Reviews

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?

Meetings

Mon, 16 Jan 2023 07:00:00 -0700

Incident Review

Thu, 05 Jan 2023 07:00:00 -0700

I’ve never heard of a company that has a business, that doesn’t also occasionally have things go wrong. Something going wrong might turn into a support ticket, an angry email, or an alert popping up on an on-call engineer’s phone. If there is user or business impact, and an engineer might need to respond, then it becomes an incident.

After the incident, the folks involved in mitigation write an Incident Review Template, and the that document is discussed in this meeting, the Incident Review.

Related Tools

Incident Review Template

Other Approaches to Incident Review

PagerDuty

Goals

Incident Reviews are a cultural carrier meeting for most engineering organizations. They are a rare meeting where you will see a wide mix of teams and seniority-levels arguing about something that the business cares about deeply: customer and employee impact. A well-run Incident Review helps new employees quickly understand how your culture works when things really matter.

An effective Incident Review facilitates these goals:

Foster and socialize learning about what caused an incident: incidents have a certain inherent rhythm, and the only way to change it is to ensure others are aware. The most valuable thing this meeting does is create awareness of what has actually happened in a given incident, which is the precursor to preventing a repeat
Surface missing context across teams and functions: customer success might mention an impact to users, an infrastructure engineering team might mention that the incident had a wider impact than initially recognized, a product engineering team might explain the business cost of delayed message processing
Inform investments on work that will best contribute to increased reliability: broaden an ongoing investment project to support a new edgecase, cancel a previous mitigation effort based on improved understanding of the underlying issue, recognize that similar issues are repeating without being successfully addressed

Anti-goals

Because of this cultural significance, Incident Reviews also have a predictable tendency to become ideological arenas, and to attract participants with ideological goals about the right way to foster reliability, run reviews, etc. Your goal as the senior leader who owns this meeting is to prevent it from becoming an open ideological discussion forum, and to instead focus it on the specific agenda at hand.

Several patterns to be wary of:

Ensuring adherance to documented process: some review meetings become focused on driving adherance to the specified incident response or review process. That is valuable work, but ineffective to conduct in a large, learning-oriented forum. Instead, drive adherance before the meeting
Pedantic or status-oriented: a surprising number of incident discussions end up orienting around policing correct nomenclature rather than encouraging learning and growth. Effective reviews are progress-oriented, with practioners who explain important context when additive, but don’t orient around policing correctness
Public performance of a one-person play: effective learning meetings don’t spend much time reading materials or reports out loud. The entire time should be devoted to discussion, perhaps with a short initial window for attendees to read the report. Learning is a group activity, wbhereas readouts as a solitary performance
Public performance of two-person play: some meetings adopt a consistent chorus across sessions. A certain set of questions, e.g. “How did you first become aware of this issue?”, will be asked and answered at each session, consuming much of the time. That feels useful, but it implicitly silences the wider group, who are not able to contribute their context and encourage group learning

Finally, like any important, large meeting, there may sometimes be individuals who are more focused on their personal ideological goals rather than the meeting’s goals, and it’s your responsibility to either anchor them on the meeting’s goals or get them out of the meeting so work can be done.

Agenda, Scheduling, and Scaling

The agenda for every incident review is discussion of one to two individual incidents or a cluster of related incidents. The agenda should be decided one to two days ahead of the review, and shared out with attendees to allow them to prepare. Because most learning occurs in discussion, I recommend against trying to include more than two incidents (or one batch of related incidents) in a given session.

Run these on a weekly cadence, canceling ahead of time when there are no incidents to review.

If you start to have backlog of incidents to review, then you have three options:

Batch related incidents if you have a cluster of incidents with shared contributing causes. For example, you might have a streak of incidents related to database instability caused by unindex queries, which would benefit from one curated, joint discussion rather than treating each as an independent incident
Extend review time for one week to have more incident review bandwidth. This works best when you have a short-term spike in incidents. Generally speaking, it is an organizatonal smell to permanently extend incident review beyond an hour a week for a large audience, as it’s an expensive investment of time
Stop discussing lower severity incidents in the review. For example, only discuss incidents with “significant” customer or internal impact, coupled with a simple definition of what incidents would fall beneath the line

Roles & Attendance

There are five key roles in an Incident Review:

Facilitator who coordinates the agenda and the conversation
Presenter who filled in the Incident Review Template for a given incident
Notetaker who ensures notes from the discussion are captured
Attendee who share context, ask questions, and learn from the discussion
Sponsor who provides organizational weight to the meeting through their participation, this is generally either the head of engineering or the head of infrastructure. It is reasonable for the Sponsor to occasionally miss, but I believe it’s essential for them to attend the majority of incident reviews

The Incident Reviews goals, particularly around learning and surfacing missing context, encourage a wide audience of attendees. I recommend allowing anyone to participate so long as they read–and abide by–the meeting’s goals and anti-goals. Ensuring folks act in accordance with the meeting’s goals is a joint responsibility of the Facilitator and the Sponsor.

Is it working?

Some questions to ask yourself if you’re unsure if your meeting is useful:

Are they getting scheduled? If that’s because you’re truly not having incidents, great! Conversely, if it’s because folks are not filling in the template, then dig into why not. Often these templates get overloaded with many questions to please many stakeholders, and consequently become difficult to use
Are key personnel attending? Particularly the sorts of folks who have important context to bring into the discussion. If the meeting is working, these should be an exceptionally high-leverage opportunity to grow the organization
Are the discussions resulting in a modified reliability strategy or roadmap? If these discussions are driving learning, then they should alter the shape of your roadmap
Do you enjoy attending?

Tools

Thu, 05 Jan 2023 07:00:00 -0700

Matthew Clarke

Wed, 11 May 2022 08:15:00 -0700

Manager

Wed, 11 May 2022 08:15:00 -0700

Interview

Wed, 11 May 2022 08:15:00 -0700

Suggestions? Take a look at ‘Want to help?’ section on About.

Folks who have shared their infrastructure engineering wisdom:

Mahdi Yusuf

Tue, 03 May 2022 14:00:00 -0700

Shawn Wang / swyx

Mon, 11 Apr 2022 08:00:00 -0700

Developer-Experience

Mon, 11 Apr 2022 08:00:00 -0700

Smruti Patel

Sun, 10 Apr 2022 07:00:00 -0700

Contract Negotiation Checklist

Mon, 04 Apr 2022 07:00:00 -0700

Fork this template on Google Docs

Negotiating contracts is an important part of managing costs, but it’s also something that you only do infrequently. Particularly in an earlier stage company, you might only negotiate one large contract a year. It’s quite hard to get better at something that you do so infrequently, but using a checklist is one way to be consistent in your approach, and to ensure learnings from one negotiation carry over into the next.

Contract Negotiation Checklist

There’s no perfect checklist: you should customize the checklist for your company based on your process, preferences and the experience level of those who are involved. If this feels too heavy, then by all means remove some steps.

More Readings On Vendor Negotiations

How to Use

Fork this template on Google Docs
Follow the template’s checklist
Link your template into an internal repository of all negotiations so folks can find it the next time you’re negotiating this or related contracts
Now you’re done!

Tips

Negotiating contracts is a learned skill, and you’re probably not going to be good at it for the first few. That’s ok! Find someone else with more experience to partner with on your first few, even if it’s just asking a more experienced friend at another company to brainstorm with you through the process
Whenever possible, negotiate knowing how much other companies are paying the vendor you’re talking to. This creates a clear price ceiling to negotiate towards
If the vendor hasn’t hit their quota and is approaching their financial year or quarter, you can almost always make significant progress on terms if you’re willing to move quickly
Everyone should know their role in each negotiation. Sometimes your role is being the difficult, inflexible person! Sometimes your role is being the person who thinks they’re the final decider but is infact mistaken when your manager “take overs” later “much to your chagrin”
Not all contracts are equal. Sometimes the absolute number of dollars isn’t high enough to follow a time consuming process. On the other hand, sometimes the numbers are genuinely massive and are worth pulling in even your most senior leadership to get the best possible deal

Efficiency: Managing Infrastructure Costs

Sun, 03 Apr 2022 07:00:00 -0700

In my early career roles, I worked at companies that never worried about their infrastructure costs at all. They were simply too low a cost and growing too slowly for the Finance team to pay much attention to it. This “ignore it until it’s too large to ignore” approach served me well.

Until it didn’t.

Working at Uber, I was caught me off guard when a new Director joined and overnight infrastructure costs were recategorized from insignificant to requiring urgent, detailed review every month. Adding the instrumentation and accountability for these costs retroactively was a difficult retrofit. Although I was surprised that time, I’ve come to appreciate that all successful companies go through the transition from ignoring to setting goals on infrastructure costs, and an early focus during my time at Stripe was ensuring we were ready ahead of that shift.

Your job as an infrastructure leader is diagnosing the right mode of operation for your company’s infrastructure costs today, understanding when you’re likely to switch modes, and ensuring you’ve done the prework to make the transition relatively painless.

We’ll explore this topic by digging into:

three distinct operating modes for infrastructure costs: early-stage, growth, and late-stage
concrete tools and tactics such as managing infrastructure costs with cloud-specific reductions, including costs in your Business Review Template, and using a Contract Negotiation Checklist
whether you should spin up a dedicated team working in this area

When you finish reading this, you won’t have your entire efficiency plan worked out, but you will have the high-level pieces, know where you need to dig in, and have a clear approach to communciate to anyone who has been pushing you for a documented approach around infrastructure costs.

Related Interviews

Smruti Patel: Head of Engineering for L.E.A.P. at Stripe

Should you prioritize infrastructure costs?

Before diving into the mechanics of managing infrastructure costs, the first question to answer is whether it’s a valuable use of organizational time to make your current infrastructure spend more efficient. How you think about this will vary a bit depending on whether your company is early-stage, prioritizing growth, or focused on profitability in late-stage.

Early-Stage

Generally speaking, very early-stage companies shouldn’t spend much time thinking about infrastructure costs. You should instead be focused on finding product-market fit for your first product.

Here are two checks you can run to determine if it’s worth reducing your infrastructure costs:

If you were to reduce your infrastructure costs to $0, and it still doesn’t increase your runway by at least two months, then it’s not worth focusing on
If you’re spending less than $2,000/month per employee on infrastructure costs, then it’s probably not a significant priority because your headcount spend will be so much higher

If you’re not violating either of those checks, then keep on ignoring infrastructure spend. If you are exceeding one, and infrastructure costs are a significant part of your overall burn, then invest a sprint into reducing spend, and then resume ignoring it once these checks resume passing.

The one notable exception is if you’re building a low-margin product or product where cost efficiency is a pillar of your long-term strategy. For example, if you’re operating a metrics collection and dashboarding product like Datadog, then efficiency probably is worth considering earlier than usual.

Growth

When you’re prioritizing growth, the primary focus of the engineering organization in a technology company is creating, operating and advancing the products that support the business. Managing costs is important, but even immaculate cost management won’t make your company a success if enough energy isn’t being invested in your product.

The fundamental question to ask is whether infrastructure’s share of cost of goods sold (COGS) is increasing as a percentage of revenue? (The simplest way to think COGS is all your non-headcount costs, although a slightly better definition would be all costs to operate your software.)

Start answering this question by plotting revenue and infrastructure costs on a chart to get a sense of how these two numbers are moving. Although logarithmic scales often generate more confusion than they’re worth, in this case it’s usually the only way to see both lines closely enough to understand their slopes within a single chart. You particularly want to understand if either line has experienced an inflection over the past few quarters. If costs have started accelerating without corresponding acceleration of revenue, that’s worth digging into.

Once you’ve looked at the two lines independently to understand their movement, simplify your first chart into a chart showing infrastructure costs as a percentage of revenue. This chart hides some detail but is easier to parse for folks further away from the details. As long as the ratio is going down and your company is focused on growth, then this data should be sufficient to justify your current level of investment into efficiency: if growth is key, and infrastructure costs are not getting in the way, why should you slow down growth to reduce them?

Late-Stage

Even the best business lines stop growing at some point. Facebook is one of the most valuable businesses in the world, but even they at some point ran out of new users to attract to their platform. Once growth slows, a business naturally starts focusing more on costs, including infrastructure spend.

In those scenarios, the easiest approach is to work with the business to align on two numbers:

Dollars spent on infrastructure overhead per engineer: this includes things like development environments, testing tools, and so on. Determine your starting point by bucketing vendors and non-production infrastructure costs into a chart and plotting them over time divided by headcount. Pick a reasonable point on that line as your target. Refine it by reaching out to industry peers to get a sense of how this number compares to theirs (be sure to pick industry peers in companies that are currently focused on profitability, otherwise their answers won’t be very helpful to you)
Infrastructure dollars spent per N product operations served: anchoring on cost of operating the product. This will vary a bit depending on your product or business, but it might be “$1.00 in infrastructure costs to powering every 10,000 searches”, “$2.50 for every 10,000 payments processed”, or “$3.00 for every 10,000 trips scheduled”

In both, the key thing is moving away from anchoring on a percentage of revenue and instead setting a target against the fundamental operations that you support. Thinking of costs as a percentage of revenue works well when you’re growing, but is too abstract and hides too many details once you’re focused on reducing costs.

If you find yourself exceeding those targets, then it’s time to dive into reducing them.

Tools for Managing Infrastructure Costs

What I’ll introduce here is the fairly common playbook for managing infrastructure costs. As you work through these approaches, your goal is to do as few of them as possible while meeting your efficiency goals. I’ve prefixed a few particularly high return-on-investment tools with a “⭐, if you’re debating where to start, consider starting with them.

⭐ Use cloud vendor’s cost optimization tools. Every cloud vendor has a program along the lines of AWS Savings Plans or AWS Reserved Instances. These plans allow you to trade usage or spend commitments for reduced pricing. If you aren’t already using these, you can usually reduce your infrastructure costs by 20-40% in a few weeks of work
⭐ Standardize your vendor negotiation process. Beyond a core cloud vendor, many companies have five or six additional large vendor contracts for things like observability, security, or developer productivity. Introducing a structured process for negotiating and renegotiating, like using a Contract Negotiation Checklist, will significantly improve your pricing (as well as visibility into costs)
⭐ Run periodic deep dives on cost. Until you have a dedicated team actively looking at your infrastructure costs, you can usually identify significant cost reductions by periodically taking a week to dig into your biggest infrastructure costs and prioritizing low-hanging fruit. These will usually be accidents, like storing unused data, development environments not getting retired, etc. The key thing is scoping the opportunity to work that the infrastructure team can take on themselves
Update your Tech Spec template to include a section that estimates costs. Many engineers will be unfamiliar with that process, so make sure the template links to examples of how a few representative services estimated their costs. A great example will be onerously detailed, including links to the specific queries and tools to estimate their costs. A template that requires cost estimation without guiding folks through that process will inevitably trend towards make-work rather than a useful discussion
Find the executive sponsor who really cares about infrastructure costs and is willing to push inefficient users to spend less. This is usually your CTO or your CFO. Without an executive sponsor willing to prioritize this efficiency work, you’ll find progress further down this list difficult. If you can’t find a sponsor, that’s usually a good sign that you’re already doing enough to prevent infrastructure costs from becoming a top priority
Find product cost optimizations. There will be significant opportunities to reduce costs by changing how your product works, e.g. improving your data model, changing storage technologies, moving workloads between streaming and batch. However, product changes have a much wider set of stakeholders, which makes these sorts of improvements harder to prioritize. Generally, only try to pursue these if there is a massive opportunity
Pursue a cloud vendor contract discount. Negotiating your cloud contract to include a discount is very doable after you reach a certain level of spend, or are a sufficiently strategic partner, but before you reach that level of spend it’s quite difficult to get a meaningful discount. Is it worth spending three weeks and making multi-year financial commitments to get a six percent discount on your cloud spend? Maybe! It depends on your priorities and your confidence in future spending estimates, but it certainly isn’t worth it to everyone. Conversely, at a certain spend level–think, tens of millions of USD per year–your discount can get much higher without requiring any product-level changes
Set coarse goals on infrastructure costs. Partner with your company’s Finance team to coarsely attributing costs across teams, then set and monitor goals against those costs. Fine-grained goals and cost attribution requires a deeper investment into tooling, but most companies can split costs across their production environment, development environments, and data engineering. Once you done that split, you can set a goal and assign that goal to appropriate teams (respectively, something along the lines of infrastructure, developer productivity, and data engineering). This will provide some visibility and pressure on costs without requiring much attribution prework
Review costs in Business Reviews. Once you’ve set those coarse goals around infrastructure spend, ensure your company’s Business Review Template includes a section on their costs. If you run Business Review Meetings, then make sure someone is showing up to ask questions about costs for teams whose costs are missing goal or otherwise accelerating
Expand metadata to facilitate fine-grained goals on infrastructure costs. Implement an approach to Ownership Metadata such that you can assign all usage and storage costs against a specific team. Once you have that ownership metadata maintained, you can go further by generating proactive nudges to teams on following best practices, prioritizing high costs, and helping them identify accelerating spend early

If doing all of these sounds overwhelming, it should! Few companies do all of these, and those that do either operate in a business that is unusually margin sensitive or are spending many millions a year on their infrastructure costs.

Should You Have a Dedicated Efficiency Team?

Generally, the way I think through spinning out any given area into a dedicated team is described in Trunk and Branches Model, and that applies for the efficiency as well. That said, let me add a few caveats to that general approach as it applies here.

Much like managing technical quality, efficiency is an area where you can make significant progress with one-off initiatives. Improving how you use AWS Reserved Instances or renegotiating your vendor contracts can reduce your spent by 30-40% in a week or two. Product-level improvements to your architecture can reduce your spend even more, although they’ll probably take a bit longer.

Because you can make significant progress through one-off initiatives, the default is to wait until late into a company’s growth to spin out a dedicated team, and in most cases that’s the right decision.

The three factors to consider as you think through whether postponing a dedicated team is the best solution for you are:

Is infrastructure efficiency a fundamental strategic pillar for your business?
Are your infrastructure costs, today as an absolute cost, 10x more expensive than a team working to reduce them?
For the past year have you had pressure to reduce costs but an inability to prioritze the work because other critical work continues to displace efficiency efforts?

If you answer yes to any of those, then you may want to spin out a team earlier than the Trunk and Branches Model suggests. As you start sourcing candidates, it’ll become apparent that this is a bit of a custom role with folks who specifically enjoy working on the problem. Recruiting one or two folks with siginficant preexisting experience will save you years!

Strategies

Sun, 03 Apr 2022 07:00:00 -0700

Business Review Template

Wed, 30 Mar 2022 07:00:00 -0700

Fork this template on Google Docs

As your company gets larger and more complex, it’s easy to become embroiled in supporting incoming asks from other teams. That’s important work, but it’s also important that your team is operating effectively and prioritizing your goals in addition to the goals of other teams making requests.

If you’re getting mixed signals on whether your team is doing the right work, the Business Review Template can help cut through the confusion. This written document facilitates an operational review of your team, and even more importantly creates an opportunity for you, your team, and your stakeholders to discuss if you’re focused on the right work.

Example using the Business Review Template

Most companies wind up using a variation of this template by the time they reach a thousand employees, with some starting much earlier. Even if there’s no structure business review process, it’s helpful to start writing them periodically for the area you’re responsible for: think of them as your area’s performance review.

Related Meetings

Business Review Meeting

Other Approaches to Business Reviews

The Kool-Aid Factory’s The Shipping Great Work Issue

How to Use

Fork this template on Google Docs
Find examples of previous business reviews at your company, and if possible ask the authors what was and wasn’t well received in their most recent review
Fill in the template for your team’s area
Iterate on your draft with feedback from your team and manager
Identify the key groups you want feedback from, and create copies for each of those groups. Transparency is important, but transparency too early often mutes the direct feedback that helps you succeed. Give these groups a week or so to provide feedback, including running a Business Review Meeting if that’s something your company finds valuable
Widely publish a clean, readable copy into wherever business reviews are collected, and let anyone who hasn’t gotten a change to see it so far know where to find it and how to share feedback on it
Now you’re done! (At least until the next one.)

Tips

Writing an effective business review depends first and foremost on understanding the audience you’re writing for, and what that audience cares about. If you’re not sure about the answer to either of those, ask!
Many companies and many teams try to use their business review to solve too many different problems. Your business review should focus on answering only two questions: how well is your area of the business operating? What do you need to do for it to operate better?
Good business reviews are focused on what the reviewers need from the review. Bad business reviews are comprehensive, capturing everything that someone on the team wants reviwers to know
Every metric you include in a business review should be a well-formed metric that includes the current value, the goal, and the trend over time
Avoid delegating the writing of your business review to multiple different folks. Short documents with disjoint authors are hard reads
The Amazon Way of Writing is a helpful set of rules for writing these sorts of documents

Infrastructure Engineering

Categories

Book

Tech Spec Review

Goals

Agenda, Scheduling, and Scaling

Roles & Attendance

Is it working?

Meetings

Incident Review

Goals

Anti-goals

Agenda, Scheduling, and Scaling

Roles & Attendance

Is it working?

Tools

Matthew Clarke

Manager

Interview

Mahdi Yusuf

Shawn Wang / swyx

Developer-Experience

Smruti Patel

Contract Negotiation Checklist

How to Use

Tips

Efficiency: Managing Infrastructure Costs

Should you prioritize infrastructure costs?

Early-Stage

Growth

Late-Stage

Tools for Managing Infrastructure Costs

Should You Have a Dedicated Efficiency Team?

Strategies

Business Review Template

How to Use

Tips