Notes on narrative for engineering leaders

Alex Reeve, 22 Principles for Great Product Managers:

You have to own the narrative. When there’s a narrative vacuum, people will “creatively” fill in the blanks themselves—and you might not like it. Losing control of the narrative can be incredibly disruptive to your team’s ability to deliver.

– (Alex Reeve, 22 Principles for Great Product Managers)

Same goes for plans & projects. If you don’t have a plan, someone else will. You may not like their plan.

Telling the story of a goal/project/initiative isn’t manipulation1, it’s setting the vision.

All narratives compress out important details and trade-offs as an expense of clarity and noteworthiness (i.e. an un-memorable narrative is not a particularly good narrative).

Narrative is is a fantastic skill to have as an engineering leader. The more you can convey your ideas, goals, projects, and initiatives as a narrative, the more you can get people on the same page. It’s also a fun skill to acquire. It’s all around us in culture. It’s one of the few things where you can improve in your profession by paying attention to how movies, television, or fiction are structured. (Highly recommended: Every Frame a Painting)

  1. Bad-faith narrative construction exists, please don’t act in bad faith. ↩

"It sounded like the kick drum was played by a drunk 3-year old, and I was like ‘Are you allowed to do that?’”

WONKY – pudding.cool analyzes what makes J Dilla special. Particularly good if Dilla Time (previously) is still in your to-read list.

Albums is a great app and The Best App for Albums is a great review of what makes it good for music enthusiasts and/or organizational hobbyists. I don’t want to jinx it, but Albums checks a lot of boxes for me that Rdio did, back in the day.

TIL Jenny Lewis covered the Traveling Wilburys’ “Handle With Care”. 👍🏻

Don’t zero out the margins

Efficiency is the enemy, Farnam Street:

It’s possible to make an organization more efficient without making it better. That’s what happens when you drive out slack. It’s also possible to make an organization a little less efficient and improve it enormously. In order to do that, you need to reintroduce enough slack to allow the organization to breathe, reinvent itself, and make necessary change.

The good stuff happens in the margins. The scribbles in books, the breath between notes, the five minutes before meetings start when folks are real. Driving a car for the sensation of driving fast, rather than driving fast to achieve the best possible time.

It’s the difference between enjoying a hobby and making a profession out of a hobby. Efficiency is the adversary of fun.

Three meditations on wins

Leaders (and managers) are successful to the extent that their teams and peers notch wins. Former Intel CEO Andy Grove calls this the “output” of a manager, and wrote the book on it1.

Easier said than done! What is it for a lead to create wins (aka output)?

1. Choose games that are winnable

Only play games you can win.

  • Warren Buffett or the Beastie Boys (probably)

Our time is highly constrained. Saying “no” is an underrated and under-discussed leadership skill. Saying no on behalf of my team, peers, or organization, I’ve created focus on a (potentially) winning effort.

Some great reasons not to play a game2:

  • The opportunity, as presented, is not yet small enough in scope to notch a win in the time available to work the opportunity. Find a smaller win in the presented opportunity that will give you a hint as to the real potential of the bigger project.
  • The calendar time necessary to run the project or ongoing effort to completion (notch the win) is dominated by process, coordination, and bureaucracy. That is, try again when there is a way to realize the impact with less overhead/organizational drag.
  • There’s a gap between the desired/supposed outcome and the project(s) that could realize that outcome. The immediate win is to research/brainstorm/write your way to connecting outcome with action(s).

Pro-tip: provide feedback on not-yet-winnable games in the form of “I don’t yet know how to win that game, let’s start by fixing that”. No one likes pessimism, cynicism, or shutting down all the project ideas. That said, it’s fair to provide constructive feedback that will improve the idea or bring it closer to action/win-ability.

2. What counts as a win?

Once something is out in the world, it’s a win. Publishing an article, releasing a feature to your customers – those are definitely wins.

