Is this where the industry is headed?

Imagine a future where you manage 50 people working on 50 different projects. Your day starts with reviewing an AI summary of important updates on some subset of those 50 projects from the last 24 hours. You have unread Slack messages in 75 different channels, and your AI bot triages and responds to most of them automatically.

You have three one on ones on your calendar from direct reports who have signed up for on-demand 1:1s. There are 8 project-related meetings today, you dispatch AI agents to attend 5 of them, and plan to attend the other 2 in person. You also have a sync with a low performer and HR today on the progress against a Performance Improvement Plan, you cannot automate these, yet.

You have a block of time this afternoon to review an AI summary of summaries from various product, engineering, and engineering productivity dashboards. In a few spare moments at the end of the day, you use an AI coding agent to make some progress on a small feature you are working on.

You are really dreading next week, when a peer manager is going on PTO, and you are going to be doing all of this for 100 people instead.

Facebook is trying it

Does this sound far fetched?

Apparently, Meta is experimenting with exactly this. Some other companies will likely follow suit, citing Facebook as precedent.

The key points from the initiative:

• Ultra-flat structure of up to 50 employees per manager
• Projects that used to require big teams can now be accomplished by a single, very talented person
• This aligns with Zuckerberg’s ongoing “Year of Efficiency” philosophy, which emphasizes removing management layers to increase speed

The stated goal is to increase speed.

Traditional expectation

Let’s think about some generic but common activities for engineering ICs and managers today. I am assuming at least senior level, going to staff and principal. This is where the most bang for the buck exists today, leveraging current AI coding tools.

Senior Eng IC activities

For senior engineers, the core responsibilities are still pretty recognizable. Estimate work, implement, test, QA, deploy, and measure. None of that disappears just because coding gets faster.

There are also some activities we can maybe reduce with AI. Code review is an obvious one. So are mitigating production issues, fixing bugs, and even parts of interviewing candidates, especially screening and structured evaluation support.

At the same time, some responsibilities probably expand. Engineers will need to identify the right problems to work on, gather requirements, and explore solutions much more directly than many do today. If fewer people are involved in each project, more of the thinking work shifts onto the people actually shipping.

Something has to give. One thing that probably gives is mentoring other engineers. In a world where everyone is expected to move faster and own more surface area, mentorship gets squeezed unless a company explicitly protects time for it.

Manager expectations

For managers, the core responsibilities remain hiring, performance management, and team health. Those are the durable parts of the role. You can compress some workflows, but you cannot wish them away.

There are definitely management activities that AI can reduce. Execution management, one on ones, project unblocking, and written communication all look more compressible than they did even a couple years ago. A lot of status gathering, follow-ups, summarization, and coordination work is ripe for automation.

But if you stretch a manager too far, the work that probably disappears is some of the most important work. For example, setting strategy.

What will your direct reports say if asked?

Consider what your direct reports would say if asked whether their manager:

• Has meaningful discussions with them about career development
• Keeps the team focused on clear priorities
• Provides feedback to help them do their job better
• Unblocks them so they can achieve important goals quickly
• Fosters a culture of inclusion
• Is someone they would recommend to others
• Creates an environment where they feel comfortable being candid
• Helps them understand how their work connects to company strategy

That’s a hard list to satisfy with 50 direct reports and a calendar full of AI proxies.

Three scenarios

Even if we take as a given that projects that used to require big teams can now be accomplished by a single, very talented person, there are still multiple ways this could play out across the industry.

1. 50 direct reports, each doing 1x the work
2. 50 direct reports, each doing 10x the work
3. 10 direct reports, each doing 10x the work

The first version is not really what is being proposed, because it fails to meet the goal of increasing speed. The last version will still happen no matter what at small companies that do not have 50+ engineers, especially early stage start-ups. I would personally be excited to lead engineering for a company where the express goal was to never have more than 10 engineers.

But that is a much easier problem.

For the purposes of this thought exercise, the scenario worth solving for is #2. That is the interesting one, 50 direct reports, each doing dramatically more work.

Hypothetical tools for a 50-direct-report manager

What would you actually need in your toolkit to pull this off?

• AI one-on-one bot for pulse check-ins
• Meeting summary AI to attend meetings on your behalf and distill decisions
• Real-time performance dashboard with metrics and feedback
• Context concierge to summarize individual and project history
• Bi-directional visibility on status so stakeholders can correct AI context when it’s wrong
• Priority triage AI to rank incoming requests

You might also need indirect access to the AI chat logs of all your direct reports. Who is going to have time to write a status report for you to read?

You would also need implicit support from the company and IT department to allow AI automation to access all of these systems without requiring human intervention at every step.

Objections and FAQs

There are some obvious objections.

How can a manager meaningfully support 50 people?

I do not think you can, at least not in the way we usually mean support. It is more likely that you focus on the 5 to 10 highest performers and mostly support the rest through self-serve automation.

What happens to mentorship and career growth?

A lot of it gets delegated to ICs, and a lot of it gets concentrated on top performers. Training junior and entry level engineers remains an unsolved problem in an AI-coding world. People will need to own much more of their own performance evaluation narrative, and it will become harder to create real growth opportunities for new manager.

How do you detect struggling engineers early?

This likely becomes heavily driven by productivity metrics and automation, at least for initial detection. The system would need to identify cases that need attention before a human manager has enough direct contact to notice. That is efficient on paper, but it also has some obvious risks and blind spots.

How do performance reviews work at this scale?

Evaluation gets harder because you have less context on each engineer and each project. Decision making, oddly enough, gets easier because one person can just decide promotions and ratings for all 50 people without much calibration with other humans. That may sound efficient, but it is also a pretty radical concentration of judgment.

How do you build trust without regular one on ones?

I do not believe this works without significant face time, and face time is exactly what you cannot afford in this model. I would expect the company-employee relationship to become more transactional. Maybe that is acceptable to some companies, but it is still a real cost.

Would managers burn out with this many reports?

Maybe not. The workload is potentially solvable with enough automation. But burnout also comes from being misaligned with your day to day work, and a day or week spent with relatively little time interacting with people will burn out many managers.

Can product managers produce shovel-ready work this fast?

I do not think so. In fact, I suspect product managers will spend a lot more of their time implementing features too. My bet is that defining strategy and requirements falls more on engineers in this scenario, similar to the way engineering has already picked up more QA, DevOps, and adjacent responsibilities over time.

Cross-functional layers

The traditional 1:1 mapping of one product manager and one designer to a team, or to 50 people, almost certainly does not hold. I do not see how one product manager or one designer could define work for 50 different projects. Each project requires too much thinking time, and if projects are also shipping faster, the demand for strategy and requirements goes up rather than down.

I think in this world product managers and designers start landing code themselves.

The real kicker is strategy alignment. How are we going to align on strategy in a world where 50 times as many things are moving at once? Maybe we do not actually need as much alignment for prioritization purposes, but it is going to be chaos if 50 projects are landing all the time and experiments are stomping all over each other.

Maybe even more AI tooling helps with that.

Organizational design

My bet is that engineering, product, and design spans of control all scale to the same level, 50 direct reports. There is relatively little distinction between these roles in this world. They all become people manager roles with some specialization around discipline.

For a company of 150 EPD employees, you could theoretically have 3 managers and a CEO. Today, with a span of control of roughly 10, you’d need at least 15 managers plus a layer of 2-3 VPs. That’s north of an 80% reduction in management roles.

Of course, if this works, many of those managers could theoretically be repurposed as individual contributors shipping code as well. For companies with 3k, 10k, or 50k engineers, the reduction in management roles scales linearly.

It is still TBD whether a traditional VP Eng, Director, or line manager would be the dominant surviving manager role in engineering. With the right automation, it could be any of them. That said, some management scenarios favor the manager always being more senior than their direct reports, which points more toward the VP Eng model.

If that turns out to be true, the most likely remaining roles for more junior managers may be at companies with more junior engineers. Historically, that probably means start-ups.

Migration and transition strategy

If you actually wanted to move a company into this state, how would you do it?

Start with humans performing the support roles in a VP Eng org: Directors, line managers, and TPMs. Set an explicit goal for those roles to automate themselves out of existence. These employees write the tools that the VP Eng needs day to day. Don’t forget to train the VP Eng to maintain those tools themselves. Those management roles may disappear, but the transition trains the people to switch into IC roles using AI coding.

Conclusion

This is an interesting thought exercise, but not something I personally want to ever do.

My preferred future is still the small-but-mighty team of 10 engineers scenario. Yes, each engineer is augmented by AI and doing dramatically more work. Yes, each of them might ship projects that would have taken a team of 10 people circa 2025. But managers still get to invest time in building real relationships and trust.

AI can compress workflows, summarize context, and help people ship faster. It still cannot replace coffee chats, dinners, conversations, and human connection.

We are entering an era where “next person” is comprised of the human and their coding agent. The job is to explain the why to both of them, onboard both of them, etc. For any job to be done, the engineer will break the problem down into many subproblems. The agent will use the docs to answer questions about many of those subproblems on the way to building a working solution.

Even if the human never has the agent actually write code, being able to ask the agent these kinds of questions is supremely useful. For example, the human might ask:

• How do I run the service for logging?
• How do I run the test for creating a new user?
• How do I create a new feature flag and branch in the code based on that?
• Who owns the authentication service?

These questions cannot be efficiently answered just by looking at the code itself. We need to make documentation more discoverable, legible and concise for effective agent consumption.

Two challenges of agent-facing documentation

The main challenge for AI agent documentation is limited context windows. Long documents mean too much additional context. That’s when the agent’s attention can wander, or it can lock onto irrelevant details. If it can’t quickly find the information it needs, it will be more likely to invent something. The job of AI documentation is to point the agent in the right direction, load just the context needed for the task, and no more.

