src
- Software, Faster - Leanpub book
Let’s get cracking
- Again, mention of “effective != productive”. We want effective teams, not productive teams.. As seen in Software that fits in your head
- Why the separation: you don’t just want productive engineers & productive teams, you want people that are “really really good at understanding the heart of the problem, and solving just for that”
There’s many methods of learning, & skills acquisition, & you’ll learn with practice, where to apply what model, & to what extent. There’s no one silver bullet
Dreyfus Squared
Bear in mind, this model is from the 70s.
First need to understand the Dreyfus model. Speaks about 5 levels of skills acquisition you go through on your way to deeply learning a skill
- Novice: needs rules, just tell me what to do
- Advanced Beginner: tests rules. At this point you understand the rules and you’re poking at them trying to figure out why. At the edges, breaking the rules a little
- Competent: Applies the rules. This is as far as most people get with most skills
- Proficient: Falls back on rules. At this point, you’ve internalised the rules, and solutions can appear to be fully formed in your head. You’ve got Instinct, insight, intuition, and still learning whether you can trust these, so you fall back on the rules.
- Expert: Transcends rules.

In the context of teams, is where the Dreyfus squared starts to apply.
Let’s look at what’s likely to happen when you pair people at different stages of the Dreyfus model
New person joins the team
- Paring a Novice & an expert
- What happens when you pair these two is that “someone dies” - we don’t know which yet😂
Two advanced beginners
- Chaos. They will break stuff, but there’s lots of learning that happens here the one thing not to do with an advanced beginner is to try and help them not make the mistakes. as that’s the process of learning
Competent & Novice
- Works really well
- At the competent level is where people write rule books, best practices, blueprints & all, because they think the best way to help people is to give them rules
Proficient & expert
- One of the most powerful pairings
Takeaway from Dreyfus squared
- Lets understand these different levels of skill
- Be mindful of how these different levels are likely to collide with each other
- That way, we can do pairings for specific situations that are most likely to be valuable.
- Some meta stuff: Understanding the Dreyfus model is a skill!
Shallow Silos
This is a class of things. Naturally, people have different propensities:
- some people are really invested in the domain they’re solving a problem for
- others are super into systems integration
- Some will nerd out on UX & usability
The premise here, is to put people where their interests lie, you get much more engaged engineers, and the work that comes out of that shows it - it’s much better quality.
A joke
You’ve made it this far, you deserve a joke.
The inverse truck factor: the number of people in your team that need to get run over before your team can start to be effective 🤣and Dan says most teams have a “non-zero inverse bus factor”
Interactions between teams
So far, the two models we’ve looked at apply when looking at interaction within teams. Now let’s step out and look at interactions across teams.
Near and Far
How should a delivery team (building a product) interact with specialists (networking, security, infrastructure, databases etc). Think someone who’s focused the last 10 years of their career just concerned with networking.
Your typical cross-functional team will have people that build the product, and the specialists embedded alongside, and that may not be the most effective way to go about it.
That’s where Near & Far coaching comes in, you have specialists that are embedded in the teams (Near), and those that aren’t (Far).
The specialists that are near are more involed in the day to day, and will spin back to the far specialists (the mothership, as Dan calls it), sort of reporting back on what’s happening.
The mothership’s job is to stay current, learn stuff, and the specialists embedded in the team have the job of implementing those ideas from the mothership, with a secondary role of coaching the teams.
Warm Welcome
Something we can all get started with right away. You only get one time to make a good first impression, and when someone joins a team, warm welcome is about making their joining as smooth as possible. Lay out the red carpet for them.
Once you feel very welcome, you want to pay it forward.
Sieze the Day
Lots of standups go kind of like this
Yesterday I did this, today I’m doing this, I haven’t got any blockers.
We’ve largely missed the point of standup.
Standup is a coordination exercise at the beginning of the day.
The question to answer during standup
What is the best possible today we can have
Do you have any news that will make my day better or different?
- This section on standup is very thin notes, note to self to dive deeper into this
- I remember this article being a good read - worth a revisit
You don’t measure the workers, you measure the work items We’re measuring the flow of work through the system. This is something sigma leadership does really well, imo.
Hack day
Not a Hackathon. But instead a day where we’re not going to do the regular job. Hack day with a theme, for example:
- Bug crushing day
- Perf & throughput days