Serverless technology is disrupting traditional IT as it grows, but how can leaders transition their teams over to using serverless approaches in their systems? How can a leader know what supports will be most impactful while still ensuring that the organization doesn't abandon the effort?

Just like any alternative approach to building systems, when moving into a serverless approach for your business, your teams will have to build a new skill set. Having had the benefit of being a part of multiple transitions across multiple companies I've really only found three approaches to this problem: purchase training, make the long transition or hire someone who has been there before. Each of these approaches has benefits, and there are scenarios in which each of these approaches is appropriate for your serverless journey. In order to better lead teams, you need to understanding the strengths and weaknesses of each approach. This will allow you to make the best decisions based on your unique business environment and team.

Purchase training

Purchasing training by itself is the most common approach, while yielding the lowest overall success rate. Training can be a useful tool, as it can help your existing team understand the transition they will make and get them hands on experience with the technology they'll be using. The big mistake that a lot of companies make is purchasing generic comprehensive training, since they don't know what specific training will apply to what their teams need.

When purchasing training, you as a leader are committing your teams to extend a lot of energy for a short period, then work to master those skill sets they've learned by applying them almost daily on the job. Mastery of a new skill set takes time, becomes easier with practice and prepares your team for the next step in their serverless education.

So how do you apply meaningful training for your team? The best advice for training is to partner with a vendor to support a specific project the team will work on for the next few months. The vendor's job will be to work with you to understand the project, understand the timeline, then put together a training plan. This plan will leverage an iterative approach to education, bringing in training for parts of the system that will be developed imminently, then step back and let the team work. As the project proceeds, the team will reach milestones and parts of the solution at which point the vendor will follow up training focusing on the next phase of the project. This focused approach allows the team to dive into the "Why" and "How" for topics which they will apply and master after the training is complete. This provides the biggest value, while reducing the overall cost for the training.

Strengths:

1. The team is learning skills up front and not having to figure them out themselves

2. Heads off many misperceptions and bad habits up front

3. Easier to fund and can sometimes be pulled from general training budgets rather than team budgets

Weaknesses:

1. Relies on high effort from the team up front, followed by an extended period to use and master the skill sets.

2. It's easy to purchase more training than a team needs and can master.

Make the long transition

The limited scope approach turns objectives into small incremental changes. This approach's philosophy is "The scope on our plate is more important than the transition". By using this approach, teams take on minor projects which will replace small portions of existing systems, moving them from their current architecture to a serverless one. In doing this the team doesn't have any major deadlines to reach and can always fall back on extending the original system rather than building the capabilities into a serverless system.

Strengths:

1. Team can transition to serverless at their own pace

2. Deadlines can be met on existing platforms

3. Over time, all major parts of the system are replaced by serverless

4. Limited budget impact as serverless migration can fit into training budget

Weaknesses:

1. Leadership needs to stay committed to serverless

2. Migrations can last over 3 years

3. Refactoring effort of your serverless systems increase, as the systems tend to be built piecemeal rather than a wholistic serverless architecture

4. Business priority pressure tends to pull the team back to proven technologies

The limited scope approach is great for teams that need to limit commitment, budget and maintain burn rate. Companies like Trek10 have created a pattern to this approach called the Stengler pattern, which has yielded successful results.

Hire someone who has been there before

The final approach is hiring someone who has been there before and who can help guide your team during the transition. With mentorship, your goal isn't to just get your team on their feet, but to set up your organization with a path to mature your development and solution architecture expertise. The two sides have complementary skill sets, but different must form different habits, focuses and will often execute at different points in the product life cycle. Building up these skill sets and habits without experience is a long and painful journey, which is why hiring someone who has been there before is so important.

Mentorship has been around ever since I first stepped into technology and is one of the most effective ways of bringing your team to a point of expert execution. This individual will give your team a safety net for their approach brainstorming as well as when they run into situations they struggle to get past. This isn't a genuine surprise as companies have used the approach for technology changes throughout my career. So what's different with serverless?

