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.
If Mark hadn’t decided on these OKRs, what would you all have planned to do next quarter?
While Mark’s vision was inspiring, [one team member] felt it was unrealistic. […] They would be working 85 hours per week. […] He had badly underestimated the lag time in a system that made work less efficient than it should be.
While Mark’s proposed goals made sense in theory, his team knew there were major obstacles that made his plan impracticable.
I’m continuing to read an Elegant Puzzle and chapter 3 had some good considerations regarding defining teams and groups during a reorg that I think are good guidelines for building teams more generally:
Consider team sizes and management spread.
Can you write a crisp mission statement for each team?
Can you define clear interfaces for each team?
Can you list the areas of ownership for each team?
Is each responsibility owned by a team?
Would you personally be excited to be a member of each team, as well as to be the manager?
Put teams that work together close. Especially if they work poorly. This minimizes distance for escalation, and reduces info gaps.
Are there compelling candidate pitches for each team?
Are you over-optimizing on individuals, vs establishing a sensible structure?
I’m reading An Elegant Puzzle: Systems of Engineering Management, by Will Larson, at the recommendation of a good friend, and wanted to take some notes on it.
First, the book is gorgeous. I’ve got a hardcover copy via inter-library loan (thank you Meridian Library District, near Boise, ID, and thank you San Antonio Public Library), and the cover is bright white rough linen with black text and printing, and a black line drawing of a bush on the front cover reminiscent of an organizational structure, data structure, or actual organic bush. The back has only the printer’s logo and name in black print. The chapters are nicely printed on full pages, which makes them easy to locate in the book. Also easy to locate are the figures, which are on bright yellow/orange pages, while the other pages are bright white and slightly thicker than book pages I’m used to. The references section in the back is broken out by chapter, and instead of the usual bibliographic BS there are URLs with QR codes. I’ve long felt it’s time to move away from standard bibliographic formats, especially ones where URLs are optional, and to something that emphasizes easily accessing the relevant data digitally. (Although, URLs break, so I would include some information with the URL, and for a book I might have a separate website with the full information…) So I’m enjoying just holding this book. It also seems informative.
Reviewing some of my notes from the Leader Development Course I noticed something I’d written regarding communication plans. My take on “approachability” is something I need to explain to my folks early, actually.
Weapon school grads want to be, “humble, approachable, credible”, and this has always been what I’ve sought to be too. I don’t always succeed I’m certain.
Approachability can be quantified by how my team interacts with me. I need to let them know that to me approachability really is important.