The secondary challenge is retrieval speed. The agent has to be able to find what it needs and retrieve the content of the documentation quickly. That means putting the key documentation into the codebase, where the agent is already operating, instead of forcing it to bounce across tools and tabs.

Caching as the mental model for documentation

A useful mental model here is to treat your documentation as a context cache. There is context that is hot-loaded (always in context), warm-loaded by proximity to where the agent is working in the repo, and cold-loaded context that has to be manually referenced (or fetched).

AGENTS.md as the “hot cache” at the repo root

All major AI coding agents can work with a common structure based on AGENTS.md files at multiple folders in your repos. The root AGENTS.md should contain only context you want loaded into literally every prompt. This is your hot-loaded cache, and it must be super small.

Good examples of root AGENTS.md content:

• One-line description of what this repo (or top-level folder/module) is
• Commands to build, run tests, and lint
• A high-level map of the repository, where to find what

That’s it. Anything else should be a reference to other code-based documentation such as a full repo index, architecture docs, how to write tests, and how to write or update documentation (yep, documentation about documentation). The root file should act like a router, not a wiki.

When you reference another doc file, do it in plain English with an explicit pointer, for example: “Writing tests: @docs/writing-tests.md”. A practical tip is to ask the agent if it can find and read the docs you’re referencing. If it can’t, it will guess, and you will not enjoy the results.

You will see varying guidance on the maximum advisable length of AGENTS.md files, anywhere from 50 to 100 lines, up to 32kb (roughly 350 lines). If you care about staying within a limit, you can enforce it with CI rules. In general, agents don’t need verbose documentation, so keep the style to short bullets and direct pointers.

You should also consider having standard section headers (and baking that into your “how to write documentation” docs). Consistency helps humans, and it also helps agents reliably locate the same kinds of information across modules.

Local AGENTS.md as the “warm cache”

You should have many AGENTS.md files at various subfolders in your hierarchy. The principles are the same: don’t repeat context from a higher-level AGENTS.md, but add a local-specific description, any local commands, a mini map of this module, and any external references specific to this code.

These are your warm-loaded documents. Most major coding agents will load both the root AGENTS.md and the ones closest to the code it’s working in. A practical pro tip is to start your coding sessions inside the appropriate module if you know it. If you don’t, switch to that module once you discover it, for example by explicitly referencing the local AGENTS.md file.

Warm cache docs are where you earn your win rate. They are the place to describe “what is special about this module,” “how to run its tests,” and “what not to touch,” without bloating the root context. They also help humans, especially new hires, who are doing the same scavenger hunt as the agent.

Referencing “cold cache” human-first docs

There is still a plan for handwritten human-first docs. Those should live in a wiki, or something similar, and you can reference the critical ones from your AGENTS.md files. If you want a cleaner separation, add a level of indirection with a REFERENCES.md file that collects and curates links.

If you rely on external docs, you should test that agents can actually load them. Ideally you do this through global agent configuration and MCP, but the baseline requirement is simpler: verify that the agent can open the link and read it without manual heroics.

README.md files are best kept human-first. The main constraint is to try not to repeat yourself, especially in ways that go stale. Treat README.md as the “narrative and onboarding” layer, and treat AGENTS.md as the “steering and execution” layer.

Making this work in today’s most common agents

The good news is that this approach maps cleanly onto what people are already doing:

• Codex uses this file convention out of the box.
• Cursor also uses this convention.
• Copilot will also read these files.
• Claude can be pointed to AGENTS.md files with stub CLAUDE.md files that say “Load AGENTS.md”.

Even if the exact mechanics differ by tool, the core pattern holds. Put the steering docs in the repo, keep the always-loaded context small, and use proximity to decide what else gets pulled in.

What about code comments?

Yes, code comments are useful for coding agents. For the AI, the most important comments are what a function does, what the arguments represent, and any required preconditions. Comments that explain why a weird decision exists are also high-leverage, because they prevent “helpful” refactors that break an invisible constraint.

Scoring documentation (so you know it’s working)

You can treat documentation quality as something you can measure. Ask agents to do tasks and measure the success rate, especially if you have a system that provides a UX on top of one-shot AI coding tasks. If the agent can’t complete common tasks reliably, your docs are not yet doing their job.

You can also ask agents questions about the code and see if they get the answers right. A bonus move is to source new questions from your actual engineers, especially new hires. If a new hire asks “how do I run X,” and the agent can’t answer, you just found a missing or mislocated piece of context.

Continuous integration can help keep you honest. Consider adding checks for:

• AGENTS.md files that are too big
• Standard format or sections (if you have them)
• Commands that don’t exist
• References to files that don’t exist

Rollout strategy

Pick a goal and a metric you can measure today, even if it’s manual. The first pass should be practical and small, because the fastest way to lose momentum is to attempt a grand rewrite of documentation across the entire company.

Start with the root AGENTS.md file, plus the basic cross-agent compatibility layer (for example, the Claude stub layer). Then pick 2 to 3 areas, and create local structure for AGENTS.md, README.md, REFERENCES.md, and any supporting docs. Aim for the modules where onboarding cost, operational risk, or dependency load is highest.

Finally, encode the above in a global reference for how to write AI documentation. That “how to” doc should suggest improvements to the documentation you have already written, and it should be referenced from the global AGENTS.md so it’s discoverable. Put another way, your documentation system should include the instructions to maintain itself.

Conclusion

If you want agents to be reliable, you have to treat documentation like part of the execution surface area of the codebase. Keep the hot context small, use local AGENTS.md files to supply warm context near the code, and make cold context explicit and fetchable. Then score it, iterate, and enforce the basics with CI so it doesn’t rot.

You do not need to throw away human-first docs to do this. You just need a repo-native steering layer that helps humans and agents collaborate without wandering, guessing, or inventing.

References

• Mercari: “Taming agents in the Mercari Web monorepo” (using AGENTS.md to reduce prompt boilerplate and help navigation):
• Datadog: “Steering AI agents in monorepos with Agents.md” (framing AGENTS.md as a contract and describing steering docs):

I’ve been playing with Claude Code lately, but not for coding in the traditional sense. I’ve been using it for personal productivity, specifically as a knowledge worker. That experiment turned into a small side project, and you can see the early results here: chase-sidekick on GitHub.

It feels like we’re at a very specific moment in time with AI tooling. We’re somewhere between “this wasn’t possible before” and “this is completely ubiquitous.” Most of the conversation right now, especially among software engineers, is focused on how to use AI to write code faster. That’s fine, but it misses the bigger shift. The real revolution isn’t just for software engineers. It’s giving all knowledge workers superpowers. Think Claude Executive Assistant.

Why engineering managers are uniquely positioned

Software engineering managers are in a prime position to take advantage of this moment. We know how to break down problems into executable steps, we can help the agents debug code, and we have the same messy knowledge work problems as everyone else. Calendars, docs, task systems, status reporting, exec summaries, etc. Claude Code turns out to be a surprisingly good tool for this. You can use it to write small libraries that connect to your tools, and then ask Claude to actually do real tasks in those tools on your behalf.

Everyone knows the future here is MCP (Model Context Protocol). And yes, MCP is coming. At some point your AI assistant will connect to all of your tools directly. But that future isn’t evenly distributed yet. Many vendors are still building their solutions. IT departments are still trying to decide whether they’ll allow it at all. And many MCP servers that exist today are third party, thin wrappers around existing vendor REST APIs.

Even five years from now, there will still be tools that don’t support AI connections natively. OmniFocus is a great example, it still doesn’t even have an API. But Claude can figure out how to automate it with AppleScript. There is an opportunity right now to pair with AI to write your own clients, for just the operations you need, in a way that your AI client can understand. You can move to MCP when it’s available, but you don’t have to wait. You get to live in the future now.

This approach is likely to remain necessary for the foreseeable future. In some cases, it’s the only option to bypass IT entirely, which may or may not be an obstacle, depending on where you work.

User empowerment, vendors, and APIs

This leads to a broader point about user empowerment and vendors. As a user, I should be able to access an API and take actions as myself. I should be able to connect to that API using my own account without any gate keepers in the way.

Google and Atlassian are good examples of this model. You can create personal API keys right inside the products. Slack and Zoom are, unfortunately, very good examples of the opposite. They require users to create an app in a marketplace, and then ask their IT departments to install it. Just to access data that user can access in the product.

Sidekick is just a personal project, but I’ve gotten remarkably far with this technique in a very short amount of time. The biggest limitation I’ve hit are the API access issues above. A smaller but still real limitation is APIs that technically exist but don’t quite let you do what you want.

Claude Code is not a chatbot

Once you get past that, the use cases start to compound quickly. Things like: download all the files linked to my calendar events for this week and generate a bullet summary for executive leadership. Or: for all teams that report to me, look up completed work across JIRA Epics for the past 30 days and generate a team accomplishments report, with kudos to specific engineers. Or: migrate Paper 1:1 docs to Confluence for my direct reports, set restricted access, and update calendar event links automatically.

This has also turned out to be a great way to learn AI-assisted coding while keeping your coding skills sharp. A lot of managers look for side projects where they can still write code and have real impact. This is it.

Getting started

Installing Claude Code itself is straightforward. You just follow the directions on their website. You have Claude initialize a project, similar to the way git init works. One big misconception is that Claude Code is just a chatbot living inside your editor. In practice, it’s a completely different beast.

If you want to try this, start simple. Create an empty Claude Code project and ask it something like: “Create a set of scripts in language X to do Y in product Z, and then write a skill so that I can ask you to do this easily in the future.” You may be surprised how far you get, and how quickly.

Changing your mindset

