How DevOps Leaders can help CTO's succeed while gaining more influence in your organization
CTOs may not see the value of platform engineering at first, but with these 5 changes, Platform Engineering teams will go from after thought to the greatest value enabler in IT.
Trying to lead DevOps and platform engineering efforts at an organization are rife with challenges. The biggest challenge can be to deliver what your CTO may need but isn't aware of currently.
There are a multitude of reasons for this depending on the CTO's background. If they come from a technical background, they are trying to figure out how to go from a domain specific trench to thinking broader. If they were management IT, they are trying to figure out which pieces are valuable vs. which are unnecessary. And if they don’t have a technical background, understanding all the components of an organization's IT environment can be overwhelming.
The end result is the same - CTOs often consider most things to be cost centers and want to reduce it, and focus on the tangible functions and features they deem will add great value to the business.
This can be a critical stage when responsible for DevOps and platform engineering, where the correct decisions can change the conversation from cost center to value enabler and multiplier. Let’s look at 5 changes you can make within your team.
Platform as Product
The first step is to shift your own team's thinking to treat your platform as a product whether you're supporting line of business applications or supporting development for customers. This shift allows the team to look at internal developers as their customers, moving away from just Infrastructure as Code to trying to optimize the developer experience. You and your team can now start incorporating developer journeys, pain points, and gathering feedback sooner. This push leads to asking smart questions, gathering client feedback and improving the customer experience. Questions such as "how do we enable the self-service capabilities to help developers deploy faster?" can give key actionable insights, that once implemented, increase your team's reputation within the customer groups, and in turn within the organization.
This change is fundamental to help your CTO understand the importance of your team and be able to align it with key organizational goals. Often this translates to increased budgets and wins the entire company can understand. Historically platform engineering would be seen as a cost center, these types of discussions help sell the value internally.
By showing the incorporation of feedback, doing customer surveys, you are now gathering the information to show your value. The team may be resistant at first, or consider it to be more "overhead" but working through those hurdles will help the team in the long run.
"DORA doesn't work for us"
Most organizations try to take prebuilt metrics like DORA and implement only to come to the realization that their industry can't simply focus on lead time for when changes get pushed into production. This can be for a multitude of reasons including regulatory, operations, safety or hardware constraints. Healthtech is a great example of an industry where reliability maybe the primary driver rather than speed and frequency.
Just because one set of metrics does not work, does not mean that you shouldn't be focusing on metrics. There might be other metrics such as SPACE that could work (We discussed SPACE in the article linked here), or understand what the goal is and find ways of measuring it. Perhaps the goal is to increase frequency of deployment within your own lab environments for faster feedback. The goal should be to create faster feedback loops from your customers even if they are internal, using that feedback so that team can address it and measuring to make sure you are succeeding.
This helps the CTOs by providing them visibility on how your team is performing under your leadership by showing improvements and value adds, but also helps the CTO communicate with other executives, clients, investors and board members showing how well/efficient their department is running and delivering.
Working with Hypotheses
When developing products it's rare to know what a customer truly wants, whether internal, enterprise, or consumer. Hypothesis driven development has therefore been useful for development of new features.
When applied to your platform engineering efforts, it helps you adopt a scientific approach to measuring the impact of your work.
Imagine rather than saying,
"Let's create templates to help our developers because we need to resolve issues sooner"
it changes to:
"If we provide pre-configured monitoring templates with standard alerts, teams will detect and resolve production issues 30% faster."
In this particular example, it would be imperative to have data for Mean Time to Recover (MTTR) efforts in the organization (hence the ability to see improvement). This approach, ensures that all effort by the team becomes an experiment that can then be repeated, controlled and improved upon.
While metrics shows CTOs team performance, this layer shows the proof and helps craft the "how" the team is accomplishing it. It helps build better cases for value, future toolsets etc for you and your team without it becoming a "guess/hunch"
Enabling Cybersecurity for the Organization
In most organizations, security starts with compliance - a focus on obtaining SOC2 or ISO27001 to satisfy external customer demands. This usually falls on CTOs to figure out how to achieve. Since platform engineering teams are fundamental to organization infrastructure, it’s the right place to introduce security best practices. These practices can then trickle down to product development teams.
By being proactive and iterative in implementing security controls, your team will ensure that you are reducing the organization's exposure, and working to make sure that when the organization needs to certify or resolve a cybersecurity incident, you are in the best position to support while knowing you have controls in place that will mitigate the impacts. You may not have buy in from the areas you serve, but even something as simple as enabling logging (with good log management) will have large impacts on the organization.
Of the 8 domains in cybersecurity, platform engineering can be a driver for all of these.
Being the champion for cybersecurity within the team helps CTOs obtain compliance faster, or help troubleshoot and recover from cybersecurity incidents. It may not give accolades or even have momentum early on, but eventually the value will shine through.
Managing Outsourced Development
This has been the most consistent issue I have seen with CTOs in my 15+ years managing outsourced developers. Whether CTOs expect the entire development or product is managed by the outsourced party (which they claim they will do but never do) to having difficulties getting external developers integrated with internal teams, eventually the organization inherits a mess that then results in engineers have to figure out and make sense of.
One of the fundamental tenants of DevOps is continuous delivery, and your team is the one responsible for ensuring that that foundation is in place for 3rd parties to use. It’s imperative to setup how you will be accepting delivery and defining the parameters early on.
Most external teams will want to take the path of least resistance to deliver, and by having a mature platform engineering practice much of the requirements for testing, integration, branching strategy, etc. is pre-prescribed for them that they have to adopt. This means allows the team to become proactive to manage 3rd parties for your practices, ensure that demoed code works in your environment (they can't bluff their way) and ensure security requirements are met rather than it being an afterthought.
For CTOs, easing their burden of managing outsourced development they can accomplish their business level goals. As your team shows results, you can increase your influence in ensuring when selecting 3rd parties to ensure smoother operations.
Yes, it is often hard to get buy in even from internal teams to do extra "overhead" work, but by working to implement these 5 areas, platform teams can help CTOs accomplish their goals and ensure they are seen as an enabler, force multiplier and ultimately given more influence rather than just being seen as a road block.
What are your thoughts? Comment below.