John Obelenus

Complexity Has To Live Somewhere

2026-02-08T19:44:42Z

I am referencing a well known piece by Fred Hebert with my title about writing software. It is well worth reading for the first time, or again. But, to get straight to the heart of it:

Complexity has to live somewhere. If you are lucky, it lives in well-defined places… With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes.

Most modern software ends up being distributed software. Gone are the days of building a successful business with simple CRUD forms and a database. In a distributed system you need to build abstractions and services that get you guarantees. The only way to do that is to have well-defined places that accept specific inputs and handle every error case gracefully without a loss of data. When the boundaries are drawn wrong and the abstractions leak, the definitions are incorrect and your data will be inconsistent and recovery is painful. Because the complexity now lies in the interconnectedness of the pieces—not within individual pieces where you can engineer guarantees. Success under leaky abstractions and bad boundaries is often dependent on consistent latency & ordering, which are always at risk in a distributed system.

When I say “writing the software isn’t the hard part operating it is” this is what I am pointing at. The code to perform the function, even a complex one, isn’t that difficult to write. However, making it perform at scale, under load, with varying latencies, without failing in a hard to recover way is what makes the job hard. To me, it also makes the job interesting and worth doing. This is also what makes our businesses valuable. The only reason we can charge for what we build is if it provides value by handling complexity people are willing to pay for.

I want to extend the analysis to the organization as a whole by bringing in another piece, if a bit jargon-heavy, about the hierarchy of work and complexity. The principle is exactly the same: if your organization’s complexity lies in the connections and relationships between people or departments, you’re in for some pain. But what is the complexity we’re talking about in this case?

The article states that the default mode of operation of an organization is to create specialists that can handle every exception, and place them in hierarchical layers that supervise and quality check. The more exceptions and variability of inputs to the system, the more layers and functions you get. Management’s job is to absorb the complexity and coordinate the layers. This means complexity lives everywhere in your organization.

The solution is not “simply” the cliches of empowerment, or autonomous teams. If the structural logic of specialists and confirmation layers remains, you’re going to get the same outcome. I really recommend you read the full article; there are so many smaller points that are incredibly valuable that I won’t cover here. To focus on my concern:

Let’s start with a blunt reality: work complexity doesn’t give a damn about your org chart.

Every organisation, from a hospital to a bakery to a national intelligence agency, must handle, at minimum, four categories of complexity. These aren’t abstract categories; they are the four unavoidable loads that every organisation must assign to someone or something.

These four categories are:

Operational, short time span, whole tasks and decisions you make every day
Coordination & balancing, sequencing #1 over weeks or months
System design, multi-year coherence and integration
Long term, regulation, funding, multi-institutional

This is not a hierarchy of expertise or elitism. Everyone working in all of these categories needs to be highly skilled. The vast majority of surgeons and software engineers make a living in category one. Moving from 1-2 into 3-4 turns you back into a “junior” where you need to re-learn what you’re doing. Because it is a fundamentally different job.

Different kinds of work sit on different inherent time-spans and interdependencies and systems fail when leaders pretend otherwise…

The truth is that Buurtzorg doesn’t eliminate complexity at all. It simply relocates it into different structures…

Buurtzorg’s achievement is not that it removed these loads, but that it redistributed them: operational and coordination complexity live inside the teams, while integrative and environmental complexity live in the architecture and the institutional environment. That’s the real design innovation.

These are organisational physics, not management preferences…

In a Jaques organisation, people carry these loads through nested managerial roles…

In Buurtzorg, the organisational systems carry them…

The “Jaques organization” represents the “default” mode of working I described above. The “Buurtzorg organization” (the name of a Dutch healthcare company) represents an alternate “flat” organization. But, not flat-in-name-only; an organization intentionally designed to deal with the four categories of complexity. Again, the question here is “Where does the complexity live?” If the boss, or the founder, or the person who’s been here the longest and knows where the bodies are buried, has to get called in to make decisions or solve problems, and the org is paralyzed without that? You get the picture.

The work doesn’t get simpler just because the org chart does

The most persistent myth in modern organisational thinking is that self-management somehow reduces the inherent complexity of the work. This is wishful thinking dressed up as philosophy or some mantra “self-management good, hierarchy bad”.

Teams need to be constructed to own a problem. The whole of the problem. If you divide and scatter the problem it is far too easy for the plot to get lost. And you can’t put the delivered work back together again. The time horizons involved multiply the problem. The longer term the work, the more time for divergence.