What you’re doing is co-creating reusable prompts and context with the model. Your repo will end up with multiple CLAUDE.md files. The proximity of those files to the code Claude is running strongly influences whether that context gets picked up. You’ll also have README files and docstrings, many of which are created or updated by Claude itself, and all of which become part of its working context.

In fact, coding with Claude often looks like creating those context files, or asking Claude to create them for you. Your prompts are what give Claude the best chance to get something working. Your help as a debugger is often the only path to success. But you’ll also have moments where Claude hits an error and then troubleshoots its own way to a solution without your intervention. The first time that happens is a genuine magic moment.

That’s what makes Claude Code categorically different from “a chat bot in your editor.” It’s the run-debug loop. As a programmer, you still feel firmly involved, for now. I don’t think this loop will exist in Ai productivity tools, long term. A few years from now, this will be a polished product category. You’ll interact with intelligent agents through voice or a UI and never see what’s behind the curtain. The mechanisms underneath may not look like code or APIs at all.

Something will be lost in that transition. Specifically, the chance to surprise your team, and yourself, when you’re experimenting right at the edge of what is possible today.

Tips and tricks

A few tips from early experimentation. You want as little code and documentation as possible, but no less than that. Part of the game is managing Claude’s attention. Use directory structure aggressively to embed documentation near the relevant code. Try not to introduce dependencies if you can avoid it. When Claude can see the entire implementation, it reasons better.

The code and documentation Claude understands best is what it wrote itself. You don’t need to write much by hand. Balancing “Claude only sees what’s in git” with “this file full of PII and secrets is absolute prompt context gold” is tricky. But you do want that full context available when you ask Claude to do things. One approach is to create a git-ignored directory where you manually store high-value context files. Also be aware that Claude will happily include that PII and those secrets in documentation it generates unless you explicitly tell it not to.

Finally, try adopting the mindset that the code itself is not the important artifact. The code is almost disposable. The important pieces are the documentation, especially the prompts. That’s where the leverage lives.

PS. The inspiration for all of this came from a podcast episode with a $4B CPO on using Claude Code for productivity. Listen from about 3:30 to 28:00.

Why use Airtable?

I’m a Google Sheets power user. Even so, I recognize there are some things that are easier or better in Airtable. The sheet itself is prettier. That matters if you’re presenting this content as part of your work! Forms are natively supported, meaning submissions can edit your sheet content directly (and in the format you want) versus feeding into a new sheet. It’s more intuitive to link a bunch of tables together with a foreign key, as opposed to using VLOOKUP. You can control visibility at the row level with Interfaces. Finally, there are more options for data visualization.

That being said, I still turn to Google Sheets when I want to do something quickly, especially if it’s just for me.

Scenario: Calibrations

Calibrations happen during performance review season. It’s a useful example for managers because it’s familiar, and involves the most common data type for managers, people! It also provides natural use cases for forms to collect data, and access control so that other managers only see people they are calibrating on.

Create simple Tables

First, create a new Table with a list of managers. You want the first column to be the primary key, meaning it should be unique. Generally email addresses or IDs are better than names, for tables of people.

Add a column to the same Table for calibration panels. These are the names of one or more panels that the manager will review calibration cases for. Use the “Multiple select” column type to normalize the data.

Also add a column with type User to tie to an Airtable user. This will come in handy later.

Next, create a list of cases to calibrate on. These rows are people. Each one is assigned to a cohort. Note that this Panel column is a new “Single select” column, which must have the same options as the column in the Managers Table. Alternatively, you can create a normalized Table just for panels, and link both Managers and Cases to those.

I’ve also added a blank column for the link to the calibration document.

Create an Interface

Ok, now we get to create a view for managers to enter the link to the calibration document for their cases.

Create an Interface called “Calibrations”. Make it type “List”, and point it to the Table of cases. To start, this just gives you back the full list of cases. Notice that it’s not editable by default. To make it editable, go back to the data view, click on the Table name, and select “Edit table permissions”.

Now, go back to editing the Interface, select the field Calibration Doc, and make it editable. Make the other fields view only. Note that some field types are editable in the list view itself, and some are not. The URL type is not editable in the list view; users need to open the record and edit it in the preview.

Filter to the current user

Notice that users can filter this view. For example, they can filter down to rows that they are the manager for. What if you wanted to make this the default for this Interface?

First, we need rows to be associated with an Airtable User record, not just the name of the manager. Go back to the Cases Table, and add a column of type User. You need to manually select the right User for each row.

Now edit the Interface again, and you can define a default filter for the Manager to be “Current User”.

Calibration Feedback

Now, we are going to add a Table and an Interface to collect calibration feedback from panel members on every case in that panel. We’re going to work backwards from what we want, which is a Table where each row is feedback from a manager on a specific case. There will be multiple rows in this Table from any given manager.

Create a Table “Feedback”, with columns:

• Primary Key: ID (type Autonumber)
• Manager (type Link to Managers)
• Case (type Link to Cases)
• Rating
• Comments

These should not allow linking to multiple records, just one record. But, how can we populate this Table with one row for every combination of case and panelist for that case?

Scripting

Create an Automation where when you press a Button, it runs a script. I wish the Airtable AI supported helping you write this code, but here is what I came up with using ChatGPT and some iteration.

Warning: this script deletes all existing Feedback records.

let managers = base.getTable("Managers");
let cases = base.getTable("Cases");
let feedback = base.getTable("Feedback");

// delete all feedback records; you could also do this manually instead 
let query = await feedback.selectRecordsAsync();
let recordIds = query.records.map(r => r.id);
while (recordIds.length > 0) {
    await feedback.deleteRecordsAsync(recordIds.slice(0, 50));
    recordIds = recordIds.slice(50);
}

let allManagers = await managers.selectRecordsAsync({fields: managers.fields});
for (let manager of allManagers.records) {

    if (!manager.getCellValue("Panels")) continue; 
    let managerPanels = manager.getCellValue("Panels");

    let allCases = await cases.selectRecordsAsync({fields: cases.fields});
    for (let thisCase of allCases.records) {

        if (!thisCase.getCellValue("Panel")) continue; 

        let casePanelName = thisCase.getCellValue("Panel").name;
        if (managerPanels.some(
                panel => panel.name === casePanelName
            )
        ) {
            console.log("Creating empty Feedback record:", {                
                manager: manager.getCellValue("Name"),
                caseName: thisCase.getCellValue("Name"),
                panel: thisCase.getCellValue("Panel").name,
            });

            await feedback.createRecordAsync({
                "Manager": [{ id: manager.id }],
                "Case": [{ id: thisCase.id }],
            });

        }
    }
}

You don’t have to attach this automation to anything. Instead, you can come back to this Automation tab anytime, and run the automation manually.

Running it will yield something like this:

Using our techniques before, it’s simple to add a second Interface to expose just the Feedback rows for the currently logged-in user.

Analysis & Dashboards

In order to build an example of analyzing the feedback results, first fabricate some dummy data.

Now, we need to aggregate ratings and comments per case. You can do this by creating a new Interface using the type “Dashboard” based on the Feedback Table. Once inside the Interface builder, select the option to add a “Pivot Table”.

It’s straightforward to create both a bar chart of average rating per case. You can also create a list of counts of comments, where the user can click into each case to view the various comment text.

Exporting to Google Sheets

The Airtable pivot table and list views are limited. Compared to Google Sheets pivot tables, they are missing one piece of critical functionality. That’s the ability to have multiple value columns in a pivot table. That enables you to do things like have one table with the average rating, the count of ratings and even the concatenated comments.

It’s easy to export one or more Airtable Tables to Google Sheets. For a small Table, you can simply select all the rows in the data view, and copy and paste into Google Sheets. You can also download to CSV from Airtable. Finally, there are third party extensions that can sync live to Google Sheets, though I would not recommend that.

Conclusion

Airtable is basically a database builder that also lets you build mini applications on top. It excels at having tables with enforced data type schemas, defined relationships between tables, and defining Interfaces to both enter and report on data.

Google Sheets excels at manipulating data, and also analyzing data.

You can easily combine the two tools, and leverage the strengths of each one. My recommendation is to use Airtable for gathering data in a consistent format with easy to use interfaces, and then export the results to Google Sheets if you need to do serious analysis.

I started coding in middle school, messing around with BASIC and writing simple programs just for fun. But things really clicked for me after Apple World 1996, where I got into web development. Something about the web—its immediacy, its interactivity—pulled me in, and I never really looked back.

During college at Boston University, where I majored in Computer Science, I took on freelance projects, which turned out to be my first real exposure to building software for actual users. After graduation, I joined a tiny startup called Bullhorn—just 10 people at the time. By the time I left, it had grown into a 300+ person company. I wore just about every hat imaginable, from coding a custom email server to racking physical machines in a data center.

I took inbound customer support phone calls, troubleshooting issues and learning firsthand how users interacted with our software. I created visual design mockups, ensuring a polished and user-friendly interface. On the engineering side, I wrote full-stack features—from styling the UI with CSS to designing and implementing database schemas. I also worked with then-cutting-edge Ajax in JavaScript to create dynamic, responsive user experiences. This experience shaped my approach to problem-solving, product thinking, and building systems that balance usability with technical efficiency. That kind of early-stage chaos taught me how to build things from scratch, solve problems with whatever was on hand, and work across disciplines.

After Bullhorn, I moved into backend engineering, focusing on Python at two different companies. Somewhere along the way, I transitioned into full-time management, realizing that my biggest impact wasn’t just in the code I wrote—it was in helping teams function at a higher level. Managing people let me shape healthy team dynamics, excellent communication, and high-leverage work.

