Building your serverless team from scratch
It's expected that by 2025 serverless solutions will be a must have for every organization. The advantages of reduced operational management and simplified support and troubleshooting makes focusing your primary capital and efforts on market expansion. Ultimately serverless technology offers a significant market advantage if done right. But if you're like most companies, this is a new challenge. You need to transition internal talent, plan how your organization will need to adapt and ultimately build a discipline where none previously existed.
So how do you do this? That's what we'll explore based on the experience Advosight has had in helping companies convert.
What are your skill gaps?
The first question to ask is what are your skill gaps. This is a pretty obvious question, but it's vague enough to be confusing. When converting a team over to serverless technologies you're entering a new echo system using new concepts, potentially changing the programming language your team is using and finally using new tools and approaches when investigating and resolving issues.
Investigating and debugging programs
Serverless design patterns
Networking & Security
It is more important to understand who on the team needs each type of experience. Trying to make a team where everyone knows everything is a good way to slow down your initial traction. For companies just starting out, it's recommended that you focus on two general skill groups: Cloud Solution Architects and Cloud Engineers. These two groups will allow some focus on depth, while not being too specialized that it's a nightmare to manage. It also has the advantage of having focused individuals working together, rather than everyone trying to figure out everything separately.
Having a consultant come in and help understand your team can be extremely beneficial. The consultant will understand what you want to achieve and help you setup a customized roadmap to get you there. They will help you understand where your team is and the options you have to get to your goals.
How long does it take to get ramped up?
Just like any new technology your team picks up, it will take time before they're truly up and running. Your team is being asked to think differently than they have had to before. Some of the basic skills they have depended on over the years vanish as they embrace technologies which can reduce 70% of the code they've been writing. After about 2 years they're getting into an area where they're super specialized or they've branched out a bit into the Solution Architect skill set. The latter will lead to the "Cross Skill Efficiency Zone".
The "Cross Skill Efficiency Zone" occurs as engineers and solutions architects gain skill sets the other has. The upside to this zone is that individuals here become more efficient by themselves. The downside to this zone is that the depth of knowledge on the specialized fronts is less focused. 95% of the time having someone with cross skill efficiency is worth it. It reduces costs and increases productivity as there are fewer hoops to jump through and performing small tweaks to the solution while the code is being developed. The other 5% of the time either takes longer or you reach out to someone more specialized.
Is there a right way to train the skill sets?
Yes and no. The first mistake is to assume that everyone needs to get an Associate or Pro certification. Getting your entire team certified in AWS is important, but getting certifications at the beginning without having experience to back it up is putting a lot of effort in that won't pay off.
The advice I give is to have your Solution Architecture team train up right away towards certifications, as they will need to know how AWS works and its options. Your Engineering team should start off identifying a small project that can go all the way to production. This project shouldn't be a completely new system, but extend a system which is already built. Once you understand your first project, then have a consultant to work with your team to design the solution with your solution architects, and train your team on the technologies which to be used. During the project, your team will struggle as it will force them to rethink the designs they've been used to creating. There will be times when there's an enormous leap in skill sets and large chunks of what they have built will need refactoring. We expect this and one of the primary reasons to start small, and let the team learn and deliver quickly. This project should take somewhere between one to three months.
Once your Engineering team has finished, encourage certifications. They'll have a better understanding of what their work will look like and pursuing a certification will make more of an impact.
This all sounds great, but when do we get to large projects?
Depending on what you want to do, you could end up with either a large project or more preferably end up with a lot of minor projects that move you to your goals without a large financial investment which needs years to come to fruition.
The planning for this next project should take place as soon as your team trains and executes on their first small project. This planning period needs to be used to understand the "Why" and "What" of the major initiative. This stage should consider the technological leap that is available along with the list of things that have been painful but just need to be done that way because that's the way it's always been. Also in this exorcize your team will start focusing on the financial effects of the technology and process changes which will help with support from management and executives. Your enterprise architect or consultant will help you define the skill sets and roles you'll need on the team, and clarify what success looks like.
This all needs to be done two to four weeks before your team will start executing on it. During this time, your Solution Architects will start working to clarify some aspects of how the system will work and construct some of the initial scaffolding for the project. Some of the early Solution Architect questions will require support from business analysts and management. This is primarily to ensure that assumptions get handled up front and any work with the network operations team gets cleared up before affecting the execution team.
You've positioned your team for execution. As your team rolls onto the project, your solution architects will continue to contribute to the team. They will work hands on with them for significant parts of your first two years.
What happens to the Solution Architects after two years?
After your Engineering team gets comfortable with some solution architecture concepts, there will be less of a need for the Solution Architects to work day in and out with the Engineering team. This team will have the potential to improve, placing more emphasis on industry and organisational designs, sharable components and more significant challenges to your business. A well run Solution Architect team will reduce the costs in operations and personnel, both in IT and business. Reducing the costs could mean rapid growth for the company, scaled down operations or various other options. In some cases your Solution Architect team can give you capabilities at low cost which large companies pay millions for. Ultimately, your Solutions Architect team will get where you want to be.
Changing to serverless computing can deliver results quickly, but there is a learning curve. To help you on your way, it's important to have someone that has transitioned companies like yours before. This could be an employee with that experience or having a consultant such as Advosight, come in to help. The good news is that getting to the finish line gives you more capabilities to expand your market and offer better experiences at less cost.