Some friends are coming over around veteran’s day… Time for some pulled pork. 17.3 lbs pork butt from Costco for $2.29 per lb. Using 1.75 cups of Memphis dust, and .5 tsp salt per pound (2.75 Tbsp).
2200 11 Nov: pork is on at 225℉, apple wood chips, red probe on top blue on bottom.
1020 12 Nov: top is at 175℉, bottom at 165℉.
1240: 180℉ top, 171℉ bottom. Bumping temperature to 275℉.
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).