The secret formula to leading your team to serverless
What do you do if you have a traditional software team, and you get tasked with taking them to the cloud? Not only that, but your company’s leadership wants you to go serverless? How do you as a leader take a traditional software team from where they’re at to be successful?
These are common questions in today’s world, as more and more teams are being asked to transition to the cloud, and the promise of serverless technologies can change how companies do business and the products they offer. Over the past 22 years, I have been a part of several breakthroughs in technologies, from being part of creating .NET to helping architect the Coca-Cola Freestyle user interface to leading transitions to the cloud and serverless. With serverless transitions, I have had the privilege to lead and worked with a variety of leaders who have spearheaded serverless efforts in their companies. The good news here is you aren’t the first to go down this path. The bad news is that there have been a lot of people who’ve tried this and failed. What is the difference between those that succeed and those that fail? Is there a secret formula for success?
When looking at successful teams there are three common characteristics: they budget for smaller projects and more initial time to deliver, they have a diversity of focus and depth, and they focus on getting things done aiming for “good” not “great”.
Smaller projects and more initial time
Successful teams start not with lofty goals, but with small expansions to existing systems. They then set expectations that the work will take two to three times longer than what it would take to extend their normal systems. This sounds scary at face value. Why would you want to spend two to three times longer to finish the same task in serverless?
What these teams assume is that they are going to be learning a lot during this time and making mistakes. They will be using tools they’re not used to, and approaches that sometimes seem like a step back (such as debugging systems that cannot have a debugger hooked up to them). At points in the project, they’ll need to rewrite features that don’t work at scale the way they expect. These initial projects, while taking longer, lead toward the experience and understanding necessary to execute much more quickly in the future.
The teams also tend to limit the number of services they’ll interact with to only a couple. They’ll focus in on small solutions using limited capability to avoid the extremely high learning curve that can be run into with AWS. This approach does tend to leave technical debt in place which must be cleaned up later, but that cost is outweighed by the benefit of being able to demonstrate business value and incremental success.
Curious about Serverless? Our Experts are here to help!
Successful teams also have a diversity of perspectives and skillsets. Software engineering teams tend to try to build consistency on approach and perspective through technology used, culture and process. Successful teams are not afraid to tear down some of these processes when first stepping into serverless. This allows the team to build a new set of skills which are more closely related to a traditional solution architect and embrace it.
Successful teams tend to have diversity in three specific archetypes: The “Technology Nut, The “Get ‘Er Done” and the “OMG This Is Too Much”. These three archetypes allow for the team to self-adjust for success. Then finally, the team’s culture has a tendency toward de-escalation and focus on solutions, not blame. The team will run into challenges they don’t expect, but a team that is focused on moving forward together is more likely to be successful.
The Technology Nut
Solution architects look at problems as blocks of capabilities that could have many potential services or systems fill the role. These individuals don’t need to be solution architects and might already exist on your team. They tend to have a drive to continually understand what’s possible and what the latest technology breakthroughs are. They are intellectually curious and would prefer to try new technologies to solve problems, as they see a distinct competitive advantage for their organizations by doing so. These individuals won’t necessarily move your existing software solution, but they start playing a larger role as the team moved into serverless.
The Get ‘Er Done
The second type of individual you’ll need are those that “Get things done”. These individuals are fine with less optimal solutions if they work for the current purpose and are timely. They know that what they write now isn’t necessarily technologically perfect, but if a system has little usage and limited scope, they’ll prefer to get it done fast as they’d prefer to focus on delivering business value.
OMG This Is Too Much
The final type of individual in the mix is the cautious teammate. The other two types of teammates can easily overestimate what they can do and how quickly it can be done. They rely on their experience of working hard to make up for their willingness to take on risks. This can lead to projects that drag on indefinitely and fail as leaders lose confidence that the investment will pay off.
To balance this out you need a third voice that is always trying to pare back the objective. This type believes that completing the project with the minimal viable system is the best way to go, then it can be iteratively improved after that. They’re not timid to start new projects, but they do want to know what at minimal is necessary for success.
Anti-Archetype
There are always those people who are sticks-in-the-mud or are resistant to change. Those individuals are fairly easy to weed out and tend to be well known to leaders. The archetype though that should be avoided is the one that focuses on achieving perfection. This type of personality will take mistakes and try to create processes, perform root cause analysis, or even name and shame. They focus on high quality even in the face of impacting deadlines and others’ timelines. During your first venture into serverless, your team will not be at this point in their mastery of the technology. To succeed the team will need to move faster than normal to show results as they work to learn the technology in parallel.
Aiming for “Good” not “Great”
The final characteristic is that the team aims for “good” not “great”. It’s easy to get bogged down in analysis paralysis, and in a world where new services and capabilities are being announced almost monthly, this can cause continual delays if you’re aiming for perfection. At the same time, successful teams tend to think of their first venture as a proof of concept. They understand that the code they write now will be referenced back to later as horrible and needing to be rewritten. The funny thing here is that they already feel that way about the legacy code they wrote in the products they’re currently maintaining in their regular software teams. This focus on “good” also anchors them to be more focused on business value, allowing them to deliver better demonstrations and complete their projects with minimal refactoring approaches they used earlier but later discovered other solutions for. If it's working, don’t fix it (for now).
Conclusion
Your team will be starting a journey that will expect more out of them than before. The goalposts for finishing are going to change from what they envisioned at the beginning of this journey to what they finally deliver. They’ll learn more and more over time and take on more ownership responsibilities if they’re able to succeed. The good news is that over time they will also become more and more independent, able to solve larger business challenges, and learn to execute much faster than they previously have in the past.
Leading a team diving into serverless for the first time can be amazing as well as challenging. Having led multiple teams with multiple backgrounds I’ve found it extremely rewarding when a team switches from “This is an experiment” to “This is what we do”. You’ll need to help them understand an extended scope they’re signing up for, and various new concepts and approaches. As a leader though, your job is to make sure the team is set up for success by giving them challenges that show success, can be accomplished inside of your team’s budget of time and expectations and with the right individuals in the group.