Serverless technology has been around for just over 5 years, with the real game changer being that your team is writing a fraction of the code they used to write and leveraging a larger number of pre-existing solutions (to learn more read 7 guiding principles of serverless systems). With serverless there are two major roles your team will need beyond what you already have: Solution Architect and Cloud Engineer. The Solution Architect role will focus on the big picture, researching what existing services can be used and where you'll need custom code. They look for patterns in services to increase effectiveness while decreasing effort and costs for your projects. Most of your team, though, will be cloud engineers. They will focus on implementing the parts of the system that need custom logic and integrations. This role is mostly similar to the traditional developer role, but with some knowledge of the cloud and delivery mechanisms thrown in.

Your first step as a leader is to find those individuals on your team that want to become Solution Architects and those that want to be Cloud Engineers. After that, you'll need to identify how to get the mentors your team needs. To do this, there are really only three options: internal shared mentors, hire a new employee or hire a vendor.

The serverless community is growing quickly, but there is also high demand for individuals with serverless experience. This can make bringing on internal support or hiring difficult. In these two cases, you'll want to identify if you want a single mentor or specialists. Having someone who focuses on both Solution Architecture and Cloud Engineering is possible, but they may have less experience on the process and practices in each. Getting a specialist in each is much more achievable, but increases the cost.

If you don't have experts internally or access to them, and you don't want to spend the time recruiting, a vendor who has a track record of mentoring and and training is a great option. The vendor's job will be to supply Solution Architect and Cloud Engineer mentors to your team. They will also work with you, as the leader, to build out your organization's Cloud Engineer and Solution Architect skill sets and help set the foundation for your company to become self sufficient and sustaining. As your team becomes more experienced, the vendor then reduces the time spent mentoring and your employees take the responsibility to mentor each other. This approach works out well, as those in your organization with deep business knowledge become the rock stars your company uses in the future to design solutions and teach others, combining the technical considerations with the deep business knowledge considerations.

Strengths:

1. Fewer initial mistakes by the team

2. Growth is continual and focused on business oriented problems and solutions

3. Your team and company become the leads and mentors for others, building up a growth plan across your organization.

Weaknesses:

1. Hiring can be hard and time-consuming, and the alternative vendor option can get confused with professional service work

2. Results per team can vary, and rapidly expanding this across a large organization quickly might not be practical.

Considerations

Just like everything in business, cool technology is typically not the driver for decision making. From my experience the big three drivers around your decision making will be budget, time to deliver and the availability of experience in serverless in your company. Each of these three areas impact the options you have at your disposal. The chart on the right outlines the three drivers, with limited access being at the center of the chart. The more you have on one of these drivers, the further you move out from the center. This results in a triangle in the chart showing a mixture of mentorship, training and scope.

Budget is the easiest to define. Typically as a leader, you understand your company's available budget and the ins and outs of your budgeting philosophy. The two extremes of this are the steady burn and targeted budget. Steady burn budgets provide little flexibility, as its more important to keep the spend constant at the expense of long term reduced spending. Targeted budgets are the opposite of that, with large budgets allocated at the beginning of the financial year. The spending of these budgets are tight at the beginning, but get a lot more flexible as the year progresses and spending must raise to meet the target. There are a lot of other philosophies that fall between these two extremes, but you must understand your budget to decide the best approach for adopting serverless technologies.

Time to delivery is next. Business isn't just about budgets, features and profits. Political will and political capital play a large part in a business' decision making. For IT political will turn into budget, innovation initiatives and a seat at the table in steering the company's long-term direction. Time to delivery speaks to the speed at which significant impact needs to be delivered from the point when a project is approved to when it needs to be delivered to production.

Finally, you need to understand the experience level your company already has in serverless. Experience could come from another team that had already converted to serverless, but it can also come from outside. Having an open headcount that you can tailor to this need can be helpful, though you'll need an individual who is an experienced change agent which can be challenging. The last option here is hiring a vendor who is an expert on serverless. With this last option, you'll need to be careful as there are quite a few vendors who will tell you they can do serverless but have very little practical experience in the area. These vendors will not help you. Having a vendor who understands how to work with companies to build their internal teams to be self sufficient is what you're really looking for, and it can save your company money at the same time.

Conclusion

As a leader, you help drive your company's vision forward, helping both set direction and fill in the gaps. Your decision making on how to support your company's transition to serverless in the early stages is extremely important in obtaining both team and company support. The good news here is that there are a lot of options on how to get there while building your team up to drive a serverless vision.