Week of 2021-06-21
The rewrite count
As a software engineer, I often see a struggle that both teams and individuals experience: overcoming the anxiety to “get it right” the first time. And it makes sense! We want to make sure that when my software ships, it does what we want it to do and doesn’t cause harm.
However, there’s something curious that happens along the way: somehow, this desire morphs into a self-judgement, detaching from the original purpose. If we don’t get right, does that make us good engineers? It’s no longer about the criticality of getting the code right, but rather about protecting ourselves from the possibility of appearing incompetent. Most commonly, I’ve seen this affect the productivity of team newcomers, who agonize over their first patches, and react in anguish when given feedback. It also affects teams who missed their deadlines and/or tackling problems that are much larger in scope than they previously realized. I am speaking from experience here. /me raises hand. Yes, I was--and sometimes still am--one of those people.
A technique that helps me here is to frame my work in terms of the “rewrite count.” I tell myself: “you won’t get it right the first time, so maybe give yourself a number of times that you’re expecting to rewrite this code/doc/deck from scratch. What’s the rewrite count here?” For easy ones, like this article, it’s one. I might finish this or I might let it go and come back to the topic some other time. For more complex bits, I give myself some “ambiguity slack,” setting the rewrite count higher. Sometimes, I set the rewrite count so high, it’s like telling myself: “you’ll probably never get it right.” Doesn’t mean it’s not worth trying, but hey -- it probably won’t work.
One way to visualize the rewrite count is with an evolutionary process. In a complex space, to find a new maxima, I need to allocate some time for the churn. I need to walk around, explore the evolutionary landscape, rather than anxiously hold what I have now as the “right thing.” Incrementing the rewrite count is a way to let go, and allow myself to start from a new angle. And most importantly, see all that I made before as a learning experience that prepared me for this new start.
Practicing rewrite counts can feel rather challenging in organizations that value impact as only the code that’s shipped. Yet, this could be the key to effectiveness in these settings. Just like leaning in the opposite direction while steering a racing sailboat, learning to let go of the objective in the objective-driven world might give you that extra flexibility and peace to do amazing things.
🔗 https://glazkov.com/2021/06/25/the-rewrite-count/
Questing, scaling, keeping
I’ve written a couple of takes on this before, but they didn’t feel quite right, so here’s another iteration. Keep that rewrite count ticking! It seems that there are some distinctions that I can draw when looking at the missions of teams, whether hidden or stated.
The first kind of mission is the one I call questing. This is the mission of discovery and pioneering. A questing mission usually involves going into the wilderness with a good chance of never being heard from again. Questing folk cheerfully accept this possibility, soaking up the thrill.
The second kind of mission is scaling. Here, the team is asked to make something go big. There’s usually already some momentum, some flywheel that’s in place, and the team needs to ride it and not fall off in the process. Scaling missions can feel a bit like catnip -- strong feedback loops within the flywheel create clarity and sense of direction, making it a game of skill: challenging, yet ultimately predictable.
The keeping kind of mission is all about preserving the value, to guard and to protect. There’s usually a treasure of some sort, and the team is asked to ensure that the treasure remains intact. Be that a key metric or some critical infrastructure, the keeping folk will make darn sure it stays the way it’s supposed to be.
Each of these missions has a different set of values. Questing missions value learning. You might fail, but you better live to tell us about what works and what doesn’t. Scaling missions value shipping. If it didn’t make the number go up, it didn’t happen. Keeping missions value predictability: “you can promise, but can you guarantee it?”
In a large organization, there are usually teams that contribute in different ways: some are questing, some are scaling, some are keeping. The mix of teams’ missions will reflect the overall mission of the organization. In a keeping organization, there will be fewer questing teams. In a questing organization, fewer keeping. The relationship between the mix and the overall mission seems bidirectional: just like a questing organization will discourage the emergence of keeping teams within it, it might have a hard time changing its mission given its current mix. For example, no matter how hard an organization wants to endeavor on the scaling mission, if most of its teams are questing, it will remain a questing org.
And that’s another twist to the story: team missions shift as they make progress -- and these shifts rarely get the attention they deserve. If by some chance a questing team hits the motherlode, it will need to rapidly transform into a scaling team. These changes are often painful, and cause polarization. I once (it was a long time ago) had gotten rather frustrated with a lead on our team. We hit non-linear growth and desperately needed to optimize, to improve quality, performance, add features -- and he wanted to pursue a whole new kind of idea! “I am more of a v1 type of guy,” he explained. I was miffed. Back then, I didn’t realize that folks have mission preferences. Just like team missions influence organizational mission, each of us will often have a preference for the mission, influencing capabilities of the team. As the team mission shifts, we are asked to grapple with the question whether this new mission matches our individual preferences. And when it doesn’t, we might be heading for another kind of crisis.
🔗 https://glazkov.com/2021/06/25/questing-scaling-keeping/
Spelunking our network of assumptions
I’ve noticed that my ability to operate in an ambiguous, complex environment depends strongly on my capacity to see a larger space of options and possibilities. There’s something very natural and yet completely unproductive about reacting to complexity with fear -- diminishing our capacity for seeing what we need to see to overcome that fear. Working across different organizations at Google, the pursuit for seeing more and understanding my own fears is just as much of a personal development as it is professional. I simply can’t do my job without a continuous practice of expanding my capacity to see.
One kind of practice that I have is spelunking the network of assumptions. It comes from the understanding that our decisions are made on top of a massive network of assumptions: things that we believe are true. It turns out that many of these assumptions are unexamined, and might contain errors.
A child believing there’s a monster in their closet might finally confront their fear and open the closet. Finding no evidence of a creature, the child might decide that there aren’t any monsters, dispelling their erroneous assumption. Or they might conclude that the monsters are only present when the lights are off and the closet door is shut. In the latter case, the “monster in the closet” assumption had gone unchallenged, and instead, new assumptions were made around it. The monster story survives and if anything, becomes reinforced, more resilient, growing larger with each attempt to examine it. Parents can’t see monsters. Monsters only sneak from behind. And so on.
In the course of our lives, our networks of assumptions grow to contain multitudes of these resilient clusters of unquestioned assumptions. No longer as silly as “monsters in closets,” they pin the fabric of our reality in ways that prevent us from seeing more. Especially when these clusters are really, really old, they don’t even feel as conscious thought: instead, it’s the weird increase in heart rate, or the flushing of the face, or the sense of irritation that “just suddenly comes over.” All of these point at something happening deep underneath the veneer of the “rational thinking,” and all of these are the object of the spelunking practice. Why do I feel this way? Is there an inner dialogue going on? What could be the assumption that I am making? And what are the connected assumptions? With enough patience, the clusters of old unquestioned assumptions start to emerge -- and become possible to examine and dispel.