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.
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)
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.
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.
Business Metrics
Are we achieving the non-IT goals we’re here for? How would we know?
They’re metrics like:
sales/workflow completion
adoption
awareness
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:
DevOps/Technical Metrics
Traditional development and ops metrics.
Metrics like:
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).
Culture Metrics
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?)