When Buurtzorg nurses make decisions about a patient, they’re not just doing clinical tasks. They’re integrating the entire case: clinical, social, logistical, relational, environmental. In Jaques’ terms, they are doing Stratum-2/3 [ed. weeks to years] work. Not because it’s written on a job description, but because reality demands it. And Buurtzorg’s architecture gives them the whole situation, not a fragment of it. That’s the key. The work itself is not chopped into roles that then need to be stitched back together by a supervisor or cross functional teams. The team owns the whole thing…

What makes Buurtzorg compelling isn’t the absence of managers. It’s that integrative and environmental complexity are absorbed through architecture and ecosystem design rather than a managerial chain

The article goes on to point out that the longest term work performed by the government and regulatory agencies in the Netherlands is required to create the context in which you can even attempt this kind of organizational operation in the healthcare field!

When I have seen Engineering teams fail repeatedly it is precisely because the conditions for success were not designed for them. They were told to be autonomous, to make decisions; while they lacked information and the people in roles necessary to be successful. All the while all the decisions needed to be run up the chain, and changes would come back down the chain.

Even in post-managerial organisations, the need for high integrative capability does not disappear. It relocates, from managerial roles to organisational system design.

Most organisations miss this entirely.

They copy the self-managing teams and skip the architecture, then blame the teams when coordination collapses.

When I have seen Engineering teams succeed repeatedly it's because they contained the necessary tools and skills, combined with the information and freedom to make binding decisions. And the responsibility to own & manage those binding decisions themselves.

Many day to day Engineering decisions only impact the short term. After the decisions are made, they disappear into the scenery and are mostly forgotten. Some decisions truly do bind you for years. Teams need the experience and skills to know when they are making that kind of decision. That doesn’t mean they’re going to recognize every single one, or that they’ll make the correct decision every time. We are only human.

Teams need the ability to course correct the moment they sense a problem. Even if the decision was made a while ago. Especially if the decision is “load bearing” and limits optionality. To reference my earlier article—we cannot predict the value of what we deliver. Because of that phenomenon we need to retain as much optionality as possible.

The coordination cost of distributing complexity across management layers is too high, too brittle, and too slow. The world keeps speeding up, and the only way to move fast is to construct a system where teams can own complex problems across long time spans.

Work As Imagined

2026-01-28T19:44:42Z

There are four categories to examine the work we do, or our co-workers, or even the work our users are attempting to do with the products we make; work-as-imagined, work-as-prescribed, work-as-disclosed, and work-as-done. Let me quickly lay out the concepts:

Work-as-imagined: how you imagine doing your job in the future, or how you imagine other people do their jobs.
Work-as-prescribed: the rules, standards, procedures, or even commands for how the organization tells you to work.
- Commonly expressed in joke form as asking a child to tell you how to make a peanut butter and jelly sandwich, and taking their instructions overly literal and making every mistake you can while still obeying their commands.
Work-as-disclosed: how you, or others, describe the work you did.
Work-as-done: the actual work you did, that exists in the moment, and cannot be accurately captured or recorded, because so much of it happened in your mind in the moment.

I am not surprised that my perspectives on an Engineering organization are rooted in epistemic realizations. I know myself. I have my work experiences. I know what I am good at. I know what I am bad at. I have a small realization of what I don’t know. There is a lot more that I don’t know, and I don’t even realize it. Multiply that by everyone. At every level of role experience, junior, intermediate, senior, manager. Multiply that by every good, and even more so bad work experience people have had. And then multiply it by the circumstances around their upbringing and early adulthood. It is not exaggerating to say that every day we are surrounded by people with millions of experiences and influences that we don’t, and probably can’t, ever know about.

This lack of knowledge, not having the ability to know, is a serious one. Resolving this conundrum is what all our communication needs to be about. Between peers, between you and your manager, me and mine, between our managers, between departments, and crucially between us and our users.

Beyond communication, the very best way I know how to overcome these gaps is to actually do the work together, in real time. So many of us in engineering like to be left alone to our own devices. I know I do. “Just write down what you want me to do, and leave me to do it.” It is a comforting thought that all I have to do is accomplish what is described, and I even get to choose how exactly to do it! But it opens the door for failure and misunderstanding at every opportunity.

