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.
I just recently finished the book Turn the Ship Around, and I don’t have anything insightful to say but I did want to recall some points from it. I found the book to be fantastic and insightful - I agree completely with Captain Marquet’s leader-leader style, and hope in future positions I can remain as committed and mindful as he was to creating environments like the one in the book. I think the practices in the book are very similar to those adopted by agile software teams and mission command leadership styles.
Doing a little more reading about what Digital Engineering & MBSE are supposed to encompass, I looked into DoD Architecture documentation. I’ve seen some “OV-1” documents before, and found them to be intuitive (when they weren’t too dense). I did not know where the nomenclature came from… Now I do.
The DoD office of the Chief Information Officer released the current version of the framework back in 2010. Now - while I think it is still completely applicable, and I acknowledge that perhaps it hasn’t needed any updates in that time… I think the age of this framework since last update probably says nothing good about how well it has been used and loved.
I’m doing just a little learning about Digital Engineering, which seems to be almost synonymous with Model Based Systems Engineering (MBSE). The concept of MBSE is that, in contrast to more traditional methods where the team-of-teams creates documents to coordinate all efforts (think long contract-style English text), the team creates a variety of models. Some of those models would be UML-like diagrams, others might be executable. Each model interface provides a view on the underlying data & model - a view useful to some of the development teams for understanding what must get build. All done in digital formats sharable among all teams. Those might even translate automatically into some of the same documents from the contrasted method.
16 lbs of brisket from Costco at $3.99 per pound (and people act like brisket is crazy expensive…), 15 lbs pork butt at $2.29 per pound, 4.87 lbs top sirloin at $5.99 per pound, and about 5 pounds salmon at $11.99 per pound.
I’m going to try to cook the brisket and the pork butt at the same time… I think it’ll fit and not overload the smoker, but I’m a bit worried about that. On the brisket I’ll use 4.5 Tbsp salt, 4.5 Tbsp pepper, 2.25 Tbsp garlic powder. On the pork butt I’ll use 2.5 Tbsp salt, and about 1.5 cups of Memphis dust.
This tutorial will cover the topic of creating Internet-accessible and non-Internet-accessible EC2 instances within the same VPC, by hand within the AWS Console. At the end we’ll have one Internet-accessible Linux box which will be able to talk to a second, non-Internet-accessible Linux box. The instances will be accessible on ports 22 and 4000 from anywhere.