DevOps Leadership Lessons from a CTO
Q: Do you have a mentor who has inspired or helped your career journey so far?
There are so many. Being in the startup community in Raleigh, North Carolina, has been wonderful, and there are dozens of folks who have helped me in ways they may not even realize. While I could call out specific names, some critical stories shaped my view of the world.
One story comes from a sales leader who spoke at one of my undergraduate entrepreneurship classes. As an engineering student focusing on writing code and developing technical skills, sales was both foreign and uninteresting to me. However, this person shared a story that helped me see things differently.
He recalled a chat with one of his technical co-workers. The co-worker said, “I don't see how you do it.” The salesman replied, “Do what?” The co-worker responded, “Carry a quota. It must be so stressful being forced to sell to eat.” He thought about this for a minute and responded simply, “It is, but if I don’t sell, you don’t eat either.”
This story really helped me contextualize engineering.
You can build the coolest product or service, but if you can’t show the value to the people it will help; you’re just engineering in a vacuum.
Another person who helped me was a mentor who had run engineering companies and divisions and then shifted his career to help people figure out their ideas and find roles at different startups. He coached me through many challenges, but one of the key nuggets he left me with was that most leaders of technical organizations excel in one of three areas:
The “Head Geek,” the rockstar manager, or the key product person. He continued by saying that a successful company needs all three, and a great leader needs to identify who they are, and then they have to hire for the other skills. It’s helped me understand my growth as an engineering leader and where to lean in or lean out.
Q: Can you name three strengths or skills that have been important to your journey?
One motto that I follow is, “Fit in, then stand out.” While it’s quippy, it reminds me that when I am working with a new team, I need to first learn the team. Understanding why things are the way they are is critical in building trust.
For example, if I show up on day one and attempt to implement or advocate for a major change, the default will be resistance, and I’ve made my job harder going forward. It’s important to look for similarities and areas of agreement within a new team before trying to challenge the status quo or make big changes. This approach applies to building new relationships in any part of life.
Another maxim that guides me is: “What people say and do are only correlated to what they think and feel.” While it might sound pessimistic, I love the idea that humans are often operating under a ton of pressure to act or speak in a particular way.
For instance, when you ask someone how their day is going, they almost always reply, “Good,” instead of opening up and really talking about how they are doing. When working with teams and groups, it’s important to pay attention to those pressures to truly understand and empathize. As an example, if someone is reporting to you, it can be hard for them to take responsibility for a mistake if they fear repercussions.
As a leader, it is essential to build and constantly evaluate our environment to foster openness. Otherwise, we may inadvertently build a culture where things can fester within the team and not get addressed.
When it comes to managing teams, people need to be persistently introspective and retrospective in order to develop strong skills. While “looking inward” works for me, it may not work well for everyone, and a good leader needs to recognize the different ways individual people learn and grow.
An effective leader focuses on balancing accomplishment and empathy, constantly reflecting on their own strengths and weaknesses, as well as those of the broader team.
Q: Which skills are you still trying to grow now?
Going back to the advice from one of my mentors, I’m constantly working on the management pillar of the three roles of a technical leader. I've been lucky to work with a coworker who is amazing in that respect and has shown me some key ways to grow and improve.
As co-founder of a tech startup, I’ve focused heavily on technology and products and worked with small teams. Now that our organization is growing, I'm having to grow with it. The craft of management is just as much of a skill as software development.
Q: Let’s talk about having a successful DevOps team. What are the key goals a DevOps team might identify for a digital transformation journey?
One of the most important things I hear from other leaders is having a shared understanding of what DevOps means to your organization. I've seen organizations where "DevOps" means hiring an SRE, calling them a DevOps engineer, and celebrating.
Taking the core components of the DevOps cycle and identifying how work and ideas flow through your development process is a key place to start. Take a single development ticket from inception and follow it through to when it spawns the next ticket, and you may identify some key gaps.
For example, you may find that your QA team is segregated and that you have a “throw it over the wall” mentality that’s impacting your ability to move quickly. Once you start to define that process flow in your organization, you can look at tooling to help.
Many organizations start with tooling and drive organizational change slowly and painfully from there. It’s a backward way to get started.
Q: Are there any challenges or common pitfalls that DevOps teams should consider?
DevOps is a way of working. In many ways, it’s the sequel to the agile transformation that swept the software development industry decades ago. It’s important to think that way. Many organizations struggled with agile transformation due to a lack of leadership understanding and buy-in. Leaders thought that we would start doing standups, and get 50 percent more tickets done. That was obviously wrong in retrospect.
Similarly, leaders today think that we just need a CI/CD pipeline to outperform Dora metrics, and we’ll see 50 percent productivity. The mindset shift is critical. DevOps enables complete ownership of the software delivery lifecycle, which enables teams to build better systems. DevOps empowers teams to identify how to get better and implement it so leaders have to create that space and support to really see the organizational impacts.
Q: How can effective collaboration and communication among team members enhance the productivity and success of a DevOps team, and what practices can facilitate this?
Communication is critical in engineering. Nearly every issue boils down to poor communication and DevOps is no different. Going back to having a shared understanding of what DevOps means to your organization, you have to really understand where you’re going and have that shared vision to have a chance of being successful.
Some of the key practices I’ve seen are defining simple stage gates in your process. These must be about the work, and not the people doing the work. Having defined processes for how tasks and information flow through your team allows you to be efficient at switching, especially when interrupting work shows up, and allows you to scale different parts of your team independently.
Each team and product has slightly different needs, and defining those gates and what needs to happen at each one will help you know where your inefficiencies are.
Q: What role does CI/CD play in DevOps, and what are the best practices for implementing CI/CD pipelines to ensure a seamless and reliable software release process?
It’s critical to get software changes from idea to production as quickly as possible. Manual processes are extremely slow and at the mercy of humans. Humans, while great at things like problem-solving and creativity, are often bad at exhaustively running through checklists hundreds of times a day. Automating the tedious stuff really enables your team to focus on where they excel. Additionally, computers are exceptionally fast and can scale quickly. Creating a pipeline that takes advantage of those capabilities is the main advantage of adopting a CI/CD process.
One key thing to remember when building a process like this is to balance speed with safety. While you can fully automate every commit from a developer going directly to production, that offers no safety. Building your pipeline to allow for that level of speed, and slowly adding in checks can help you in the future. Maybe at first, everything needs to be explicitly signed off on by a QA engineer and a release engineer, but the actual process may just be a button press.
Once you get the automated testing in place, you may be able to eliminate the QA signoff.
Q: How does fostering a DevOps culture and mindset contribute to the overall success of a DevOps team, and what strategies can organizations use to promote this culture among their development and operations teams?
The main battle in this transformation is fighting the “throw it over the wall“ mentality. If you’re new to this journey, you may have five or six teams that have to touch each piece of work before it makes it into production. As you move into DevOps, you’re fostering a shared ownership of the entire lifecycle of that product.
It may require significant shifts in how you design, build, and deploy your solution. While many folks are familiar with creating software that is more testable, adopting a DevOps culture requires building systems and platforms to be owned end-to-end by small teams.
Q: What are the “5 Essential Components of a Successful DevOps Team”? Please share a story or example for each.
1. A shared understanding of what DevOps means to your organization. – One of the most counterproductive DevOps initiatives is if management and the team are misaligned with outcomes. DevOps is way more than just hiring “DevOps” engineers and buying a CI/CD tool. Once you are aligned on the fact that it’s a mindset shift, you empower the teams to truly own the end-to-end delivery of customer value
2. Space and support to identify and implement change – DevOps teams often identify many ways to improve delivery and the efficiency of the team. Not allowing space for this exploration really limits the impact your team can have on driving change.
3. Ways to measure and identify success through data – Everyone is familiar with the DORA metrics, and four key measures you make of your development organization to assess DevOps maturity. While these are a great start, you need to identify what being a DevOps organization means to your business - and you should do that through data.
4. A product built to support ownership and development of this philosophy – DevOps is a great philosophy for many organizations, but often companies are not ready to embrace the transformation. You need to be sure that your product is capable of being supported by a combined operations and development team. Products that are on-prem, products with rigid release cycles, and products that just aren’t at the level of maturity to support such a team may not be good fits. You’ll see some benefits as your team adopts a more operational mindset, but the impacts are limited.
5. Automation and tooling - Ensure things happen consistently and quickly and ensure accountability for working agreements. One of the core changes in a DevOps organization is the working agreements you establish with your team and between your teams. If you are establishing a testing process that requires all code to be regression tested before deployment, you should automate it. You should establish automated checks and gates to ensure that. Once you establish these tools and practices, you often find that lofty goals like continuous deployment are only a few more steps away.
Be sure that that testing doesn’t just run but meets your quality standards.
Q: What emerging trends do you see that could significantly impact digital transformation strategies in the future?
Many of the grand promises of things like shifting to DevOps are based on high-level data and broad outcomes. Oftentimes, these headline numbers, like “your organization is 50 percent more efficient,” are nearly impossible to measure, and it can be difficult to verify that you achieve those types of outcomes.
I expect to see a more focused effort to identify specific outcomes for each organization before starting on a multi-year digital transformation journey. Not only does this align with the increased business efficiency focus of the past few years, but it also ensures success. Instead of broad goals like the ones mentioned, specific (but impactful) goals like “We resolve customer issues 25 percent faster” are more focused.
Fostering Growth Through Mentorship
The power of mentorship and open communication is evident in Jeremy Freeman's journey. By actively learning from others and fostering a collaborative environment, leaders can empower their DevOps teams to achieve great things.
Subscribe to The CTO Club Newsletter for more interviews, DevOps insights, and mentorship tips!