Engineers should work together writing code. Product and Engineers should work together when defining problems and coming up with solutions. Product, Design, and Engineers should work together when making wireframes and mockups. Design and Engineers should work together when creating interfaces. It is a sliding scale of how much and how often. How well is your team functioning and communicating? How comfortable are they with each other? If you think it needs to improve, slide that scale and have them work together more often and for longer.

A very common anti-pattern that I see in organizations is each of the disciplines working alone, and then everyone coming together to discuss status for an hour a week. Every engineer will tell you that typing the code is not the slow part of the project. Every designer will tell you that clicking in Figma is not the slow part of the project. Every product manager will tell you that writing the ticket description is not the slow part of the project.

Trying to condense all your work into a shared hour of communication is an anti-pattern. Meet together to do the work, delete the status meeting from the calendar. If you’re working together, you don’t need the status meeting. And when you’re together you’ll be doing the hard parts. Once everyone comes to a shared understanding of the problem & solution it will be very clear when they are ready to split up to let their fingers do the rest of the work.

The ROI of a Solved Problem

2026-01-26T19:44:42Z

We build software to solve problems. The solution to the problems must be valuable enough for a customer to pay for them. There is a fundamental assertion here that we have to make—we, as a collective group of people, are extremely bad at solving valuable problems. I feel very comfortable making that statement because 90% of all start ups fail. And incumbent companies that already sell valuable solutions also go out of business. VCs are willing to burn money rolling one hundred dice just to get one that hits.

The foundation of my thinking here rests on this article, of the same name, by Dorian Taylor. To summarize the article: when we attempt creative problem solving, we cannot know the maximum value the solution holds, and therefore cannot estimate return on investment. To quote directly:

…if you pick a problem you can solve today, and close out the day with that problem solved, you have an asset.

If 90% of everything is crap, the obvious strategy should be to produce as much crap as you can afford, because the other 10% will be spectacular.

We all have gut instincts, especially about problems we suffer from. It is why engineers making products for other engineers has a higher success rate. But instinct is not evidentiary knowledge. And we talk with potential customers, “Of course I would pay for that”, which I will call hearsay. Until the money has transferred hands, it is not evidence. Even thoughts like, “I’ve made products like this before and it worked last time, so it will work this time” has an incredibly short half life. The world is changing faster and faster, the preconditions for people’s behavior to remain the same does not last very long.

There is some good news with framing the situation in this way: when you have a valuable solution that people pay for, you have a tangible asset. I have witnessed companies that keep chugging along based on the work that people did five years ago. Their product works, the maintenance cost is pretty low. Every year, for four years, in January at the company kickoff, the same problem is trotted out in different words. Every year they tried new things, unable to solve the new problems they faced. But, even in the face of those failures, the company kept on chugging.

As you may have guessed, I am extremely comfortable with the word failure. I think we often associate failure with a bad character, or negative morals. Failure, entropy, is simply the regular state of the world. It takes skill, perseverance, and luck to succeed. Nature tends towards disorder. We should not feel bad when we fail to produce value, that is just going to get in our way when we try again.

How should we approach creative problem solving in a world where failure is common, the value we produce is unclear, and it is impossible to determine the return on investment? That is the framing in which I look at Product Engineering organizations.

This is my answer to the question:

Define the problem to solve in great detail
When you lack details to define the problem make the smallest investment to get more information
When everyone agrees on the problem, brainstorm multiple solutions
Attempt an MVP solution with the least investment required
Put the solution in front of real people with the problem and see how valuable they find it
Iterate. Over, and over, and over. Until you’re very tired of it.

This is where I bring up the phrase I wrote down in my previous article:

The answer is not in this room. If it was, we would have solved the problem already. The answer is out there somewhere.

No. 5 cannot be answered by anyone in your organization. Only actual customers can answer that for you. As a reminder, it's extremely likely that you will fail to produce actual value every time. Failure is the default. You ought to have every freedom to decide “this is the wrong problem,” or “this is the wrong solution, let's try another.” If you’re following this pattern you are going to gain lots of data along the way, you ought to be rethinking how much investment specific solutions require. And which problems are valuable.

