words _by jm_

Dont cut the burger

Thu, 14 May 2026 00:00:00 +0000

One of the biggest mindset adjustments I had to make when transitioning to a manager was to learn to not cut the burger for my team.

One time my wife and I were out to eat with a friend of ours, and he was having issues trying to eat the comically gigantic burger he had ordered. My wife offered to cut it in half for him to make it easier to eat. Keep in mind: we’re all grown people. He was perfectly capable of doing it himself, but my wife works a lot with kids, so it’s her normal instinct to just step in and fix problems like that regardless of whether it’s the best option in the situation.

I had an issue with this when I stepped into my first Pure Manager™ role. I was just as technical as my team and love solving technical problems with code, which was helpful when it came to estimating, unblocking team members, guiding technical decisions, and so on. But it also made me really prone to cutting the burger. Oh, you’re stuck on a problem? You know what, just let me slide in here and fix that. We need to get a feature out the door? I’ll just jump in and crank out some code really quick.

If you do this as a manager, you (without even meaning to) may be doing a number of bad things for your team. You may be depriving them of a growth and learning moment. You might be depriving them of your attention on something more “managerial” that would help the whole team rather than dealing with this one problem you’re trying to address. You could be making them feel like, since you’re having to “step in,” that they’re not doing a good enough job even though you’re really just trying to accelerate the work forward.

Early on in my managerial journey, I had to apologize to a lot of team members about this issue. I just wanted to get my grubby paws on all these cool problems and solve them! I love to code! But I needed a reality check. The first time it happened, I had a team member get very upset with me nearly to the point of tears because he felt like he was working as hard as he possibly could, but I felt like I still needed to step in to help. That made him feel like he wasn’t doing a good enough job when in reality, I saw that he was working incredibly hard and wanted to help him out. In doing so (at least uninvited), I communicated a pretty negative message with my actions.

Obviously, there are caveats. If your involvement or intervention is invited, of course you need to act. If the work is something you should be responsible for in the first place (i.e., something manager-y), obviously step in to do it. But don’t deprive your team of the opportunity to do their work and/or grow just because you can’t keep your tendencies in check.

Don’t cut the burger for your team.

Gratitude

Thu, 14 May 2026 00:00:00 +0000

It’s my opinion that the best non-mechanical skill (i.e., not project management methods, communication styles, etc.) one can cultivate as a manager is gratitude.

I have worked for managers who were great at it, and I’ve worked for managers who literally told me that my pay is my gratitude for my work. I’ll let you guess which set of management was actually engaged with the work happening and the people doing it and which set of managers simply saw the work they were doing effectively as moving things around in a spreadsheet.

When I say “cultivate gratitude,” I don’t mean learning to say variations of “thank you” in several languages or putting a fruit basket provider on speed dial for rapid fire gift giving. It’s not just the expression of gratitude that matters. Anyone can fake it and say “thanks” a lot, but in reality, there doesn’t have to be any appreciation there. I’m talking about adopting a posture of gratitude towards those around you whose work you manage and help you do your own work. Cultivating gratitude means developing a genuine appreciation for their work and sincerely expressing gratitude and thanks to them when it warrants it.

The true catch to this is that it requires taking a real interest in other people and their work. You have to have a sense of wonder about people, what they’re working on, and how it helps move things forward in the business (if it doesn’t move the business forward…well, then one may need to adopt a posture of feedback 😅). Having the people around you know that they’re seen and their work is seen not only provides a positive feedback mechanism, but it also validates them as people. It makes them feel valued, and when people feel valued, they’re more fulfilled, they’re more invested in doing well, and they’re far more likely to be able to steer clear of burnout.

The other, less obvious catch is that you shouldn’t just adopt this perspective for things that help you directly. This mindset isn’t transactional. It’s holistically appreciating people for who they are and what they do, so even if they don’t things that directly benefit your career, you should still appreciate and validate their work as best you can. Side note: it also means that even if they’re super annoying or otherwise personally distasteful to you, if you adopt this way of thinking, you’ll still appreciate and express gratitude for their work. It’s not always easy.

