Nathan's Notes - April 8, 2024

This week, I’d like to share a handful of articles I came across over the past few weeks that I found particularly interesting and wanted to pass along to you. Have you run across any interesting articles on leadership, coaching, or technology that you’d like to share? Please send them over!

Thanks for reading! Subscribe for free to receive new posts, and be sure to forward this along to anyone you think may enjoy it.

Engineering Crits

Really great read about how Figma introduced "engineering crits" into their development process. One specific thing really stood out to me though.

Their philosophy, and one that I've held close for years, is very similar to that of "Braintrusts" described in Ed Catmull's book "Creativity, Inc" about the history of Pixar: where a group of seasoned leaders would come together to provide feedback on a new idea or story, but the presenter would be coming seeking perspective, not permission. Especially in the early phases of an initiative, it is not about approvals; it is about collectively making the ideas better.

Perspective, not permission.

This post is definitely worth a read (as is "Creativity, Inc", if you have not read it).

Leadership Requires Risk

"If you want a bottom-up decision-making environment, but feel that taking on personal risk is an unreasonable demand, then maybe you actually don’t want a bottom-up decision-making environment."

What a great line from one of Will Larson's latest posts on engineering leadership.

He touches on a concept in here that really resonated with me though, and it applies beyond just the engineering audience. He mentions that "the typical executive holds a basket of risks", as opposed to, say, a Staff Engineer, who may only own one.

As an executive, one is not only managing a team and multiple projects, they are managing a portfolio of risk.

DevEx in Action: A Study of its Tangible Impacts

As the business environment has shifted so considerably recently from growth-at-all-costs to sustainability and profitability, the work that these researchers have done to begin to reframe the narrative of Developer Experience from "Productivity" to "Outcomes" is incredibly important.

To development teams, these outcomes have always felt implicit and obvious: the fewer the interruptions, the more intuitive the processes are, and the more efficiently the team can work... the more impact the team will be able to have on the business.

But to those outside of the process, it may be far less clear. And as technology leaders, it is our responsibility to be able to translate what may have always felt intuitive to something tangible:

How is investing in Developer Experience actually going to quantifiably help my business?

These researchers are onto something.