Post·technical
Technology Vision
Technical leaders are often asked what their technology vision is. Well, what should it be?

“What’s Your Technology Vision?”

“What’s Your Technology Vision?”. Technical leaders – those in charge of delivery of technology (and thus overseeing technology organizations) get this question a lot, especially when they join companies. For some, it’s an opportunity to pontificate; others fill the air with management-speak. It’s a challenging question – it’s too broad for answers to feel satisfying, and almost always there is important context – the question behind the question, so to speak. Did an engineer ask it, worrying that the organization might stop innovating? Has previous leadership not set a clear direction? Does the team simply want to get to know the new leader?

Actually, I like this question. For one, it reveals that the team is curious and engages at the topics of how (and maybe why) we do the work. Also, for me it’s a good chance to address the meta question:

How does one – and how should one – form a technology vision? What is a technology vision, anyway?

I start with the principles and the invariants. What are some key tenets that define how the Technology organization (and maybe any other organization as well) should see the world and its work? My answer is to start with, and always connect to the customer.

A Technology organization that focuses on the customer and their needs is often an important voice in potential debates between serving existing customers and finding new customers (are we growing at the expense of being able to serve existing customers?). Teams are less likely to work on “engineering pet projects” or sponsor initiatives with no incremental benefit to the customer over a long timeframe.

I don’t claim this to be a universal tenet – Technology organizations may insert a different belief as their central thesis – but I do think that most organizations would benefit from subscribing to it. And there are also core beliefs that the leader brings into an organization that may help shape how technology gets built – and what kind of technology is delivered. The beliefs I bring are:

  • Teams take pride in their work – this doesn’t necessarily mean that everything we ship we’re proud of; but I want teams and individuals to take pride in the work they do. Building technology is a tangible way to create value for the customer and for the company, and engineering teams that feel the pride tend to think outside the box, and think longer-term
  • Teams aim to be greater than the sum of the individuals comprising them. This is easier said than done. In most organizations, the scale of teams is actually a side effect of the need to get a lot done and there are costs to scale; a team of ten engineers isn’t twice as productive as two teams of five engineers each. But teams can create value in excess of the sum of their members. They can help each other learn, create needed redundancy in business knowledge, cover each others’ blind spots. Teams can sustain the “team flow” for longer than an individual can sustain their own
  • We are a learning organization. I want each team member to be curious, to believe in self-improvement, and to reflect on the past to improve outcomes in the future. This implies that we focus on teaching as much as we focus on learning. Do junior engineers have outlets for both structured and unstructured learning? Do senior engineers invest in sharing what they know as part of their jobs? Do we create forums where groups can come together and share knowledge?

Know Your Genus

Beyond the principles and the invariants, a technology vision needs to align with the company’s vision and purpose. This doesn’t mean duplicating the vision statement – each function has a unique perspective to bring to the whole. The key idea I suggest for engineering leaders is to make sure the organization knows its genus.

  • Are you a platform, existing to enable others to build on top of you? If so, your organization needs to prioritize reuse and dogfooding
  • Are you an engagement machine, focused on the creation of “virtuous cycles”? If so, your org needs to be architected to look at the entire lifecycle, and be able to rapidly experiment with flows
  • Do you crystallize meaning for your customers? If so, your org needs to be able to tackle open-ended queries and requests and needs to have a solid data and integration architecture

Your genus defines a number of aspects of the organization – your prioritization bias, the organizational structure, the technology architecture, key metrics, and the trade-offs (for example, availability vs consistency).

That’s usually where I would stop before learning a lot more about the company’s objectives, its challenges, the path it took and the historic biases and scars it had to deal with. Once I have that knowledge, there is a multitude of dimensions to consider:

  • What is Tech’s build vs buy philosophy? Does AI change this picture at all? Does it change over time?
  • What is our approach to AI in the first place?
  • What are our biases in terms of structuring and organizing the team? Do we prefer small “tiger teams”? Larger teams with some redundancy and fast stable-state velocity? Do we organize teams around exceptional individuals? Do we keep teams by-and-large stable or do we encourage shifts, often even if nothing is broken?
  • What’s the bar for the quality of our systems? This affects how comfortable we are moving fast and what level of certainty we need to accomplish to feel good about the project

It’s All About the Trade-offs

A careful reading of the above dimensions reveals what makes some technology vision statements more actionable than others: the clear and explicit acknowledgement of trade-offs. Good technology vision statements offer a compass that helps navigate these trade-offs. After all, a direction becomes important especially when there is pain involved. Common attributes that leaders need to trade-off between include

  • Quality and Velocity – do we need to outrun competition, or do we need to build trust with our customers?
  • Focus on Today vs Tomorrow, and focus on First order vs Second order effects – both are effectively a statement about how much we want to invest in our future at the expense of results today
  • Investment in team Empowerment vs Alignment – while not always a direct trade-off, many top-down organizations achieve high degrees of alignment at the expense of allowing members at various levels of hierarchy feel empowered to act

Regardless of what attributes are highlighted, best vision statements benefit greatly from Consistency and Clarity. Very often, making sure that everyone rows in the same direction is more important than what specific direction is chosen, and for that, making the vision and its implications clear, and aligning the organization’s processes, rituals, and habits with each other and with the vision has a tremendous payoff.

Finally, thoughtful leaders realize that technology vision cannot be static. Technology organizations are dynamic systems, and that is true not just throughout a leader’s tenure, but also across these tenures. A leader who wants to make the vision stick is able to connect to the past – the organization’s scars and burns, its highs and lows. They are intentional about transitions, carefully selecting which aspects of the organization’s operations should change smoothy vs suddenly, and where a compromise (such as a workaround or drift away from the “ideal” vision) may make more sense than a “creative destruction” of the previous vision.

There’s a lot of art to shaping and implementing a technology vision. Fortunately, leaders have a chance to refine and redefine the vision throughout their tenure. For leaders who understand why consistency and transition are important, it helps not to jump to conclusions too soon. After all, just like the leader will end up shaping the organization, the organization may well very end up shaping the leader.