Serverless event-driven technologies are changing the way we view our traditional development teams. Development teams have been the standard across IT for system maintenance and innovation, but as we adopt serverless, we start to see a significant change in the makeup of these execution teams. This transition can best be described as a combination of solution architect skill sets and development skillsets. An emerging term to refer to this combination of skills is SolDev.
Having built and led serverless teams across multiple industries, I’ve seen teams built from C#/.NET teams all the way to COBOL teams. The biggest challenge when building your team is understanding what your technology gap is, from where your team is to what they’re expected to do. Leading your team across this gap effectively requires you as the leader to have a clear picture of expectation of what your team will look like after the transition.
What is it that you’re taking on?
Your team will start having to make infrastructure and technology decisions at the execution level more often. The days of defining a three-tier architecture is quickly disappearing, where your infrastructure and technology layers could easily be predefined (Server OS, Database System, Network Tech, Firewalls, etc.). Now, the team will be spending time identifying which services match their technology business objectives and piecing together existing solutions and as a result, reducing the amount of code they write. This skill set is more often associated with solution architects rather than traditional development teams, but also reduces the depth that your developers are required to have in deep understanding of programming language nuances.
There are two approaches I’ve taken with this problem with success. The first is bringing in expertise from vendors who already have experience in this space. This allows the team members to model others who have experience in executing in the method they’ll be growing toward. The other approach is to get the team working with someone already in the organization who specializes in solution architecture. In my experience, the first approach resulted in a far better outcome as the vendor was able to identify pain points in the development lifecycle early on and fill the gaps based on tools they used in the past. The second approach tends to require a lot of discovery as to which services, processes, and approaches work best for the team and the solution as the solution architect becomes more familiar with the pains that the development experts have to deal with.
While not all of these will fall on the team to define, the team will need to start becoming aware of areas of technology that are pre-defined at the company or organizational level, which areas the team can innovate on, which they need to align with, and which are required to conform with.
What is a solution architecture skill set?
Application architecture relates the ability to break down software, services, and distributed components into meaningful units which can be implemented. By contrast, solution architecture breaks down the full scope of a product or a set of services into components which are fulfilled by existing services, common systems which need to be stood up, common systems which are shared, network considerations and tolerances, or blocks of capabilities which are distinct. This big picture approach then lets application-level architects focus on unique aspects to their systems while re-using common components. They tend to see the technology landscape as continually evolving to fill in patterns that can be re-utilized towards their goals.
Due to the nature of technology always evolving, a solutions architect needs to be constantly consuming and evaluating new services and approaches in technology, their industry, and even in their organizations. Strategies around this can be found in knowledge repositories called Architecture Repositories, which help the solution architect quickly identify components that can help fill the needs of the problems they’re currently trying to solve.
While this skill set is important and your team will take on aspects of it, the discipline and complexity around this scope will be smaller with serverless solutions. This reduces the need for a high competency in this area. That said, it's still a good idea to have someone in the organization who has this skill set who can be reached out to for consulting and review purposes.
Common stumbling points
There’s a saying that history does not repeat itself, but it sure can rhyme. Each team you lead into this space will face different challenges, but there are some common patterns that occur.
The first one is overcomplicating a solution. It’s common for senior-level developers to want to write frameworks, abstracting away common patterns so they only execute on the most impactful unique problems. They’ve built up a career of building relational data models, inheritance, etc. This is a quick way to end up with a very complex system. The team needs to convert to thinking about serverless as the framework, similar to service-oriented architecture frameworks. By using fewer abstract concepts they’ll reduce the code written and increase productivity.
A second stumbling point is “programming” in the AWS Console. This is a typical challenge new teams face as they try to identify how to be productive with a brand-new toolset around serverless technologies. This leads towards code that isn’t designed to be deployed in a release pipeline, code that goes missing, and hand-crafted environments that don’t give the same results for the same input. To mitigate this, choose a framework for your serverless team to use early on. The article “Serverless guiding principles deep dive: #1 – Use a framework” can be a useful resource for thinking through why you’d want to use a serverless framework rather than going other routes.
A third stumbling point is overestimating what the team can do and expecting a perfect solution for their initial projects. Your team will find new techniques and tools constantly, which will change their perspective on how to build serverless solutions. At the same time, the team needs to be careful about constant refactoring of components that are not ideal but work. Finding the balance between finding new solutions and sticking with what you have will be an ongoing discussion. The article “Leading Your First Venture into Serverless” explores setting up a team for success.
How important is seniority when it comes to serverless?
How important is it to have extremely senior-level engineers working on your team? This is a very interesting question that I’ve run into in the past. Senior engineers have become a necessity for the average development team, often able to produce more value per dollar than junior and mid-level engineers. What’s interesting on SolDev teams is that serverless technologies appear to simplify the code created. This eliminates a significant number of tools and programming design patterns that were previously necessary. It’s also fascinating that extremely senior developers tend to have to eliminate skill sets and approaches as they take on serverless technologies due to the less complex nature of the domain. This means that the skill gap to get systems built is higher for those who have reached higher stages of expertise.
I’ve seen many entry-level engineers pick up serverless technology straight out of school and become productive at a faster rate than individuals who were considered senior-level engineers. The big difference really comes down to this: when the individual runs into a problem they struggle to get past, where do they look for a solution? The senior-level engineer will look internally to design patterns, while the entry-level engineer will look externally to services to solve their issues. While typically in serverless we want to look externally to find a solution, rather than write a custom solution for ourselves, there are occasions where having a custom solution is the right choice.
Conclusion
Building a new team taking on serverless is a journey that should really pay off as your team starts delivering more business value. Getting your team to that point will require leadership to help guide them through the initial stumbling points they will run into. The good news here is that there are many ways you can set your team up for success.
After constructing your first team, things get more interesting as your organization starts to grow the number of teams working in the serverless AWS space. Amazon has a great article that outlines the roles and challenges with this type of growth in “OPS 2: How do you structure your organization to support your business outcomes?”
Finally, make sure your team gets familiar with supporting their systems through disasters. In the article “Cloud Emergency Preparedness Kit Pt. 1” Jeremiah Owens talks about how to plan for disasters and ensure your system stays production capable.