I fell in love with mentoring new engineers and first-time managers. I geeked out on things like hiring processes, promotion frameworks, tech talks, and internal blogging. As I moved into senior leadership roles, I found myself drawn to the big, messy, ambiguous problems—the ones where there’s no clear solution. Things like shifting team culture, rolling out a new process across hundreds of people, or even navigating major layoffs. Those were some of the hardest things I’ve ever had to do, but they were also deeply engaging learning experiences. The irony is, the bigger the problem, the less I can write about it!

Beyond Work

Outside of work, I’m into basketball, ultimate frisbee, and the occasional RPG video game binge. I’ve also developed a love for photography, gardening, personal finance, and cooking. When I’m not diving into leadership challenges, you’ll probably find me coaching Little league, reading science fiction (Goodreads profile) or experimenting with a new recipe (cookbook link).

At the end of the day, I like solving problems—whether it’s in code, teams, or life in general.

My Working Style Profile

• Myers-Briggs (ISTJ): Logical, structured, and detail-oriented; values stability, planning, and accuracy over spontaneity.
• Strengths Finder (Analytical, Focus, Discipline, Futuristic, Relator): Data-driven problem solver who thrives on long-term planning, structured execution, and deep connections.
• Enneagram (Type 8 - The Challenger): Independent and direct; challenges ideas, values autonomy, and resists control or rigid authority.
• Insights Discovery (BRGY - Logical & Independent): Strategic and objective thinker who prefers working independently and values precision.
• BlueEQ (High Self-Confidence & Resilience): Accountable, disciplined, and motivated; comfortable making tough decisions with a long-term focus.
• My Worldview (Redefining): Challenges norms, seeks deeper understanding, and values intellectual curiosity and alternative perspectives.

Working with Me: A Guide to Navigating My Precise, Analytical, and Independent Thinking

If you work with me, you’ll quickly notice a few things: I value precision, thrive on logic, and am relentless in my pursuit of clearly defining the principles behind a decision or creating a structured framework for thinking about a problem. I enjoy breaking down complex challenges into organized solutions, and I don’t make decisions based on gut feelings or emotions. Instead, I gather data, assess the facts, and execute with a methodical approach. My closest team describes me as a “teddy bear wrapped in barbed wire”—I can come off as intense or intimidating, but at my core, I care deeply about getting things right and supporting the people around me. If you’re looking for someone who brings stability, organization, and follow-through, I’m the person you want in your corner.

Strengths: A Strategic, No-Nonsense Problem Solver

I operate with a long-term vision and high personal standards. I’m analytical, systematic, and disciplined—someone who enjoys assembling facts, structuring information, and identifying patterns. I don’t need constant check-ins to stay on track; if you give me a problem to solve, I’ll take it seriously, dig into every possible angle, and provide a well-reasoned path forward. I don’t get overly swayed by sentiment—my decision-making process is rooted in logic and practicality.

As a leader, I set clear expectations, delegate heavily, and take a hands-off approach, trusting my team to take ownership and drive outcomes. I value efficiency and accuracy, and I have little patience for unnecessary bureaucracy or inefficiency. My expectation is that my team always does what’s best for the company, takes full responsibility for their work, and embraces a certain level of scrappy, non-scalable effort when needed to meet leadership where they are and assume good intent. If you need honest, critical feedback, I won’t sugarcoat it—but it will always be geared toward achieving the best possible outcome. I appreciate regular 1:1s where we share notes in writing, including feedback, materials to align on, and as an external brain/memory for future reference.

I can count the number of people I haven’t gotten along with in a work context on fewer than five fingers. I prioritize building strong professional relationships and fostering trust and psychological safety with my peers and closest teams, which has consistently led to productive and collaborative working environments.

How to Work Best with Me

• Be clear and factual. I respect logic and objectivity, so the best way to work with me is to present well-reasoned arguments supported by data.
• Don’t take my directness personally. My feedback is about improving the work, not a personal critique. If I challenge an idea, it’s because I want the best possible outcome.
• Give me space to think. I’m not a fan of extemporaneous discussion—I prefer time to process before making a decision. If you need a fast response, providing key details upfront will help.
• Be prepared to adjust plans. While I value structure and planning, projects inevitably evolve. Helping me see the strategic benefits of a shift in direction will make the transition smoother.
• Build a working relationship over time. I work best with people I know well and trust. If we haven’t worked together before, expect to invest if really getting to know each other before we hit full stride.

In short, I’m the kind of person you want leading a critical project, managing complex problems, and ensuring follow-through on key initiatives. I’m analytical, disciplined, and strategic—but also independent and structured in ways that may require adaptation from teammates who operate with a more fluid, emotionally driven approach. If we align on expectations and approach work with clarity and purpose, I’ll be a reliable and effective collaborator.

Frequently Asked Questions

What are your expectations for your direct reports?

• Build strong relationships with your product and design partners, as well as your direct reports.
• Deliver on sprint and quarterly commitments at least 90% of the time.
• Take ownership of one or two impactful initiatives per year.
• Come to 1:1s engaged, ideally with a written agenda.
• Proactively follow up on action items.
• Communicate effectively in writing.

See also My Expectations for Managers

What can you expect from me, as a manager?

• Dedicated and reliable weekly 1:1 time, where I’ll bring topics to discuss.
• Transparent and timely information sharing, when appropriate.
• If I ask you to attend a meeting, I’ll ensure it’s well-run and valuable.
• High autonomy—most decisions will be yours to make.
• Flexible work hours, location, and vacation policies.
• I almost never ping people outside of business hours.

What do you need from your manager?

• Weekly 1:1s with my boss, ideally with written notes.
• Maximum transparency, especially on context from executive leadership.
• Meetings that start on time, follow an agenda, and have clear written takeaways.
• Dedicated focus time for deep work, with the flexibility to decline meetings when needed.

What motivates you?

I thrive on projects and initiatives where I can:

• Set and execute against long-term goals.
• Think deeply and refine ideas before making decisions.
• Collect data and evidence to guide strategy.
• Improve processes through iteration.
• Provide guidance and mentorship to others.

How would your team describe you?

Unflappable, practical, informal, and disciplined.

What is your biggest weakness?

If I don’t write something down, I’ll likely forget it.

What’s the most surprising thing you’ve learned about yourself?

I’m introverted, but I gain energy from spending time with people I know well. It takes me a few months to feel fully comfortable with a new team or business partner and about six months to build deep trust.

Benefits of HDHP + HSA

The premium — the amount of money coming out of your paycheck automatically — for an HDHP will be lower than an PPO or HMO. How much lower will depend on your employer’s contribution, but it could be a low as a $500 a year. By itself, this is probably not motivating enough to switch. The main benefit is the pre-tax savings. In 2023, the limit on HSA contributions is $7,750 for a family. That comes off of your taxable income for the year. If you are paying close to the marginal tax rate of 37%, that would save you about $2,800 in taxes. Many employers will make their own contribution to the HSA, which could be thousands of dollars. This is extra free money.

The real incentive is investing that money. If you invested the whole $7,750 in an index fund that returns 7% a year for 15 years, you would contribute $116,000 and it would grow to $194,000 in those 15 years. That return gets larger over long time horizons. If you did the same thing for 30 years, you would contribute $232,000 and it would grow to $731,000. This is the primary attraction to an HSA for people already maxing out their other pre-tax investment vehicles.

Note: leaving contributions to grow requires that you don’t use the HSA money to pay for in-year medical expenses. This means that your post-tax expenses in the current year would increase up to your HDHP deductible, typically something like $6,000 for a family. On paper, the pre-tax benefit of the HSA is still worth it.

How HDHP + HSA Works

When you’re on an Health Medical Organization (HMO) medical insurance plan, you do not get billed directly for most medical expenses. You may receive a statement in the mail that says “this is not a bill”, as a cost transparency mechanism. But, you only have to pay the premium — deducted from your paycheck — and small per-visit copays. When you’re on an HDHP, you get billed for medical expenses from the service provider, and you need to pay those bills until you hit the deductible limit on your plan. After that, you will mostly not get billed and the insurance covers the additional expenses, with the exception of copays and potentially a small percentage-based co-insurance payment. You should keep receipts for any medical expenses you want to get reimbursed for.

The HSA is designed for you to tap into your pre-tax HSA contributions to pay for these expenses before you hit your deductible. For small expenses, you can use a debit card they issue you. For larger expenses you do this by logging in to their website and telling them how much of the funds to send back to you. This can be either a check in the mail or a direct deposit. The HSA provider will not ask you for a receipt for your expenses. When you file your taxes for the year, you will declare how much you contributed to your HSA and how much you were reimbursed from your HSA. You will not need to submit receipts, but you should keep them for seven years in case you are audited.

You invest HSA funds through the HSA provider’s website. Similar to a 401k provider, you select contributions amounts and which funds you want to invest it. With an HSA, you are selecting one contribution amount for how much additional money you want to deduct from your paycheck to put into the HSA, plus a second amount that you want to be moved from your HSA cash balance to your investments.

Downsides of HDHP + HSA

The downside of an HDHP + HSA that everyone knows about is the contribution amount. There is more money coming out of your paycheck. Assuming you contribute pre-tax to the HSA, that will more than offset the savings in premiums. People who are already maxing out their other pre-tax savings vehicles see this as a benefit; it’s reducing their taxable income and increasing pre-tax investments. But, the short-term negative cash impact is nonetheless a downside — and the most well-known one.

Billing Errors

Increased paperwork and exposure to medical bureaucracy are less well-known downsides. When you’re on an HDHP you need to keep track of and pay medical bills. When you’re on an HSA, you need to keep receipts for medical expenses. If you’re on an HMO you may never have looked closely at a medical statement. It’s common for various doctors and specialists involved in something like a visit to the emergency room to all send you different bills. There are often mistakes on the bills, such as being double-billed for something. There is not a lot of clarity on exactly what an item on the bill represents. If you’re on an HMO you don’t really care. If you’re on an HDHP, you may very well find yourself calling your insurance company to figure this stuff out. They will often need to bring someone from the service provider (hospital) into the loop to sort it out. All this takes time, and is frustrating.