Getting something out of your team or head, that’s a sort of win. Rolling out a new process or tool is some kind of win. Worth sharing! But it doesn’t directly improve what customers are paying for, so focusing entirely on this kind of win doesn’t count.

Wins have to change your company’s world in some tangible way. The change need not be objective or quantitative; a subjective/qualitative survey is enough!

If what you’re recognizing as little wins doesn’t yield bigger wins, then it’s time to reflect on what you’re encouraging.

3. Avoid short-term thinking, build momentum with little wins, build big wins

A culture of thoughtfulness about outcomes, potential, impact, and trade-offs makes 1 and 2 happen.

Loud voices may try to convince you that un-winnable games have lots of promise. Urgent voices might tell you counting something as a win and moving on is the right move.

Moving the goal-line closer, so you can recognize a win, is expedient and productive, occasionally. Other times, moving the goal-line is self-defeating.

It is often difficult to stick with long-term projects. There is so much other stuff to work on, all of it intriguing. Other folks in the organization will want to know how much of “all of it” we could produce in the current and next quarters.

The challenge is to stay the course, believe in the purpose, and stack all those little wins, every week, until the big win takes shape. Tell your colleagues about the big win’s emergence…

In short

  1. Choosing what to work on (or not) is of crucial importance.
  2. Recognizing the right kinds of progress makes it easier to stack little wins on the way to big wins.
  3. Exercising the discipline to stack meaningful progress (wins) is the engine for generating big outcomes.
  1. High Output Management. See also, GitLab’s notes on the same. ↩
  2. Would a whole post on indicators of losing/un-winnable games come off as too cynical? ↩

Improving when you can’t rinse and repeat

You can’t practice at some things. Putting the cat back in the bag or the toothpaste back in the tube. The undoable, the things that you can’t unsay. The measure twice cut once stuff.

In those cases, a little preparation and reflection go a long way. I think about what's important to say or verify before I say/do the undoable. Afterward, I reflect on how things went, if I learned anything surprising, and how I can improve the process next time. Ideally, I write all this down, so I don't lose any wisdom for the next time I'm faced with a similar challenge.

I'd normally say rinse and repeat here. But the point here is there is no rinse! There is only setting myself up for success when I find myself facing a one-way door.

Top of Mind No. 5

Like everyone (it seems), I’m exploring how large language model copilots/assistants might change how I work. A few of the things that have stuck with me:

My take right now: GitHub Copilot is the real deal and helpful, today. On the low-end, it’s the most useful autocomplete I’ve used. On the high-end, it’s like having a pair who has memorized countless APIs (with a somewhat fallible memory) but can also type in boilerplate bits of code quickly, so I can edit, verify, and correct them.

I don’t expect the next few products I try to hit that mark. But, I suspect I will have a few LLM-based tools in my weekly rotation by the end of the year.

Err the Blog, revisited

Before there was GitHub, there was Err the Blog. Chris Wanstrath and PJ Hyett wrote one of the essential Rails blogs of early Rails era. Therein, many of the idioms and ideas we use to build Rails apps today were documented or born.

I’d figured this site was offline, as are most things from the mid-2000s. ‘Lo and behold, it’s still online in its pink-and-black glory. Lots of nostalgia on my part here.

Writing is a "do it, somehow, every day" game

Whenever I find myself wishing I was posting more toots/articles/etc., I remind myself that the first step is to get words out of my head and onto the page. The hack is that “the page” is often a personal journal (I use Day One), a paper notebook (Baron Fig, currently) , or even a task with a note of a few sentences in Things. It all counts.

Just sitting around like The Big Liebowski does not count as writing

More importantly, it generates momentum. Possibly, this writer’s most crucial but immeasurable input commodity.

Related: finishing is the skill and Austin Kleon’s notes on daily blogging, and stock/flow.

Dock jackpot

In twenty years of using Mac OS X/macOS, rarely has my dock not been all blue icons or a bunch of faces staring at each other. Today is one of those days, bless.

Focus in a time of distraction

