Solving Problems & Saving Time through Software and Crushing Entropy
Powered by Cecil & Hyde.
I started and ran a gym with some friends for six years. I learned a lot about training, and how to maintain and train without getting injured, and what to do when you do get injured. And we're not talking big "go to the hospital" injuries. Just the standard injuries when you are pushing your body past its current limits; strains, pulls, and alignment problems.
There is a common piece of advice that "When my knee hurts" the problem is not in my knee. The problem is actually in one of the adjacent joints: your ankle or your hip, and your knee is compensating. As a result of that compensation it is either over worked, beyond its designed range of motion, or out of alignment. And the "hurt" is your body's signal back to you to stop and adjust.
I like using this metaphor when diagnosing organizations as well. If you're putting your finger on a problem, or a part of your organization is crying out for help, it is likely that you need to look at one of the adjacent pieces of the org, the other teams that are interfacing. As we say in programming: garbage in, garbage out. If a team isn't getting the right inputs, or isn't working under the right conditions, or lacks context, their output isn't going to match your expectation. This is an alignment problem.
Alignment problems need to be solve from the outside. Because the part of the org looking for help either; does not have the capability as the org is designed, does not believe they have the authority, or doesn't know how, to fix the problem.
As a leader you have to answer the conundrum: who ought to have the authority and how can you make that a reality? How do you begin teaching others how to fix the problem they're dealing with?When do you change the organization to enable new capabilities? Without answering these questions you will continue to spend your time maintaining aligment. The only way to move on to different problems is to give someone else this problem.
Read more: A Diagnosis Metaphor
There is no shortage of discussion around how silos are harmful to people, teams, and whole organizations. Every level of humans is affected. I don't think I have to convince anyone there. However, there is a twist now—we are (for the most part) all remote. This is a natural breeding ground for silos to be born. Even when we are trying to avoid silos!
The common element to silos, handoffs, and asynchronous communication is: Context. Silos are bad because they purposefully deny shared context. This means you need a formal handoff. Handoffs fail when all the context is not passed along. "All the context" is why working asynchronously requires hard work and commitment by all parties.
Gone are the water cooler conversations, as well as looking over shoulders to help with a problem, and the quick nod on how something ought to work. Even under "normal" working conditions, handoffs fail. There is a reason you don't swap out a whole surgical team during a long procedure. You'd rather have the same someone on their feet for twelve hours because they have twelve hours of context in their mind. Think about that. As an organization, a hospital will forfeit "normal" schedules, 5-days a week, and adjust all their staffing and labor law compliance just to keep the same surgeon on their feet for 12+ hours, rather than swap a new person in after a few hours. They realize just how difficult it is to communicate a full context. They are doing one of the riskiest jobs there is—they have someone's life in their hands, their body open on the table.
Working asynchronously with people requires building that shared context over time. It is not going to come instantly. As an organization, you can support this process by keeping teams together for longer, with fewer distractions. The more remote, distributed, and spread out across time zones teams become, the more important it becomes for organizations to realize what is happening.
Two decades ago the only asynchronous work that happened in software was outsourcing. No one enjoyed trying to make it work. And it rarely worked. Companies blamed their international counterparts, but I bet the companies' inability to share the necessary context for asynchronous work was just as culpable, if not more so.
Read more: Silos are Bad, Handoffs Fail, Async Is Hard
I am sure the majority of managers in my industry would recognize Goodhart's law:
When a measure becomes a target, it ceases to be a good measure
What surprises me is how often this maxim gets forgotten! Whenever there are discussions about quantifying "How good are our estimates?", "Is our productivity increasing or decreasing?", or "Are our teams happy and healthy?" folks routinely believe that these questions can be targeted for improvement by (more or less) direct measurement.
Management routinely accepts that with humans "by observing something you change its behavior." They understand that the measurement will have some margin for error and believe "it is close enough." And they are probably correct. It is likely that it is close enough.
Once an engineer knows you're monitoring their productivity, and then you set productivity targets their ears start burning. Now they know that their next promotion relies on productivity improvement. They know their favorability within the org relies on productivity remaining the same. And, they know that if their productivity ever goes down they might get fired. And somehow management believes they will still have an honest measurement of productivity?
Managers have to realize that they cannot have their cake and eat it too. I believe this is a constraint when creating a well-functioning organization. If you're interested in quantifying these kinds of things, you can not also talk about "making estimates better" or "increasing productivity" . I truly believe once you do that the game is over, and slowly but surely you will lose the trust of your team.
If that isn't controversial enough for you try this one on for size. Common wisdom for increasing the productivity of your startup is to hire more people—rapid growth! I believe that is incorrect, it is only part of the story, at best.
Hiring people increases your potential capacity—not "real" capacity. Real capacity is how many things you can do at once. Potential capacity is about how many things you can do at once in the future. I think Will Larson illustrates the problems with rapid growth where you are always hiring more people:
Just how challenging this is depends on how quickly you can ramp engineers up to self-sufficient productivity, but if you're doubling every six months and it takes six to twelve months to ramp up, than you can quickly find a scenario in which untrained engineers increasingly outnumber trained engineers, and each trained engineer is devoting much of their time to training a couple of newer engineers.
In any scenario close to the one that Larson describes there is zero question that you've hired more people, and more people are able to do more things. But have you increased productivity, or have you decreased productivity? If you haven't put a considerable amount of effort into making onboarding effective, which is incredibly difficult, the chances are you will experience decreased productivity.
Odds are the executives told you: "Bigger, Better, Faster" and your response was: "Give me cash and I will hire people!" As a manager how are you going to manage this constraint? Eventually, people get trained, but what are you going to do until then, and how will you manage expectations with executive leadership?
Read more: Two Beliefs About Organizational Constraints
If you've read a handful of my posts I don't think you would be surprised if I told you I am an academically-minded person. There are a fair number of causes for this (which I am learning about more and more) and there are plenty of reasons why that would be a surprising development.
As a kid, I was "good at math". The truth is more that it came very easily. However, it never engaged me. It was easy and boring. I still have not done a lot of math in my day, though I wish I did more. I wish they taught math differently because when I see the kind of work that Grant Sanderson does at 3 Blue 1 Brown I am positively riveted. Even though I am entirely incapable of actually doing that math—it would take a lot of work now to even attempt getting there.
The link between high-level math that looks so interesting, my "academic-ness" nature, and my career in software revolves around the question of "How do we know what we know?" In my mind this boils down to two famous sayings: "All models are wrong, but some are useful" and "Don't confuse the map for the territory."
Grant Sanderson wields his understanding of high-level maths by fitting a solution to a real-world problem. He answers "How do we know how to solve this problem?" by reframing the problem in terms of a system of math that can generate an accurate and useful answer. For those who don't enjoy math, but have seen "Hidden Figures", this is precisely what Dorothy Vaughn did to solve their trajectory problems by picking a different mathematical system that would give them an answer they can use. In the view of people without this kind of mathematical mastery, it looks like they are wizards, or they are merely cheating—making up answers as they go along.
We know that computers only do what they are told. Decades ago you had the ability to see and understand everything the computer was doing. Not today, there are too many layers and too many authors of code in every machine running today. Computers are still doing exactly what they are told. There are just too many authors yelling at the computer.
This is the root of bugs. The computer is doing what it is told. The problem is us. We got an unexpected response. It is our understanding that is flawed. The "territory" is what it is. Our "map" is wrong.
We are wrong constantly. This means that we should always be learning. Many people are afraid of being wrong. I've never understood that perspective. Learning oftentimes means you were wrong. After all, it's rare that we go out of our way to truly learn something from zero knowledge. More often we are adding to the knowledge, and more importantly, changing the knowledge we have. Updating our maps, not treating them as dogmatic truth to rely on.
Read more: Epistemological Models
About the time I was heading off to college I was introduced to an interesting phase. I am not entirely sure where I heard it, but I believe it was from my Aunt. Throughout her career she worked at IBM, Dun & Bradstreet, and Hewlett Packard. The saying went something like this: "If you need something to get done, give it to someone who is very busy."
As a kid who had never had a white-collar job before I didn't understand it. It still flies in the face of conventional thinking; surely you should give a task that needs to get done to people who have free time to do it. Only as my career has advanced am I beginning to understand the inherent wisdom in the phrase.
The first layer of understanding this wisdom is Parkinson's Law: "work expands to fill the time allotted." In the context of delegating an important task that needs to be completed; if you give the task to someone with enough free time the task will take longer. Delegate accordingly.
The second layer of understanding this wisdom, you'll discover, is that some people aren't interested or motivated. It is incredibly rare to see a skilled and ambitious person twiddling their thumbs waiting for something to do between 9 and 5. That said, staring at the ceiling trying to figure out the right decision to make counts as working for many of us. If something is urgent, out of the ordinary, or outside someone's comfort zone (and they haven't agreed to a stretch goal) you may reconsider delegating to this person.
Make no mistake, this is not about "a lack of trust". You trust the person to do their job, if you don't they shouldn't work there. But oftentimes things that need to get done lie on blurred lines.
Read more: If You Want To Get Something Done