No. 6 I think is where the rubber meets the road and what separates organizations that take this kind of approach seriously from those who do not. Iteration is what turns failure to success. There are a million reasons I have seen organizations not iterate. The engineering and product managers are too busy; “Just tell me when you’re done with this Epic, I don’t need to be involved”. Or, “we all assume what we decided is correct and all the users will love it, so we don’t need to check!” To define a problem in great detail and choose an MVP you are going to iterate on is difficult, and not without conflict. Which is one more reason I have seen teams avoid it. You end up with a large project that takes up lots of time, and is incredibly difficult to determine if it was successful in its goal or not. While no one was uncomfortable in a moment of conflict, I’m willing to bet almost everyone was confused at one point or another as to what we’re really trying to do here.

If you asked me to paint a picture of what this looks like across a Product Engineering organization I would say:

Small autonomous groups of people working together daily.
Decisions are made quickly, and re-examined when new information is acquired.
Solutions are accepted from everywhere, and many require tiny amounts of engineering effort
Solutions are chosen based on willingness to invest, not deadlines.
Delivery & Feedback is accomplished in terms of days, not weeks.
Success and Failure belong to the whole team.

Product Engineering is not all of Engineering, but it is the organization that needs to spend its energy exploring. Exploration is its own specific kind of activity with its own modus operandi. The rest of Engineering has its own MO, neither is it a cost center either. These organizations must mutually reinforce each other.

Go And See

2025-12-29T19:44:42Z

Every year when the calendar starts getting to the end, and life starts to slow down a bit, I get an opportunity to step back a bit and think a bit more broadly.

My mind wandered towards how many articles I've read and how much content is getting churned out. Our industry is constantly asking good questions. Yet, over the last couple of years many of the questions are the same, and the articles are repetitive. That isn't a bad thing, it just means people are focused and coalescing into the same spaces.

I'm in a large professional slack group, and over the years you can see strong themes in the kinds of questions people ask. And as more folks enter the group, the themes are even clearer. The same kind of phenomenon is happening within a select group of people.

Through some conversations in that slack, I was reminded of a little project I started for myself a few years ago.

In order for myself to get a handle on my views as a leader, I came up with over 30 questions & situations where I wrote a paragraph or three to try and explain my views and defend it just a little bit. I ended up writing ten pages! But it lacked a throughline that held everything together. I realize that I was just supporting specific tactics that I have seen succeed repeatedly.

I felt like I was making a directory, so when folks asked questions, whether in Slack, or an interview, or just having a conversation about work with a friend, I had responses that I had thought through, rather than trying to formulate a comprehensive approach in the moment. That approach has limited explanatory power and utility.

2025 was an amazing experience at System Initiative. We made lots of product changes, adding features, removing other approaches, rebuilding product experiences left and right, and aggressively going to market where we learned a ton.

Reflecting on the decisions we've made, I realized there was no way that I could point at my prepared tactics as having a forceful influence on my thinking. I still believe them, and see where they would have fit, but I was retrofitting it backwards onto a decision, rather than in the moment realizing I was leaning on something I built up mentally beforehand.

It finally dawned on me. I needed to express the strategy behind it all. The throughline that I observed was missing. The "why" behind. The tactics are useful, but tactics always fall out of a strategy. So I'm going to do that!

I identify four specific principles I can point to that turn into a concrete coherent strategy. Let's get to the first one: Go And See

This principle sits on top of foundational understandings of reality:

All models are wrong, some are useful. - George Box

The map is not the territory. - Alfred Korzybski

The philosopher Alfred North Whitehead named this error: "the fallacy of misplaced concreteness”

Or, to reference Adam McKay's opening in The Big Short:

It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.

What I really want to get across is: you are wrong. Often. About something. It could be a real small thing, or it could be big. Please entertain the idea that you are wrong.

When folks on your team come to you with problems, technology problems, people problems, product problems, marketing problems, sales problems, personal problems—whatever your first take on the situation, you are probably missing something.

One of the more frustrating moments in working with teams throughout my career is when someone asks a question, and people immediately try and answer it. Even the person who asked the question does this! No one asked clarifying questions, follow up questions. And no one brought any new information to the table.

When you're wondering "Why isn't X shipped yet?", "What is holding back Team A?", "I really thought we were going to close that deal" the answer is to go and see. There is data you are missing. Everything you think you already know does not contain the answer to the question.

One of the phrases that I will repeat in these moments is: "The answer is not in this room. If it was, we would have solved the problem already. The answer is out there somewhere".

Go And See. All leaders are tremendously busy. You are not always on the front line. There are some front lines you likely have not seen in a few years. It happens. You have to get back to the front line in those moments. And you need to advise the folks that report to you to go back to the front lines themselves. Get out of your comfort zone. Get out of the rooms you normally live in. If the answers to your problems were there you would have already solved the problems.

