“The purpose of life is not to be happy. It is to be useful, to be honorable, to be compassionate, to have it make some difference that you have lived and lived well.” - Ralph Waldo Emerson
The purpose for the dev team is to be useful (1). We will accomplish this by being more productive and building the right things. Tactical plans to achieve this purpose will vary greatly. It is more useful to have a set of guiding principles which can be applied as the situation evolves. These principles can be used in any situation as a framework for decision-making that will guide us forward.
We don’t confuse productivity with efficiency. Efficiency is a fine goal but we’re not trying to do more with less. That can work in a factory but not in a creative endeavour where our speed is managed by our knowledge (2).
Instead, we want to do more with the same (3). We will accomplish that by optimizing our approach to delivery and expanding our use of technical leverage.
Our approach to delivery depends on many factors: technical architecture, org design, process design, and paying attention.
Defining bad technical architecture is easy: it’s a ball of mud (4). The path to a good technical architecture is harder to define. What we’ve found to work well is:
- build clean interfaces (5),
- have good practices (6) (7) (8),
- make hard things easy (9), and
- make it hard to screw up (10) (11).
Building software this way has many benefits: it reduces the cost (and the fear!) of change, makes it easier to onboard new developers, and encourages devs to improve their craft and pursue mastery.
Org design is mostly a solved problem, yet many companies continue to ignore the solution. It's not enough to just be a smart org; the org also has to be healthy (12).
- build small empowered teams with shared purpose (13),
- give teams a clear mission (14),
- ensure aligned autonomy (15), and
- hire for your blind spots.
- stop starting, start finishing (16)
- spend less time on tasks, more time on deep work (17),
- push decisions to those most impacted (18), and
- limit work in progress (19) (20).
- define goals with timeframes and targets (21) (22),
- identify proxy metrics that correlate to the goals, and
- measure organizational health (23).
Leverage is about maximizing your impact. Working smart, not hard. 10x devs aren't 10x better - they've figured out how to use leverage. They teach what they know, listen to others, use off the shelf software, and are always learning.
- show & tell, munch & learn
Being productive and building great software doesn’t mean anything at all if we’re not building the right things. We need to spend at least as much time choosing what we build as we do in deciding how to build it.
To make sure we’re building the right things, we’ll be sure that we’re making something people want and evaluating outcomes rather than outputs.
- Start with a hypothesis, launch quickly, and then talk to users (24) (25)
- Darius Foroux, “The Purpose Of Life Is Not Happiness: It’s Usefulness” - https://medium.com/darius-foroux/the-purpose-of-life-is-not-happiness-its-usefulness-65064d0cdd59
- Dan North, “Deliberate Discovery” - https://dannorth.net/2010/08/30/introducing-deliberate-discovery/
- Aytekin Tank, “Focus on productivity, not efficiency” - https://www.jotform.com/blog/productivity-over-efficiency/
- Brian Foote & Joseph Yoder, “Big Ball of Mud” - http://www.laputan.org/mud/
- Steve Yegge, “Google Platforms Rant” - https://gist.github.com/chitchcock/1281611
- Will Larson, “Notes on A Philosophy of Software Design” - https://lethain.com/notes-philosophy-software-design/
- Jeff Atwood, "Programmers and Chefs" - https://blog.codinghorror.com/programmers-and-chefs/
- Dave Cheney, "Clear is better than clever" - https://dave.cheney.net/paste/clear-is-better-than-clever.pdf
- Kent Beck, Twitter - https://twitter.com/KentBeck/status/1111281250059182081
- Chris Coyier, “Make it hard to screw up driven development” - https://css-tricks.com/make-it-hard-to-screw-up-driven-development/
- Michael Marx, "Who Deleted Toy Story 2? A Pixar Lesson in Continuous Improvement" - https://michaelmarx.info/who-deleted-toy-story-2-a-pixar-lesson-in-continuous-improvement/
- Patrick Lencioni, "The Advantage" - https://epl.bibliocommons.com/item/show/935215005
- Interview with Ken Exner, “How Is Software Developed At Amazon?” - http://highscalability.com/blog/2019/3/4/how-is-software-developed-at-amazon.html
- Nick Caldwell, “Write Useful Mission Statements in 3 Easy Steps” - https://hackernoon.com/write-useful-mission-statements-in-3-easy-steps-929deae26092
- Henrik Kniberg, “Aligned Autonomy” - https://www.youtube.com/watch?v=_qIh2sYXcQc
- Henrik Kniberg, "Focus – my keynote at AgileByExample, Warsaw" - https://blog.crisp.se/2016/10/20/henrikkniberg/focus-keynote
- Michael Karampalas, “Time to Think” - https://statushero.com/blog/time-to-think/
- L. David Marquet, “Turn the Ship Around!” - https://epl.bibliocommons.com/item/show/1128717005
- Will Larson, “Why limiting work-in-progress works” - https://lethain.com/limiting-wip/
- John Cutler, "Creating Flow and Value in Product Development" - https://amplitude.com/blog/creating-flow-value-in-product-development
- Christina Wodtke, “The Art of the OKR” - http://eleganthack.com/the-art-of-the-okr/
- Atiim.com, "OKRs (Objectives and Key Results) – What are OKRs" - https://www.atiim.com/okr-goals-objectives-and-key-results/
- Henrik Kniberg, "Squad Health Check model – visualizing what to improve" - https://labs.spotify.com/2014/09/16/squad-health-check-model/
- Can Olcer, “Quantifying YC’s ‘Make something people want’” - https://hackernoon.com/quantifying-ycs-make-something-people-want-2d07b7762f56
- Jeanne Ross, "Why Hypotheses Beat Goals" - https://sloanreview.mit.edu/article/why-hypotheses-beat-goals/
- Marty Cagan, “The Alternative to Roadmaps” - https://svpg.com/the-alternative-to-roadmaps/