What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.
DevOps lessons learned: What I wish I knew sooner
Eight DevOps veterans share the one thing they wish they'd learned earlier in their careers. Apply their wisdom to your work
5. Use enthusiasm to your advantage
Carmen DeArdo, DevOps leader, Nationwide: “I wish I had known how powerful the idea of having teams run DevOps experiments and then tell their success stories would be. We know that culture is the key component of improving an enterprise's DevOps capabilities, and we’ve learned that having the teams themselves tell these stories to both executives and to other teams has a significant impact. Executives not only saw amazing results (like automated testing suites times being reduced from two days to one hour, or teams being able to deploy daily instead of monthly), but also saw the excitement and increased engagement from the team itself. And other teams saw that these types of results were possible right here, right now, which motivated them to create their own success stories.”
6. Leadership must model the desired change
Jonathan Smart, head of ways of working, Barclays: “The leadership team needs to be team No. 1. They need to be role models. They need to be the change they are expecting from their organization. This helps avoid cargo cult behavior and just a change of labels without any real change in behaviors or the system of work. And don't automatically start with tooling. Tools may not be your biggest impediment.”
7. Don't underestimate your value to the business
Robert Reeves, CTO, Datical: “A super valuable lesson I learned (later than I would have liked to) is the value of my work to the business. Starting out as an engineer, I placed a very low value on what I did for the business. Of course, it was easy for me and, thus, I thought it was not as valuable as what the people on the ‘money’ side of the company did. Boy, was I wrong.
Thanks to the folks at DORA (and especially Dr. Nicole Forsgren), we know that companies who are high IT performers have a far higher market capitalization growth rate. In fact, those that are high IT performers actually beat the S&P 500! What that means is that the engineers can (and should) have a huge impact on the business’s bottom line.
Had I learned this lesson earlier, I probably would have advocated for what was early DevOps and SRE much stronger and, perhaps, changed the trajectory of those companies. Being a DevOps engineer isn’t just about toolchains and Value Stream Mapping; it’s about gathering data to identify slow points in your release process and having the ability to rally resources to resolve them. Both of these are amazingly valuable for the company and you personally.”
8. DevOps is not a destination
Anders Wallgren, CTO, Electric Cloud: “In effect, DevOps is a process of continuous improvement, it’s not an event or a destination. Then how is success defined if there is no finish line? You’ll know you’re ‘doing DevOps right’ when your organization can confidently release new applications and safely adapt to change at any speed demanded by the business, with the analytics and insight to measure and improve your results. Realizing this early on would have helped in several ways:
- Setting expectations with senior management. One does not simply 'Do DevOps.'
- It eliminates the need to constantly reset expectations of the teams implementing it.
- It also helps mesh with the goals and precepts of Agile development processes, which is also about going faster and better.”
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]