That is, some notes on helping junior developers focus on execution when they are surrounded by the twin distractions of novelty and outright broken things. With apologies to Love in the Time of Cholera1.

Faced with a junior developer who finds themselves stuck, what questions could you ask them to help them get back on the happy path without all the distractions that junior developers face:

The trick for juniors, is they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up my development server, but then something weird happens with Unix. It’s the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time2.

Is this a side quest?

Compared to senior developers, juniors often find themselves down the wrong rabbit hole. Senior developers have a better sense of when they are chasing the right lead. Over the course of months and years, they develop a sense of when we’re looking at a red herring. More so, they learn to recognize issues caused by development environment rot, bad data, unrelated bugs, and other sorts of non-essential annoyances.

In those situations, it’s helpful to ask junior developers if they’re pursuing the essential problem or if they’re on a side-quest. If it’s a side-quest, write it down and get back to the essential issue. If it’s the essential problem, then…

What do you need to know to focus or make progress?

At all experience levels, software developers face the frustration of “it just doesn’t work”. Occasionally, this is down to outright broken software. Often it’s not knowing about or misunderstanding a crucial detail of how the sub-systems work together.

It’s extremely tempting to skip ahead, tell a junior developer what they need to know, and move along. That’s how it works on the internet2. It’s time efficient. The ability to swoop in with an answer feels wizardly, and that’s pretty fun.

Unfortunately, that’s the “give a man a fish, you feed them for a day” approach. Junior devs are a source of endless questions, sometimes excellent and sometimes not. Answering one question, no matter how decisively, is unlikely to change the shape of the ‘questions per hour’ graph.

Better questions, better information

Better to teach junior developers to generate better questions. Nudge them to lead with what they know about the non-working situation. Encourage them to steer clear of trying magical solutions3 and whack-a-mole troubleshooting4.

This teaches a junior developer two things:

  1. They probably know more than they think.
  2. They’re more likely to find their answer by answering questions than by fixating on what doesn’t work

Which questions can you answer right now?

Now that our junior developer is armed with better questions, it’s time to answer them. Given all the questions that might help them make progress, they should start from the ones we know how to answer right now. Sometimes luck strikes and the problem is solved. Other times, the issue and the tricky questions remain.

This is the scenario where senior developers5 can help a junior developer the most and teach them to fish, so to speak. Senior developers are often more adept at using REPLs, debuggers, automated tests, documentation, static code reading, inspecting data, or observing runtime behavior to turn good questions into answers. In one session, a mentor can show an apprentice how to use an unfamiliar tool, think about problem-solving, and solve the original question. The mentor will probably learn something too!

Luck happens

There is a bit of chance in solving problems. Recall what you already know. Pattern match on the (correct) factors that likely won’t bring you closer to a solution. Ask answerable questions that narrow the issue space. If you make a mis-step at any of these, you could end up confusing yourself even more!

Stick with it. Maybe step away if you’re already drained, or it’s getting late in the day. But stick with it. Persistence beats luck and chance, most of the time6.

Thanks to Wade Winningham and Henrik Nyh for sharing ideas on this topic via ruby.social.

  1. Which I have not read but is a pretty snappy title. ↩
  2. e.g. Stack Overflow and its ilk ↩
  3. e.g. restart the computer, reinstall something ↩
  4. Trying random changes, repeating one test in hopes of seeing a different result, blindly applying suggestions from similar problems posted on the internet. ↩
  5. Senior developers appear to have the superpower of seeing circumstances and going directly to the root cause. That usually happens by quickly enumerating what they know about the problem and pattern matching on the circumstances to reduce the problem space to a few possibilities worth eliminating or verifying.
    This happens via answering enough questions that the problem or behavior of the system becomes obvious. It’s a bit of crafting a theory until you trip over the actual situation. ↩
  6. Casinos and rigged games are notable exceptions. ↩

Reading, February 2023

I’m still reading about the Manhattan Project. The going is slow. Big books, big timelines. At least, for the speed at which I read.

