Adopting a Strategic Mindset? Start here.
Adopting a Strategic Mindset? Start here.
Aimed at engineering leaders, but transcends across the functions of SDLC
Over the years, many conversations with engineering executives have led to a sentiment similar to the following:
“I want my leaders to be strategic thinkers. They execute reasonably well but act as order takers in a typical IT shop mentality.”
On the other hand, I’m also fortunate to work alongside some great R&D leaders. The difference between them and the rest lies in their strategic approach to the work. It’s a skill and not some innate ability; a skill, by its very definition, is something that can be mastered with appropriate focus.
Well, there’s so much to unpack. Let’s begin from the macro (organization level) and move to the micro (a team setting).
A gap between strategy formulation and execution
While you can assign some blame to an engineering or product leader for lacking strategic vision, it often starts from the top. Pie-in-the-sky strategies with no connection to the ground realities and no formidable plan are doomed to fail.
The following is a snippet from a study more than a decade-and-half ago (emphasis mine):
“Why is there such a persistent gap between ambition and performance? Our research reveals that, on average, 95% of a company’s employees are unaware of or do not understand its strategy.”
Source: Robert S. Kaplan and David P. Norton in a Harvard Business Review article.
You read that right. Ninety-five percent of employees in that study do not understand their company strategy. Admittedly, that research was a bit dated. But do you think the percentage of employees understanding their company’s strategy is any better in recent studies? I’m not so sure.
At length, Richard P. Rumelt discussed good and bad strategies in his seminal book. He argues, “a good strategy is a coherent action backed by an argument, an effective mixture of thought and action with a basic underlying structure I call the kernel.”
Rumelt describes the kernel of a good strategy as having three elements:
A diagnosis: explains the nature of the challenge.
A guiding policy: an overall approach for dealing with the challenge.
A set of coherent actions: designed to carry out the guiding policy.
Insofar as what usually appears in the corporate strategies or the thick decks presented by the startups, only element #2 (guiding policy) is equated to the strategy. If you are lucky, you see some diagnosis (#1, above). But, in most instances, there is no description of the coherent actions.
“You’ve got to start with the customer experience and work backwards to the technology. You cannot start with the technology and try to figure out where you are going to sell it.”
— Steve Jobs
That quote above holds true for everything (non-trivial) you are building: Customer personas vary between various segments B2B, B2C, B2D (developers), external, internal, platform, etc.
As an engineering leader, it’s imperative that you act based on sound strategy. That’s true even if you’re presented with an incoherent strategy. Note that you are a high-agency individual who takes pride in your craft and does not blame the environment. Instead, you adopt the strategic mindset and work on improving your environment — bottom-up. Here are four related ways to start (require a ton of deliberate practice, though).
1. Get out of the delivery mentality.
Delivery is a vital responsibility of an engineering leader — identifying the resourcing needs, finding the right people for the roles, and unblocking the team. You can do every one of these items well but won’t move the needle — for your customers and business.
Don’t talk about how many story points you delivered and how well you devised a sprint or program increment. You go on and perfectly build the wrong features, the kind of features your customers don’t care about.
Building the right products (and features) takes precedence over building them right. The quality of what you’re creating and the robustness of the infrastructure are crucial. However, if the software is not solving your customers' needs and helping the business, everything else is a moot point.
Product Managers take the lead in product discovery and facilitate the prioritization conversations. The misunderstanding is that it is solely the responsibility of the product person. Wrong. Unfortunately, product teams are equally responsible for perpetuating the false notion.
The product tells what to build, and engineering makes it — how arcane is that? Still, that’s become a norm. It is a partnership. A product manager should take the lead in product discovery, but engineering is a partner and has a seat at the table. Fight for that seat at that table if you don’t have one.
2. Learn your product domain.
If you go deep and introspect, you will discover something I did while leading engineering several years ago. In a high-profile product initiative, I was busy putting off fires and hiring the right engineering staff. But I was not in the mix when my product peers defined the product roadmap or strategy. When I’m occupied totally in the tactical items — even if it was the proper focus at that time — there’s no surprise you get no invite for strategic planning.
People see what value you bring to the table and act accordingly.
The insight I gathered helped me ramp up my learning of the problem space — healthcare and nuanced points of customer needs. For the next several weeks, I carved out time deliberately to learn. In this day and age, there’s no shortage of resources to help. It’s you and how you manage your time and priorities.
Note that learning is a journey. There is no expectation of you becoming a subject matter expert overnight, but for a consistent, purposeful effort.
3. Embrace product thinking.
Start with “why” and learn more about the “what?” (scope). Unfortunately, a lot of engineering leaders gravitate toward “when” (delivery date) and “who” (the staffing). There’s nothing wrong with thinking about the delivery and quality; they matter only if you understand the core of why. Demand it from your product counterparts if you don’t understand the rationale of building a new capability, customer details, and the metric it will impact.
Let me make it simple for you — every day, make it a point to think about your customers and how your work impacts them (or not). Join your customer and stakeholder calls. Recall the previous item above; you join the calls as you actively learn your product domain and insights about how it works. Otherwise, you will become a passive listener on the call. Billions of dollars are wasted annually with unproductive calls—no need to add to that infamous metric.
Strive to become a product-led organization. No, it doesn’t mean led by a group or team called ‘product management.’ Instead, your product becomes a primary vehicle to drive growth. There’s much more to write on this topic; leave it for a separate post.
4. Learn to articulate your thoughts.
On your path to becoming strategic, you should be able to articulate your thoughts. Otherwise, any learning becomes merely a theoretical exercise. I don’t know about you, but for me, writing clarifies the thought stream. Don’t bother about publishing but keep a log of your networked thought. For example:
Write about various ways you can improve your product.
Take a hypothesis-driven approach to your pitches. For X to be true, Y and Z need to hold true.
Map your technical roadmap with the product roadmap.
This purposeful practice leads to a positive feedback loop: getting better at writing clarifies your thinking, and clarity makes you a better writer.
Summary
By myopically focusing on the day-to-day responsibilities of the releases and product delivery, the engineering leaders tend to lose touch with the product strategy. Your success is directly proportional to how well you understand the product strategy. Better yet, partner with your product partners to co-develop the strategy.
Focus on “why.” Do not jump into “who” is going to work on a work item or “when” you’re going to deliver it. Dig deeper into understanding what KPIs impact — customer adoption, experience, or business metrics.
To be strategic, you must invest time in learning the business domain. There are several resources online nowadays, but this may also require reaching out to your domain experts. Do your homework. There’s no shortcut.
Product sense and product thinking are not just for the product management team. Embrace product-led thinking, and work on aligning engineering practices around it.
Articulating your thoughts and ideas is essential for you to impact change. After all, you are adopting a strategic mindset to make a more significant impact. Adopt a writing habit to connect the dots.
Very best! Like every skill, strategic thinking requires habit formation to build that mental muscle. Do not skip the daily reps.