Now the act of “Go and See” that you perform should be timely and aggressive. A problem showed up on your doorstep. You can’t solve it without information you don’t have. You shouldn’t schedule a meeting for three days from now. Or ask someone to follow up with you without a constraint. If the data is outside your org and out in the market where the potential customers are, I hope reaching out is a motion you have practiced and have some repetitions under your belt.

Rules For Drawing Cartoons

2024-01-24T19:44:42Z

A good friend and I were chatting about his job. He was talking about how they were putting in place a number of rules for all the people doing jobs like his. My natural instinct was that this must make it harder to do his job. That people are creating bureaucracy. He went into greater detail, but I really didn't know his industry to know heads from tails. He said that this was a good thing. He compared it to the design rules for cartoons. And it got me thinking.

Each cartoon has their own style. It's necessary to establish the brand and for differentiation. Rules communicate to viewers what to expect. And when you break the rules—its for effect. Though there are some rules that you don't break.

In addition to some of the simpler and strict rules like those above. There are guidelines to follow in order create the desired effect. I think about rules like these as if they were a director. The director knows where he wants to put the camera and why. Individual cartoonists may not know how or why to "move the camera."

These artifacts are written down guidelines to make sure everyone is on the same page about how we work together to achieve a cohesive look and story between dozens of different individuals. Everyone has their preferences and opinions. At the end of the day we do all need to work together towards a single destination.

My good friend then asked me:

What are the rules for your company?

I honestly had nothing that I could reasonably point to as an answer for him. As I look around the industry at-large I see "Thought Leaders". Many of them are very vague. The rules we saw for cartoons above are very specific. I really don't think I've ever seen something so specific before. On some level "if the compiler accepts it, it works!" is the bar, even if that bar is incredibly low.

We have to do better. On my very last project I started to do just that. I used ADRs to explain why I was refactoring code to fully utilized class-based views in django-rest-framework. I explained why I was moving code out of views and into serializers. I explained which methods you ought to be overriding to achieve your outcome. And which methods should not be overridden. I even had an example of when I had to break that rule. I wrote a knowledge base entry in our wiki and shared it with the wider dev team.

I received amazing positive feedback on what I was writing up from several people. This is definitely a practice I am going to repeat in the future.

Acting Like an Operator

2024-01-18T17:30:41Z

I have been putting together some interesting correlations that I have observed throughout my career. It is giving me a realization about why I care about what I care about. I'm still figuring it all out, and this post is one attempt to vocalize a part of it.

I have noticed a gap in outcomes between software engineers who have had to be operators, and those that have never been operators. When I mean operators—I mean responsible for more than just producing code that goes into production, and if it breaks in the first 48hrs fixing it.

"DevOps" is a convenient label for this, but it's not the whole part. Of course a culture of DevOps (note: this is not a team whose name is DevOps) is a good thing. But that doesn't necessarily make someone an operator that has an interest other than software qua software.

One reason that engineers making products for other engineers works so well is because the ones who are most interested in this are the ones that need tools that don't yet exist. Because they are operating something. This is the best version of dog-fooding, or drinking your own champagne, whichever metaphor you prefer.

I've been an operator when I was a software consultant. My job was building software for my clients to operate. I felt the pain of operators, and it was tied directly to my paycheck. I had immediate access to my users. And if I couldn't solve their pain, they would stop paying me.

I've been an operator of a gym, with some friends. We started a powerlifting and olympic weightlifting gym in a warehouse. Paid rent, got equipment, and tried to get people in the door. It was, and remains very successful.

Growing up our family friends were operators. Construction, plumbers, electricians, roofers, you name it. One of them had a particularly strong influence on my I will never forget. I worked construction renovation with them for a summer.

In my career I have observed that software engineers who don't take on an operators perspective when building tend to have some commonalities. Maintaining their software is difficult. Operating their software is difficult. The concerns of those who are operating it are less important than some technical merits. This often holds back improvements. A perpetual list of things to do is seen a "a good thing" and predictable output is the highest possible good, regardless of whether there is any value in that list. Whenever the mood or task at hand feels Sisyphusean, that is when I know in my gut that the folks building do not have the perspective of an operator.

