Centralizing and standardizing tools and processes can result in more developer productivity. Our challenge is too avoid going all RUP/ITIL again where documenting that process was followed becomes the bottleneck and the primary, hidden work product.
Plus: YASCS. Yet Another Spotify Case Study.
Original source: Maximizing Developer Effectiveness
I wonder how many problems are hidden from us because we unconsciously dismiss them as 35 year problems…. And I wonder how many of those 35 year problems are actually “a few weeks” problems, if you have enough compute.
…
So what I’m saying is that maybe there is a class of problems which lack the solvability affordance. Because we don’t see them as solvable, we don’t even recognise them as problems.
As new tools are available, revisit your assumptions that problems are too hard to solve, that desires are unachievable.
Original source: [http://interconnected.org/home/2021/01/04/rubiks_cube](Solving the Rubik’s Cube and other hard-to-recognise problems)
Anti-patterns:
Insist on doing everything through “channels.”
Make “speeches”. Talk as frequently as possible and at great length.
Refer all matters to committees. Make the committees as large as possible – never less than five.
Haggle over precise wordings of communications, minutes and resolutions.
Refer back to matters decided upon at the last meeting and attempt to re-open discussion on those decisions.
Advocate “caution.” Advise colleagues to “avoid haste” which “might result in embarrassment” later on.
Question every decision as to whether it lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.
Original source: What can the 1944 OSS manual teach us before we all return to sabotage the office?
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:
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.
Metrics like:
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:
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.