This is something I’m constantly working on inside myself. Over the years as I’ve put the work in, I’ve found it increasingly easy to see the inherent value in the work that people do, but I’m still learning how to find opportunities to express it and express it well. My best advice here is don’t lean on formal opportunities like feedback cycles and skip levels. First, because you might forget before then, but secondly and more importantly, sharing gratitude solely in these situations can make it feel more like a mere formality than a genuine expression of thanks.

Remember: the idea here is to create connection with another human and help them feel valued, not check another checkbox on the feedback rubric!

Opportunity costs

Thu, 14 May 2026 00:00:00 +0000

Every action you take (or don’t) has an opportunity cost, and sometimes it’s super easy to overlook them because the choice may not even feel like a “choice.”

It’s vital to, of course, consider opportunity costs when working. One is always running the calculus on things like “If we pick this tech stack, we will need a this amount of ramp time before features go out” or “If I spend the time mentoring this junior member of the team, I can’t knock out as many stories this week.” Weighing these against the results of the choices is just part of the job.

But it’s also important to calculate the opportunity cost of factors impacting the galaxy of your life surrounding your work as well. That analysis could range from things like “If I have this conversation at work, it may limit my ability to advance at this firm” to “If I spend these extra hours working, it may impact my relationship with my family.” It’s easy to overlook these choices because they don’t always have a deterministic, discrete result to measure against, and negative results can creep in without you even noticing.

I’m sharing this because it’s approaching the holidays, and every holiday season I have to live with the fact that I gravely miscalculated an opportunity cost that resulted in something I can never fix. I was working on a big, very visible project at a big, very visible company. I had been working on it solo for months (not my choice), and it was going slowly because I was working in a new tech stack with poor documentation and a small ecosystem (somewhat my choice but not really). It was supposed to launch in the Fall, but it wasn’t ready yet. It kept slipping until it wasn’t going to launch until after Christmas, but that was likely only to happen if I worked over our Christmas break to get it done.

I hadn’t seen my family in a long time (I think maybe I’d missed the previous holiday season with them for various reasons), but I had been promising to get home to see them this year. With this project hanging over my head, I told them I’d have to miss holidays again, but I’d make it home as soon as I could, at least before my grandmother’s birthday in May. I just really had to get this done and out, or it just felt like it was never going to get done. I didn’t really consider any other option because it just seemed like this was what had to happen. I was blinded by the seeming inevitability and/or banality to any opposing consequence that I may have needed to consider. My manager directly asked me to work over the holiday break to ship it, so obviously I needed to. I’d just knock this out, go see my family with some PTO later, and all would be good.

Well, my grandmother didn’t make it that far.

My grandmother who helped raise me, who was like a second mom to me, had a sudden stroke and died before I could make it home again. Even typing this right now is a little overwhelming, so I won’t dwell on the emotions that evoked. I’ve worked through them, I’ve accepted it, but it still hurts. Honestly, the worst part is that project never launched. I did finish it, but no one was working then to deploy it because they took their PTO. And then when they returned, all these new requirements came into existence that were never previously communicated, so it just got shelved. So, I gave up a lot of badly needed PTO, missed seeing my grandmother one last time, and essentially ended up in a state of serious psychological distress for…nothing. That was not a well considered choice.

But these things have soft edges. They leave a lot to factors that are often out of your control. I don’t beat myself up over it, but if I could do it again, I would 100% have chosen differently. All I’m asking is to be sure to take a deep look at your situation to make sure that you’re not making what seems like an easy or obvious choice (or acting on things that may not even seem like a choice!) simply because you aren’t considering that there may be wider consequences to it.

Support team

Thu, 14 May 2026 00:00:00 +0000

Something that jumped into my brain this weekend: if you’re a product owner of SaaS tool, talk to your support people to see what canned replies they have saved in their support tool. That’s basically free pain point discovery from your customers because your support people have had to reply with the solution so many times they automated it.

Hopefully you don’t have many of these, but I’ve been surprised by how a big pile of these things can accrete over time because “well, that’s just how it works.” Maybe it doesn’t have to, though?

The stack, such as it is

Sun, 22 Mar 2026 00:00:00 +0000

