If you are responsible for technology in your company, whether as CTO or middle-manager, this post will help you to thrive in the technology evolution in your company. If you work in a startup or a big organization, this post will show you 5 best practices to elevate your company to the new technology paradigm.
Committed Technology Manager
Are you are the kind of person who loves learning about cutting edge technologies, discussing with your peers about different ways of using a tool or language (probably nowadays it would be Terraform, GO, RUST, Python, …), or how to use new development practices to improve your development life-cycle, such as XP, Agile, Lean or DevOps…? Is Everything going right and you are having fun? Do you want to go a step further, so your company can benefit from your knowledge about technology? Isn’t that why you write an ideal roadmap which your company should invest in to perform better at delivering software ? Up to now, everything is working fine? You’ve been working for many years in the IT industry, starting from the grassroots. You caught the new vibes from the latest cutting edge technology trends. You are prepared to lead your company’s technology evolution. You truly believe that the company should provide a budget for this program and run it to stay competitive.
My Stakeholders Do Not Understand My Evolution Roadmap
Your roadmap seems to be perfect, and it’s completely aligned to the latest technology trends. You then share the plan and the program with the development team. Although your plan is focused on the development team, in order to improve their deliveries and make their life easier, they do not feel comfortable with your plan. Your roadmap requires too much effort to learn new tools, and to change processes, beyond the volume of business deliverables they have with current apps. They think your plan is great but not feasible. You feel disappointed. You don’t understand why developers want to continue working in the same way, and with the same technology and tools.
But your nightmare doesn’t end here. When the roadmap is exposed to your CEO, simple questions follow: “How much money will this transformation program cost the company ? What is the estimated date to put it into production environment?” In your mind the answers are: “The program will cost whatever it is worth, and we’ll be using these enablers as soon as possible”. You bite your tongue as you know they are not the right answers. TOP Management must always have the answers in terms of COST and TIME.
Others Walked This Way
From my personal experience, for evolution projects to be successful, you must align different goals: delivering software, estimating ROI in terms of quality, cost or time to market, and assuring the development team that their life will be easier. Another point worth considering is getting feedback from all stakeholders. Make sure that your roadmap provides answers to all of the likely problems that will be raised in the feedback.
This Is The Plan
You can follow these practices to build a much more feasible roadmap:
1. Get vibes from all stakeholders.
You should get feedback from all stakeholders. It allows you to create an inclusive roadmap, and align different needs. By adding all perspectives in your plan, ensure alignment throughout the organisation. Stakeholders examples:
- TOP Management: Your plan must give answers to their questions. Of course they want software and infrastructure with the latest technology, but they are responsible for many other aspects of the company. Each project in your program must contain a rational response of the benefits, and an approximate date of when it will be effective.
- Business: These people live in the real world, using a production software system. It’s important to know their experience and to improve it.
- Development Team: They receive pressure from the business directly and they do not have time to innovate or to learn new languages or techniques. Their aim is to build the desired software for business in the expected time and cost. They want to focus on business, no matter which tool-chain they use, neither the most advanced tooling nor scripting.
- IT Industry: They are the easiest. Like you, they enjoy learning about cutting edge technologies and experimenting with new software and techniques, they believe in choosing what is best for the organisation.
2. Detail constraints or restrictions inside your organisation
Tools, frameworks and technology need custom changes to fit in every organisation. For example, to operate a business under a regulatory environment requires compliance with certain rules. Knowing constraints and pains will make it easier to identify risks in your projects, and to include solutions in your roadmap, which will help to increase the interests of your stakeholders. By adopting new tools, techniques or languages, you will enable your stakeholders to learn new features to be added in their products, or to change the way they do something to an easier, less costly or time efficient way.
3. Include a budget to enable the adoption
Consider a certain amount of the budget to help people learn how to use new tools or frameworks. Otherwise they will not be able to run with your brand new plan and the program will fail. Allocate part of the budget for adoption, as it will give the customers a chance to validate new capacities and time to learn how to use them.
4. Detail projects appropriately.
I highly recommend the usage of the SMART Framework to define each project on the roadmap. The method will help you manage the expectations of your stakeholders, and communicate your plan in an accessible language so everyone understands what you want to do, and what can be achieved.
5. Review your roadmap regularly.
You should include a mechanism that allows you to adapt some points of the projects’ roadmap whilst being executed. I recommend that you include regular milestones to deliver value (for example every two months). In these reviews you can re-adapt defined projects, or add/remove projects, and fit a continuous evolution roadmap of technology.
Roadmap Evolution Example
Let’s make an example: You want to provide a platform where the development teams can easily deploy new container-based applications, abstracting them from the complexity of build, release and operational tasks, and let them focus on solving business needs. You consider launching at least these projects in a program format:
- New K8s cluster in AWS provisioned and operated with Terraform.
- Tooling based on Gitlab and Jenkins X.
Adopting these technologies and tools not only implies installing and configuration, but also the changing of processes and behaviors of many teams in your organisation.
I suggest you use a tool to organise your technology evolution (taskade is a great tool for this purpose), and build your roadmap applying the explained best practices. Information included in the roadmap should be in response to some of these points:
- A common goal with which all of your stakeholders are aligned. For example: improve Business Agility by creating and delivering digital products and services.
- How much it will cost. Although you can’t accurately predict the cost, it should provide a High Level Estimation for the execution of these projects:
· Time Material (consultancy, implementation, enablers, adoption).
· Infrastructure.
· Cost of maintenance in production (Licensing, Support Services, …).
· Any other likely costs required for the projects. - How you will measure the success of your goal. To establish key performance indicators, will enable to report progress based on empirical arguments, not feelings. In this example we should use the followings:
· Lead Time: time reduction of 20% converting a defined product to an operational product or service.
· Mean Time To Recover Service: time reduction of 30% by detecting the root cause of an outage and activating the fix in production. - When the new platform and toolchain are in use. For each technology you should set the basic milestones every two months. Let’s see the example of Kubernetes:
· Milestone 1: Kubernetes up and running.
· Milestone 2: Showcase application running in K8s.
· Milestone 3: First production application running in K8s. - Support needed to use this platform and tooling. In this example there should be a platform team responsible for productivity and constant evolution of the platform. This team should also have the role of enablers, helping everyone to learn how to use this brand new platform.
Takeaways
Aligning all involved stakeholders is critical to get the approval of your evolution roadmap.
Constantly measure, review and offer feedback of the progress of each project, provide visibility of the work and give enough information to drive the roadmap in the correct direction.
I hope it helps you design your own roadmap evolution.
Don’t hesitate to contact me if you want further information.
Thanks for reading!
