Joe Contrera is a leadership coach friend of mine and we just had a lively discussion about why so many strategic technology decisions look bad in hindsight and organizational transformations fail.
He asked a great question:
How technical do you need to be to set strategy for a technical organization?
My answer is “not very,” which you might find surprising.
I think it’s more valuable for organizational leaders to develop empathy and high-trust feedback channels within their organization so the organization can set strategy in a scalable way than for technical executives to obtain the technical expertise to develop the strategy themselves. Tech executives need to know enough to call “B.S” on technical (or product or process) hand-waving, but that’s an achievable minimum bar.
Leaders who demonstrate empathy and have feedback channels from all levels of their organization can then lead discussions that develop, review, and refine the:
- mission around changing customer and organizational needs
- strategy to meet those needs
- specific collections of components and teams that can actually implement the strategy
- experiments to validate the strategy
- milestones to track implementation progress and gate or enable the each stage of implementation funding
Defining and executing an inclusive strategy development process is the responsibility for a VP of Operations, CIO, or CTO — doing all the underlying research is not. Adopt a generative strategy development process and leave the pathological model behind.
Certainly leaders must understand there are differences between technology components but it’s the senior individual contributors and managers who should research and describe these in a 6-pager, design document, or other written artifact so that it can be incorporated into the strategy. Leaders can then ask probing questions around the differences between implementations. The Container orchestrators are the same but different is a good example for this.
It’s impractical, if not impossible, for an executive to perform serious due diligence on a Cloud platform, delivery process and toolchain, or similar architectural component at the rate these decisions arrive. But developing a repeatable process to do that built on standardized information flows is achievable. As a leader and decision-maker, you are in control of the questions. So focus your effort on asking good questions and let your team improve those questions on the way to answers.
My colleague Jeff Nickoloff at Topple calls these ‘read requests,’ where a decision maker or information consumer defines the information needed to make that request. Then the subject matter experts can research, experiment, design, and generally do what they do best to inform the decision. Now your decision is built on the information and perspectives of five, ten, or maybe more people.
This approach is inclusive, scalable, and efficient.
And it’s definitely one way to avoid having your decision-making process described as “made in a vacuum,” “micromanagement,” or “out of touch.”
I’m sure you’ll have many great ideas about how to improve in 2020, so write those questions, possible answers, and who want feedback from to develop the Big New Thing further.
Stephen
#NoDrama
