Impact through Influence

NOTE: This is part of the tech lead academy series. This post contains mostly raw notes from the course I took from Kent Beck.

Intro

Due to the way FB engineering culture has developed over time, it really is a sink or swim culture. Old geezers can prevent young'uns from making mistakes that we've been used to spotting since forever.

Kent: "I've been programming since before you were born. I hated when senior people said this to me, but now that I can say it, I can tell you it's so satisfying".

During individual coaching of engineers, he noticed common patterns in behavior amongst E3 (entry level) and E4 (early career) engineers. This lead to the creation of N00b academy, a set of courses targeted at that cohort. Those courses covered concepts like time management, prioritization, code reviews, informed decision making, etc.

As you go more senior, a new set of issues arise: you need to go from creating your own individual impact, to achieving impact through influence. As an E5 (senior) or E6 (staff) engineer, you need to focus on influence and a different set of metrics. Code is just one part of your impact.

As you go from E4 to E5, your proposals for ideas go from "this is bad, so I shouldn't do it" to "this is bad, so I should go and fix it".

Today's course is all about riding the E5 bicycle.

Problem solving styles

Kent discussed a fascinating discovery he made a few months ago. He would normally tackle uncertain problems with fast iteration cycles. But he'd never asked "what problem are the waterfall people solving?"

Plan heavy people are also solving a problem - just a different one than what he's solving.

This is best understood using the explore-expand-extract graph:

S-curve showing the various stages of a project: explore, expand, extract.

Each project or product goes through this cycle over time:

Explore: This is where you try to find product market fit and a niche for what you're building. This phase can be long, can be short. The goal is to do as many uncorrelated experiments as possible to find what works
Expand: Time is compressed, need to rush and double down on the early successes so you can capitalize on what you have. The payoff can shoot up really fast, and it's not always clear where it will top out.
Extract: The goal here is to extract value from what you have built and use that to pay for further exploration, fueling future growth.

Each phase brings with it its own set of approaches. One example: You likely don't want to focus on heavy test coverage during the explore phase, but want to add them in the extract phase.

Editor's note: Kent has his own post expanding upon this model here.

Planning oriented people are essentially trying to do extraction better; while iteration oriented people are trying to be better at exploration.

This is fine! Different people are better at different phases. As an example, asking an intern to work on adding 4 widgets to the Foo product is likely a waste of an unpolluted mind (which could go to trying new ideas).

It's important to learn about yourself so you can go to the phase you're most comfortable at - each phase needs leadership and influence.

Necessary conditions for growth

Kent: "Do you think your abilities are fixed? If so, you're an idiot".

There are a few necessary conditions for growth:

Challenging work: You need to be operating outside your comfort zone
Feedback: You need to be receiving feedback on how you're doing, and be open to hearing it.
Resilience: You'll fail at times, and you need to be okay with that (and have an environment whereit's ok to fail)

Once you're out of your comfort zone, you'll be in chaos mode and have time to grow. However, remember to be careful to not get too overwhemled.