There’s been a lot of keys typed about what’s happening now and what’s to come. My personal experience has been a pretty similar one to what I hear from friends, family, and the tech media in general, but it’s been such a powerfully transformative one that I still feel the need to write about it as best I can, even if the same thoughts have been described many times before by others. The change in thinking, the new perspective, trying to think about a world where this technology can continue to accelerate at breakneck speeds; it’s almost too big to really think through without trying to put thoughts to paper.
The most simplified version is: I have routinely been getting less sleep at night. Not because I have “The Fear” about an upcoming AI doomsday scenario (as referenced in The Thinking Machine), but because I’m just having too much fun at night playing around with the tools. I mean, it’s really incredible - every day, I have passing, transient thoughts about some cool project, or an interesting idea, or a question I haven’t pondered before. Most of the time, these are dead-on-arrival - maybe for the most engaging ones, I spend a weekend hacking at something and then I just realize it’s too much work for the payoff. I have gone through the end-to-end process before (check out some early blog posts of mine on things like varints in rust), but the ratio of ideas to tangible outputs has traditionally been rounding down to zero. Now, however, I can just fire off a couple of prompts and get something that works - which is just simply incredible.
I’m not talking about within the workplace - that’s a topic for a dedicated post - but personal projects. Some are fun, some are “art”, some are useful. Some get thrown away, but those have helped me actually understand why some software / tools I may not have appreciated fully before are actually the best form factor for a problem (I have tried four or five times to build a TODO app that’s catered to me, and it turns out a post-it note is amazing for 90% of the tasks I tackle in my life).
A lot of chatter has been about whatever world we’ll arrive at over the next few years has been around what humans will do with their time when we’re freed from all of our menial tasks and labor. I know with my extra time, at least for now, I’m trying to action on all of those previously bottled up idea fragments and start to see where they go. It’s a lot of fun! It’s freeing - and almost scary - in thinking about the possibilities when the cost of something goes to zero. Previously, those limits were good excuses as to why one couldn’t pursue this thing or why so-and-so was impossible. I’m finding that I’m increasingly running up against (and grappling with) the real reason why I may not have pursued a passion or evaluated an idea, which before was previously just shrouded in something taking too long to do.
My apologies if these thoughts aren’t coherent or insightful, and they’re certainly not mean to share a message or push a narrative other than a snapshot of what now feels like. I know June 2026 feels completely different from June 2025, and I’d wager a year from now will even more foreign. The ramifications are so big, the spectrum of outcomes so wide, and the writing helps as a thinking process. It feels like chopping at a tree of understanding, and each swing of the axe from a different angle cuts a little closer to been able to really grasp the collective change (and excitement or fear or whatever) we’re all feeling in some way.
]]>The market is starting to realize this, selling off a bunch this week after Anthropic rendered a category of applications effectively useless with its legal tool (AI is Killing SaaS). There has been much chatter about the AI bubble fueled by CapEx investments, but in comparison much less about the long-term effects on companies like Figma & ServiceNow, down 80% and 45% in the last year. What’s holding SaaS up is inertia and distribution (and, let’s be honest - security, compliance, exec trust, etc. aren’t going away in the short-term and will keep the status quo going for awhile).
Work is starting to realize this. Whether we like it our not, every business must assume our competition (both currently existing and yet to come) will be fully equipped with AI tooling both augmenting and authoring code (and eventually everything else). Maybe there is some counter-positioning strategy advantage that comes from being mostly hand-written code, but currently the arms race is fully engaged. The feeling is existential - we must adopt or die. At an individual level this changes the workplace dynamics significantly, but both the good and the bad news is that almost all developers are aware. The good is that that everyone is undergoing this massive change at the same time and we’re all in this predicament together, so all starting from the same piont; the “bad” is that rather than being an opt-in accelerator (traditionally, this might be spending free time building projects, taking courses, etc.), it is functionally a requirement just to keep pace with peers, and all of your peers. Bad might mean “painful” here if you’ve excelled in the previous way the software workplace worked, or just don’t like AI; there is almost a career-switch level of change that might be required for some folks.
Individuals may be starting to realize this too. Clawdbot / Moltbot / OpenClaw went viral this past weekend. Most of the hype was around Moltbook, and it seems like that might’ve been faked to some degree, but the main takeaway here will be the mindset shift for folks who watched or participated; it went viral for how believable it was, because the leap from where we are today to a world of OpenClaw agents is just a small step and probably inevitable to some degree.
What’s most exciting to me about this shift is also about the impact at the individual level. It’s the potential for just-in-time personalized software: if you have an idea, just build it. No reason to wait to build it either - just build it as soon as you have the idea. Leveraging AI coding tools paired with AI interfaces allows for compressed creativity, where the main limits are a properly setup automated build harness, a bunch of tokens, and coming up with ideas. The constraint of time no longer exists.
There are so many small tools and/or utilities that could be built that may be helpful:
I mean, there’s nothing revoluntionary there. A few of those are probably technical interview questions for a mid-level engineering job. They definitely could’ve been built at any time over the last 10 years.
Software has always enabled us to build personalized tools. It’s just that before, the ROI was just not high enough for the time & maintenance. And, who knows if by the time it’s finally built, I’d really even care that much about it anymore (my diets typically last all of two weeks!).
The scarce resource is no longer time, because that’s outsourced to Claude or Codex or something else. Paired with a Ralph Wiggum approach or a Gas Town (I am only Stage 6, so not quite to Gas Town levels yet), you can kick something off before bed and wake up to it baked (maybe half-baked) in the morning, and start to actually use it pretty shortly after. I can easily envision in a year’s time running the rote or high activation energy parts of my life with a bunch of small automated utilities. Building on top of that, there are many areas of enrichment that I’d like to do, but can’t due to a lack of time (and poor time management). It’s pretty exciting to think about what happens when lack of time is no longer a reason not to do something.
Personally, my list of project ideas has always been way longer than my ability to complete them; now, that’s no the case.
]]>One of my most opinionated stances is that any software developer that’s a SWE II+ must have a good command of git. “Strong command” at a minimum means things like: using git through the command line, understanding the basic commands to stage/unstage & commit, understanding the difference between a squash and a merge. I would expect a SWE II to know about (and maybe even have used) reflog or bisect if they’ve gotten into a pickle. They should be utilizing git as the wonderful, critical tool it is.
With that, I have strong opinions about how commits/branches should be sequenced, sized, and applied. The general framework is at the bottom of the post, but it’s all centered around atomic, isolated, squashed commits into the main branch.
I’ve found that this approach is pretty contagious and gets adopted pretty quickly if I join a new team, without needing to explicit convince others to follow along. By just modeling the behavior myself, the usefulness becomes self-evident once someone’s tracking down where a bug came from or needs to revert a specific change. It’s the closest thing I have to a religious belief about software development.
That was all until agentic AI workflows, and AI programming tools in general, came to prominence. The cost of writing (generating?) code has effectively dropped to zero, and even the method in which that code is written has changed in such a drastic, structural way. It has completely upended the harmony of my git workflow in at least two dimensions.
First, the bottleneck in the feedback loop has shifted from writing the code to the review + deploy process. Taking the extra effort to split branches and limit the changes in each eventually-squashed commit was infrequently the bottleneck in the end-to-end development process - the time to write the code for one change was usually in the ballpark to get a review for something else you had worked on and in review. Part of the point was to make it easy for a human to review by keeping it small and as simple as possible.
Code Review is also not just a QA process to ensure code looks good, but it is also an information dissemination process at both the specific project level and the generic technical level: engineers could share ideas and approaches with those around them as a passive byproduct of working those techniques into their changeset. Code Review allows each engineer to engage in someone else’s thought process, to be a participant in a professional “show your work” process. The best techniques rise to the top after rounds of meticulous review and being able to empirically see how they perform in the wild. It’s a natural way for a team to get better just by learning from each other.
Now the balance between those two processes are out of whack, and the act of writing can be much faster than reviewing. That doesn’t devalue Code Review, and likely makes it more important, but it changes the incentives and metrics a bit. As the speed of code generation is at an entirely different scale than human-written code, the opportunity cost of not writing code feels that much higher (that is certainly the message being delivered within the mainstream software / entrepreneurship culture, however you feel about it). You can also imagine someone taking the stance: who cares if you deploy a bug if you can just vibecode the fix?
It’s unclear where the new balance around code review will rest, but there are still many blogs to be written on the topic over the next few years.
Second, the parallelization of work was roughly limited to the number of developers on a given team. By producing atomic commits, separating refactoring from behavior changes, etc., git conflicts between developers could be kept to a minimum and, when they happened, dealt with just a little extra effort. A little bit of planning ahead of time allowed every developer to work without fear of clobbering something that someone else was working on.
Well, the number of developers is clearly not a real limit anymore. Building in parallel with Claude or Cursor is becoming the default, not counting the ticket-based fully autonomous agents, the chatbot interface PMs and commercial folks can use, and all the other form factors that will emerge over the next few years.
Maybe this more of a function of how mature the code base is, and heavily AI-built projects tend to be earlier on where larger changes are needed as basic entities and themes are still in flux, but a persistent problem I’ve run into is AI processes have overlapping scopes, resulting in pretty gnarly conflicts that take awhile to untangle. I run into this on solo projects, so it’s hard to imagine anything beyond a two-pizza team not having this be a nagging issue producing a significant drag on the team.
The reliable old approach seems to need rethinking. The unfortunate bit is that I don’t know what the solve is. I’m not advocating for totally abandoning this approach that has worked so well, but it’s become glaringly obvious that there are some real downsides to consider in this new world.
When development was human rate-limited, it was clear (IMO) what the best approach to git was. Now, the underpinnings of my git doctrine are shifting, I’m having a bit of crisis of faith, and I don’t know the righteous path forward.
Truthfully though, it’s a bit exciting. A bit freeing. It’s nice to be unburdened, to break some rules, to reject the ascetic approach. A software rumspringa. That’s what’s so great about these AI tools - they’re making software development fun in ways it hasn’t been for a long time. They’re allowing us to focus on bits that we haven’t been able to for quite awhile. For right now, that seems to be the most important thing - we’ll figure out the rest later.
My general git framework:
main should be squashed into a single commit. This allows the history of the main branch to match reality (i.e., what actually deployed and in what order), and allows for easier identification and reversion if needed later.main branch should be a complete but atomic change. That can be at a bugfix, chore, or feature level, but they should consist of a single, isolated change that is as complete as is reasonable. There should be one purpose of the commit.These have come out of a decade of writing software within teams and working solo, and the many hours spent tracking down the source of bugs, reviewing code, dealing with merge conflicts, minimizing overlapping work, orchestrating deploys, rolling back bad changes, etc. All the things that make software fun. Time & time again, it is always easier to deal with atomic commits that clearly have a defined, isolated purpose. It makes life generally, and cleaning up messes specifically, much easier.
]]>In managing interns, new grads, & even all the way up to senior engineers, I always share this advice. The checklist is such a simple tool but it can prevent so many issues and help accelerate learning & impact.
In the case of early-career engineers, a checklist sets up a healthy habit of tracking assigned work. Having the understanding of what work is relevant, how much is remaining, and in what order it should be done (or, having to do at least some prioritization within the checklist) all sounds straightforward, but that understanding is frequently missing for early-career engineers. The checklist provides the necessary guardrails around task management so that early-career engineers can focus on the important bits of learning at that stage, which is actually getting their hands dirty with implementation. It eliminates a whole set of variables around the overhead of getting work done, not the actual work itself.
A checklist is also a positive feedback mechanism, where an early-career engineer - often beginning with a thin layer of self-confience - can feel the satisifaction of finishing pieces of work when they’re able to mark them off the list. The act of physically marking something of the list, and eventually owning a checklist with many items crossed off, helps snowball positive momentum and build self-confidence for that engineer. It’s a visual representation of all the effort that they’ve put in.
For more experienced engineers, the checklist is about stabilization and continued alignment with previous decisions. Think of it as dumping state for later. The effect of the checklist for a grocery store run is the same effect during the workday; one can’t be expected to remember everything, so the checklist is a way to communicate from our past selves to our future selves. This becomes increasingly important as one moves through their career: directions get more ambigous, managers / tech leads supervision becomes more hands off, and context switching becomes the norm. In the ever-increasing din of noise, having a steady checklist to set orientation becomes invaluable.
There is a point where a checklist can actually become harmful. Like any tool (Maslow’s Hammer, etc.), overreliance can yield less-than-optimal results. The checklist is fantastic for tactical thinking: what needs to get done in the immediate term & in what order? However, the further along in one is one’s career, the more strategic thinking & creativity is required.
Strategic thinking runs counter to tactical approaches - it extends beyond the short-term, and needs to incorporate the broad array of objectives with a set of imperfect information to build medium- to long-term plans. Checklists are all about rigidity and structure, while broader roles such as Staff Engineer, Tech Lead, etc. need more latitude and creativity to solve broader and more complex problems. In those roles, overreliance on the checklist to do one’s thinking for them can mean that they’ll missing the forest for the trees.
Once the habit of keeping on task is fully embedded in the way one works, the training wheels of the checklist can safely be taken off. Senior+ engineers should throw off the rigid yoke of the checklist (and, if they’re Senior+, likely already have) and embrace a little more gunslinging. However, when the seas become rough and the ship feels like it’s beginning to list (no pun intended), falling back to a checklist to can be helpful to steady the ship and calm the waters.
The checklist is often underestimated as a tool, but proper use of it can yield consistently strong results. For early-career engineers, it’s a secret weapon that provides focus and clarity. As engineers grow in their career, it can continue to be relied on to keep track of context and owed work as ambiguity and context-switching becomes the norm. Eventually, the checklist might become too constraining as longer-range thinking is required in certain roles, but it’s always a helpful fallback to steady things when situations become too chaotic and need structure and clarity.
]]>We spent so much time putting together the nursery, taking care to pick out the right crib and wall color. We sat through all the appointments and scans. We excitedly planned our little one’s entire future, listing all the trips we’ll definitely take and activities they’ll of course excel in (all-star soccer player, first chair in the concert band, winner of the science fair, Shark Tank participant, reading 2 grade levels ahead, etc. etc.).
We also naively shrugged off all the “warnings” from friends who were already parents about just how big of an undertaking the first few weeks (and, the next 18+ years) can be.
The first few weeks of parenthood is exactly how people describe it, but you don’t really get it until it’s actually happening. When folks would say “no sleep”, I didn’t realize that - at least for the first few days - that was literally no sleep. Our hours of sleep at night have gotten slightly better after the first few days, but it’s still severely lacking. Even with perfect sleep, everything would be overwhelming - each day is a new set of lessons, each routine you think you’ve nailed down changes underneath your feet - so the noctural behavior is an impish multiplier. Exhaustion has taken on a whole new meaning.
We’ve felt extremely lucky with how things have gone so far. The first few weeks have an incredibly rewarding challenge. There is nothing else like it. We’ve marveled at seeing our child increasingly recognize the world around it, each day understanding a bit more than the previous day. Every moment has been new and wonderful and demanding and captiving all at once in different degrees. Each day reveals something new for us to tackle, learn from, and apply going forward.
It’s only been a few weeks, but there have been a couple common sense principles that have helped us navigate this new world:
There’s really nothing to prepare you for:
In the fog-of-war that is the week post-birth, I wrote this to a friend that checked in on us:
There’s a moment too, in some random act - maybe realizing you need to coordinate with your partner on if you can step away to simply fo to the bathroom or grab some food, or you notice something odd in how they’re moving their head, and the entire weight of this child’s life comes crashing down on you. You knew in theory that your light would be exhaustively altered by this child, but when ou’re faced with the reality in the moment that this is complete and comprehensive, that there is no vacation policy or coffee breaks, you spiral for a little bit. After a day or two your brain works through it, but it’s an Atlas-like realization. It makes you really appreciate having a partner to go through this with and help shoulder the load together, and you get a blank check of sypathy for all situations more complex than your current one.
The challenge of the journey so far has been the sweetest that I’ve ever experienced. Everything now feels so natural and just clicked into place. You will rise to the occasion. But, the initial shock from the transition of theoretical to concrete parenthood hits like a polar plunge.
Preparation is so key - don’t leave anything for when the birth comes. We had an ill-timed bathroom reno that needed to be done, and it still needed some painting and cleanup after the baby came. It sucked to have those few hours each day to finish the project and not be just focusing on my child or learning how to be a parent. So, don’t start any projects that aren’t guaranteed to be completed before the birth.
But, all the suppliers we’ve needed - bassinet, stroller, floor mar, both short-sleeve and long-sleeve onsies, velcro swaddles & sleep sacks, diapers, wet wipes (get so many wet wipes), changing table, pads for the changing table, saline drops, spit up cloths, etc. - it’s been so, so nice having all those ready to go. Having needed supplies at the ready provided a much-needed level of stability during the chaos of the first few weeks.
The nights oscillate - some we work the graveyard shift, others we’ve managed a few spurts of consistent sleep. When we get any sembelence of shut-eye, we feel on top of the world. There’s an extra gear that we have during the day, and the typically frustrating times of extensive crying or not being able to follow our set routine are handled much more gracefully. There’s been a big push around better sleep routines over the past couple years, and now I understand why.
Parental duties are constant, and it will be hard to get a sustained period of time to run errands like the old days. The 2-minute rule really applies here. I was always someone who batches errands all at once, but it required a block of time to do those errands which just simply isn’t available anymore.
It’s pretty straightforward. Do things immediately as they come up. Dirty dishes go straight in the dishwasher or are cleaned by hand in the sink. Collect laundry (there will be a many small items like spit-up clothes, onesies that get directly, bassinet sheets, etc. that require cleaning each day) and do it in the morning. Put clothes away as soon as they’re. Schedule pediatric appointments and put them in your calendar right away. Messes are dealt with immediately. Take out the trash as soon as it’s full. Get ahead of filling humidifiers, organizing supplies for the upcoming night, prepping food, etc. when you do get some longer periods of “downtime”.
It’s nice to exist in as much of a clean, structured environment as possible while everything else in life feels upended.
pa·tience /ˈpāSH(ə)ns/ noun the capacity to accept or tolerate delay, trouble, or suffering without getting angry or upset.
There are two forms of patience that have emerged.
The first is easy to imagine: staying cool and collected, proceeding methodically with the task at hand, when sleep-deprived, operating in low-light, on a screaming, crying, and fidgety subject that is incredibly sensitive to any sensation. Patience is learned, and it becomes quickly understood that any internal frustration just interferes with a thing that must be done. Changing a diaper or putting on a onesie cannot be avoided, so handling it with grace and cheerfulness (easier said than done in some situations) makes it a much better experience for everyone involved.
Second, there is the more abstract patience-with-self. This is a completely new phenomenom in the sense that someone is utterly dependent on you growing and learning and achieving a level of competence.
It has been a long time since I have felt the utter hopelessness that came with the first time changing a diaper. It was the first few hours of being a dad, and I questioned the basic premise that I could even be a dad in any capacity. Thankfully, that was the low point. Since then, generations of instincts have slowly conspired to turn me into a better caretaker.
Everything will come in time. I have evidence - within the first day or two, there were two different pictures snapped of me 12 hours apart. Both show me nominally doing the same thing of holding my newborn. In the first, I’m tense & clearly uncomfortable, clenching my teeth and all; it looks like I’m carrying something radioactive. In the second, my body is relaxed and nearly carefree, and I’ve got this huge smile on my face. 12 hours! That’s how quickly it all changed. That transition has given me confidence over this whole experience that I will learn what I need to learn, and I can’t expect myself to be an expert from the jump.
In extremely simple terms, not unlike a [Tamagotchi](https://en.wikipedia.org/wiki/Tamagotchi), there is really one main communication channel for child to parent1 This is a gross oversimplification, as there are a million little signals that you begin to detect patterns against that can help inform you what’s going on. Are their eyes open or closed? Are they moving their mouth in a certain way? When is the last time they ate or needed a change? Each permutation is a little fingerprint that maps to an outcome, although the hard part is that that mapping is constantly changing.. The vocal cry of a newborn is not a warning but an alarm; something is already wrong or past the threshold of comfort, and it is up to you to figure out what. There are really only a few main options to check through, and I’ve found it helpful to work through this list and eliminate choice by choice to narrow it down. If you reach the end of the list, you’re in uncharted territory - good luck! You’ll likely find something to add and prioritize within the list.
There will definitely be things added to this list over time. We’re in the early stages of just figuring it out. So far, however, applying the scientific method has helped us quickly detect and resolve situations as they come up.
]]>The superpower is simple: the ability to experience everything as new.
Much like a toddler that has entered the “why” phase, a new hire can experience the world for the first time, and ask a simple but powerful question: “why is this thing the way it is?”. The new hire wants to understand the system, and to understand best is to determine the reason for something’s existence.
The concept is simple, but the effects can be quite powerful if acted upon. The simple process of asking “why” is really a challenge to the conventional wisdom of the organization. The “why” then requires explanations about processes or policies that may not have been examined holistically. Instead, those processes and policies have grown organically, twisting into form not through a straight line but a series of decisions that may have been reasonable in isolation but when tested in aggregate no longer hold up. The answer to the “why” may reveal that the intended purpose of the process or policy is not really being served. If there is no good answer (or, possibly, no real answer at all!) to the “why”, then it’s maybe time to consider whether this thing is really just a vestigial structure.
Why is this superpower limited to new hires?
Primarily, new hires don’t have any expectation about how things work, so all processes are evaluated with completely new eyes. There is no context or history that may fill in the gaps for the new hire. They have no concept of the existing organizational structures that may make it obvious to others why a certain policy is in place.
For folks already working within the organization, certain practices are just normal. After working for long enough, it’s just become the expectation that this is how things work - which, in extreme scenarios, may seem crazy to new hires. For a new hire examining a practice for the first time, they may not be able to fathom as to why something is the way it is. But, organizations are living organisms, and new processes or precedents sprout up in response to specific situations. The impact from a incident or previous failure may be dwarfed by the lasting reaction. Much like a human body, the company will remember the scars and bruises it absorbs; however, the healing process may result in the wrong cure being used, whether through the wrong prescription, or the right prescription but the wrong dosage. After the cure is applied, the organization reaches homeostasis, and without a catalyst for change things will stay as they are.
The new hire can then be a catalyst for change. In addition to the superpower of examining everything without prior context, the new hire likely has a set of tools in their belt that others don’t: the time and lack of existing responsibilities to do something about it. Unencumbered, the new hire has more free time to play free agent.
This “free agent” role is unique to the new hire. For existing team, there can be a willful ignorance to certain issues because of a lack of time or resources. Acknowledging a problem exists then means it must be solved. Naturally, that problem falls onto the person or team making the discovery. If that problem has existed for a long time, that implies that there have been workarounds and alternate paths discovered. The organization has learned to work with the foreign body, rather than work on expelling it. This implicit acceptance of the issue means that the problem is not seen as an obstacle stopping progress, but rather just an occupational hazard of getting work done within the organization. If a team acknowledges said problem, it becomes their responsibility to fix it. As the problem hasn’t been seen as a showstopper, there is no organizational incentive to fix it, spending valuable resources fixing an “non-issue” costs political and organizational capital.
However, the impact that this issue was having on the team will only be recognized and acknowledged post-hoc. Once the issue is resolved, leaders will question why such a decision wasn’t made earlier, because it will seem so obvious in retrospect. But, the inertia of the organization meant that no one ever got around to solving the problem. The new hire, without being swept in the current of the organization yet, is allowed to find the problem and focus on fixing it.
For new hires, the ability to earnestly ask “why” and seek to understand is simple but extremely powerful. Asking “why” may result in an unsatisfactory answer; an unsatisfactory answer means there’s a great opportunity to fix or change something. Questioning things with a perspective untainted by context is an effective way to dissolve parts of the system that have become calcified, useful, and occasionally harmless.
As a new hire, a recipe for early find something that you think is broken (or that other people metnion is broken, but don’t have time to fix), and go and fix it. If you find the right thing to solve, fellow engineers will love you, and managers in turn will sing your praises to other leaders and the rest of the team. It’s a great way to make a good first impression and also have an immediate impact on the organization. There is also a snowball effect here - proving that you can have an immediate impact to the organization in ways seen as unconventional to the team will give you more leash to continue to do the same thing, and fix or remove those issues that are past their expiration date.
Note, however, that there may be solid, well-thought out reasons why things are the way they are. There could be a number of reasons - it may be that you don’t fully understand a complex process, or that coupling means that the cost of fixing something makes it no longer worth it - so make the assumption that people have acted in good faith and have done the best they could’ve in the circumstances.
Unforunately, after awhile those zany processes will start to become normalized. Your superpowers will wear off as you understand more of the business and context. You will slowly be able to reason out why things are the way they are (those reasons may not be wise, but they exist nonetheless). It is a natural and necessary reaction as you learn how to work effectively within the existing organization.
However, you can still do your part by encouraging the new hires that you in turn will influence, work with, and potentially manage, to not be afraid to discover why things are the way they are, and to work toward eliminating the processes, practices, and policies that no longer make sense.
]]>My last substantial blog post was from June 2021, more than over a year ago. Since then, a bunch has happened which has reduced the amount of time that I have to spend on writing close to zero.
As things are settling down a bit, I’ve been coming up with a bunch of things to write in my head, but haven’t had the time to put them down on paper. So, here’s to the back nine of the year being a bit more productive on the content side…
]]>Some possible adjustments:
be more realistic :)
Introduction
On any team, in any organization, all responsibility for success and failure rests with the leader. The leader must own everything in his or her world. There is no one else to blame. The leader must acknowledge mistakes and admit failures, take ownership of them, and develop a plan to win.
This means taking ownership over everything that impacts the mission. I’d subordinates aren’t doing what they should, the leader must explain the strategic mission, develop the tactics, and securing the training and resources necessary. If individuals are not performing at the level required, they must be coached up and mentors. However, mission and team come first, and a difficult decision must be made to terminate them and hire those who can get the job done.
Total responsibility for failure is a difficult thing to accept, and taking ownership when things going wrong requires extraordinary humility and courage. But doing just that is an absolute necessity to learning, growing as a leader, and improving a team’s performance. Leaders must set ego aside. Such a leader does not take credit for the team’s successes but bestows that honor upon junior leaders and members.
With Extreme Ownership, you must remove individual ego and personal agenda. It’s all about the mission. How can you best get your team to most effective excite the plan in order to accomplish the mission?
Leadership is the single greatest factor in any teams performance. Whether a team succeeds or fails is all up to the leader. The leaders attitude sets the tone for the entire team. The leader drives performance - or doesn’t. And this applies not just to the most senior leader of an overall team, but to the junior leaders of teams within the team.
One thing I didn’t quite get: there was a section on “carrying along mentally weak performers”. But, the focus is on the mission at hand, which for the boat crews was completing hell week and trying to win races. Did those performers not participate? Afterward, the leader Leif insinuated that he talked to other people on the boat crew and they realized there were mentally weak people that they didn’t think were up to the standards. That does not seem like proper leadership - that seems like pointing fingers and casting blame, even when the boat crew as a whole performed well.
It’s not what you preach, it’s what you tolerate.
Leaders should never be satisfied. They must always strive to improve, and they must build that mindset into the team. They must face the facts through a realistic, brutally honest assessment of themselves and their teams performance. Identifying weaknesses, good leaders seek to strengthen them. The best teams are constantly looking to improve and push standards higher.
In order to convince and inspire others to follow and accomplish a mission, a leader must be a true believer in the mission. Even when others doubt and question the amount of risk, the leader must believe in the greater cause. If a leader does not believe, they will hit take the risks required to overcome the inevitable challenges necessary to win.
A leader must ask the question why? Why are we being asked to do this? When an order comes in. Deconstruct the situation, analyze the strategic picture, and come to a conclusion. If one can’t be reached, ask your the chain of command until they understand why.
Ego clouds and disrupts everything: the planning process, the ability to take good advice, the ability to accept constructive criticism. It can even stifle someone’s sense of self-preservation. Ego can be a good thing - it drives the most successful people to be the best. However, it can prevent us from seeing the world as it is and can become destructive.
When personal agendas become more important than the team and the overarching mission’s success, performance suffers and failure ensues. We must operate with humility.
Simply comes down to teamwork: smaller teams within teams can become so focused on their own task that they lose the greater meaning of the mission. Teams might then start to compete with each other, or animosity develops when obstacles occur.
Keep things simple. Start simple. Complexity is to be avoided at all costs when it can. It leads to miscommunication, difficult situations, and higher chance of failure. Simple, not easy.
The greatest of challenges can overwhelm leaders. That risks failing at all of them. What a leader must do is step back from the emotional reaction and determine the highest priority from the team. Rapidly direct the team to marshal resources. Then, determine the next priority and so on.
Relax, look around, make a call.
No single person has the cognitive ability, physical presence, or knowledge of everything to enable them to effectively control every maneuver, every position, or personally manage every person. Decentralized command allows junior leaders to lead from a tactical standpoint while others can take a strategic look at the situation.
Junior leaders must be empowered to make decisions on key tasks necessary to accomplish the mission in the most effective and efficient manner possible. Teams within teams are organized for maximum effectiveness for a particular mission. Every tactical-level team leader must understand not just what to do but why they are doing it?
Junior leaders or team members do not operate on their own program; that results in chaos. Instead, junior leaders must understand what is in the scope of their responsibilities. They must communicate outside their authority to make recommendations, and also pass critical information up the chain so senior leadership can make informed strategic decisions. Junior leaders must be proactive rather than reactive.
Senior leaders must trust their junior leaders, and junior leaders must be able to feel that trust to confidently execute.
When leaders try to take on too much, operations can quickly dissolve into chaos. To fix this is to empower frontline leaders through decentralized command.
The best teams employ constant analysis of their tactics and measure their effectiveness so that they can adapt their methods and implement lessons learned for future missions. Analysis addresses the following: what went right? What went wrong? How fan we adapt our tactics to make us even more effective and increase our advantage?
A checklist for planning includes the following:
Leaders posses insight into the bigger picture and strategy, even when they are immersed in the planning of tasks, projects, and operations. This information is not automatically translated to junior members of the team, who are usually focused on their specific task implementation. They do not need the full insight or knowledge of senior leaders, but it is still critical they have an understanding of others roles, and how the mission contributes to big picture success.
This is often not intuitive or obvious to rank-and-file as leaders expect. Leaders must continually communicate with team members about their role in the overall mission. Saying something once does not make it so. Leaders need to communicate the bigger picture in a clear, concise way that team members can understand.
Leaders need to lead up the chain as well. The leaders above have more strategic overview, and are also not mind readers with the details, plans, and daily activities of the team - that must be communicated to them.
Leading up the chain requires tactful engagement with immediate bosses to obtain the decisions and support necessary to enable your team to accomplish its mission and win. It takes more more savvy and skill, as the leader cannot fall back on positional authority. Leaders must also understand that their superiors are allocating with limited resources, and that the team may not be the current priority or senior leadership has decided to go a different direction.
Leaders cannot be paralyzed by fear - that results in inaction. It is critical to act decisively amid uncertainty, to make the best decisions based in only the immediate information available. There is no 100% right solution. The picture is never complete. Be ready to make decisions promptly. Then be ready to adjust those decisions quickly based on evolving situations and new information.
The first discipline test is one of willpower in the morning: when your alarm clock goes off. Do you get out of bed, or lie back in comfort? Getting up early makes more time for you to work on what you want, to train, to improve. You are making time for yourself.
Discipline is a battle against taking g the easy road. Discipline demands control and asceticism, but it results in freedom. You have more free time. Your time is more effective. Discipline makes things more flexible, adaptable, and efficient. We can work within the framework of our disciplined procedures.
However, for some teams imposed discipline can be restrictive, inhibiting leaders and teams ability to make decisions and think freely.
As in all things with leadership, there must be a balance between two forces that could be considered opposites. Here, it is discipline and freedom. But, discipline can be a pathway to freedom.
]]>The three minute egg: an encapsulation of production in a well-known scenario. Let’s dive into the process needed to create a breakfast consisting of a cup of coffee, buttered toast, and a boiling egg.
We must first find the limiting step - in this case, it’s the boiling of the egg. We can work backward from the time of delivery, with an understanding of the limiting step, to determine when to start each step other step, leaving time for assembly.
Three fundamental types:
These steps can be readily applied to very different kinds of productive work, such as training a sales force to sell a new product.
What happens when other complications such as a line for the toaster emerge? We could
If we built an automated machine, we would be sacrificing flexibility for continuous delivery. To ensure that things are working, we need to add a test step, either taking a finalized product and testing it or measuring various proxies during the process.
We must also determine what our raw material inventory should be. Inventory costs money, but if incoming materials are delayed or unsatisfactory, the raw material inventory can be used to continue production without stoppage.
As materials flow through the process, each step adds value. We must try to fix problems at the lowest-value step.
To determine output and efficiency, you need indicators. The 5 basic indicators that provide a good sense of what’s happening are:
Indicators can cause us to overreact, as we focus and optimize for them. Indicators should be paired with a counter-effect, so that if we’re focused on lowering inventory levels, we should also monitor the incidence of shortages.
Indicators should measure output, not activity involved. Countable things should be paired with quality indicators.
Leading indicators give one a view inside the black box of production. They can help prevent a problem before it becomes a problem. However, you should only use ones you trust; otherwise, all they give you is anxiety.
Linearity indicator provides a simple and helpful leading indicator over time, allowing us to determine future rates of return required over observed. Trend indicators let’s us extrapolate from past results to the future.
Some industries are build to order: you make a purchase, then they build it. However, to decrease the time between purchase and receipt of goods, one will need to build to forecast and contemplate future orders. However, this causes some inventory risk.
Productivity is the measure of output over time/labor. Increasing productivity should always be in the mind of a manager. There are a few ways to do this:
A managers output is the output of their organization and the output of the neighboring organizations under their influence. Why? Because work is done by teams.
Usually the most casual verbal exchanges are where the most useful information comes. So why are written reports necessary? They:
There is a hierarchy of information - verbal offhand comments are valuable but often sketchy and incomplete, while written reports may have a positive spin but are well constructed.
Can managerial activity such as information gathering, information giving, decision making, nudging, and being a role model happen outside of meetings? Getting together with others is not an activity, but rather a meeting, for managers to do work.
To delegate effectively, both parties have to have a shared base of knowledge - otherwise, instructions need to be described in detail.
Delegation without follow through is abdication - you can never wash your hands if a task. You are still responsible for it.
Delegate the activities you know best, as you can truly monitor their progress. Adjust monitoring cadence based on the task-relevant maturity that that person has, reducing over time as they gain experience.
Think of the managers calendar as a medium of production. It should not be a repository of orders (people putting time on their calendar) but should be a production and forecast planning tool, scheduling work that is not time critical between the limiting steps in the day. Like a factory, managers should understand their capacity and say no at the outset and keep the start level from overloading the system, otherwise a backup at a bottleneck might arise.
A manager should have raw material inventory - projects that need to happen but don’t need to finish right away - when slack or pauses in schedules come up. Try to standardize what we do, and leverage the early time we spent thinking about a process.
Since part of a managers role is to co very information and preferred methods of approach, meetings are a necessity. We should not be fighting their existence but rather using the time spent as efficiently as possible.
1:1s are the subordinates meeting. For good reason - each subordinate has to prepare only once per meeting, or the manager would have to prepare 8 times.
1:1s cadence should be proportional to the subordinates task maturity.
Staff meetings should only include discussions that are relevant to more than two people in the meeting. The discussion and confrontation between subordinates is a great way to learn detailed information a manager might not get elsewhere.
I didn’t take notes after a certain amount, as I read through the rest of the book racing against the clock to finish this book by the end of 2021, to complete my books-read goal.
]]>