I theorize about what the “dev” in DevOps has come to mean 15 years in.
Last week I did a three part series on metrics for ALL THE DIGITALZ. Metrics are like anything else: people say your metrics are terrible if they don’t like them, but they tend to like their metrics.
Ultimately, if you’re changing how a large organization works, you have to “manage by metrics.” You also need to manage by “talking to people and thinking for yourself.” I mean, if you’re transforming a large organization YOU NEED EVERY THING THAT’S HELPFUL THAT YOU CAN GET YOUR HANDS ON.
Here’s the three types of metrics I went over.
Are we achieving the non-IT goals we’re here for? How would we know?
They’re metrics like:
- sales/workflow completion
- cost per transaction
- customer experience and satisfaction
For an indirect tracker, some people at TD Ameritrade come up with a way to track business value progress, i.e., “are we progressing at improving things?” by using # of apps deployed on the new cloud native platform (Tanzu Application Service, but you could use “kubernetes”) in dev and then prod. Their reasoning is good:
Traditional development and ops metrics.
- deployment frequency
- lead time for changes
- time to restore service
- change failure rate
There are mostly from the DevOps reports and little bit of SRE. There’s more SRE “golden metrics” that are interesting to contemplate. And the thinking behind “negotiating” error budgets between dev and ops (SRE) is probably a helpful way to think about SLAs (yes, yes – I know – DO NOT EMAIL ME).
How do you measure the state of your organization, the people in it and how they’re operating – “culture.”
These are much more squishy, but you can start with:
- Employee NPS (eNPS)
- Staff belief in leaders, mission, and strategy (do they understand strategy enough to do the right thing?)
- Staff retention and churn rate
There’s some interesting metrics commentary/survey work in a recent VMware sponsored survey:
If you prefer, all of this is written up in a guest column, but in a more serious, no-jokes way and with much less of my face. They’re also written up extensively in my books The Business Bottleneck and Monolithic Transformation.
I started a new, I don’t know, streaming thing today. I’m trying out live streaming every Tuesday and Thursday at 11am Amsterdam time. It was nice – but we’ll see if it matters.
Here’s the recording.
I didn’t monitor myself, so my wires were screwed up and there’s a hum for most of it. Sorry!
And, here’s my “shows notes.” I used miro for this, which I didn’t like. I think I need something simpler. People tell me there’s HackMD. I dunno.
A two part video/podcast, with white-boarding and stuff. Rohit Kelapure knows his stuff from years of first-hand work. If you’re working in an enterprise on software, and especially if you’re an enterprise architect, you should check these out. The real work of application is modernization isn’t rewriting and re-platforming, but it’s the analysis that goes into finding and ordering what to modernize and then the process that runs your program over the next few years. Rohit boot-straps you into that.
Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu’s Rohit Kelapure who’s been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through.