A business and DevOps communication crash course for developers
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – techtarget.com
Under the hood of every enterprise, the same war wages: technical vs. business teams. On the technical side, you have developers, engineers, operations and IT professionals. And, on the business front, you have the C-suite, sales and marketing. It’s a clash of two different worlds.
A persistent point of contention that fuels this ongoing DevOps communication battle is the lack of common vocabulary. On the surface, it may seem like technical and business teams are working against each other, but in reality, they are fighting for the same cause.
For example, when developers say, “We need to improve the speed of the system by 20%,” business leaders may hear, “We need to spend more money on an incremental change.” A traditional computer science background does not properly prepare developers to build strong business cases, and that holds developers back from achieving their goals. It essentially blocks them from taking a driver’s seat in the overall business.
I’ve worked with dozens of development teams in Fortune 500 companies to resolve these types of disputes and to foster positive change in the everyday lives of developers. If technical teams just make simple adjustments to their requests, it can lead to better DevOps communication — alignment with leadership, more effective conversations and a potential fast track in career advancement.
To get started, here are three things developers can do today.
Know your business pain points
As the centuries-old adage says, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” In less dramatic terms, if you understand the goals and pain points of your business, you have the table stakes to create a compelling case to leadership. The harsh reality is the business cares more about what might hurt them than what’s bothering you.
Start building your business case by actually reaching out to members of the business team. Ask questions that will help you understand how they indicate positive business performance, which could take the form of competitive advantages, sales milestones, industry events or more. These key performance indicators should link any proposal you make to the right business context, so leadership can clearly tie it back to something they’d like to accomplish. Spoiler alert: The answer is most likely rooted in money.
Speak in dollars
Business leaders have to make decisions based not only on reducing pain and friction in a workflow but also from a financial standpoint.
Learn how to negotiate
With the adoption of microservices comes a shift in the communication ladder. Microservices have changed how we develop software. They’ve changed the paradigm and made developer managers obsolete — the ones who typically connected with leadership on behalf of developer team needs and wants. This means that developers need to be confident enough in their DevOps communication skills to talk to leadership themselves about development and business problems. If there was one life skill I wish I could impart to every developer, it would be how to negotiate.
Most things in life require some amount of negotiating, whether it is buying a car, getting a mortgage, applying for a job or, in this case, getting the business to invest in technology shifts. This skill combines the first two steps: knowing your business’s motivators and putting a dollar value to the benefits of your requests.
Finalize your proposal
Let’s return to the example I posed at the beginning: A developer says, “We can improve the speed of a system,” and a business leader hears, “The devs want me to spend money on an incremental change.” A more effective proposal might sound like this: “We can increase revenue by X amount of dollars, if we improve the speed of the system by 20%.”
If you receive pushback, be prepared to follow up with more data that shows the value of the improvement. That data could include how degraded performance can negatively affectcustomers’ ability or willingness to buy.
If I had to boil down my advice to one big takeaway, it would be measure, then measure some more, then compare. That’s the quickest and most straightforward answer to proving the worth of your work and building confidence with business leaders. When it comes down to DevOps communication, developers need to set their data in the context the business side can understand. That data can act as the Rosetta stone for business and technical teams trying to speak the same language.