Software teams are a lot like pastries.

When one is preparing a recipe, there is a list of ingredients to follow along with instructions on how to use those ingredients to produce a composed dish on the other side. That part is obvious. What might be less obvious, is that adding an ingredient or taking one away fundamentally changes the recipe. It’s not that it’s the dish but different. It is no longer the same dish. The difference between exquisite pâte à choux and down home southern biscuits is simply adding eggs. They are 90%+ the exact same elements, but they produce vastly different products on the other side.

It’s the same with software teams as well. So many times we think adding a person, removing a team member, or moving someone around will create minimal chaos, but the reality is that the entire chemistry of the team changes when that happens. When you add an ingredient to a recipe, you have to adjust the steps to alter the product or you’ll end up with a mess (trust me, I’ve experimented in the kitchen enough to know this is true!). Likewise, when team chemistry changes workflows have to be adapted, expectations have to be adjusted, knowledge gaps have to be filled, and so on. Fundamentally the graph of responsibilty and relationship has changed within the group of people on the team. It’s up to you as a manager to recognize this, and put the work in to rebalance everything.

The great thing is that these changes can present opportunities for positive transformation. Composition dictates capability. Ending up with “better” or more cohesive “ingredients” on the other side can present the opportunity to turn a janky biscuit recipe into perfect puff pastry. Take advantage of it!

Wu Tang AI

Sun, 08 Feb 2026 00:00:00 +0000

I think there’s an old Wu Tang jam about AI models: “D.R.E.A.M.” That is, Data Rules Everything Around Models.

As practitioners have started implementing LLMs in their tech stacks, I’ve seen a lot of chatter and confusion about what the limitations of these models can be. When you fiddle with ChatGPT for a while, it can seem like some sort of black magic, so when you start bumping up against some of the limitations of LLMs, it can be confusing. Why can it understand my questions about Miley Cyrus’s dining preferences as expressed in her memoir “Miles To Go” but can’t seem to parse this seemingly simple question about traffic laws in Milwaukee? Why is it telling me over and over about the growth patterns of eggplants when I asked about the inhumane egg farming plants that I saw in a documentary?

The thing is, artificial intelligence isn’t “intelligent” as we colloquially describe it. We tend to use “IQ” to measure someone’s perceived intelligence, and AI models currently are not very good at the things we use to determine that. Someone actually did a study (https://lnkd.in/eRszr5Ft), and the results weren’t great (spoiler: some models barely reached “average,” most were slightly below average). AI models currently can not establish new ground truths or innovate newly reasoned facts. They can combine and remix their existing knowledge in new ways, but their training and fine tuning data determine everything that they know or can possibly know without augmentation. Think of them more like really good remix artists rather than lyrical virtuosos.

This fact also goes for relationships between data. You can supply a giant corpus of data, but if you’re asking questions about correlation between data and haven’t supplied any training data to enforce the relationship (i.e., you don’t have to draw a line between A and B as facts but instead draw a relationship between the types of data), the AI will be very unlikely to make that connection for you. At the least, it will produce very poor understandings of it.

Side note: that’s why having a base model that’s trained on a corpus of data that fits your needs is important. Yes, you can fine tune, but unless you need really general capabilities, it’s probably better to find/build/train a more specialized model. For example: sure, the big LLMs handle code pretty well, but why not deploy something that’s especially geared towards understanding code to cut down on the amount of fine tuning and augmentation necessary to get the results you’re seeking?

Hello, world

Thu, 15 Jan 2026 00:00:00 +0000

This is the obligatory first post. It exists to prove that a Markdown file in content/posts/ becomes an HTML page in _site/posts/. If you can read this in your browser, the pipeline works.

§1What lives in front matter

Title, date, categories, and an optional one-line summary. The generator infers everything else — the URL slug from the title, the reading time from the word count.

§2What lives in the body

Plain Markdown. Headings like the one above are renumbered automatically as §-sections by the build, so I never have to keep them in sync by hand. Code blocks render in Computer Modern Typewriter on a slightly darker paper:

content/posts/*.md  ->  generate.py  ->  _site/posts/*/index.html

That’s the whole story.