Rhodes, Making of the Atomic Bomb – I’m 500+ pages in and only up to the early 1940s. That’s a hefty history meatball. That said, it’s a deep dive into the history of science in context with chemistry and quantum/nuclear physics. If you like a hefty but complete book, this one is your jam.

Wellerstein, Restricted Data – I have very much enjoyed the author’s blog of the same name over the years. The author goes deep on the newly created apparatus for keeping the Manhattan Project secret from very nearly the whole world during the war. The pace for this one is a little off, to my preference, so I’ve put this one down for the moment.

Gleick, Genius – Big Richard Feynman fan here. This book does not disappoint as a biography. Gleick is a great writer, writing with detail but without losing pace or going so deep that the thread is easily lost.

Reading in topical clusters has worked really well for me. The books talk to each other. It’s a bit like a Manhattan Project Cinematic Universe when personalities come together in Los Alamos and then disperse as each book follows a different thread of history. Physicists assemble, I suppose!

Write linked notes so you don’t have to remember

Writing linked notes helps engineering makers and managers alike develop the super-powers of augmented memory and the appearance of effective multitasking.

I’m revisiting Simon Willison’s essay and conference talk Massively increase your productivity on personal projects with comprehensive documentation and automated tests. I’ve started thinking about it1 as “the surprisingly effective power of writing linked notes”.

In particular, those last three words:

  • Writing: most thinking is improved and clarified by writing.
  • Linked: writing is even better when the writer or interested colleagues can return to it later. Linking facilitates discovery via browsing and searching.
  • Notes: mostly static text, but sometimes executable tests/documentation, too!

Over time, writing linked notes gives you what looks like the myth of multitasking. Really, it’s reducing the cost of context-switching and remembering:

This is how it relates back to maintaining 185 projects at the same time.

With issue driven development you don’t have to remember anything about any of these projects at all.

I’ve had issues where I did a bunch of design work in issue comments, then dropped it, then came back 12 months later and implemented that design—without having to rethink it.

Occasionally, I get a feeling, whilst working on a tricky problem, that I am starting to lose the thread. Keeping all the variables, ideas, and context is difficult as the interconnections grow. That’s the moment when writing it down to get it out of my head allows me the space to remember less, concentrate more, and push through to make progress again.

Highly recommended.

  1. And, sharing it with anyone who will listen. Present company included. ↩

Top of Mind No. 4

The practice of building software/technology is going through a phase shift. We’ve worked from abundance the past few years. Now we have to figure out which developments are worth keeping and make a dividend of that exploration. It’s not clear what job roles, kinds of software, practices, and benefits1 will persevere.

We’re going to have to ask “what would you say it is you do around here?” of software development assumptions from the past few years. It’s unsettling2, but some good corrections will come of it.

I’m betting that using writing as a lever will remain under-rated and under-used. Both for asynchronous/remote work and improving all kinds of thinking about building software.

Furthermore, Poker Face is excellent.

  1. Sorry, nap pods and ping-pong tables. ↩
  2. And, often executed cynically. ↩

Natasha Lyonne is my generation’s Joe Pesci

Poker Face is a gem. Do yourself a favor and start watching it[1]. I didn’t realize I needed a weekly murder mystery kind of show. But I did, in this specific form.

Poster image of Natasha Lynne wearing sunglasses in the American Southwest
Poster image of Natasha Lynne wearing sunglasses in the American Southwest

Like murder mysteries of yore, Poker Face has a recognizable and soon-familiar cadence. We see a murder happen in the first few scenes, rewind to a few days previous when Natasha Lyonne arrives on said scene, we see her discover and solve the murder. The format works, even if you aren’t a viewer of crime shows and procedurals.

This being a show about a journey[2], each episode brings a few interesting actors in for a cozy, crisp murder mystery. These guest stars are as excellent as you might guess given the show is produced by Lyonne, Maya Rudolph, and Rian Johnson.

