090: Perfectly Designed Systems
🤔 What's your chronotype?
Are you a morning lark, night owl, or hummingbird (midday) person? How does this affect how you plan your day/life? (here's an assessment if you want to get rigorous)
🧠 On Human and Tech Systems
I'm reflecting on a couple tweets I saw recently that relate to a project I'm driving at work.
Tweet 1:
One of the key lessons I've learned as as an "architect" is that if you can't influence the design of the org, the design of the tech and systems is a futile activity.
— Damian Hickey (@randompunter) January 29, 2022
Our goal is to build and improve tooling to help Meta engineers be more productive around documentation. Code documentation, API documentation, project documentation. And this first tweet hits home pretty hard: we can make the tooling better, but we also need to influence the org's design to get better documentation to be created.
Tweet 2:
The current "system" of the organization, it's forces, it's communication structure, feedback loops, tacit "norms and rules" culture and incentives are more powerful and resistant to changes than most people would like to accept
— Juan Bernabo (@JuanBernabo) January 30, 2022
Quality documentation is an outcome that emerges out of an interaction between technical systems and human systems. As the W. Edward Deming quote goes, "Every system is perfectly designed to get the results it gets".
I've written before about how Meta is hyper-focused on delivering impact, which for engineers means mostly shipping code that gets tons of user engagement, or optimizes ad delivery to squeeze out more profits.
To some degree, engineers are also rewarded for "good citizenship" style activities like interviewing eng candidates, fixing bugs, or writing documentation. But when you have to quantify all those things, documentation does not get the same kind of recognition as other activities. Which makes our project tricky.
Tweet 3:
Lol I had made a mental stereotype in early in my career (to help make quick decisions between offers from different orgs)
— Arnav Gupta 😷 💉🟢 💉🟢 (@championswimmer) February 5, 2022
Who heads engg?
CTO
Engg is profit center
CIO
Engg is cost center
HoE (no CXO)
Tech is overruled by product/business
VPEng
CEO micromanages tech
I thought this discussion of what the highest ranked engineering leader is in an organization says a lot about how much power they have, and how engineering is viewed. Theoretically the job a software engineer does has nothing to do with this senior leader, but in reality, that eng's responsibility varies tremendously. A CTO are more likely focus on unlocking the upside revenue opportunities of their engineering resources, while a CIO may be more focused on reducing the total cost of delivery.
What does all this have to do with resilience? Well, it's a reminder for innovators that trying to bring your big ideas into the world requires a deep appreciation of the human systems you're working inside of. Without an understanding of those systems and how you plan to interact with them, your innovation will not succeed.
🖼 An (Updated) Resilience Rules Framework
I've been working on an updated version of the resilience rules framework, trying to lay it all out visually. Would love any feedback you have. Is it too dense? Or still lacking details on each of the rules? What's the right balance here?
👉 Humanities: A Free Illustration Resource Library
If you like the cat from this issue's cover image, or the octopus from last week, then you're admiring the handiwork of Levi and Lily Nunnick of Humanities Studio. They're offering 50 lovely, hand-drawn illustrations for a "pay what you want" model.
Recent Issues
More Resources and Fun Stuff
- Book Notes: Summaries / quotes from great books I've read
- Scotch & Bean: a webcomic about work, friendship, and wellness
- Birthday Lessons: Ideas, questions, and principles I've picked up over the years
- Career Spotlight: A deep dive into my journey as an athlete, PM, founder, and creator.