Forget the "Wait 90 Days" thing. Make decisions now.

Eugene Yan sums up conventional wisdom that all new executives are bound to hear:

“[Don’t] fall prey to the action imperative. Don’t feel the need to take action too hard and too quickly to put your stamp on the team. Instead, adopt a beginner’s mind and focus on learning. If we’re too busy taking action instead of learning and diagnosing, we risk prescribing the wrong medicine. This leads to making bad decisions early on, losing trust, and inadvertently building resistance to any future ideas we have.”

In contrast, Will Larsen writes: “When you read the literature, the platonic ideal of your first ninety days is time spent exclusively on learning, preparing for measured, effective execution on the ninety-first day. Depending on your circumstances, this might be feasible, but it might be misguided.”

I’m with Will, except I’ll extend his statement. It is usually misguided.

I’ve been at this for about 25 years. Time alone has armed me with instinct about what should and shouldn’t be. It doesn’t take ninety days for those of us who have put in time managing engineering teams to spot problems. Further, companies hire experts precisely because they have problems, and they want them solved yesterday. Given these dimensions, it’s not hard to know what needs fixing.

I wrote recently about what “fast” is. Bonusly wanted me to start making engineering fast right after I started, like in my first week. So I wrote down this six-month plan with three expanding phases (blue, green, and orange) and shared it with the other executives:

I had three principles in mind when developing this plan. The first takes the longest to address but is the most impactful. The last can be done the fastest, but is also the least impactful relative to the other two.

1. Talent. People are the most important element and take the longest to get right. Does Engineering have the right skills? If not, can they be learned quickly? Do people want to learn them? Do we have a culture that pushes through friction? Do we need to hire people to get faster? Note: hiring/curating great talent will make it easier to address the other two principles. But this first one takes time to get right.

2. Focus. Is the team given a clear goal? If not, do they ask for one? Do they understand it? Do they believe in it? What are we saying "no" to? Are teams explicit about what they’ve said “no” to? Are people aligned with that? Are we giving teams enough time to achieve their goal? How often are they interrupted? Is all this unplanned work important?

3. Technical debt. How hard is it to work in the codebase? How confident are engineers that their changes will behave as expected in production? How quickly can engineers fix production problems?

Making decisions, now. The blue zone.

I had lower confidence that we’d actually do things further to the right in the plan (green and orange). I had higher confidence that the left-most things (blue) would start speeding us up. So I made decisions.

1. Measure productivity with SPACE. A lot has been written about measuring developer productivity. Many argue it can’t be done (check out this article). And it’s true, product development is a craft. And that word, “craft,” implies creativity. How does one measure the act of creation? Fair. But if the artist isn’t painting anything, we can conclude she’s not going to create impactful art. In product development, there is no customer value without productivity. I wanted to spot productivity trends and chose SPACE and DX to help implement it.

2. There was no formal on-call process. So we paid for PagerDuty, set up a schedule, and put all engineers, including me, on call. This would have a couple of side effects:
   
   1. The “usual suspects” who kept the lights on would find reprieve.
   2. Engineering, holistically, would appreciate customer pain more than it did.
   3. On-call issues know no partition; engineers would become conversant in most areas of our system regardless of what part of the code they were normally in.
   4. Most important: we’d tackle customer issues faster.‍
3. Slowing international hiring. Some executives firmly believed our velocity problems were caused by headcount problems; if we had more engineers, we could do more. We should continue hiring overseas to get more engineers. That’s logical, but I didn’t agree with it. We debated. And the executive team trusted me to shift toward building our domestic core, even if it meant less people. I was convinced that fewer, timezone-aligned engineers would help us build a solid engineering kernel. We made adjustments to our comp bands, too, fixed people who were out of band, and hired more talented engineers who had worked for great companies to join our team.

When I have my first 1:1 with people who start here, and they ask me for advice, I tell them to make decisions now. I tell them the wrong decision is better than no decision, in my opinion. At least you’re trying to make a difference. We trust you.