The bottom line, in this case, is the star is the show. The show is built around Natasha Lyonne, who is perfect in this role. Lots of little wise-guy energy. The way she uses her arms and voice to fill scenes, it’s great. I can’t stop telling people she is my generation’s Joe Pesci. They’re even the same height!

  1. If you have the means, get yourself an NBC Peacock and watch yourself a great show.  ↩

  2. This will make more sense after you watch the first episode.  ↩

Make code better by writing about it

Writing improves thoughts and ideas. Doubly so for thoughts and ideas about code.

Writing, about software or otherwise, is a process wherein:

  1. thoughts and ideas are clarified
  2. ideas are transferred to colleagues
  3. culture (of a sort) is created by highlighting what’s essential and omitting what’s transient

Documenting code, as a form of writing, is a process wherein:

  1. the concepts and mechanics in the code are clarified
  2. what’s in our head today is made available to our teams (and ourselves) in the future
  3. culture happens by highlighting what’s intended and what’s “off the beaten path” when working with this codebase

I suspect that open source is (often) of higher quality than bespoke, proprietary software because it has to go through the crucible of documentation. Essentially, there’s a whole other design activity you have to go through when publishing a library or framework that internal/bespoke software does not.

I can’t objectively verify this. Subjectively, when I have made the time to write words about a bit of code I wrote, it has resulted in improving the design of the code along the way. Or, I better understand how I might design the code in the future.

Writing is a great tool for designing code. Use it more often!

Corporate personhood and ants

Filtered for ants and laws, Matt Webb:

Let’s say we could chat with ants. Could we trade with them? What would we want from them?

…

In short: people treat almost everything as people, at least a bit, including companies.

  1. We could try to communicate with ants and then include them in capitalism. Would this raise all boats for humans (who currently do low-paying/low-prestige work) and the ants (what is good pay/prestige/standard of living for an ant, I don’t know!)?
  2. We attribute person-like qualities to corporations. Infamously, in the case of Citizens United and more innocuously like attributing creativity to Apple, potential then hucksterism with Tesla, or declining design aesthetic with BMW.
  3. If we bring ants into corporatism and personify them, there’s an opportunity for some futurist/dystopian sci-fi where a mysterious cadre of house cleaners/chore-doers conceal themselves via surveillance technology and financial engineering of shell corporations. Turns out, it’s just a mega-colony of ants.

Turn the pages. Read the code. Hear the words.

“Turn every page. Never assume anything. Turn every goddamned page.” — Robert Caro, Working

So goes the wisdom super-biographer Robert Caro received from a mentor when he was an investigative reporter in New York. Caro went on to apply this energy and depth to write a sprawling biography on real estate developer Robert Moses and four volumes on the life of LBJ.

I like the energy, determination, and purpose of Caro’s advice. In his writing, Caro takes a maximalist1 perspective2. He looks to understand the system. Caro read every original document in every archive he could find (“turning the pages”) to ensure he fully grasped the context of historical events and didn't miss any details that might change the interpretation of events. Caro tries to load the whole state of his subject into his head and notes. Only then does he start writing his expansive biographies.

1. Read the code

Building software benefits from the same energy and determination displayed by Caro. As I’m working on a project, I flip between code I’m writing, code I’m using, and adjacent systems. Once I’ve read enough to have the problem and system in my head, I can move through the system and answer questions about it with that everything is at my fingertips feeling3. Fantastic.

Recommended: read third-party libraries, frameworks, standard/core/prelude libraries. Read demo code. Find inspiration, learn something new, and build the muscle for reading code with confidence.

2. Hear the words

When I’m really listening, avoiding the urge to think through what I’ll say next, I’m doing my best work as a coach or mentor. When I really hear and understand what a colleague is trying to accomplish or solve, it’s a bigger win for everyone.

Subsequently, I can switch to brainstorm or solution mode. Not before.