Unreasonable Medical Costs

Exposure to absolutely insane, detached-from-all-reality, inside-baseball itemized medical costs are the next downside. On an HDHP, you are incentivized to spend less on medical expenses, until you hit your deductible. Did you know that something like a 1-hour speech therapy session for a child can cost $700? You will get bills like this from the provider. You may very well not be able to find out how much it costs until after the service. It doesn’t matter that the going rate for this service outside of insurance is $150. When they bill you this amount, it’s not negotiable. If you’re on an HMO, you don’t care what inflated price the provider is changing themselves.

Tax Paperwork

The next downside is tax complexity and audit risk. When you file your taxes, you will submit a form 8889 for your HSA. You report contributions and distributions. This is not a big deal, it’s just one more thing to keep track of. HSA providers do not send this form to you, like 401k providers do. You need to fill it out manually. You don’t need receipts for medical expenses either when you request a distribution from the HSA provider, or when you file your taxes. You will need your receipts if you even get audited, however.

Bad HSA Providers

You are locked in to the HSA provider that your company chooses. Like 401k providers, there is a wide range of quality here. The company has an incentive to pick the lowest cost provider, not the one with the best website or customer support. In short, there is a good chance the only provider you can use will be terrible. Websites may be poorly implemented. There may be no phone number of call for customer support — instead you may be directed to your internal benefits team. There may be limitations on the number of transactions you can make. There may be annual fees.

Your company may also change providers. Your cash funds may or may not be rolled over to the new provider automatically. Even if cash funds are moved, investment funds may not be. There is the added complexity of special “in-kind” transfers that are necessary for avoiding tax implications of moving to a new HSA provider. You may or may not be able to do an in-plan (i.e. without leaving the company) transfer to your own third-party HSA provider. But, you will not be able to use a third-party provider for automatic contributions from your paycheck and your employer. Over the course of a long career, you may end up with many different HSA accounts at many different providers, unless you spend time to consolidate them.

Psychological Cost

Don’t underestimate the added element of decision making on top of all medical decisions, especially when there are family members and spouses involved. Even if the cost of medical treatment up to your deductible is a negligible expense in your overall budget, you may be surprised to find yourself in protracted conversations about whether it’s “worth” getting various medical treatments. Maybe your knee is bothering you, but it’s not a show stopper. Do you get an MRI, even if that might cost you $1500 dollars out of pocket? This is one of the points of a HDHP, from the perspective of the insurance company — to make consumers more aware of medical expenses. They know that this will reduce unnecessary medical expenses. But, it will also reduce necessary preventative expenses.

Identity Theft

One of the primary use cases for an HSA is paying for medical expenses. You will get a debit card sent to you for this purpose, whether you want one or not. You will be required to create a username and password for the website of the HSA provider. This website is like small bank account, where anyone with your password can make a deduction. Both the debit card and the website are vectors for identity theft and potential financial loss. Neither of these are purely theoretical threats — there are news articles about fraud happening in the wild.

Conclusion

Enrolling in an HSA is not a one-way door. You can typically make a different election once a year, or when you change employers or at certain qualifying life events. If you save a large amount of money in an HSA and then switch back to an HMO, you may have trouble spending that money. It’s not clear what expenses are eligible when you’re no longer on an HDHP. It’s difficult to research, but you are probably fine to expense copays and any services or medications purchased outside your insurance. Plus, you can still save the money for medical expenses in retirement.

What would it take to “fix” these risks to HSA programs? Medical costs would need to become both understandable and reasonable. You would need to be allowed to choose your own HSA provider. Neither of these are likely to happen.

In the meantime — as with many aspects of finances — you can’t go wrong with keeping it simple. For medical insurance, it doesn’t get any simpler than an HMO.

Burnout is a state of poor professional mental health, where the feeling of being overwhelmed or a lack of enthusiasm impacts your effectiveness. It can be caused by a mixture of mental or physical exhaustion, lack of belief in the work, and lack of belief in yourself. Each individual has a personal expectation about an ideal work environment on these dimensions. When reality becomes too far detached from this ideal, the result is burnout.

If you are currently burned out, you probably already know it. It feels like a crippling inability to get things done or to even care. It’s hard to ignore. But it’s also common to slowly be trending towards burnout without realizing it until it’s too late. If you think you might be at risk of burnout, ask yourself the questions in the Burnout Risk Checklist.

Burnout can severely impact your attitude, professionalism and performance at work. It’s also one of the leading causes of attrition.

Well-being and Performance

Personal well-being is the best leading indicator of professional success. Think about all the people in your career that have left a company, whether it was their individual choice or they were actively managed out. If that person chose to leave, they were likely unhappy in their work situation. If they were managed out, they were likely unhappy in their work situation, and that resulted in poor performance. It’s relatively rare for someone happy and engaged to have severe performance issues.

Now think about high performers you have seen over your career. They were likely universally enthusiastic, and engaged in their work. They were happy in their work situation.

This is especially true for a leader. Your well-being is highly visible. It also directly informs the well-being of others and the performance of the larger organization.

Own Your Mental Health

The more senior you get, the more you will need to manage yourself. It’s true for career growth, but also for well-being. You won’t always be maximizing growth, impact, and well-being at the same time. You may have periods where you are trading off one for another. There will be well-being fallow periods. Part of your role as a leader is navigating yourself — and others — through those periods.

Everyone is responsible for their personal expectations about an ideal work environment. But leaders have a greater effect on both the expectations and reality of the work environment for others. Part of your role is taking ownership of the well-being of everyone.

You can do this by providing a narrative that ties short-term goals to long-term strategy and impact. That’s critical for your well-being too, as more senior roles have longer cycles for impact. By owning your well-being, you are taking control of your performance, longevity in the role, and ultimately the impact of the organization. Doing what’s necessary for your well-being is doing the best thing for the company.

To be alert for personal burnout, you need to learn to identify the warning signs. You need to be able to diagnose burnout signals in yourself and others.

Diagnosing Burnout

Lack of action is the number one leading indicator of burnout. If you notice in yourself a distinct lack of activity relative to your baseline norm, it’s worth digging in to see if you may be on the path to burning out. If you manifest any of the overt warning signs of burnout, then move on to trying to figure out which flavors of burnout you are experiencing.

You may be experiencing poor mental well-being due to a mix of exhaustion, depersonalization, or ineffectiveness.

Exhaustion

Exhaustion means that you feel mentally or physically tired, consistently, over a period of weeks.

Taking an extended vacation may help. Utilize general stress management techniques. That means sleeping well, exercising, focusing on a healthy diet, seeing family, and engaging in hobbies.

Making lists can also help. What things in your personal life do you find the most engaging? What things are you grateful for? Try tracking your mood over time with a journal or app.

If you get energy from spending time with other people, make room for that in your work week. Traveling to a shared working space or social event can be time well spent if it’s combating mental fatigue and re-igniting well-being.

Depersonalization

Depersonalization is a lack of belief in the impact of your projects or the lack of alignment with your values and well-being.

Actively connecting the reality of your work to your ideals is the general mechanism for addressing depersonalization. Make and update lists of your accomplishments. Think of it as preparation for your next self review. This will serve as a forcing function to articulate what you are doing, and what the impact is.

You might find that work that you previously thought was not valuable did deliver impact. Format your notes to briefly describe the situation you were in, the behavior you demonstrated, and the impact on the business. If you feel stuck, you may need to force yourself to document even the smallest impact. After doing this, you may find that some projects did not have impact. Use that to inform what you choose to work on in the future.

Make a list of all the places you have worked. For each one, write down four or five projects that stick out as the most memorable. These are likely to be the projects that align most closely with your values. What did you enjoy about them? Translate these into generic themes like “mentorship”, or “hiring”. Brainstorm some side projects that you could be doing now for each theme.

It’s OK to take on new projects, if it’s something you are going to be excited about, or you feel confident it will have an impact. If needed, make space for this by punting — or delegating — items that you are not as enthusiastic about. Just make sure to inform any stakeholders that may be counting on you to complete a project. A good source of project ideas are items that you have heard other folks propose and own, but which are stalled out. Ask them if you can take it off their plate!

Start small, and pile up quick wins. Making forward progress on items that naturally engage you is the more surefire way to build back up your sense of making a difference.

Ineffectiveness

Ineffectiveness is burnout stemming from a belief that a project cannot be completed, either because they are generally infeasible, or because of your lack of ability.

Remind yourself of projects that are being completed, no matter how small. Try tracking and celebrating wins that are happening. As a manager, it’s common to focus your conversations with others on things that are not going well. Try to intentionally do the opposite. Talk to folks in 1:1s about what projects are succeeding. Compile and send an update on recent successes. Intentionally spend extra time giving others public kudos or otherwise show your appreciation.

You also need to keep in mind that your ability can change over time. Focus on what you are learning. This is known as a growth mindset. Try keeping a list of things that didn’t go well, and what you learned from them.

Talking about Burnout

You should talk about burnout with significant others, family, and friends. You should talk about it with your boss and other coworkers, provided that you have the necessary psychological safety. If your boss has already proactively raised the topic with you, talk about your plan to reestablish well-being.

Like a midlife crisis, burnout at work is ultimately caused by the gap between your ideals and reality. Both are likely to be most accurate after major changes. If that’s the case, give yourself time; this isn’t something that will be fixed quickly. Self-reflection will be important. If talking to friends and family is not enough, then seek professional therapy.

Acceptance is the other half of the equation. Increasing self-engagement will be very helpful. Take the opportunity to reexamine your ideals about your work environment. Whether your self-worth is too tied to your engagement in your professional life is a question only you can answer.

