The days of big team consulting are over. Technology organizations are aligning their budgets to get projects done faster and more agilely. More applications are being built by small teams of cross-functional engineers moving fast, providing higher quality code, designing away waste and cutting out processes that don’t add value.
It’s becoming apparent that engagements incorporating smaller footprints and shorter iteration cycles are more common. The best outcomes are where an engineering team is small, lean and iterating many times faster than much larger teams. That means that enterprises get their applications to provide value earlier and at lower cost, and they cost less to maintain over time, starting right away. It means applying higher quality and better managed teams using core engineering principles. It means cross-functional technologists, not cross functional teams working in silos in their specialties
The catch is: How do you incorporate that at enterprise scale? It’s not easy to do because there is a lot of internal resistance and inertia. And many organizations will not achieve this.
Agility and priorities are key here. Future thinking organizations don’t waste this effort on trying to knock out backlog. They make sure they’re applying themselves in a targeted fashion and they drive velocity higher on things that matter. It’s not about providing spot fixes. Don’t start with building a CI/CD pipeline or an AWS migration. Work with your engineering team on driving down the overhead that’s slowing down the delivery of your platform.
It’s not about using this tool and that tool, and this programming language and that platform to host it, and that it will integrate a certain way, and you are now able to say that you are delivering in a continuous integrated fashion. You should get continuous delivery set up. However, continuous deployment is one step. What you really want to do is reduce costs by 20% and reapply that to a feature that you’re looking for next quarter, instead of waiting till next year. You can restructure the conversation because from the get-go you front load the delivery strategy with those kind of performance terms. And this is real money. We are applying these processes where customers are paying for software to be delivered.
What doesn’t work is “Let’s do some DevOps over here, and then maybe a little over there and make incremental progress.” Spend resources doing principled engineering all in the same application—not bits and pieces in various places and hope to bring it together at some point
One way to know if you are doing DevOps—or any cloud related engineering—better is that you have a better grasp of Amazon’s APIs than Amazon does. Literally, the best companies release updated APIs for Amazon before Amazon releases their new APIs. That’s how good they are.
Different organizations move at different rates with an understanding of DevOps. Some people still say “Get me a DevOps engineer.” Others say “Get me a DevOps’ culture change,” which is OK. But, really smart organizations are asking for small engineering teams to build high performance, high priority platforms quickly, at the lowest possible cost, using the best engineering principles available.
One other way to know that you are doing good engineering and DevOps is when you need DevOps engineers and you talk to a big consulting outfit and they say, for example, that you need 65 SREs with different skill expertise, four project managers, a bunch of data scientists and product people and client partners. They say it’s going to be really expensive and that they’re going to be here forever, and that this is an engineering challenge. Let’s address it from that POV. The engineers are running it, the engineers are closest to the work, they understand the issues and the opportunities, and they just need 10 really good full stack engineers.
The name of the game now is applying engineers that clearly have a specialty, but are more importantly good engineers with software and know how to write code well. You might have a platform engineer, which is going to be like your infrastructure SRE but he’s going to be knowledgeable and know how to write code at a basic level. That will work. You might have an engineer that isn’t the best software developer, but knows platforms, what clouds are available, how to offer it across those programmatically, etc. That will work, too.
The bottom line is moving initiatives that are focused on building revenue or saving a lot of money and driving them forward at a higher velocity, with higher quality delivery at their product launch through foundational concepts, such as continuous integration, continuous delivery and continuous deployment. Leading organizations are focused on doing that in a way that is future-forward, focused on stateless and serverless infrastructures.
This article was co-authored by Jack Keck. Jack is a seasoned technologist leading a cross-functional engineering organization at a global investment bank. He spearheads transformative initiatives with the goal of raising revenues through the use of future forward technologies.
