SWLW #456: Building a culture of low-risk learning, Why is it so hard to decide to buy, and more.

Heya,

As always, below you can read my best findings for the week -
 

This Week's Favorite

​​Root Cause of Failure, Root Cause of Success
5 minutes read.

"When the boulder falls, it means that the collection of processes weren’t able to compensate for the disturbance. But there’s no single problem, no root cause, that you can point to, because it’s the collection of these processes working together that normally keep the boulder up." -- Important read by Lorin Hochstein you should share internally to build some understanding and appreciation for the humans involved in owning a complex system.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Product [sponsored]

 Promote your product on SWLW and reach over 27,900 leaders 

Culture

When You’re Just a VC but Celebrate the IPO Like You Ran the Company the Whole Time
1 minute read.

My humble effort to help you start the weekend with a smile on your face, even in this difficult time.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Shipping Fast and Safe: Building a Culture of Low-Risk Learning
7 minutes read.

Kesha Mykhailov shares useful tips when testing the impact of your work (aka customer value) in production. "Ship the read path first" and "Ship instrumentation first" are not yet common as others (feature flags, canary deployment, etc.), so worth learning and experimenting with them if you haven't so far.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Rethinking Best Practices
5 minutes read.

It's often the words we use that shape the culture we build. Very much like "postmortem" (we use BetterNext), you should consider your language and using the term "best practice" in your team. I love this framing: "We should regard best practices as provisional, not optimal, as a floor rather than a ceiling."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


Why Is It So Hard to Decide to Buy? (Vs. Build)
8 minutes read.

"It’s easy to see the bill for your SaaS software every month, and hard to appreciate that the engineering cost to build an internal version is still probably higher because you haven’t factored in the opportunity cost of having engineers build that system instead of contributing to more core business opportunities." -- Camille Fournier covers well when to build versus buy, why it's hard for companies to build (and why it's often hard to buy) and how to set incentives correctly.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Jobs [sponsored]

Director of Engineering @ Forter (Israel)
Scale the team from 30 engineers to 60, building the world's most advanced systems and products to prevent fraud online.
 

 Looking to hire for your team? Promote your open positions on SWLW! 

Peopleware

Why You Feel Uncertain About Everything You Make
3 minutes read.

Tobias van Schneider with a short yet important reminder on the need to collect feedback while also forming a strong opinion: "Ask enough people for their opinion, and you’ll receive whatever answer you’re looking for – plus plenty more you didn’t want to hear. The feedback cancels itself out."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


The Use of Spaced Repetition Memory Systems Has Changed My Life Over the Past Couple of Years. Here's a Few Things I've Found Helpful (Thread)
3 minutes read.

I love Michael Nielsen's work, and he made me go deeper into Spaced Repetition and try out Anki. Figuring out the right driver to practice it is key, or as Michael wrote it: "But what finally made Anki take was frustration that I'd never really learned the Unix command line." -- is there something you want to learn and remember? Try to find something that would be practical for your day-to-day work.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.


DevTools Leverage
4 minutes read.

I cannot agree more with this recommendation: "Over the larger arc of your career, I'd recommend switching between roles every so often: build a product, build tools to make that experience better; go back and continue building the product; and repeat. You'll become a more rounded and effective engineer once you have experience across both sides. It's not a completely binary decision either; you could always split your time and play toolsmith for a part of the week."

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

And finally, inspiring tweets...

@copyconstruct: Moving to kubernetes/any other platform to improve your reliability is the infra equivalent of rewriting your codebase in a different language for perf/stability etc. There might be some (debatable) gains, but there are *guaranteed* to be a slew of bugs and nasty surprises.

@ShaneAParrish: Finite games are won with intensity. Infinite games are won with consistency.



p.s. if you're interested in joining SWLW's Slack channel, simply reply to this email and let me know.

If you're leading a team, consider writing your Manager README (it's free) or getting my e-book and interviews Leading Snowflakes: The New Engineering Manager's Handbook. You can also support me and my work by becoming a SWLW Patron. Thank you ❤️




Keep reading, keep learning.
-- Oren Ellenbogen.