Chaotic Beautiful Snowflakes

You arrive at work. You sit down at your desk and you scan your inbox for potential disasters. Two mails pique your interest. You write brief responses to nudge the engineers in the right direction. Nothing else is urgent so you walk to the kitchen to get breakfast. You sit down with three fellow engineers who are also working on your product. During conversation over the course of breakfast, you discover that you and Phil are working on exactly the same problem, so you decide that Phil is going to take point and you two will chat once he’s done.

Nice, crossing that off my list.

Walking back from the kitchen, you see Joey, who runs the design team. He stops you to ask, “Why are we meeting at 1pm?” You explain that you’re unclear about the workflow for the feature you’re working on. He explains that the team met late yesterday afternoon and he thinks he has a working paper prototype, which he conveniently hands to you. You glance at it and say, “Yeah, this is exactly what I need. No meeting necessary, but this is wrong. You mean that, right?”

Joey nods, “Yeah, good catch. Thanks.”

It’s been an hour since you arrived. You’ve checked your email, eaten, and unexpectedly crossed two significant to-dos off your list simply by walking around the office. The only things that were planned were your rough arrival time and your intent to have breakfast.

Everything else… just happened thanks to proximity and serendipity.

Non-Obvious Work

You are a single hypothetical you. You are a unit of a person who surprisingly has their shit together this morning, and while you haven’t written a single line of code yet, you’ve created a significant amount of work. Let’s recap:

You sent two emails that need to be digested and acted on by the recipients.

You and Phil had an ad-hoc meeting in the kitchen where you discovered and fixed a duplicate effort problem and assigned the work to Phil.

You and Joey had a hallway design meeting where you iterated on a design and killed an unnecessary meeting. Sweetness.

And you ate.

My point: you are a software engineer. You worked very hard to learn about the science of computers. You enjoy the calm, rational aspects of developing software and I’ve just written 396 words about an hour of a hypothetical morning and described a slew of unplanned work you never planned.

And that’s just you.

You’re part of team of 23 engineers who have also spent this morning walking around the building and bumping into people, talking, discovering, making decisions, and it feels organic and natural. And it is. All of these random interactions are a sign of a healthy team, but you are underestimating the amount of both obvious and non-obvious work it’s creating for unsuspecting others.

You Squared

In the 1970s, a systems engineer at TRW named Robert J. Lano invented the N-squared chart. The diagram is used to “systematically identify, define, tabulate, design and analyze function and physical interfaces.” One of the simple byproducts of a well-designed N-squared chart is that you quickly understand how fast complexity increases as you add more functions to a system. The chart visually documents what Big O notation achieves in describing the complexity of algorithms. In the case of a O(N2) algorithm, its performance is directly proportional to the square of the size of the input data set.

You, your productive morning, and all the other yous walking around the building are a wonderful N-squared problem. While not mathematically sound, the fact is that you significantly underestimate the amount of work that you generated this morning. You could document and communicate the obvious work, but you can’t document all the unexpected side effects of your actions. In a large population of people, it’s close to impossible for an individual to perceive and predict the first order consequences of their well-intentioned actions, let alone the bizarre second order effects once those consequences get in the wild.

Humans – engineers especially – significantly underestimate the cost of getting things done in groups of people. We focus on the obvious and measurable work that needs to be done: iterate on a design, write the code, test, iterate, deploy, and we put a huge discount on the work required to share that process with others.

Engineers have a well-deserved reputation for regularly being off by a factor of three in their work estimates, and that is partly due to the fact that we are really shitty at estimating the non-linear chaotic work (and fun) that exists in keeping a group of humans pointed in the right direction.

On Leadership

It is entirely possible that I am permanently biased regarding the necessity for leadership in a large group of people. I am actively watching zero leadership experiments in progress at Medium, GitHub, and Zappos, but I am a firm believer that you need a well-defined leadership role to deal with unexpected and non-linear side effects of people working together. You need someone to keep the threads untangled and forming a high-functioning web rather than a big snarl of a Gordian knot.

There are a slew of good reasons to hate crap leadership. There are leaders who hoard the information they discover. There are leaders who have crap judgement and perform awful analysis and make precisely the wrong decisions. There are leaders who are genetically bad at communication. And there are those who are simply a waste of air and space; they define their existence by creating unnecessary work for others to make themselves look productive.

It is likely that you’ve run into one of these leaders and their distasteful anti-human behaviors, and this has tainted your opinion of leadership. It is equally likely that you remember these crap leaders a lot more than the leaders who quietly and effortlessly helped. The ones who gave you the data you needed when you needed it. The ones who pointed you at precisely the right person at the right time. The ones who served as a sounding board, worked hard, and when they made a decision, you found their judgement reasoned and fair.

Whether your opinion is that leadership is mostly positive or negative, you’ve certainly come upon the question: “What does my lead do all day?” A portion of every leader’s day is the detection, triage, and resolution of work we never planned. Sometimes it’s a complex people-related fire drill, sometimes it’s a simple clarifying conversation. But speaking as a leader, I can confidently say that it’s 9:23 am and I have a full calendar of meetings, but I don’t actually know what I’m going to do today. It’s an essential part of the gig.

Chaotic Beautiful Snowflakes

Working as a team is hard work. Let’s forget about product market fit, let’s ignore web scale architectures, and let’s blow right by your last valuation. The work isn’t hard because of the things you know; it’s hard because of the unknowable. This piece is not an argument for more leaders, it’s a request to appreciate that the unknowable arrives – every single day.

You are a beautiful snowflake with your own unique behaviors that affect your team on a daily basis in ways you can’t even imagine. Let’s multiply this “uniqueness” by the 23 other snowflakes wandering the building. And then let’s throw our hands in the air and ask, “How in the world are we going to get anything done with all these unique goddamned snowflakes bumping into each other and creating additional unexpected work that we can never plan for?”

So, take a moment. Think about your last hour at work. Think about what you were planning on doing and what you actually did. Did you do what you expected? Probably not. The hard work of great leadership isn’t just managing the expected tasks that we can predict, it’s the art of successfully traversing the unexpected.

The first time I got promoted to lead developer, I really struggled and was shocked to learn that I was lucky if I got to spend half my day writing code. I got frustrated and felt like I was doing something wrong. I struggled to communicate where my time was going and what I was doing all day. Over time, I realized that that’s just part of the job of being lead. Thank you for sharing so eloquently – if I’d been able to read this before, I wouldn’t have felt like so much of a failure for the first year.

Great post. I _lead_ engineering at Medium, while we don’t have people with the title “manager”, we absolutely have people who act as managers, and we certainly aren’t “zero leadership”. If anything Holacracy allows us to explicitly recognize several different forms of leadership that are missing from the traditional two-track engineering ladder.