An Elegant Puzzle
An important property of teams is that they abstract the complexities of the individuals that compose them. Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals.
Fitting together those guiding principles, the playbook that Iâve developed is surprisingly simple and effective: Teams should be six to eight during steady state. To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five. Never create empty teams. Never leave managers supporting more than eight individuals.
Adding new individuals to a team disrupts that teamâs gelling process, so Iâve found it much easier to have rapid growth periods for any given team, followed by consolidation/gelling periods during which the team gels. The organization will never stop growing, but each team will.
Teams take a long time to gel. When a group has been working together for a few years, they understand each other and know how to set each other up for success in a truly remarkable way.
Most system-implemented systems are designed to support one to two ordersâ magnitude of growth from the current load. Even systems designed for more growth tend to run into limitations within one to two orders of magnitude.
You only get value from projects when they finish: to make progress, above all else, you must ensure that some of your projects finish.
Finally, the one thing that Iâve found at companies with very few interruptions and have observed almost nowhere else: really great, consistently available documentation. Itâs probably even harder to bootstrap documentation into a non-documenting company than it is to bootstrap unit tests into a non-testing company, but the best solution to frequent interruptions Iâve seen is a culture of documentation, documentation reading, and a documentation search that actually works.
In my opinion, probably the most important opportunity is designing your software to be flexible. Iâve described this as âfail open and layer policyâ; the best system rewrite is the one that didnât happen, and if you can avoid baking in arbitrary policy decisions that will change frequently over time, then you are much more likely to be able to keep using a system for the long term. If youâre going to have to rewrite your systems every few years due to increased scale, letâs avoid any unnecessary rewrites, ya know? Along these lines, if you can keep your interfaces generic, then you are able to skip the migration phase of system re-implementation, which tends to be the longest and trickiest phase, and you can iterate much more quickly and maintain fewer concurrent versions. There is absolutely a cost to maintaining this extra layer of indirection, but if youâve already rewritten a system twice, take the time to abstract the interface as part of the third rewrite and thank yourself later. (By the time youâd do the fourth rewrite, youâd be dealing with migrating six times as many engineers.)
If you really want a solid grasp on systems thinking fundamentals, you should read Thinking in Systems: A Primer3 by Donella H. Meadows,
Since reading Accelerate: The Science of Lean Software and DevOp, by Nicole Forsgren, Gene Kim, and Jez Humble,4 Iâve spent a lot of time pondering the authorsâ definition of velocity.
The themes that Iâve found useful for populating the problem space are:
Some of the aspects that Iâve found useful to consider during this phase are:
The elements that Iâve found effective for solution validation are:
Strategies are grounded documents which explain the trade-offs and actions that will be taken to address a specific challenge. Visions are aspirational documents that enable individuals who donât work closely together to make decisions that fit together cleanly.
With that said, itâs time to dig into how to write strategies first, and then visions.
A good vision is composed of:
Good goals are a composition of four specific kinds of numbers: A target states where you want to reach. A baseline identifies where you are today. A trend describes the current velocity. A time frame sets bounds for the change.
The two tests of an effective goal are whether someone who doesnât know much about an area can get a feel for a goalâs degree of difficulty, and whether afterward they can evaluate if it was successfully achieved. If you
From there, the approach that Iâve found effective is:
Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most tools and processes only support about one order of magnitude of growth22 before becoming ineffective, so rapid growth makes migrations a way of life. This isnât because you have bad processes or poor toolsâquite the opposite. The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.23 As a result, you switch tools a lot, and your ability to migrate to new software can easily become the defining constraint for your overall velocity.
Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt.
The first phase of a migration is de-risking it, and to do so as quickly and cheaply as possible. Write a design document and shop it with the teams that you believe will have the hardest time migrating. Iterate. Shop it with teams who have atypical patterns and edge cases. Iterate.
The next step is to embed into the most challenging one or two teams, and work side by side with those teams to build, evolve, and migrate to the new system. Donât start with the easiest migrations, which can lead to a false sense of security.
Each team who endorses a migration is making a bet on you that youâre going to get this damn thing done, and not leave them with a migration to an abandoned system that they have to revert to.
Many folks start migrations by generating tracking tickets for teams to implement, but itâs better to slow down and build tooling to programmatically migrate the easy 90 percent.
The best migration tools are incremental and reversible: folks should be able to immediately return to previous behavior if something goes wrong, and they should have the necessary expressiveness to de-risk their particular migration path.
Start by stopping the bleeding, which is ensuring that all newly written code uses the new approach.
Okay, now you should start generating tracking tickets, and set in place a mechanism which pushes migration status to teams that need to migrate and to the general management structure. Itâs important to give wider management context around migrations because the managers are the people who need to prioritize the migrations: if a team isnât working on a migration, itâs typically because their leadership has not prioritized it.
Your tool now is: finish it yourself. Itâs not necessarily fun, but getting to 100 percent is going to require the team leading the migration to dig into the nooks and crannies themselves.
I believe that, at quickly growing companies, there are two managerial skills that have a disproportionate impact on your organizationâs success: making technical migrations cheap, and running clean reorganizations.
My checklist for ensuring that a reorganization is appropriate:
Does the problem already exist? Itâs better to wait until a problem actively exists before solving it, because itâs remarkably hard to predict future problems. Even if youâre right that the problem will occur, you may end up hitting a different problem first.
I recommend reasoning through this number from three or four different directions:
Otherwise, targeting five to eight engineers, depending on experience level, is pretty typical.
Once youâve grounded yourself, here are some additional considerations:
From there, you have four sources of candidates to staff them:
A few questions to ask yourself before you decide to fully commit:
After youâve answered those questions, make sure to get not only your own buy-in but also buy-ins from your peers and leadership.
In general, the actual tactics for doing this are:
Some of the most common controls that Iâve seen and used:
For whatever controls you pick, the second step is to agree on the degree of alignment for each one. Some of the levels that Iâve found useful are:
The three rules for speaking with the media:
Leading without authority, and Iâve written about one of the styles that Iâve found surprisingly effective in those conditions. I call it Model, Document, Share.
Iâve been trying something different.
Model. Start measuring your teamâs health (maybe using short, monthly surveys) and your teamâs throughput (do some lightweight form of task sizing, even if you just do it informally with a senior engineer on the team or with yourself), which will allow you to establish the baseline before your change. Then just start running kanban. Donât publicize it, donât make a big deal about it, just start doing it with your team. Frame it as a short experiment with the team, and start trying it.
Document. After youâve discovered an effective approach, document the problem you set out to solve, the learning process you went through, and the details of how another team would adopt the practice for themselves.
Share. The final step is to share your documented approach, along with your experience doing the rollout, in a short email. Donât ask everyone to adopt the practice, donât lobby for change, just present the approach and your experience following it.
When considering how the Model, Document, Share approach works, itâs interesting to compare it with the top-down mandate.
The two most common flavors of this Iâve seen are âproduct reviewsâ to standardize product decisions and the âarchitecture groupâ to encourage consistent technical design. There are hundreds of varieties, and they crop up wherever decisions are made. Some of these groups take on an authoritative bent, becoming rigid gatekeepers, and others become more advisory, with a focus on educating folks toward consistency.
Along the way, Iâve picked up some tips that I hope will help you prepare for your next presentation:
Start with the conclusion. Particularly in written communication, folks skim until they get bored and then stop reading. Accommodate this behavior by starting with whatâs important, instead of building toward it gradually.
Everyone loves a narrative. Another aspect of framing the topic is providing a narrative of where things are, how you got here, and where youâre going now.
My general approach to presenting to senior leaders is:
The most impactful changes Iâve made to how I manage time are:
Finish small, leveraged things. If youâre doing leveraged work,40 then each thing that you finish41 should create more bandwidth to do more future work. Itâs also very rewarding to finish things. Together, these factors allow large volumes of quick things to build into crescendoing momentum.
Since then, weâve iterated on format and eventually stumbled on an approach that has worked consistently:
People find it very hard to discuss content that theyâve just learned if itâs too far away from their previous experience. That also creates an environment where learning has to come from the facilitator instead of from the group at large.
Optional pre-reads. Some folks arenât comfortable being introduced to a new topic in public, and for those individuals, providing a list of optional pre-reads can help them prepare for the discussion. I find that most people donât read them (which, surprisingly, I also found true when hosting paper-reading groups46), but for some folks theyâre very helpful.
âWith the right people, any process works, and with the wrong people, no process works.â
Managers work more indirectly, so when we get stuck it isnât always quite as obvious, but we absolutely do get stuck, both on individual projects and in our careers. Here are a few ways that happens.
To partner successfully with your manager:
There are infinite ways to create and distribute opportunity! Some of the programs that I have found more helpful are:
Membership is the precondition to belonging. The programs Iâve found most impactful here:
To increase the number of folks leading this kind of project, Iâve iterated into a structured process that has worked quite well:
The ingredients necessary for such a team are:
Ben Horowitzâs recent post on âCan Do vs. Canât Do Cultures.â
âIf youâre offered a seat on a rocket ship, donât ask what seat! Just get on.â âSheryl Sandberg
Iâve run over the past few years and those I got to experience recently, I believe that, while interviewing well is far from easy, it is fairly simple.
My experience is that you canât conduct a kind, candidate-centric interview process if your interviewers are tightly time-constrained.
Almost every unkind interviewer Iâve worked with has been either suffering from interview burnout after doing many interviews per week for many months or has been busy with other work to the extent that they
It really depends on the signal youâre looking for, but a few of the interview formats that Iâve found very effective are:
Being unprepared is, in my opinion, the cardinal interview sin, because it shows a disinterest in the candidateâs time, your teamâs time, and your own time.
Interview preparedness is much more company-dependent than it is individual-dependent.
Make sure your candidates know that youâre excited about them.
The fix for all these issues is to ensure that you build feedback loops into your process, both for the interviewers and for the designer of the interview process.
For direct feedback from candidates, Iâve started to ask every candidate during my âmanager interviewâ sessions how the process has been and what we could do to improve.
The final step of building a process that remains healthy for the long haul is instrumenting the process at each phase (sourcing, phone screens, take-home tests, onsites, offers, and so on) and monitoring those metrics over time.
Referrals come with two major drawbacks.
My standard approach to cold sourcing is:
Your reach-out notes can be very straightforward:
Candidates tend to come from three large buckets: inbound, sourced, and referrals.
Instead, the formula that Iâve found most effective is pretty simple:
This phase is tricky because youâre balancing quite a few objectives, some of which are in conflict:
Instead of ending your funnel at closing candidates, add four more phases:
The number of approaches to performance management is uncountably vast, but most of them are composed of three elements:
Most companies start out using a single scale to represent performance designations, often whole numbers from one to five.
More important than the scale used for rating is how the ratings are calculated. The typical setup is:
Some rules that Iâve found useful for calibrations:
The approach Iâve started using to design interview loops is:
Theyâre roughly sorted in order from those I found most valuable to least:
One of the first steps to do that is identifying some papers worth chatting about, and here is a list of some papers Iâve seen lead to excellent discussions!