Join 📚 Felicity's Weekly Book Highlights
A batch of the best highlights from what Felicity's read, .
In my experience there are a few parts to the change. First we need to shift the definition of team success from pushing code to production (output) to achieving the team goals (outcomes). The constant drum beat of launching steps, and seeking user/business evidence helps drive the point home. Second, we want team members to have plenty of context: users and their needs, business rationale, competitive situation, and more. The context helps team members understand what makes sense and what doesn’t, and eliminates the need to spoon-feed them with bite-sized, detailed requirements.
Evidence-Guided
Itamar Gilad
*Staff Engineer* introduces an approach I call [Take five, then synthesize](https://lethain.us20.list-manage.com/track/click?u=f7003ed301623a88fab7cf783&id=1e5e9d0544&e=a102c6f471), which does strategy by:
1. Documenting how five current and historical related decisions have been made in your organization. This is an extended exploration phase
2. Synthesizing those five documents into a diagnosis and policy. You are naming the implicit strategy, so it’s impossible for someone to reasonably argue you’re not empowered to do strategy: you’re just describing what’s already happening
Who Gets to Do Strategy? @ Irrational Exuberance
Will Larson
Anytime you’re building a new system, regardless of how technically complex it might be, testing the value of the idea is the best place to start. If no one wants it, it doesn’t matter how hard or easy it is to build it.
How I Break Down Hypotheses to Make Them Easier to Test
Jeff Gothelf
...catch up on these, and many more highlights
Readwise