Early in my management career, I believed most processes failed because they insufficiently addressed the problem at hand. I thought that if a process’ results were poor, it was because the process needed more nuance and sophistication. What I’ve learned since, mostly through designing thoughtful processes that nonetheless failed, is that good process is a deliberate tradeoff between quality and overhead. (View Highlight)
To figure out the appropriate degree of process sophistication for your team, you have to start by figuring out who’s going to run the processes, and reason backwards from that answer to the degree of process sophistication your organization is capable of sustaining. (View Highlight)
Brand new companies all use what I call the Early Startup pattern: either a founder or the functional executive does something for their function, or it doesn’t happen. My first year as Calm’s CTO, there were no shared People processes, and I ran Engineering’s performance review process out of a spreadsheet. It needed to get done, and I was in the position to do it. (View Highlight)
Finally, there is the Business Unit Local pattern, where engineering reports into each business unit’s leadership, and there is no longer any one leader who is responsible for the entirety of engineering (View Highlight)
Any process that you want to run needs to be run by the founders, or managers hired by those founders.
Companies usually exit this pattern because there is impactful process they want to run, often initially this is performance management, but they feel they’re too busy to run it with the current team. (View Highlight)
Pros: low cost, low overhead, few downsides at small scale beacuse most process is focused on supporting large teams
Cons: often valuable stuff doesn’t happen because everyone is too busy, sometimes quality of process is very low due to limited time or experience running that process (View Highlight)
Baseline: Engineering-scoped processes are run by engineers or engineering managers, and company-scoped processes are run by a centralized function, usually in People or Human Resources. Most companies stay in the baseline pattern for an extended period of time, with perhaps one small exception for a dedicated recruiter for engineering hires. (View Highlight)
some modest specialization to allow Engineering to focus on engineering rather than foundational company process, complexity of HR tasks tend to outstrip engineering manager depth by this phase (e.g. managing visas), unified systems allow executive team to inspect across functions rather than just in their own function (View Highlight)
Specialized Engineering Roles: increase efficiency in Engineering-scoped processes by hiring dedicated, specialized roles to fulfill that work. (View Highlight)
It’s a lot of work to effectively support specialized roles like engineering operations or technical program management. Specialized roles often freeze a company in a given way of working, whereas engineers is incentivized to eliminate a process, the specialist is incentivized to improve it (View Highlight)
Business Unit Local: each business unit in a company has its own, separate engineering function. This split typically occurs when an organization becomes large enough to have multiple meaningful business units, and there’s a perception that standardization across engineering in those business units is unnecessary or unnecessarily expensive. (View Highlight)
All of these patterns have flaws, but are worth considering. That said, if you asked me to pick one without any additional context, I would always recommend the baseline pattern. It’s generally good enough, and the easiest to manage (View Highlight)
While there are operational challenges to moving across patterns, most of those challenges are only obvious in hindsight. Instead, the biggest impediment for moving from Early Startup to Baseline or from Baseline to Specialized Engineering Roles will be the budget implications. Even if you can show that three Technical Program Managers would significantly improve Engineering impact–which likely is true but you likely can’t prove with a spreadsheet–most budgeting processes are anchored on relative dollars rather than absolute impact. (View Highlight)
Most companies that successfully shift up the patterns’ cost curve do so when they are rapidly growing. Such companies are comfortable with rapidly growing headcount costs, and are generally tolerant of adding roles to support that growth. In all other circumstances, companies generally aren’t tolerant of adding new roles and structures, even if they would likely increase efficiency. In the latter scenarios, you’re much more likely to hear folks talk about “doing more with less” than “designing our organization to operate efficiently (View Highlight)