While re-reading, I felt like this topic was introduced in a bit of a confusing way for me.
This note captures & groups together what I find myself citing from the topic.
Context
Maturity/Capability are mental models. They are also operational models. They include frameworks and heuristics used for decision making around engineering projects.
Just to be clear
❌ Maturity model = bad
✅ Capabilities model = good
1. Maturity Model
Fixed mindset, focused on getting to a mature state then declaring yourself “done” with a journey.
It usually sounds like “we’ve achieved CI/CD & don’t plan in investing in that again”
Same energy as the guy who says “I finished FIFA” or other sports games💀
Very prescriptive & linear:
Every team’s told to use the exactly sets of technologies and process.
There’s tradeoffs here, giving teams absolute freedom can very quickly become inefficient. Defining sensible defaults is a good place to start.
1a. Vanity metrics
Measuring vanity metrics tends to be common when operating in a maturity models environment.
Writers who operate by Will Larson helped me solidify the why behind my writing. I expand on it here. Since then, I’ve been writing a whole lot more in Apple notes, but my publishing rate hasn’t changed. I’m ok with this balance, for now.
I go through lots of tech content: articles, podcasts, books, videos. As a result, I often find myself sharing the same groups of links with my mates & colleagues, all over different chat apps.
This is a consolidation effort.
Books on my shelf
An Elegant Puzzle. Been a big fan of Will’s blog for a while now. This book’s my current active read, I’ve been wanting to read his books for a while. This summary gave me the final nudge to start the book.
I’ve routinely seen team morale at its highest when everyone is focused on the same goal. One task, one feature
For an extended period of time
Extended period of time allows people to learn each others’ rhythms. That’s not something you can speed run unless you have very self aware, or very experienced people who can also communicate well
The shared context makes for reduced overheads of coordination & communication cross teams
This also goes hand in hand with autonomy. It drives autonomy and ownership, but it needs you to be trusted with autonomy in the first place, before you can start reaping those benefits
Having a shared problem & collaborating your way to a solution can also strengthen your relationships with the collaborators. “Something something trauma bond” 😂.
But if we give teams too much autonomy, there’ll be too much variance in our codebases
A way to mitigate this is to have those responsible for architecture & platform to define what the constraints are
Ie: which areas can we innovate on, and which areas are standardised
Goldman Sachs managing director and Law School adjunct professor Jim Donovan shares his insights on the skills necessary to manage and cultivate client relationships. Donovan is responsible for advising many of the largest corporate and individual clients of Goldman Sachs. (University of Virginia School of Law, Nov. 6, 2015)