Don’t Give Away (All) Your Toys

Especially when you are digging out of a burnout hole — but anytime — it’s OK to spend time on some things just because they boost your well-being. Sometimes senior leaders delegate too many things, including their favorite work. You may have gotten the advice to stop coding altogether. But, if you find it engaging, and the code will have an impact, give yourself permission to continue doing it. Everything is in moderation. Just don’t neglect your core responsibilities.

Never sit around with nothing to do. You can always invent impactful work. If all else fails, read an article or a book for professional development. Take ideas from that and implement them.

Don’t wait for an exciting project to come down the pipe before you re-engage. You need to proactively be fixing your engagement, first. You are ultimately accountable for staying engaged and managing your own burnout risk.

Burnout Risk Checklist

• Have you been “bored” at work?
• Have you caught yourself being overly cynical?
• Have you been unable to stop thinking about a work event that happened a while ago?
• Have you been dreading starting your work day?
• Have you experienced a perceived lack of work to engage with?
• Have you experienced regret about projects other people are doing, instead of you?
• Have you noticed a decrease in enthusiasm in your personal life?
• Have you gone through a major change at work?
• Have you suffered a major professional setback or failure?
• Have you projects you completed not had the expected impact?
• Have you said something in a professional setting that you wish you could take back?
• Have you let projects languish on your TODO list?
• Have you been unable to do something that you used to do regularly?
• Have you gotten feedback about your attitude or engagement?

Burnout Playbook

• Keep a journal of how you’re feeling
• Talk to a significant other
• Talk to a family member
• Talk to a professional peer
• Take some time off
• Improve your exercise and diet
• List things that you are grateful for
• Make an effort to connect with coworkers in person
• Celebrate the impact of others with public kudos
• List things that you would be excited to learn professionally
• List recent successes in situation, behavior, impact format
• List things that you are grateful for
• Brainstorm past work projects that have been the most engaging
• Generate a couple of projects that you will be enthusiastic about
• Make time to work on enthusiasm projects
• Delegate current projects that you are not enthusiastic about
• Identify some small wins you can achieve
• List what you have learned from challenging situations
• Write down how your professional life relates to your self-worth
• Write down what is most important to you in life
• Write down what you are giving yourself permission to do in the name of mental health

Why Calibrations?

Calibrations are primarily about reducing the bias of ratings from individual managers, and increasing equity between managers. Secondarily, they are a great way to train managers on how the company thinks about performance. They also give senior managers data on the highest potential folks in a large organization, for strategic organization design.

In most companies, there is a fixed budget in dollars for things like compensation changes and promotions. Calibrations distribute this budget as fairly as possible. This post will not explicitly cover compensation, but know that most companies will want to link compensation to some combination of company, business unit and individual performance.

In a “pay for performance” system, you want to have outsized rewards for outsized impact. But the budget is still fixed. If you put twice as many people in the exceeding expectations category, then those people will get half the compensation increase they would have otherwise gotten. In order to maximize the impact of rewards, you do need to make decisions between cases.

Elephant in the Room: Stack Ranking

Stack ranking means that you create an ordered list of individuals, according to their performance. It’s a mechanism to force the discussion about how to allocate rewards for greatest impact. The version that most people object to is if you are forced to label some people as low performers. Don’t do that.

If you have a large organization, it’s reasonable for there to be a bell curve of performance. In practice, I have seen that for cohorts of 50 people or more — at both large companies and start-ups — performance will roughly fit a curve. This comports with the central limit theorem, which says that a sample size of at least 30 will approach a normal distribution. But that does not mean that the low end of the curve are necessarily low performers. I do not think it’s acceptable to mandate a fixed percentage here.

You can keep yourselves honest by pressure testing people in the “meeting expectations” bucket. This is less of a budget issue, and more about holding managers and individuals accountable for real performance problems. While it’s not fair to absolutely require a fixed number of people to be labeled underperforming, there is a definite tendency for managers to avoid these difficult conversations by giving someone an unwarranted “pass”.

Stack ranking gets a bad name from being forced on too-small cohorts, and for forcing low performance ratings. Companies that had a bad reputation for doing this in the past commonly still do have ratings and curves, but have substantially changed their process for how the ratings are generated and reconciled. Some do away with ratings, but still have differentiated compensation changes that could be reverse engineered into ratings. Some move the reconciliation to the Director level, and give them more discretion on fitting the curve.

How to Run Calibrations

I’m going to outline a process that works well for cohorts of about 50 individuals, and can scale up to any size by layering on multiple calibration rounds. The goal of calibrations is to have fair and consistent performance ratings across organizations, roles, and levels. You want to reward high performance, and make sure that appropriate poor performance conversations are happening.

This process can also be scaled up and down, in terms of how much time it takes. You can cap write-ups in length. You could potentially do the entire thing asynchronous ,with no meeting. Reducing the size of the cohort will also save time. There are all trade-offs against how much to want ratings to be equitable across teams.

Pre-work Before Calibrations

Before you can calibrate, you need initial ratings and write ups. You need to gather data. This is where self reviews and 360 reviews come in.

Self reviews should use the same format as the eventual manager review. You should have a defined template for this up front. They should reference your existing framework for expectations per role and level. You should ask people to provide a rating for themselves. Any training you can do here to help folks write good self reviews will pay off.

Individuals and their manager should determine a set of three to five 360 reviewers per person. The format of a 360 should be short. Ask reviewers to timebox their effort, skip pleasantries and platitudes, and focus on situation, behavior, and impact. 360s can be anonymous or not, as long as it’s clear to the reviewer.

Managers should draft their reviews in parallel with self reviews and 360s, and then incorporate any new information prior to calibrations. It’s at this point that managers should document initial ratings and promotion candidates. You are going to want to gather these in some central system, even if it’s just a spreadsheet.

The Calibration Meeting

For the actual calibrations, you should pick one facilitator. It’s this person’s responsibility to set an agenda, set a timebox for each individual, and manage time during the meeting. The facilitator will need to have access to the preliminary ratings and promotions for every person to be discussed. They should create an agenda that has the name of each individual, the order they will be discussed, and a link to the manager write-up. It may help to give the attendees basic guidance about how many people would need to receive each rating in order to hit the budget.

Calibration meetings have a reputation of taking forever. A six or more hour meeting to decide the ratings for 50 individuals is not uncommon. It’s also common for certain managers to dominate the airtime, which can result in bias. How can these be run more efficiently, and result in equitable outcomes?

After several iterations, I’ve arrived at a format that I love. It’s pretty simple:

1. Send out a pre-read with the links to each write-up ahead of time. Group by level, and then by proposed rating. For example, all people at a certain level who are up for an exceeding expectations rating should be calibrated on in a block.
2. Solicit Q&A about each individual right in the agenda doc. This is the most valuable feedback the manager will ever get about how well they are calibrated.
3. In the calibration meeting, each candidate starts with 5 minutes of silent reading. Managers do not “present”. Attendees can write additional questions during this time.
4. The manager answers the written questions live for the rest of the time, someone else takes notes.
5. At the end of time, everyone submits a “confidence vote” on the candidate

The confidence voting is the real secret sauce here. The idea is that every person present at calibrations submits a “blind” score for how confident they are in this individual being “at the bar” for the proposed rating or promotion. Blind means that scores are submitted without seeing anyone else’s score, to avoid bias. You can use any scale, but I like a star system with options for:

• Not Ready
• Stretch Case
• Solid Case
• Slam Dunk

You can also include a free-text field for comments. If not, encourage folks to leave any comments about why this case was not a “Slam Dunk” in the Q&A notes.

The confidence voting system can also be used to pressure test low performers. Typically, managers are somewhat reluctant to put individuals up for discussion as potential low performers. Assuming you do not have time to calibrate on every single individual in the organization, it helps if you have some proxy data you can use to identify people to talk about here. For example, you could identify individuals who have missed delivery milestones, or who have not done the expected volume of candidate interviews. Group these folks together, and vote on confidence at a “meeting expectations” rating. This is how the group can come up with calibrated ratings for potential low performers.

Post Calibrations

The confidence votes are tallied and revealed after calibrations. Scores are averaged together per case, and the results are made available for all calibration attendees. It’s at this point that the overall decision maker for the organization can make final decisions by defining a “cut line” in the graph. It’s up to them to figure out how closely to hew to any distribution guidance.

Calibrations need one decision maker. Typically this would be the manager that all of the calibration attendees report into, with the same being true for the individuals whose performance is being calibrated on. Alternatively, you could randomize cohorts across an organization to further mitigate bias, and the cost of the calibrators having less context.

With the voting system, the decision maker does not need to make the final decisions live during the meeting. Instead, they can look at the results after the fact, and decide. Just because an average score is under the “Solid Case” line, does not mean that the rating or promotion does not get approved. It may, but much more important is the scores relative to other individuals up for the same rating or promotion.

I’ve been surprised in that decision making role just how close the ranges of scores on any given individual are in practice, and also how much differentiation there is between cases. When this happens, it’s a sign that the managers in those calibrations are indeed thinking about performance and expectations in a way that is aligned. In that case, the decision maker knows that they are not unilaterally making decisions that may be biased.

Large Organizations & Multiple Calibration Rounds

A single calibration session can only scale up to cover 50 individuals. Assume that you only discuss people who are not solidly “meeting expectations”, and that those folks will be roughly 50% of the total. If you need a minimum of eight minutes per person, this would mean a three hour meeting. The total number of managers, or meeting attendees, would be between 6 and 12.

You will most likely have multiple calibrations, due to visibility issues. It’s typical for managers at level N to only sit in on calibrations discussing individual contributors at N-1 and below, or similar. That means that higher level individuals are likely to be discussed by managers that control more scope, which means managing larger orgs, which means that there are probably hundreds of individuals under those managers, way too many for a single session.

