Everyone’s familiar with a company mission statement; the assertion of its values and purpose alongside the long-term aims, whether that be to produce market-leading products, disrupt industries or the advancement of society. However, for the technology side of any business, there needs to be a separate, well-defined plan to guide engineers, direct time, effort and resources, and ensure successful outcomes are achieved.
Long term, global view – where you are now and projecting where you want to be
What teams need to do to achieve the vision and when
How various teams across the business will work individually and collectively to implement the vision and achieve the overall mission
With that in mind, what is the best way to define such a strategy and what needs to be factored in? Here we break it down for you.
“The beginning of a good strategy is knowing where you are today. But equally important is understanding how you got there. It allows you to understand culture and context, and will help shape your way forward” –Klaas Ardinois, VP of Engineering at Cloudcall
The Document itself
There are various ways to create a strategy, arguably the easiest and most accessible is to have a working word document. Some technology teams however, may see fit to have a slide deck or presentation-style format, if this is what they are used to. Each company could have their own expectations on how to present, document, and continually reflect on a corporate or departmental strategy. Thinking about how you communicate, and the needs of that communication for the audience can help you decide whether a long-form document, a presentation with or without slides, or something else is the right format
The most important aspect is that the document is accessible both in a practical and language sense. If necessary, use a skilled communicator – avoid jargon and too much intricate detail. It should be read and understood by everyone involved, technical and otherwise.
While the vision and subsequent strategy should not be ‘set in stone’ – it needs to be adaptable – it also shouldn’t require continuous rewrites or rethinking. A six-to-nine month timescale is ideal, but in order for it to stay relevant, it should be reviewed at least every three months and updated with key learnings discovered along the way.
Principles and Values
These are the What, How and Why of everything the team(s) will be planning and building in line with the technology vision. They are the foundations that feed into and guide the process to ensure it is shaped in a way that also reflects the business’ overall mission.
Principles and values act as the cultural cornerstones for both the employee experience and the customer journey to verify that they are well-matched and ultimately moving towards the same goal.
When considering what you are trying to achieve and how your team(s) are going to do that, you need to decide what the most important factors – from a principle and value perspective – are:
- The aim of the product/service – Essentially, why is it needed and why now?
- Internal usage – Which teams will be relying on it and how will it enable other departments/business units within the company, from a technological perspective?;
- External usage – What is its purpose? I.e. Ease of use, accessibility, reliability, community etc.;
- Leadership – Who needs to be involved? Do they have the right expertise to influence the strategy and outcomes? If there is to be a hierarchy, set it out clearly for those it impacts, and empower the appointed decision makers by: conferring the responsibility, defining its scope and enshrining it in writing;
- Key learnings/teachings – The process should involve continuous learning – reflections should be made at each stage of the journey to ensure not only that the guiding principles and values are aligned, but that the strategy is informed regularly (and if necessary, changed) by those involved/impacted;
- Outcomes over output – Understand what success looks like in terms of how it reflects both the technical goals but also the mission of the wider company.
This stage is the best time to have discussions regarding ethics, behaviours and practices – i.e. How will data be used and stored? What considerations and steps will be taken to protect users’ privacy, while also learning from their usage habits? How will misuse or misinformation be prevented? Attention needs to be paid to design, development, and dissemination of the technology not only within the business setting but to specific communities and even society at large. Although companies play an important role in the advent and development of technology – and make associated value judgments around its use – it remains open how we should understand the contours of what firms owe society as the rate of technological development accelerates
Further, issues like security leaks/hacks or lack of transparency can breed distrust from both stakeholders and customers, undermining the longer-term technology strategy and potentially harming brand identity, which if not addressed appropriately can be fatal to the end product and in extreme cases, the business in its entirety (especially if early stage startup).
Deloitte’s 2020 Global Marketing Trends report, brand trust is more important than ever for businesses—and the implications of factors that damage that can be far reaching: ‘Customers, regulators, and the media expect brands to be open, honest, and consistent across all aspects of their business, from products and promotions to workforce culture and partner relationships’. Lee-Jon believes this is especially true for B2C businesses, but is part of a wider consideration of factors for sales-led companies. In his view, technology needs to maintain an agreed level of quality of product, which could be measured qualitatively as brand trust. To be useful in this context, a strategy should address the trade offs made by technology leaders, and highlight within any plan where trade offs are being made, and what that means for quality and the overall brand.
Roadmapping and Architecture
Arguably the most important part of any technology strategy is the analysis of the current infrastructure. Lee-Jon believes being knowledgeable about your current position is the key activity in a strategy. As he says: “Your strategy is about subtle movements on the global stage to achieve objectives. To do that you need to know where you are, what your capabilities are, where your strengths lie, and weaknesses, and what factors are external to that which could affect you positively and negatively.” analysis is more about all knowledge and assets, rather than just technological infrastructure.
Consider what software components already exist and what framework is needed to implement the tech vision (or specific parts of it) including tools etc.? If change is necessary, what will be required, at what scale, how much is it likely to cost and what’s the estimated timeline? Senior executives, stakeholders and tech teams will need to know if they’re looking at straightforward updates, legacy migration, or a complete digital transformation.
Further, consider what separate specialities need to be identified and then address them within the strategy document. This includes (but is not limited to):
- Cloud migration;
- Mobile and webs app; and
- Online communities.
As Lee-Jon says, examine where your strengths/core competencies lie, and what you can leverage against a market as an opportunity because this will help indicate where a deeper dive is needed.
On a macro level, this would also be the time to observe and factor in key trends or market changes (including disruption caused by a global pandemic or a recession for example) that may impact the infrastructure and platform, as well as the wider business in both the short and longer term. Consider whether the necessary agile processes, data capture and systems are in place so that the ability to pivot during such times to avoid problems is possible.
Finally, each roadmap step should be marked out from high-level operations to daily tasks so that the vision and strategy remains relatable at each layer of the organisation and each business unit knows when and what is required from them. It will also need to outline each team’s defined ways of working and collaboration processes, plus dissemination of information (flow and timings etc.) across each category. Each unit or specialist area will function and communicate differently and as such, this requires both acknowledgement and joining up – the latter of which is pivotal to overall success.
It’s only right that consideration of the technology is followed by consideration of the people that can implement said tech. Not just in terms of people power, but understanding what is needed in terms of roles, responsibilities and cross-functional input (be clear on what team formation is needed for which type of work).
It can be tempting to push forward without doing it, but for any tech strategy to be successful and the vision implemented effectively, thought needs to be given to any skills gaps, mindset alignment, coaching, training and development. This includes understanding the need and expense of whole new teams being formed and/or individuals being brought in on a consultancy basis if specialist skills and expertise are necessary, but not available within the company (and sufficient time isn’t available to upskill).
In the event external assistance is required, the strategy document will further need to outline a plan for onboarding consultants or contractors properly. This is to ensure they are up to speed with current processes, fully bought into the vision and can amalgamate themselves within pre-formed teams. You will also need to foster an environment where their skills are utilised properly and the benefit maximised.
Buy-in, Alignment and Process
It goes without saying that everyone needs to be on the same page about what is being built and why. Nothing can kill a new project strategy, faster than misalignment or thinking you have consensus and full buy-in, when you don’t. As Lee-Jon Ball, CTO at Easol says: “Never present a strategy that the group hasn’t heard before”.
To get everyone on board, it’s important to have the right people in the room at conception stage. Think about who will provide core insights from the business perspective and who will offer it from the technology side. Remember, diversity of thought is key – while it is most important to have people from the key intersections between tech, business, design, product and customer-facing sides, don’t just invite those in senior roles to participate. You need people who will not only ask the right questions, but the difficult ones too. The group should be big enough to cover all bases, but not so large that significant voices are drowned out.
Getting buy-in from non-technical stakeholders will involve ‘selling’ the vision somewhat. Answer the big questions around scalability, timelines, usability and functionality, market compatibility and budgets. Extrapolate beyond the fundamental principles and values and spell out exactly how the technology vision and strategy interplay with, support and enable the wider business vision and goals. At this point, flag any potential siloes and discuss what can be done to mitigate them.
Successful solutions need successful strategies and alignment is created through shared understanding and purpose – what will the product/service do for customers? I.e. Help people/solve problems/create community? Great, communicate that. And for the people building it/assisting with implementation and execution – are they looking for meaningful, interesting work and/or a new challenge? Be transparent and provide the necessary information to all involved so they can make context-based decisions. Complete agreement may be hard won, but not impossible and you need to avoid becoming bogged down by admin and red tape – or whomever shouts the loudest.
Klaas Ardonois, VP of Engineering at Cloudcall further advises: ”Spend a lot of time on the marketing aspect of your strategy. Think about almost slogan-esque statements to summarise the key pillars. It’s a lot easier to remember ‘We think cloud-first’, compared to reading a lengthy wiki page where you explain all the benefits of cloud, the projects and roadmap that will achieve that, skills needed etc. While you need that detail, it’s not what people will remember. For most people who aren’t in leadership, strategy is the backdrop for their daily activity. So make sure it’s something that is easy to use as a frame of reference and can be top of mind.”
Process-wise, keep records of all and any discussions that go into forming the final vision and strategy documents. If necessary, have a moderator, but always ensure a neutral note taker is present in case issues arise further down the line, important points aren’t missed and everyone leaves the meeting(s) with clarity regarding their roles and responsibilities, and any immediate actions to be taken.
Implementation, Metrics and Delivery
Put simply, what does success look like to you, your team and the key stakeholders? Have the principles and values been adhered to? How will you know when the technology vision has been implemented adequately and the wider company mission achieved?
Answer: OKRs, KPIs and testing, all which must be specific, outcome-focused and at relevant markers along the delivery journey.
Think about what data you will collect and why, how this will be utilised to inform the strategy and just as importantly, how it will be translated to those with limited technical knowledge. When progress is small and incremental, data will be your friend in demonstrating that the strategy is working and if not, flag that changes need to be made to get it back on track.
Feedback and Reviews
Putting this last is somewhat of a misnomer because reviews and feedback need to take place at several points: after initial creation of the strategy, mid-implementation and post-delivery.
At the beginning, ask for feedback to ensure the strategy document has covered everything discussed and agreed, and make any necessary changes (make them clear in any subsequent published copies). Once delivery is underway, retros/all hands should be utilised to ensure everything is moving as it should be and if not, amendments can again be made to realign. Lee-Jon recommends re-reading a strategy each month, especially if there was good analysis because it’s likely you’ll forget parts.
As a working document, some may not have a solid ‘end’ point per se, rather preferring a strategy that moves with the team(s) and shifts focus every six-to-12 months (unless the purpose, values and/or product/service change). Regardless, it is necessary at a defined project closure or implementation point to ask the questions: what went well, what could be improved and what needs to be scrapped or changed entirely for the next iteration or venture.
And there you have it. A comprehensive guide to building the ultimate tech vision and strategy. We hope you find this useful and would love to hear how you get on if you use all (or even some) of it to help craft your own!
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more