On the other hand. When the folks building have the perspective of an operator, you see creativity, and a varied approach to solving problems. These folks have more than a hammer, and there are more than just nails in the world. You see defensive designs because they expect the unknown. Problems rarely have a large blast radius. And best of all, the folks who work this way are able to move on from what they've built. They're not tied to it like an anchor. Because the maintenance is low, and its easy to operate. It might still have flaws and lack specific things. But they are able to go off and build the next new thing.

Because they are focused on value there is not an endless list of tings to do. Many things & directions have been ruled out. They don't react to incoming feedback by jumping and saying "How high?" They don't react until there is something with large value enough to return and work on it.

Why is the determining factor "acting like an operator"? Because operators have Important Things To Do. Operating the software is something that has to get done in service of the true task. Operating is never itself the goal. The less time and energy spent operating, the more time and energy you have for value creation.

As the line from Halt and Catch Fire goes "Computers aren't the thing. They're the thing that gets you to the thing."

Ownership At Work

2023-12-18T18:41:02Z

When we talking about "who owns what" most commonly I hear people discuss it in terms like these:

"Who owns this module in the codebase?"
"Who owns this page in the application?"
"We don't own that!"

The way people talk about ownership betray some of my most important values. This is how I translate that kind of talk; "We don't want to touch it", "It is their responsibility", "I am not allowed". You may not want to touch it, but if its in the way of doing your job, I want to see you activate, not wait around for someone else. It may in fact be someone else's responsibility—that doesn't help us make progress in the moment. Do you mean someone is actually penalizing you when you tried?

I value people who activate, get involved, make decisions, and finish work. Every one of these questions avoids getting involved, looks to someone else to make a decision, and does nothing to finish. Finishing something is the only way to create value, hit your goals, and start working on the next thing.

I don't think people are thinking about the implications of their idea of ownership. Here is just a small bit of the quagmire this creates:

When we talk about ownership do we really mean "only owners can modify it"? Does everything only have one owner? Doesn't that make collaboration really really difficult? What does it mean to possess code? Its not even a real thing in the world! What do we do with a list of things that are not owned? If you're claiming ownership why is no one else allowed to touch it? Why do you need such tight control? What value does that create for you? What value is that denying for others? If someone else owns something, and you need a change, and you're not allowed to do it, you've now linked your success to their ability to make that change on your timeline. Is that really how you want to work?

If you own something, and its not successful, does that mean you ought to be fired? I have rarely met anyone who would agree with that statement, but also still believe in "ownership". After all, what is ownership without fully responsibility for the outcomes?

I would love to change how we talk about ownership. I think talking about it this way causes too much stress and anxiety for teams. I want the engineering teams I work with to think about ownership in these terms:

I own how I invest my time each day.
I own making progress on my team's goals.
I own collaborating with my peers in order to find the best way forward.

Software Engineering is a team activity. No one person can do it all. No one person owns the code. No one person owns the whole outcome of our work. But you absolutely own getting involved, working hard, and the impact you make. No one but you can stop you.

Opinions Held

2023-02-27T18:46:21Z

I think the idea of "Strong Opinions, Weakly Held", as it is commonly received, is a terrible concept. Another word for "strong opinion" is "a belief". Beliefs should be required to have costs associated with them. "Weakly held" implies to me that you create beliefs absent any costs.

In my view, beliefs are strongly held. They are created based on impactful lived experiences. These beliefs that I have, have come at great personal cost to me in blood, sweat, and tears. I don't know about others, but I do not take lightly to having my lived experience "weakly held" and brushed aside easily.

Weak opinions, weakly held sounds entirely plausible to me. That sounds like brainstorming or doing some hand-wavey "napkin math. Yes, you better hold those very weakly. You spent as little time as possible coming up with the opinion. When someone else comes along, having done more work, you should probably perk up and listen to what they've got.

We don't want to hold on to our beliefs because they are simply ours. But rather because we know why we believe them, how they got created, and how are they working for us. Does our most recent experience comport with our established beliefs?

Humans Acting At Scale

2022-11-18T16:53:26Z

The aphorism "A person is smart, but people are stupid" has always stood out to me. It never sat right. If an element of a set contains a property, then the set ought to exhibit the same property. Right?! Well, what are we really trying to communicate when we say this?

I think one aspect of what we're trying to say is that when we take a given person in a situation, we're probably imagining that person at their best. Any given person in their best moment, ready, willing and focused, is going to behave as intelligently as they possibly can.