There should be one overall facilitator to create the timeline and define the cohorts for how these multiple calibrations will be scheduled, so that no cohort is over about 50 individuals, and individuals are not discussed multiple times.

Sometimes, you may choose to intentionally discuss individuals multiple times. This can be when you want to give managers practice writing their cases, and provide feedback in time to affect the final decisions. It can also be when you want to gather data from managers who work with a high-level individual regularly, before presenting the case in a higher level calibration.

In all these calibrations, you should strive (or require) cohorts to individually meet their budget guidance. This is how you scale to any organization size without having to directly compare every individual with every other individual. It will not be possible to draw cut lines across cohorts later, because the relative confidence scoring between cohorts is not directly comparable.

Last Word on Confidence Voting

The confidence voting system in particular delivers some key benefits that most calibrations struggle to achieve. The meeting time and conversations about individuals can be timeboxed. You can choose to not discuss up to 50% of people who are solidly in the “meeting expectations” camp, if time does not allow. The final results can be justified with data, and we can reason about exactly how “calibrated” the group was. We can choose how closely to follow any given budget guidance. We can also pressure test low performers.

Not needing dependencies is a luxury afforded to teams in small companies, or those running very high priority projects. I once ran a tiger team that was both. We moved experts from across the company onto the team so that we could own every piece of the execution. In large companies where a single product spans many teams, most projects will require one or more dependencies. You need to have a playbook for managing dependency risk.

List the Dependencies

First, you need to know what the dependencies are. One of your core competencies as an engineering manager is “asking the right questions”. Hold a brainstorm and help the team see dependencies that they might not know exist. Cross-functional dependencies like security, legal and compliance can be particular blind spots for engineers. For actual software engineering, the team can almost certainly identify the big dependencies off the top of their heads. Doing a pre-mortem exercise can be one way to enumerate them and quantify the risk for each. You want to do this early in the project, as part of project estimation.

Create a list of all the dependencies for the team, for the year. Each one should have a project name, a short description of the dependency, the risk or priority of the dependency, the name of the remote team that you are dependent on, and a specific team member who owns it. Try stack ranking them, with the highest risk/impact dependencies first. Share this list with your manager.

Having a prioritized list of dependencies is useful for more than just your team. Suggest that your manager ask all their teams for this, and that they create a combined list. How they prioritize the list across teams will tell you a lot about how well aligned you are, how they are going to present these priorities to their own peers and stakeholders, and may also give you early signals on when a dependency is a non-starter.

Show your list to the engineering managers you are asking for dependencies from. Ask them to share their full roadmap, and share yours. Include not just the engineering managers, but tech leads and product managers on both sides, as well. Make sure you have a solid business case for your project. These stakeholders, artifacts, and visibility are how dependency problems are turned into creative solutions.

For any given dependency, you should first try to remove it, and then you should secondarily try to push it back. Removing a dependency typically looks like changing scope, so that the dependency is not required. Pushing it back looks like structuring milestones – provided that early milestones deliver user value – so that it is not required until later. This is basic execution management that should happen for all your projects, and should be old hat for yourself, your tech lead, and your product manager.

Get Engineers Engaged

If the dependency cannot be resolved with a creative solution, the next step is to get the right people to bring the right expertise to bear on the problem, and to get work started right away. A dependency that is not being actively worked on by engineers is an at-risk dependency. As an engineering manager, allocating these resources appropriately for the business is another core competency. That’s not to say that it will be easy! Managers sometimes confuse accountability for allocating resources with having authority to dictate those decisions. Given that we know that we will mostly not be unilaterally allocating people across disparate teams, what staffing levers do we have at our disposal?

Use your knowledge about the organization and other teams to identify the correct team for the dependency, and also the most likely points of contact on that team — the experts — who can help the most. Start by asking for a consultation with that expert. This could start as one-time, and then you can collectively evaluate if consultation alone can satisfy the dependency. Identify your own experts, and get them involved. If you respect the remote team’s time, create a pre-read, and get aligned ahead of time with their manager, this should be a slam dunk. Even if the work turns out to be too large for a consult, you will have cemented a clear point of contact on the remote team.

Next, create a dialog with the right points of contact on both sides. This could be a simple Slack channel dedicated to the consultation. Eventually, this may be the rally point for a full on roadmap dependency. Your goal is to create and nurture a relationship between the teams, to facilitate a conversation. If you make it transactional, that is how it will feel to the other team. Try to set ground rule expectations. Can the other team agree to provide support for things like technical spec reviews, and code reviews?

Another staffing mechanism available to all managers is embedding, also known as tours of duty. This means offering to loan one of your engineers to another team for a specific period of time. Alternatively, they could loan you an engineer. It’s easier than a roadmap commitment, because it’s timeboxed. The receiving team agrees to return the engineer on a specific date, based on the initiating team’s estimates of the work. The engineer(s) exclusively work on the dependency. If it’s not resolved in time, that is the responsibility of the initiating team. The embedding should end on time regardless. Managers should write down expectations for things like how specs and code get reviewed, what needs to happen to merge a code change, and whether the person is expected to improve the state of the surrounding code. If folks are willing to cross-train, this can work even if there is a skills or domain knowledge gap in the person being embedded.

Other staffing solutions may or may not be available to you. Most dependencies that get to this stage require domain knowledge. If the dependency is primarily about raw staffing, you can of course hire. Even if this is not the case, if you are in charge of a headcount budget, reserving some budget for dependencies like this can be effective, to facilitate potential internal transfers, both to be able to receive an internal transfer, or to offer as compensation to another team for a transfer.

Depending on your scope, other options like moving people between teams, or moving entire teams, may be available. During a regular reorganization of teams, you should be actively managing your dependency risk.

Mitigate Risk with Milestones

Once you know what your dependencies are, and the right people are working on them, the next step is to structure the work. How you structure the work greatly affects how much risk you are taking on. Your goals are to shorten the window before work begins, bring forward the first increment that delivers user value, and shorten the cycle time between further iterations.

Creating a prototype is a critical early milestone. This should be a quick and dirty development environment only implementation of just the very core of the product. This gives you some real code to discuss, some real experience to demo, and will also uncover some of the primary unknowns and decisions that need to be resolved. Concurrently, you can also do “spike” sprints to try to resolve specific unknown and technical risks.

After that, you want to move to an in-production implementation, behind a feature flag, as soon as possible. This is Milestone 0, a foothold that you can continue to expand, refine, and polish for the rest of the project lifecycle. After that, milestones should be “theoretically shippable”, i.e. a user could get some value out of this, no matter how small. Don’t break things down into milestones like backend, front-end, release testing, etc. Instead, think of thin vertical slices. Each slice should deliver some user value, end to end. The slice itself should accomplish part of the overall job to be done. It should be just polished enough that you could release to wider and wider audiences, such as team-only, internal-only, early access customers, etc.

When planning the scope of the milestones, think about whether certain dependencies are only required for some of the scope. Pushing that scope back into future milestones will reduce the risk associated with delivering earlier milestones, at the cost of non resolving unknown technical risk inside those dependencies early. If possible, try to de-risk those separately with their own prototypes, potentially on another team’s roadmap.

For any cross-team dependencies, agree on a code interface for the dependency. This can greatly clarify what each team needs. You may also want to create failing unit tests for those code interfaces. You could go as far as to mock the dependency with basic behavior, which will be useful in your own development and testing. Any performance or scalability requirements can also be part of your interface definition.

Finally, come up with a Plan B for each dependency. This will not always be possible. Examples include planning to build and ship a heuristic solution to a machine learning model dependency, or hard-coding something that will eventually be configurable. Other examples could be shipping a mock implementation of a back-end system, or further dropping scope so that it’s not necessary.

Escalate Unless Development Starts

If dependencies cannot be eliminated or committed to such that they are beginning work soon, you should escalate. This is a last resort, only because you need to attempt other methods first. But don’t let dependency conversations linger too long without making forward progress. If progress has plateaued for two or three weeks, it’s time to start the escalation process. Much of the time, you will not end up having to escalate at all, but that’s part of the magic!

Often the mere act of sitting down and trying to write up a proposal will lead to Frank and Faythe to come to a compromise. Partially this is because writing down details forces clarity on the situation. It also reveals options that neither party had thought of independently. A big part of last-minute compromises is that everyone is reluctant to involve their manager, asking for a decision. This makes it more likely that each side will accept a compromise that they would not otherwise have accepted, simply to avoid escalating. — How to Escalate

The short version of how to escalate is:

1. Create a doc collaboratively with the other engineering manager, and include cross-functional peers
2. Pair down to two or three potential outcomes
3. CC both of your leads at the same time, plus any cross-functional partners, via email

If the escalation results in a roadmap commitment, you should have a record in the above email. If not, create one. This is critical for clarity and accountability.

Done correctly, most escalations will be resolved by a compromise before your leads are included. This is what healthy cross-team collaboration looks like; identifying problems and finding solutions. Don’t treat an escalation as a threat, your goal is to share context and exercise empathy, and iterate to a solution that is best for the entire company. The biggest failure mode in escalations is not doing them, or not doing them early enough.

Checklists

Dependency Risk Level Scorecard

How high risk is your dependency? If you cannot answer “Yes” to three or more of these, your dependency is at high risk.

• Has work started?
• Is work starting in the next quarter?
• Is there a working prototype of the solution?
• Is the team confident that they know what the technical solution is, exactly?
• Do you have an API interface definition agreed on by both teams?

Team Lead Dependency Mitigation Checklist

