"Of course your project was successful, look at all these amazing engineers!”
I've heard this. And yes, we started with some amazing engineers. We also had juniors.
Pair programming as learning is a skill which needs to be learned by seniors. Some people never seem to learn how, and become frustrated. When it works, though, the senior learns right along with the junior, and the junior becomes proficient very quickly.
in my mind, i started to replace "forest" with "garden" for this metapher. In my mind a forest us something ancient and wild, and a garden is cultivated and sensitive.
It's interesting how different metaphors hit people differently. I lived in a forest most of my adult life, a forest where I was not the apex predator. I know there's danger there but I also know how to stay safe.
Same, I use "The Forest" as an metaphor for something nasty that side-tracks us (https://www.fractalproductivity.club/about). As it is used here, it only makes sense if it is contrasted to The Desert as they usually do. But maybe they could've chosen "Oasis" instead of "Forest" :P
A minor detail that doesn't take away from the main theme of this article: when we miss a demo we need to either "Slice the next week finer" (often a good idea) or *reduce friction*.
Maybe some code complexity has accumulated or the tests have are slow/flaky or a knowledge/skills gap has developed, etc. Put another way, desertification has stricken our otherwise-lush forest.
I have been lucky to have worked in a forest a long time ago and I would like think that I have managed to create a small oasis for my teams in the dessert too.
One thing I wanted to mention is that optimizing for learning, as opposed to production, works because of the available slack that acts as a safety net for production. Specifically, the production output is closely monitored and is always maintained at high level. And it is exactly because there is a big buffer, the new feature can be given to a junior engineer. If this engineer starts to take too much time, the senior engineers can step in and help, but again they could be pair-programming with this junior from the start so there is really never a drop in productivity.
What was hard for me to do as a manager is to trust that we are not creating a bottleneck by delegating complex things to junior engineers for learning. The setup that ended up working well in the end is working through TLs: senior TL would be responsible for delivering the feature/change in the end, but the junior person was assigned to drive it.
From management perspective I have referred to this set up as “building capacity” in the sense that we are not just delivering a feature (which would be faster to do by having the TL work on it), but we are also using extra engineering capacity now (i.e. working a little slower), in order to have more engineering capacity in the future (by growing the capabilities of the junior engineer).
The main challenge is the race to the bottom in the short term: if people are evaluated by how much they deliver in the limited amount of time, investing in the future is indirectly discouraged. The created capacity is invisible to higher level of management, but the (lower) output in the short term is. So it takes a good amount of management work to create and sustain this environment (if the rest of the company has a dessert/scarcity mindset).
"Of course your project was successful, look at all these amazing engineers!”
I've heard this. And yes, we started with some amazing engineers. We also had juniors.
Pair programming as learning is a skill which needs to be learned by seniors. Some people never seem to learn how, and become frustrated. When it works, though, the senior learns right along with the junior, and the junior becomes proficient very quickly.
in my mind, i started to replace "forest" with "garden" for this metapher. In my mind a forest us something ancient and wild, and a garden is cultivated and sensitive.
It's interesting how different metaphors hit people differently. I lived in a forest most of my adult life, a forest where I was not the apex predator. I know there's danger there but I also know how to stay safe.
Same, I use "The Forest" as an metaphor for something nasty that side-tracks us (https://www.fractalproductivity.club/about). As it is used here, it only makes sense if it is contrasted to The Desert as they usually do. But maybe they could've chosen "Oasis" instead of "Forest" :P
A minor detail that doesn't take away from the main theme of this article: when we miss a demo we need to either "Slice the next week finer" (often a good idea) or *reduce friction*.
Maybe some code complexity has accumulated or the tests have are slow/flaky or a knowledge/skills gap has developed, etc. Put another way, desertification has stricken our otherwise-lush forest.
Pause the work and address the underlying issue.
I have been lucky to have worked in a forest a long time ago and I would like think that I have managed to create a small oasis for my teams in the dessert too.
One thing I wanted to mention is that optimizing for learning, as opposed to production, works because of the available slack that acts as a safety net for production. Specifically, the production output is closely monitored and is always maintained at high level. And it is exactly because there is a big buffer, the new feature can be given to a junior engineer. If this engineer starts to take too much time, the senior engineers can step in and help, but again they could be pair-programming with this junior from the start so there is really never a drop in productivity.
What was hard for me to do as a manager is to trust that we are not creating a bottleneck by delegating complex things to junior engineers for learning. The setup that ended up working well in the end is working through TLs: senior TL would be responsible for delivering the feature/change in the end, but the junior person was assigned to drive it.
From management perspective I have referred to this set up as “building capacity” in the sense that we are not just delivering a feature (which would be faster to do by having the TL work on it), but we are also using extra engineering capacity now (i.e. working a little slower), in order to have more engineering capacity in the future (by growing the capabilities of the junior engineer).
The main challenge is the race to the bottom in the short term: if people are evaluated by how much they deliver in the limited amount of time, investing in the future is indirectly discouraged. The created capacity is invisible to higher level of management, but the (lower) output in the short term is. So it takes a good amount of management work to create and sustain this environment (if the rest of the company has a dessert/scarcity mindset).