But what are we saying about "people" in groups? We're no longer imagining one situation, but all situations. And not when any of those given people are at their best, but everywhere along the Bell curve of their possible performance.

We're comparing an individual high water mark, with the average of a bunch of people between their good and bad moments and days. No wonder! I think there is a more charitable description than we can give this than the common aphorism. That is: Humans Acting at Scale.

Why am I interested in this as a software engineer? I build systems that other engineers operate. I build products that users & customers operate. When building these systems and products there are a lot of decisions to make along the way. When we're making these decisions are we thinking about our users and their abilities?

Are we thinking that they will only be operating the system or product after 10 hours of good sleep, after their first cup of caffeine, in their favorite outfit, without a care in the world, and totally focused on doing an excellent job today? Or do we think that they'll be operating the system or product with one hand because with their other hand they are on the phone trying to get someone to come fix their furnace, after they got a bad night's sleep because their dog was up until 1am vomiting? If they drop their phone on the keyboard, or the cat walks across it—what happens?

How many things does this operator need to remember (Knowledge in the Head) versus things the system is showing them and giving them feedback on (Knowledge in the World)? How are details surfaced to the operator? How are expectations and impact of their operations communicated back to them? Do they get a clear confirmation screen? Are their actions reversible?

Once we're working with a product or system that is operated by a group, or multiple groups, of people we have to stop considering the fact that we know one of the individual humans who is operating it. "I know Steve, Steve is great at his job. This is a little complicated, but he can handle it." We have to consider how many other people are also operating it, who no doubt are also good at their job. But that we are all simply human, and our ability to perform & operate varies all the time due to an uncountable number of factors.

Demanding a standard of "just be better and don't make mistakes next time" is not a valid approach you can have towards operators.

Designing with empathy is not about pitying people, or even thinking you're better than them (you're not). It is about designing for the worst outcomes and making sure your system and product support what the humans need in the face of those worst outcomes.

Placeholder for a Conversation

2022-03-12T16:44:02Z

As a new manager, in an environment where team and company processes are morphing and changing, I have been asked to share my opinions on a number of topics. My answers are taking a common shape; tools are placeholders for conversations. The first example is Jira.

There are no shortage of opinions about Jira. Both the software itself, and the effects on teams it can have when wielded in certain ways. I have many strong opinions. I have almost no opinions on Jira. It is... irrelevant to me how people want to use it. How many columns on your board? How many statuses? Are we using labels, custom fields, themes? I say: "Whatever you want."

I do care about is the ticket. I don't care if the ticket has paragraphs of detail, I don't care if you use Jira as documentation (I think you're going to have a really bad time, but thats a different conversation). I don't care if the body of the ticket is empty and as the Engineer you prefer to write it in a notebook. I have zero feelings on that.

What do I care about for tickets? A ticket represents a conversation. I don't care where the conversation gets recorded, or at all (provided the people are capable of remembering it). My problem is when a ticket exists absent any conversation at all.

No matter how hard you try you're not going to have a successful handoff in a ticket. Not to mention handoffs are bad. Handoffs exist when one person has context, and others lack it. Now we have to perform a knowledge transfer. First, have as few handoffs as possible. Teams that work together should be building shared context together. If you have shared context, there is no handoff. How do you measure whether you're doing this well? When the real conversations about the tickets get shorter over time.

If you've worked at a startup I am willing to bet you've had this experience. You open up the Jira backlog. It is full of tickets. Old tickets, weird labels and epics. Acronyms you've never heard of that the startup doesn't even use anymore. You see dozens of tickets that only have a title. You're seething because you have no idea how to make any sense of it all. "Why didn't they document anything?!"

Those old tickets with only a title, no description, were created by some of the founding & early engineers. Maybe they're still working there, maybe they left a while ago. This is strong evidence of a team working with extremely shared context. That ticket may be two years old, but if you ask them about it—they can still describe what its about to you. That team had a conversation and created a ticket to mark the conversation. You're seething when you see this because you have none of the context, you weren't in the conversation.

That conversation is what matters. Jira (or Trello, Pivotal, sticky notes on a wall, pick any other etc) is only a good tool when it facilitates those conversations and makes sure that the team has them. If people use the tool to have the conversation thats what really matters. That is the best way your team is going to build shared context. And maybe one day they'll make tickets with only titles, but you won't be mad because you know exactly what they're going to do.