By Robert Reeves, Co-Founder and CTO, Datical

In the early 2000s, Jeff Bezos mandated that all applications at Amazon would offer web services for other applications to access data and functionality. Prior to this, Amazon was struggling with a ponderous, unwieldly group of applications. Downtime was an issue and Bezos had had enough.

Instead of taking software to the wall separating one team from the next and chunking it over, teams were now responsible for not only creating the functionality but also making certain it was working in production. We’ve shortened that to “You build it; you run it.”

Looking at the results for Amazon — they were able to rapidly scale their applications to support growth and they accidentally built Amazon Web Services — it’s no surprise that other companies want to duplicate their success.

But it’s hard. You will dramatically change your org chart, delaying customer demanded functionality and a lot of your employees who don’t get onboard will need to leave. That’s scary, but it’s worth it as your employees will be able to deliver improvements faster than ever.

“Who Moved My Cheese?” – Changing Your Org Chart

The first step in building cloud applications is creating cross-functional product teams. No longer do you have dev, test, operations or developers, system administrators, and DBAs. You will have product teams that encompass those roles and skill sets.

One of the most frustrating aspects of application release is waiting on external teams to complete tasks that are blocking you. Cross functional teams eliminate this bottleneck. For example, instead of waiting days or weeks for an external data services team to review an SQL script for execution, the product team now has the skills and ability to review and execute the SQL script themselves. Goodbye waiting.

And that’s a good thing. The research team behind the “State of DevOps” report found that companies with zero review prior to application pushes and companies that had external teams reviewing change had the same IT performance. That’s right…There is no difference between how your company’s IT organization performs if you have external reviews. The one type review that predicted software delivery performance was peer review of changes. Thus, if you have a peer review process, you will have better software delivery performance.

That’s very scary for the teams that perform those reviews. However, if those reviews are moved into the product team, the company will have better software delivery. Thus, the team members currently performing reviews must work closer with the product teams and become members of those product teams.

Do Not Delay Customer Functionality

We have all seen companies that focus on internal infrastructure at the expense of customer functionality. A classic example of how IT decisions can wreck a company is Zynga. During the explosive growth of Farmville on Facebook, Zynga embarked on leaving AWS and creating their own cloud. During this period, they not only failed (and returned to AWS) but they also missed out on the explosion of mobile gaming.

Moving to a product-team oriented organization is not the same as building your own cloud infrastructure from scratch. First, it’s proven that product teams who use web services for cloud applications works. Contrast that to Zynga, which worked on how they hosted their software instead of the software itself. Second, product teams accelerate the rate of innovation in your company. By focusing on customer demands and not internal demands, better customer functionality is delivered faster.

Of course, you can test this yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately exposing data and functionality via a web service. Then, have the monolithic application call the interface to use the functionality. Finally, improve it. By measuring how long it takes at each step, you will prove to others that you can deliver customer functionality faster. In the end, focus on you are what you are good at –  building your application. There are plenty of really good cloud computing options out there to house your app. Don’t make the mistake of trying to build one yourself. If you do, functionality will surely be delayed, your customers will not be happy, and your topline will suffer greatly.

Change Is Scary

The only way to see long lasting impactful change in an organization is to make change appealing. And change, we must. The question is not how to change, but how convince your team they want to change. And, the answer is simple: reward those that engage and drive change. Those that fight change or sit on the sidelines will ultimately see the results and choose appropriately.

What is needed is a change catalyst. Leaders should identify teams that are adapting to this new way of building and delivery applications and reward them immediately and loudly. As people see the rewards, the laggards will begin to change.

However, that is not sustainable for the long term. Employees need to see that they are able to perform their jobs better and faster. That’s self-actualization which is far more efficient of a reward system. As employees see their projects being released faster and the hassle factor of releasing lessens, they will whole heartedly adopt this, “You build it, you run it” mandate.

Amazon shifted to a “You build it, you run it” philosophy in the very early 2000s. Since then, they struggled internally with changing their org chart, unfounded fears of delaying customer functionality, and convincing employees to embrace the change. When you are able to manage these issues effectively, your move to cloud applications will be far easier and much more rewarding.

About the Author

As Chief Technology Officer, Robert Reeves advocates for Datical’s customers and provides technical architecture leadership. Prior to co-founding Datical, Robert was a Director at the Austin Technology Incubator. At ATI, he provided real world entrepreneurial expertise to ATI member companies to aid in market validation, product development and fundraising efforts. Robert cofounded Phurnace Software in 2005. He invented and created the flagship product, Phurnace Deliver, which provides middleware infrastructure management to multiple Fortune 500 companies. As Chief Technology Officer for Phurnace, he led technical evangelism efforts, product vision and large account technical sales efforts. After BMC Software acquired Phurnace in 2009, Robert served as Chief Architect and led worldwide technology evangelism.