jonoropeza.com

Making software and software development teams. Mostly the people parts.


Andy Grove's High Output Management and the Three High Impact Activities

Andy Grove's High Output Management is a classic. My first mentor insisted I read it when I was building my first team, and I'm happy to see it still relevant and referenced today.

While the book has a massive amount of gems, the wisdom can be summarized for fast consumption by bulleting out Grove's opinion of the three highest impact activities a manager can focus on, these are:

  • Gathering information
  • Making decisions
  • Influencing others

I'm not sure those map perfectly to my opinion of the highest leverage activities a leader can focus on in 2022, but they're close. Real close. You won't lose with that as your go-forward how do I organize and plan my week framework.

There's a Medium post out there that summarizes the book nicely if you don't have time for the full read. But this is one you really should make time for the full read for.


Roll Back or Fail Forward

How to decide between rolling back or failing forward (or fix-in-place) as a policy for a given experience in a given environment.

Rolling back is generally the more mature habit. It enables everyone to take a breath, identify and fix problems (ideally with test coverage) in a low-pressure environment. Failing forward, on the other hand, is cowboy coding. And it's fast, and if it works it generally lets teams move on to the next problem much quicker and gets value in the hands of users faster.

Often I've found myself in situations where an engineering squad is making an argument for why they should fail forward in a given environment.

For me, as an engineering leader, I use the following framework:

If, in a given incident, users and stakeholders of the experience would be fine with an order of magnitude (10x) the downtime you've taken, then failing forward is fine.

Example 1: A production retail site. A typical incident might be 12 minutes long. 12x10 = 120 minutes. During that time the business would lose an estimated $50k in sales. That's not acceptable, therefore the policy should be to roll back failed changes.

Example 2: A non-prod environment is used by a vertical squad (PM+Design+Engs) to demo changes to stakeholders once a week. Same typical incident time but in this case, 120 minutes of downtime is fine unless of course it happens to overlap with the weekly demo. Failing forward is an acceptable policy in this case, trusting the team to manage around that weekly demo (policy can be written such that the team gets autonomy to choose between rolling back or fixing in place by accepting the accountability of managing around their own schedule... this is probably a separate post).

A counterpoint is when you have a team that's too aggressive for your current state. A while back I was on a team that had been acquired, and many of us were still acting like it was a startup even after revenue in some streams had 100xed. That team needed a strong counterpoint to its previous behaviors, and so "never fail forward in any environment" became our tacit policy.

The tacitness there is important. As always, the best policy is no policy. A team that expects to be told what to do in every situation needs either more capability or more confidence or both. A team that requires it is functionally useless other than as a feature factory. First principles and a strong values-based decision making culture, on the other hand, obviate the need for explicit policy in every space. 


Dimensions of Engineering Management Focus

Task, team, individual

No wrong answers here except ignoring one or two of these. Every EM has a preference. One of the things you want to find out when interviewing EMs is when the chips are down, does the candidate index highest on task, team or individuals. Case studies can be really good here.

Tech, people, systems

Too much tech is an obvious red flag... unless it's a tiny org that really doesn't need an EM yet. Some orgs create roles where the tech is entirely out of the equation, and the EM is a pure manager of people. Even then, time should be allocated for systems of hiring, people management, review cadences, performance criteria.

Now, next, later

This is often situational. One trap is staying focused on the Now once the incident is solved, the last minute report is done, the spend is back under budget. Another trap is obsession with later at the expense of next. Some time for long term vision is essential, however it's the next that will move the needle, and stacking a few solid quarters together under a loose vision often works a lot better - and is appreciated much more by the business - than looseness on the quarterly level with a strong but always further-out vision.

Ground level, tree tops, mountain top

More traps here. Punting the ground level to your seniors and leads can work if you've developed high trust. I've worked with a few leaders who refused to leave the mountain top... I've never seen that work long-term. The only way I've seen it work is when EM is a quick stop on the way to higher rungs, directorship or beyond. Stick in the EM role for a year or more without at least coming down from the mountain and at best you'll have a team that nods along but isn't listening to half the words you say.

Working in the org vs working on the org

The EM who takes an on-call shift or puts in a toil PR understands the pain of poorly constructed systems or flaky CI. Not to mention winning the respect of their team. Especially relevant for new EMs coming into an org. A lead who's been there, done that and has their name all over the blame might be able to get away with spending full time working on the org... if they can resist the temptation.


Second Lap

Talking to a candidate the other day who described himself as "being on my second lap", I thought, yeah. That resonates. For me, this is what my career looks like so far after over 20 years in tech:

  • Studied Computer Science at SDSU
  • Worked as an IC and then later as a Director at a retirement planning brokerage
  • Started businesses, cofounded a seed-funded startup, Startup CTO
  • Then back to IC as modern JavaScript, React and Chrome made building for the web fun
  • Enterprise Principal Engineer, doing architecture and systems designs
  • Then back to my true loves: People & startups. Senior EM at a Series A turned Series B healthcare research rocketship

There was a time when my age worried me. Sometime around my mid-30s: Silicon Valley was the hot show, and I was very concerned about aging out and how valuable was a 40-something technologist, anyway?

As turns out: Very much so. Every day I find myself referencing and making decisions from something experienced along the way. Whether it's people management mistakes, making a poor hire, or microservice complexity explosion, having been there, done that gives me the kinds of sniff tests that often lets me smell trouble long before anyone else sees it.

This kind of career path wasn't talked about when I got into industry. Back then the thought was, well, it's one way up the ladder. And if you ever fall off, then you're stuck at the bottom for good. Not the case anymore.

Will I go for a third lap? It's hard to say, but at this point my lean would be why not. I've never lost the deep love for programming and for building that I've had since childhood. Building orgs is fun, and I'd be perfectly happy to keep doing this. And... if an opportunity comes up someday to focus again on writing code? A third lap sounds like a good challenge to me.


Time Is The Toughest Dimension

Along the way, you learn to reason about systems along two axes:

Vertically: the tech stack, generally from persistence forward to a UI.

Horizontally: the capabilities and experiences built from said tech stack.

Time is the third dimension, and it's the hardest to reason about. Spending time reading the blame is one way. Talking to people is another. Usually somewhere in the intersection of those written and oral histories is a clear picture of how we got here.

The superpower is in being able to tell a story, based on trajectory and velocity, of where we might go, and where we should go.

My experience is that most ICs and even many leaders will struggle to see the time dimension clearly.