• Have you asked critical questions about the product and the technical plan?
• Have you identified the right stakeholders?
• Have you written and communicated a compelling business case for this work?
• Have you brainstormed potential dependencies and risks with the team?
• Have you held a pre-mortem about what could go wrong, worst case?
• Have you listed all of your dependencies and risks somewhere?
• Have you prioritized your dependencies by negative impact?
• Have you documented your full team roadmap, and shared it?
• Have you defined milestones that are thin vertical slices of potentially shippable product increment?
• Have you cut scope from early milestones to de-risk dependencies?
• Have you set up an ongoing consultation with your primary dependencies for questions, design review, and code review?
• Have you created a safe space where you can engage in dialog with each dependency?
• Have you built a working prototype of the solution?
• Have you mocked up a code interface for each dependency, with example inputs and output?
• Have you documented the dependency and the commitment in an email?
• Have you identified specific people as points of contact for the dependency?
• Have you put together an escalation doc for this dependency?
• Have you sent the escalation doc to leads on both sides?
• Have you created a Plan B for if this dependency is not satisfied?
• Have you determined whether there is a relationship or trust issue between these teams? (manager of managers)
• Have you brought in the right experts from outside the teams to consult on this dependency? (manager of managers)
• Have you considered moving people around for this dependency? (manager of managers)
• Have you considered embedding engineers across teams? (manager of managers)
• Have you reserved headcount to facilitate this dependency? (director)

What is an Organization?

An organization is a set of teams with one name. Your company is one organization. A large company includes many nested sets of organizations. How you group sets of teams together, and what type of shared mission you give them, is the result of trade-offs you make between competing factors like coordination and dependencies.

What is Organizational Design?

Organization design is how you choose to group the teams together, and what name you give them. Mission scope, coordination cost, and dependency management are the primary factors in any organization design.

Mission scope simple means the job of the team. What is their primary goal, and what problem are they trying to solve? The mission should be compelling, distinct from the missions of other organizations, and meaty enough to have impact commensurate with the expectations of the larger company.

Coordination cost is incurred in the form of communication overhead for any two teams that have a dependency between them. If possible, you want to remove the dependency altogether. If you cannot remove it, you want two teams involved in the same work to share the shallowest common “branches”. As the distance increases, so does the risk of misalignment and prioritization conflict, which can lead to the dependency blocking the project.

The reporting structure of the organization, literally who reports to whom, determines the distance and number of people in the decision-making loop. In terms of risk, there is a natural incentive to make sets of teams in an organization as small as possible. But there is a competing factor called the “span of control”—giving teams a sufficient number of people to realize impact—that incentivizes larger sets of teams. For any given manager, most companies ideally want somewhere between five and eight direct reports, for cost efficiency and to give each direct report the right amount of attention and support for their personal development.

Making trade-offs between these factors are the primary driving force informing organization structure.

Small Organizations Don’t Need Structure

My first job was in a start-up with one and a half other software engineers, and no product managers or designers. There were no teams, or rather we were one big team of 12 including sales, finance, and customer support. There was a reporting structure, where sales people reported to the head of sales, etc. But there wasn’t an organization structure. We didn’t need one.

In a small company, communication and coordination overhead is negligible. When you’re coding a feature, there are probably no dependencies. If there are, you can literally turn to the person next to you to resolve it with a quick conversation. Engineers are able to deliver almost all their work by themselves.

Medium-Sized Organizations

As a company gets larger, there will be many teams. You’re all working on one product, but no matter how you organize, you will start to see more and more dependencies.

Teams can be grouped by technology, feature, business goal, or customer. We are going to ignore grouping by customer, because it tends not to scale past a few types of customer.

Grouping Teams by Technology

Codebases are broken up into repositories, services, modules, and files. They are naturally categorized by theme, i.e. what can I include in this set that’s cohesive as a unit, and has minimal dependencies on other things?

Engineers have a tendency to first think of organizational structures that match these themes. This makes sense! You know this will minimize dependencies, and you know that assigning code ownership will be straightforward. Using an organization structure like this for a set of teams will tend to incentivize quality, which is also a classic engineering value.

Organizations structured this way will excel at keeping things running, and running well. They will maximize uptime, performance, and correctness. They will tend to be more stable over time, as the basic thematic groupings of code do not change often. They are great for knowledge sharing across engineering teams. This structure is often used in Platform organizations.

On the other hand, these organizations will bias towards investment in existing use cases vs new use cases. Innovation will often look like rewriting an existing component. Engineers may gravitate towards this work, even when the business thinks it’s low value. It may be difficult to get engineers to work on higher impact stuff. Work on new initiatives may be diffused across more teams, increasing overhead and risk, and reducing accountability.

Group Teams by Feature

If you need to make significant progress on a relatively well-known new or existing feature, consider grouping all the teams who need to deliver work for that feature together. This may make sense, especially for a handful of top priority initiatives. By having every skillset the teams need to deliver their roadmap, you are minimizing coordination cost and dependency risk.

This could look like front-end, back-end, mobile, database, and devops engineers all working directly together on cross-functional teams, separate from other engineers of the same horizontal discipline. One manager may have direct reports from each discipline, and together with their peer managers report to one organization manager, who can easily resolve prioritization issues.

This organization structure maximizes execution, assuming that the solution is relatively well known. It may be ideal for large cannot-fail mega-projects. Of course, projects can always fail, but this structure greatly decreases execution risk.

With this organization design, you are incurring maximum churn on team missions and superstructure, as missions revolving around features will naturally change more often as the features ship. When that churn happens, more people will change managers, and it will take time to reestablish processes on affected teams. Plus, there is a high likelihood that this churn will be incurred again, as the project is completed and teams align to the next feature.

In the initial move to feature organization, there may be resistance to decoupling teams from their previous groupings, especially if they have formed a sense of identity around being a “platform”, or “mobile” organization.

These organizations are sometimes over-staffed. It’s a fine balance on the continuum between creating an organization for a solution that’s fairly well known, versus creating the organization in order to define the solution. Too much of the latter, and you run the risk of having people and teams roped in without a lot of actual work to do. Worst case scenario, this can lead to scope creep and unneeded complexity as teams “invent” work to do.

Large Organizations

As the company gets even larger, you are likely to be working on many more totally different things, even multiple different products. The number of dependencies grows exponentially. You cannot truly minimize dependencies, instead you need to pick which ones to derisk.

Large companies contain many organizations. Each organization may be responsible for one product, or one sub-goal. Inside each organization, you can mix and match grouping sets of teams by technology, features, or customer.

Grouping Teams by Business Goals

Like the feature grouping, grouping by business goal puts a sufficient number of people under one overall accountable person to achieve the goal self-sufficiently. Unlike feature grouping, the solution is often undefined. Instead of being about estimates to build a specific feature, the number of people allocated to this type of organization is based on how much of a “bet” the company is willing to make on this goal. Sub organizations can be created for sub goals, which should have their own single accountable person.

This type of structure prioritizes innovation. Doing this well requires clear goals and metrics. The strategic vision must be compelling. With unknown solutions, there is a tendency to give each product leader similar resources. This option is often used for product-led organizations, i.e. organizations where everyone ultimate reports to a head of product.

Teams and individuals in this model may need to exercise more of their cross-functional skills, versus organizing by technology or feature. You may need to repurpose an engineer for something that does not 100% match their skillset, or you may discover that you need a new skillset as you uncover solutions in the space. You may also need to unblock dependencies by changing the working agreement so that teams inside your organization can do work in codebases that other teams own. These both have real costs. Swim lanes inside the organization may be unclear, especially as you uncover new solutions that don’t match the initial structure.

Hybrid Grouping

You don’t have to choose just one organizational strategy for your entire company. A mature product may be organized by goal, while a new product has no organization, and a shared platform organization is structured by technology. Structures will also change over time, as the situation changes. Knowing when to use which structure is important, even if there is no “right” answer.

A common tool when mixing structures is the “matrixed organization”. This means that the reporting structure does not match the sets of teams structure. For example, an engineering manager may have direct reports in various squads, working on different things, and working with different product managers. This increases coordination cost. It also reduces the context between a manager and their direct reports, which can make performance evaluation more difficult. Watch out for negative impact on cross-functional alignment.

Other Factors to Consider

Inertia is a force that is actively fighting your organizational design. All else being equal, change is hard, and people will be naturally resistant to it. Assuming you overcome that, enacting change is a lot of work. You need to communicate the changes, move people around, and change the names of teams in hundreds of places. Teams with personnel or mission changes will be starting further back on the forming/norming/storming curve.

Changes in code ownership have their own cost. There should be a very good reason for moving ownership between teams. “Keep the Lights On” (KTLO) type work should be as uniform as possible across teams, which may involve additional ownership changes.

Teams and organization names are a powerful tool for autonomy, i.e. “You’re the Activation team, you’re empowered to own anything that involves user activation across the entire company”. But names can also be burdens, as in “every team with something they can squint at and call activation work is going to try to get you to own that”.

You should also consider whether to group specialized skill sets together (i.e. Mobile, Devops, etc). You may also want to think about giving teams the largest possible “swim lane” to an organization, where they can have autonomy, cohesion, and separation of concerns from others.

There is no perfect solution that will solve all factors. The best you can do is pick a set of dimensions to optimize for, and be aware of the trade-offs you’re making.

Conclusion

As an organizational design changes over time, you will make different trade-offs. This is fine, because there is no perfect organization structure. If you stay at a company long enough, you may see a particular pendulum swing back and forth more than once. Each time is a response to a current problem.

Organizational design is not something you can solve permanently. It will need to be solved again as strategies change, and projects come and go. You can only design an organization for about 12 months, the typical macrocycle where both company and team roadmaps are most stable.

Remember to not create dependencies if you don’t have to. Definitely don’t architect in more dependencies than absolutely necessary. Make the best trade-offs you can, for today. You can always make different trade-offs in the next reorg!