Remember when you were a kid and you really wanted to go to a concert but you knew your parents would say no?
You spend all this time preparing arguments, counterarguments, getting the names of the friends who were also going, and building a presentation to tie it all together. You present it to your parents with gusto just to hear them say...
"No."
You of course ask why and you're hit with the immediate "because I said so.".
And that was that. You didn't go to the concert even though you really, really, really wanted to.
It made sense to you, your reasons were sound and justified, but your parents weren't having it.
The same thing is happening with serverless.
Evangelists talk about the scalability, cost savings, and reliability boosts of serverless, yet the adoption rate hasn't taken off with large companies.
According to the State of Serverless report by DataDog, we have a continuously growing adoption rate of serverless services like Fargate and container-driven Lambda functions. But these are just stepping stones to getting to a true serverless experience.
A true serverless experience, in my opinion, ditches the containers unless they are absolutely necessary. Almost any problem can and should be solved with serverless services like Lambda, Step Functions, SNS, SQS, and EventBridge.
But this message seems to be lost when approached by many software companies. People have been doing software development in a specific way for decades, why change now? What would the cost be to the company?
What we need are people who get out there and prove it. Show how it scales to meet demand. Show how much money it saves. Show how much more time engineers have to solve business problems now that they don't have to fight with hardware issues.
What we need is serverless enablement.
What Is "Serverless Enablement"?
A few weeks ago, I had the privilege to go out to the Postman customer summit in Napa, California and talk shop with their executives and with senior leaders around the tech industry.
A theme that came up over and over again was the concept of tech enablement. In a sense, these enablement teams acted like teams of scrum masters to other development teams. They were experts in a technical area who coached, trained, removed roadblocks, and provided valuable examples, references, and proof of concepts to other teams.
Similar to a concept I described a couple years ago as the inner startup, building an enablement team starts small with narrow focus. In my case, we built a team to explore the ins and outs of serverless.
I led a team of engineers for years to pioneer serverless and its pragmatic use for our company. We started of small, but as our expertise grew so did our range of use cases. Eventually we got to the point where we built a legitimate production application and deeply understood the nuance of how serverless scales and how to design production-level applications.
It was at this point that our serverless enablement team was born. We had strong team of engineers that were experts in serverless development who could provide real, production-level experience to other teams across the company.
They knew the answers, they were armed with examples to solve problems, and best of all: they were internal to the company. We didn't have to pay for expensive consultants to come in and give advice. We had our own people who already had relationships and rapport built around the company who were ready to spread the good word.
Serverless enablement is not just talking the talk, but walking the walk.
Once we had a team that the technical ability and know-how, it was time to spread the knowledge. Teach the other teams how to break into serverless and utilize best practices we had put in place.
Benefits of Enablement Teams
Governance is everything in any new tech, and building an expert team up front helped establish it.
An enablement team not only provides a wealth of practical experience, but they also provide established governance rules. Standardizing on a tech as wide open as serverless offers tremendous benefits on so much more than cloud spend. Providing governance enables consistency, guardrails, and accelerated development.
While the serverless community is getting bigger every day, you might still have issues digging up answers to difficult business questions the leadership in your company might ask. The expertise of your enablement team brings quick answers backed by evidence. This provides a higher level on confidence in the technical direction the company is marching toward.
I have had several conversations with companies that don't quite understand serverless. They know the gist of what it offers but they fall into the traps of some common misconceptions associated with it.
The most common misconception I hear about serverless is that it can't handle advanced problems. Many times I will be discussing the benefits of serverless when someone asks, "but what do you do about difficult problems?" I always answer back that serverless can solve basically any use case (with a couple of exceptions), but it always falls on deaf ears.
What makes enablement teams so valuable is when they relay a message like that, they can also prove it. They can point to existing software they built in production and show that serverless can, in fact, handle complex problems. Being able to completely quell misconceptions is a significant factor in the rate of adoption of any technology.
How to Start
Getting started with an enablement team does not have to be a significant effort. If you've made the decision to go serverless, you can start small. Build a team of engineers who are dedicated to research and development of a serverless application or component of your existing application.
Let the team build experience and get an understanding for the tech. Allow them to become experts. Remember, this team will act as your internal consultants.
Building expertise takes time; you won't have your enablement team overnight. Allow the team to practice, iterate, design, and build. With each iteration on the project, your team will become smarter and their skills will get better.
Once your team is established and their expertise has grown, start developing your governance standards. Let the experience they've built up guide the initial rules you put in place for other teams. Don't rush toward governance. Build your expertise and really understand the technology all the way up and down the stack.
After you get your goverance in place, start incorporating the team members into the mix with other development teams. Remember, the members of this team act as consultants and should be utilized as such. They bring their expertise to the table and assist in training and enabling others.
The LEGO group is an excellent example of how to get started with serverless enablement. Sheen Brisals gave a talk at AWS re:Invent 2020 about how LEGO.com uses serverless to accelerate innovation. In his talk, he describes the process they went through to build up their engineers on a new tech stack.
Conclusion
Serverless enablement is a modern take on a classic approach to incorporating a new tech stack into your organization. Build a team of experts, then let the experts spread the knowledge amongst your other teams.
Build a library of practical and real-world examples. Heck, build a production application. You will never have more concrete proof and better references than an app in production.
The entire purpose of an enablement team is to make it easier for others to build. Unblock resources, answer questions, do the dirty work and investigate new concepts and paradigms. R&D teams aren't new, and most companies have them. But what separates an enablement team from a standard R&D team is consultation.
Be sure to incorporate the team members into other development teams around your organization. In order to be successful, you must spread the expertise from your enablement team to others. If you didn't, then they would be considered just another app team.
This is a long and arduous process from start to finish, but the end absolutely justifies the means. Serverless has tremendous benefits to any organization, and the number of use cases it satisfies continues to climb.
Happy coding!
Top comments (0)