7 Steps for Building New Technical Capabilities within Your Team

How to help your team quickly adapt and learn new technologies?

Business vector created by pikisuperstar

More often than ever, we are pushed to solve complex business problems using disruptive digital technologies. In less than a decade, Cloud Computing emerged and gained mainstream adoption, and so did their respective open source counterparts such as OpenStack and Kubernetes. In a yet faster lane, many storage and analytics technologies, vastly different from the traditional databases from the past, were created.

Part of our jobs as Architects, Engineering Managers, Chief Technologists, and other technical leadership, is to make sure our teams are able to approach and learn new platforms in a consistent and predictable manner. The process below can help you to walk through this path and hopefully make you avoid some of the pitfalls you would encounter with an ad-hoc learning approach.

1-) Identify the problem and engage stakeholders

Unless you are working in a small company or tech startup, new technologies are not adopted because they are cool or they are trending. They need to be solving real problems. A few examples:

Start by identifying the current challenges you’re facing.

• DevOps (integrated pipelines + automation): Reducing production deployment issues (business downtime/SLA) and improving customer satisfaction.
• BigData/Machine Learning: Reducing operational costs (e.g. automating processes using ML) or integrating data from multiple silos.
• Kubernetes (Borg): Managing large scale applications spanning multiple servers with redundancy and scalability
• OpenStack: Managing a private cloud used to run large computing resources (usually with a steady/predicted demand).

New technology usually emerges to solve existing problems. Once the technology is publicly available (becomes a “product”) it is natural for us (tech people) to want to use them because they are the “state of the art”, but our geeky passions rarely resonate with business needs and willingness to invest.

So, if you are considering jumping in to use new technology, you should already have a clear business problem or you need to identify an area that could really benefit from it.

Either way, during this process, it should be clear who the key stakeholders are, and who will be most affected by both the gains and potential risks of that implementation. Both sides of the coin need to be aligned before any further investment (time and resources).

This initial commitment may happen in different ways depending on the organisation (workshops, quarterly meetings), the only constant is that it is never easy. That is why you should always propose to start small and make sure that everyone impacted has a chance to get involved. There are many unexpected things that you are going to learn during the process apart from technology. Things like privacy, legal, operations and support requirements that may not be clear at first.

2-) Test it out with a proof of concept before jumping head in

Before investing in new technology and after identifying a problem you should build a proof of concept 100% focused on demonstrating a possible solution (again, focus on the solution aspect, not on the technology).

It should be delivered quite fast (think a two week time frame) so you do not lose momentum. Though it’s still not the time to implement all the bells and whistles, you should take note of all things you left behind to help you on the next phases.

It is okay if you need to manually set up or if it does not work for all scenarios. Remember, if the problem you are trying to solve is important, even a “quick and dirty” solution could be enough to get people’s attention and help you sell your idea.

3-) Building a business case

After you put in some work building your PoC, it is demo time. You should put together a business case presenting your findings, asking for what you need to move forward (people, servers) and lay out the goals for your next steps.

The PoC can be used to demo the idea and convince everyone that you are going in the right direction.

Again, in the ideal path, you should have non-technical stakeholders backing you up, presenting, communicating and explaining the benefits of that new piece of technology in business language.

4-) Set up for a successful prototype

When preparing and building your prototype, you need to identify the main aspects of the technology and of the whole solution. It needs to be big enough to prove that the solution is technically feasible and economically viable.

The prototype should have all the components expected on the final product. They don’t need to be completely configured, but it is usually a good idea to have everything automated so you can play around with it for different purposes.

It is a good idea to keep the prototype code functional even after your main solution is up and running in production. There are several benefits in doing so:

• You can use it for learning and teaching (new team members);
• t can be used to validate different configurations (multi-node, different cloud vendor);
• It can be deployed on cloud, on premises;
• You can share it with people and gain feedback(more on this later).

The timing for a prototype will heavily depend on the number of integrations. You can skip simpler things like logging or Single-Sign-On, unless you have very specific requirements that require this.

I would say a 4–6 weeks is good timing for prototyping. More time than that, and you better be getting closer to the final product; not giving yourself enough time can affect the product greatly.

5-) Testing and understanding your specific challenges

Testing your prototype is probably going to be your best teacher. You will be able to play around with the levers and gears which you’ll need to master before planning any production workloads.

As we are talking about new technologies you should stress all the non-functional areas that are the trickiest and the ones that will help you understand all the fundamentals of the underlying product:

• Performance
• Scalability
• Security
• Network requirements
• Storage requirements

Even products of the same category (e.g. AWS RedShift and Google BigQuery) are completely different in many aspects and it impacts the way people use them, how to secure them and so on.

It may even happen that you find out your selected technology is not what you were expecting and that’s totally fine.

6-) Effectively using specialized/expert support

You may wonder why getting in touch with an expert is not right at the top of this list. For starters there is so much information available about any technology on the internet that it is very unlikely that you won’t be able to set up a PoC and a prototype learning from scratch.

Secondly, no person outside your organization will know your specifics. Engaging with an expert right at the beginning will drain a lot of energy (teaching him about your reality) and you will only absorb the generic information (and much of that is freely available out there). You need to know the minimum in order to understand your challenges and really know the right questions to ask.

Your prototype will also be a great tool for this. You can use it to “wrap up” your scenario and use it with any expert/consultant/ninja/guru you hired to support you.

I have even used parts of prototypes when dealing with technical issues where you need to get in touch with tech support. It may be daunting to investigate a very specific issue dealing with a large and complex application. Your prototype will be much easier to be sliced and diced so you can cherry pick only the necessary bits for the investigation and hand it over to the support channels.

7-) Launch the MVP and learn from it

At this stage your learning curve is almost done, you built yourself a PoC and a prototype and you already should have had the chance to review your doubts and technical questions with one or more experts. But we know that in the IT world we can learn more from users in minutes than from books in months.

Until you have run your new solution in production you cannot really be sure that this will meet all the expectations.

This article is not intended to be a “DevOps” guide, but I would like to highlight a few good practices that are especially important when you are launching a new piece of technology that you and your organization may not have fully mastered yet:

• Analytics: make sure you have a minimal set of analytics tools in place to make sure you (1) understand how your new component is being used — think Google Analytics and HotJar here and (2) monitor what is going on (log collection, system cpu/memory/io monitoring).
• A/B Testing or Feature Flags: there are cases where you need to run the new technology side by side with the previous one. If that is the case, you need the ability to control which cohort of you users will access each version. Tools like https://launchdarkly.com/ can help you with that.
• Fail Whale: if everything goes south you need to plan for “graceful degradation”. You need to be ready to deactivate the solution while you investigate any issue without a chance of compromising security and privacy of users and other systems.

That is it! I hope you enjoyed and learned something new to be used on your next endeavours!