Hello again! I’m going to keep this one a bit more focused on _just_ the section I read. The book is so densely packed with tidbits! My last few posts felt like an information firehose. Here I go with some tighter prose!
⏮ Start at Part 1 | ⏪ Back to Part 5
This read is the start of a new chapter called Proximate Objectives in Part II: Sources of Power. A proximate objective, he says, names a target the organization can reasonably be expected to hit.
Takeaway #1: “Landing on the moon was a proximate objective for Kennedy. It was judged feasible, but beyond the reach of Russia at the time.”
Kennedy’s diagnosis: world opinion was swayed by Russia’s successful satellite launch (away from our technological superiority). We needed to improve our position.
Takeaway #2: “The feasibility of a proximate objective can influence organizational energy and focus.”
Rumelt tells the story of a team at the JPL who couldn’t decide what the surface of the moon was going to be like. This was problematic because the team could not defend any one rover design against another.
⭐ As a leader, how can you unlock energy and focus in a stalemate? Once upon a time I worked with an engineering team who had 2 opposing opinions about a piece of front end technology. Let’s call the opinions “Buy It” and “Build It”. Team Buy It argued that we should build our reporting front end using a time-tested off-the-shelf library for graph generation. It had reams of documentation, live support, and based on our (projected) usage, the licensing would run about $10,000 per year for the next 5 years. Team Build It argued that it didn’t conform to the culture and best practices for the front end community, and that maintaining it would require learning a completely new way of doing things. So how do we decide? How do they decide?
(to be continued… 👇)
Takeaway #3: “An important duty of any leader is to absorb a large part of [the] complexity and ambiguity, passing on to the organization a simpler problem—one that is solvable.”
Takeaway #4: “Taking responsibility is more than being willing to take the blame…it is setting proximate objectives and handing the organization a problem it can solve.”
⭐ Back to the Buy It and Build It contingents. Our team’s job to ship a reporting prototype to customers in 3 weeks. This was ahead of a game-changing suite of reporting changes coming to the platform that quarter. This was part of an initiative to keep us competitive and deliver never-before-seen insights into the conversational sales pipeline. Our ability to execute quickly, and to stay close to the customer (for validation and to keep them successful) would help us win in the market.
⭐ Team Buy It won in this context. Building this graphing library in-house with the goal of a reliable, “Pure JavaScript” library with broad browser and device support, excellent performance, well-documented interfaces, a literal decade of usage by other companies, and the risk je ne sais quoi of in-house dev… would have been a disaster. The expense was approved immediately.
Takeaway #5: “The more uncertain and ambiguous a situation, the nearer the leader must look. The more dynamic the situation, the poorer your foresight will be.”
⭐ This one blew my mind a bit 🤯. I feel like I’m having the same conversation over and over re: software time estimates, and this is absolutely the key to simplifying those. Instead of a commitment to a padded, subjective estimate, I should really divide the effort into knowns and unknowns, and then set near-term objectives for the unknowns.
⭐ This will let me be more transparent as well. When you pad estimates, it’s really hard to explain why. I’ll always take a path of action I can reason about to customers or peers.
Takeaway #6: “An excellent proximate objective creates a strong position with lots of options.”
⭐ Let’s recycle the “buy it” or “build it” options above. Which one would put the team in a stronger position and open up new options for future strategizing and action? In that context, I’d argue that implementing the off-the-shelf software did that for us. We were able to deliver results that could be validated by customers almost immediately (within a week of purchase we shipped one of our use cases to a beta customer). We also had a spec with dozens of literal options for our designers. Instead of inventing graphs or designing visual system for a series of graphs, they plucked them from the documentation like a catalog. A few customizations and compromises later, and our reporting machine was humming along. We delivered in tune and on time 💰.
Takeaway #7: “High level proximate goals create goals for lower-level units.”
Takeaway #8: “To concentrate on an objective—to make it a priority—necessarily assumes that many other important things will be taken care of…like the high rungs (ex: world domination) in a ladder, you can’t reach them until you’ve crossed the lower rungs (feeding and clothing yourself).”
⭐ See how the buy it vs. build it conversation was clarified earlier? It wasn’t because someone handed down an ultimate judgement. It was because we followed the trail of higher and higher-level objectives to get clarity for our “spec”. If the context had been different, and it was strategically valuable to have a pure JavaScript graphing library, I’d be telling a different story. But we weren’t a JavaScript library company, we were a conversational sales platform trying to achieve a competitive position.
⭐ Even in my role today, I’m coming to crossroads like these. Which cloud vendor do we choose? In the scope of my proximate goals, I’ve come to a judgement about which vendor we should commit to. However, we’re still growing and maturing as a company. We don’t have a guiding proximate objective that will unlock ultimate clarity and purpose here.
⭐ If I were in the CEO’s shoes right now (it’s my newsletter, so I’m going to just jump into the imagosphere for a moment…), I’d say, hey team, here is our proximate objective: Re-position ourselves to deliver behavioral health programs in all countries with a Human Development Index > 0.9 by the end of 2022. I could see this cascading into revenue, engineering, product, security, clinical research, et al. I see nothing but options on the other side of this, and I can see it forcing us to address the basic malfunctions we have today in order to achieve these “higher rungs of the ladder”. I would want to see federated and cohesive 18 month plans (or much shorter, where things are still dynamic). Food for thought 🧆.
🔖 Bookmark! Next time, new chapter: Chain-link systems 🔗
The book again is Good Strategy / Bad Strategy: The Difference and Why it Matters by Richard Rumelt, and Thank you for reading Takeaways!
If this is your first post, subscribe! I write a new one every week or so. I have a big stack of books to read, so there’ll be content for a _while_. Thanks!