Recommended: literally listen to what they’re saying. Especially for the leaders and managers out there. Get the context needed to understand what they’re thinking. Ask clarifying questions until you’re sure they understand what they’re thinking. Don’t start responding until you’re sure you understand the context and the kind of response4 expected of you.

3. Build a model

Reading (words and code) and listening are great ways to build a mental model of how an organization, system, team, or project works. That said, a model is mostly predictions, not rules or hard-won truths.

To verify your model, you have to get hands-on at some point. A model is likely invalid unless it’s been applied hands-on to the system in question. Make a change, propose an updated process. See what happens, what breaks, who pushes back. Building (with code, with words) upon the model will evolve your understanding and predictions in ways that further reading or listening will not.

Recommended: turn reading words, reading code, and listening into a model of how your code-base, team, or organization work together. Apply that model to a problem you’re facing and use the results to improve your predictions on what actions will produce welcome outcomes. Rinse and repeat.

4. Go forth and deeply understand a system

With due credit to Robert Caro, I suggest doing more than “turning the pages”:

“Read the code. Read every damn function or module you’re curious about.” — me, a few months ago

"Listen to what they're saying. Hear every damn word until they're done talking." — me, several weeks ago

Next time you think “I need more context here” or “that seems like magical code/thinking”, go deeper. Take 15 minutes to read the code, or listen 15 seconds longer to your conversation-mate.

Turn the pages. Read the code. Hear the words.

  1. Aside from his biography quote above, all of his books are doorstoppers. ↩
  2. Extensively aided, it should be noted, by further research and organization by his wife. ↩
  3. Aka Fingerspitzengefühl ↩
  4. e.g. commiserating, brainstorming, un-blocking, taking action, etc. ↩

Remote work skills today look like being online in my youth

Checking my emails frequently. Responding to a few group/direct-message chats at a time. Managing to write code, do math, or put together a slideshow/essay at the same time. Always in front of a computer.

That’s what productivity in my college years1 looked like. There was lots of multitasking and goofing around online. A smidge of collaboration via nascent networks2.

There is little coincidence that’s close to how I work today. Slack is a better IRC3, messaging apps work a lot like AIM4 and ICQ5 did back in the day. I try to focus more and multitask less, to the extent that circumstances and discipline allow.

What strikes me is, when my career started6, that’s not how we worked.

In the early 2000s, if I needed to talk to more-experienced developers or managers, I wrote an email or walked over to their office/cubicle7 to try and catch them for a quick chat. If I needed to talk to a more junior developer who was just out of college (like me), I sent them an instant message. I probably had Slashdot, IRC, or several blogs open in a minimized window somewhere.

Now, I’m the experienced developer/manager-type person, and the style of work matches a lot of my college habits. A lot of that is leadership determinism (i.e., I have the agency to set and model the structure of our work). Maybe some is down to measurable productivity improvements that, e.g., Slack bring. Most of it feels like it is down to the opportunity seized of remote work – you can’t work remotely without all the tools folks in my cohort started using as we were pivoting from students to professionals.

Today, “Extremely online” is a whole other thing that is unrelated to how I work professionally. But as a new generation becomes the largest in the workforce, probably that will change and things will look a little weird to me. So it goes!

  1. 1998-2003. Most of those spent on a dual-everything Linux PC. I bought my first laptop/Mac in December 2002. ↩
  2. Mostly, folks were Very Offline. Especially outside my generation, but even in my peer group. Now, we’re all Pretty Dang Online. ↩
  3. For all but the neck-beard-est measurable axes. ↩
  4. AOL Instant Messenger, the definitive software of my youth. ↩
  5. Which required knowing your user ID to get people to add you as a friend. Thusly, I can still tell you my ID to this day: 11772935. ↩
  6. Roughly 2000 is when I did my first productive programming for money. ↩
  7. Thinking back, cubicles were not great or cool, but they did beat desks in an open layout on most axes. Larger pair cubicles with someone you like to collaborate with were pretty good, all things considered. ↩