How Do You Bring Serverless Awareness to Business Stakeholders?
Convincing product teams and business stakeholders of the necessity of a new technology is a tough ask. Though they may not directly influence the choice of technology, they’re responsible for the final approval in many enterprises. Surpris‐ ingly or otherwise, in such situations, the main reason these stakeholders reject new technology is often fear of change—and the two main fear factors center around business disruption and cost of operation.
Business disruption does not always mean service unavailability or downtime. Stake‐ holders may fear technology change because of the risk of poorer quality of ser‐ vice, customer revolt, performance degradations, reduced business insights, changes to developer velocity that affect outcome and flow, and more. Moreover, many enterprises still operate in siloed team structures where business stakeholders are not always kept updated on upcoming technology changes and often only learn about changes when things go badly, or through hearsay from peers and canteen gossip, which is unhealthy for any organization.
Serverless adoption adds extra mystery for your stakeholders, because it’s not always well understood. If engineers find a serverless mindset is hard to attain, you can imagine the difficulty for others. Hence, it’s essential to keep the stakeholders in the loop and start the conversations with them as early as possible.
Speak a common language, and avoid serverless language
Does serverless have a language? Well, it depends on how you talk about it! At least during the early days of selling serverless to stakeholders, try not to use specific service names such as Lambda, DynamoDB, and S3 or possibly unfamiliar phrases like managed services, FaaS, SaaS, etc. You should not expect everyone to know what these are. Instead, use universal terms like cloud, programs, functions, databases, tables, and files, and understandable flows such as “a function is called or executed when the user enters data,” “data is stored in a table,” “a notification is sent when a customer account is created,” etc.
While working on solution designs, include high-level context and flow diagrams with basic notations for everyone to understand the problem domain. Keep the cloud and serverless service icons and technical drawings aimed at engineers in a detailed design section.
