In the unit I am taking command of, we value an environment of continual improvement, agile delivery, and rapid innovation and risk-taking. These are the philosophies and behaviors that will enable us to win, and that will enable our customers to win in competition and conflict against our adversaries. Each of these philosophies and behaviors requires a diversity of thought.
Diversity of thought breaks through group-think. Diversity of thought raises issues early, and solves them more quickly.
I recently finished The Unicorn Project and found it compelling, as was The Phoenix Project. I wanted to document some of the lessons it teaches, because they’re something I hope to keep in mind while leading a software development unit. These lessons are “the three ways” and “the five ideals”.
The Three Ways
My thoughts here are expansions of some of the excerpts at IT Revolution.
Flow/Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Flow/Systems Thinking
Consider the performance of an entire system instead of just a part. One way to look at “the system” is the entire flow of work from product owner, through dev, test, and release into availability for employment. Another way to look at “the system” is as the literal system people are building.
Costco leg of lamb, 4.6 lbs, $5.49 per lb. Slathering it in, per lb:
2 cloves garlic
.25 Tbsp salt (this is a change from the past, when it was too salty)
.25 Tbsp pepper (to match the salt now)
.5 tsp oregano
.5 Tbsp rosemary (my current recipe says .5 tsp but I don't believe it, so I'm trying Tbsp)
.5 tsp thyme
1 Tbsp olive oil
Before a recent off-site the boss set the expectations for the event. This struck me as an extremely useful tool. I particularly liked the ROE - I think stating these early got everyone out of their normal mode of working and into the mode conducive to the event. It seems like developing ROE and purpose like this is good to consciously do for many types of event. It’s not unlike a normal meeting agenda.
You do know what you’re talking about - you are the expert on some things, specifically, the things you’ve experienced. Remember that you know what you’re talking about there. But be careful to not generalize that and override your team because most of the time…
You don’t know what you’re talking about - listen to your experts when they’re describing their situation. They are the experts in their situation, that is why they work with you. Most of the time as a manager their situation is the relevant one. Most of the time they know what they’re talking about.
There are many schools of systems engineering philosophy, but one dichotomy that appears to me more commonly than others. I think of it as a Unix vs Mac/Windows philosophy. I’m writing down my thoughts on that here.
Just a disclosure at the start:
Sure Mac is Unix now, but in the same way that Android is Linux - the philosophies that pervade the builders and users of the commonly recognized forms of the latter are significantly different than those of the former. They’re different.
I’m doing Advent of Code 2022, and Day 16 was - in the parlance of our time - a doozy. The problem presents a cyclic graph with each edge costing 1 second (weight of 1), and nodes have state (on or off), it takes 1 second to turn the node from off to on (default off), and when a node is on it contributes a certain amount of benefit each following second. You have 30 seconds to get as much benefit as possible (function maximization).
I’m continuing to read an Elegant Puzzle and chapter 5 discusses organizational culture. I think it provides some good actionable and concrete ways to think about culture, and most discussion I’ve seen about culture suggests that it is some mostly ineffable quality.
Inclusiveness
Will also thinks culture is difficult to reason about, but suggests two major components for fostering an inclusive organization: opportunity and membership. An inclusive organization is one in which individuals have access to professional success and development.
I was solving Advent of Code this morning and generally thinking about programming when an event from my weekend struck me as an excellent example of the benefits of lazy evaluation. Allow me to explain.
My wife is pregnant, and loves chewing on pellet ice. You know, the kind from Chic-Fil-A or Sonic. Well, it was Sunday and my wife was out of pellet ice, so it fell on me and the kid to go get some.