What does "outcome oriented" really mean?
Also, automate app modernization analysis and conference CY2024 talks.
The Business Bullshit Dictionary
I’m recording a few tiny videos defining some business-world jargon. “Input,” “outcome oriented,” “politics,” and, here, “bureaucracy.” Once you’ve been in the corporate world for a few years, you stop noticing these words and a few years later, you stop taking them seriously, or at least, in a nuanced way. They’re just part of the noise of the cube-farm. But, if you pay attention to them, they’re often signals that are telling you either to beware or pointing to a problem that can be fixed. Or, they’re just silly, stupid slang people in the office use.
Check out the first one, I’ve got several more queued up for future newsletter episodes.
Modernize THOSE Apps
We're always going on about the right applications to pick when you start modernizing. It's usually a manual process with lots of sticky notes. Now, you can automate it a bit more with this open source tool from VMware Tanzu, the Application Portfolio Auditor. Check out Marc Zottner’s write-up for more!
Wastebook
Well, it wouldn’t be the first time.
Do the Right Thing. Do What Works. Be Kind.
“It’s been clear for quite some time that the early social media strategy of ‘jam a million people in a colosseum and let them fight it out with free speech’ isn’t panning out, but never has it been more clear than now” Jeff.
“You’ve shown us how vulnerable we are to strings of text produced by a machine – willing to believe and put faith in them. Even though you still misspell your own name on your birthday cakes.” Here.
Logoff
I’m trying to come up with a few new talks for next year. So far, I have one on why people don’t want to change and how to address (fix?) that. You know, in the context of BUSINESS, BUSINESS, BUSINESS stuff, not, like, real life. Also one on platform marketing.
I have two issues when with coming up with new talks: (1) I don’t do anything technical, so I can’t, like, code and walk through some new programming thing of Kubewhatever. (2) I’m pretty bored with all the “culture” talks out there. I’ve been consuming that stuff for 20+ years (from the Rational Unified Process, to Agile/XP/Scrum, agile infrastructure/DevOps/SRE/platform engineering and their it’s all about the culture DORAnation, all the corporate re-org stuff from the 90s and my historic reading from the 1980’s, then we have the digital transformation stuff from the 2010’s or so. I know I’m complaining here, but I long for something new and interesting in this space. It feels weird just discussing the same things over and over.
I see a lot of what we’ve talked about for decades (see above) boiling down to just a handful of things:
Get clarity on what the goals, outcomes, “value delivered” is for your organization. You must understand that and guide your daily-work by it.
Understand the end-to-end process it takes to get “product” (usually software) out the door, simply know it and track it!.
Remove waste from the system, “toil” if you like. This is tightly linked with
Automation and “platforms” as we say now. You have to use tools to remove waste/toil.
Team autonomy and “let the person doing the work make the decisions.”
Don’t be an asshole, have a good culture.
We have many different tools and studies for all of this, some are vague and hand-wave-y, some driven by surveys, some mystical and awesome, and some clear and simple. I think the biggest shock for me is that people don’t already do all of this: like, is there anyone who doesn’t already know this and know that it’s the best way to work? What is the deal? What is motivating organizations to not operate like this, how did they get there, and why is it so hard for them to change?
Stories and case studies are still great to hear, so long as they talk about how people changes the organization, convinced people to change, created new corporate artifacts and process - all of that stuff.
There’s some interesting work swirling around in the past year’s worth of developer productivity tracking and metrics thinking and shit-posting. Perhaps a good talk would be something like “is developer happiness really the best way to increase EBITA?” It’d be fun to look at ALL THE GREAT PDFS and dig down into how they connect happiness (flow, autonomy - good culture) to success, and then track the business success of those organizations. Don’t worry, I believe all those studies that say that happy people do good work and that, thus, you should have a good culture. As I’m typing this, I think what I’m missing is the explanation of all the other stuff that you need to do well. In the tech world, there are many instances of companies with good cultures that fail. The goal wouldn’t be to dismiss all these developer productivity findings, but to try to steel person them more for all the finance and non-IT executives out there who’d be like “what an adorable, precious angel y’all are over there in nerd land!”