No manager decides to be a micromanager, but micromanagers obviously exist, so they must come from somewhere. Managers who do micromanage either say what they’re doing is not micromanaging or provide a justification for why they have to manage that way. Both of those are the result of the same underlying problem: these managers don’t understand how to give direction.

A manager giving direction can do it either of two basic ways. One way is to define the activities to do and the other is to describe the output to produce. Micromanagement is to some extent a matter of degree, which is to say providing the direction in too much detail. More often, though, it’s a consequence of providing too much detailed direction in the activity not too much detail in the output.

The simple explanation is that defining the desired output is actually hard. We spend most of our thought and energy on how to do something. We don’t think nearly as much about the product of that activity. Thinking about it less means we are less able to describe it.

To make it worse, it can be hard to describe what a good work product is. What we can remember may be hard to describe precisely, e.g. what it means for a software change to be fully verified. We also don’t always remember everything we want to describe, only realizing the omission after our delegate produces something that doesn’t meet the requirement we forgot to state. The desired properties of the product are not always apparent. They’re embedded in implicit knowledge, the things we know but don’t know we know.

On the other hand, actions are easier to see and thus easier to describe. You do one thing, then the next thing, then the next. What you’re doing is visible. Certainly there’s nuance, but they’re easier to break down into individual steps. You don’t even have to explicitly describe them. You can just say “watch this” and expect them to emulate you. They don’t need to understand the why. They don’t need to understand how you painstakingly arrived at this method after years of trial and error and improvement that you don’t clearly remember and can’t fully explain. Just… do it. It’s not that hard. And when they do get it wrong, how do we try to debug it? We want to know how they did it.

Micromanagement happens because good management is hard. It’s hard to describe the desired outcome. It’s hard to think of what is fixed and what is free. It’s hard to transfer the knowledge and judgment that allow you to assess a work product and deem it good. It’s hard to debug the expectations you gave someone because they make sense to you; how could they possibly have misunderstood? So you throw up your hands and just tell them what to do. It’s just easier that way.

When people come to me for career advice, it’s because they’re struggling with a decision. They have an option that is intriguing, but there’s enough risk and uncertainty that they are nervous and uncertain. For instance, they’ve been an individual contributor, and they have the chance to become a manager. Or perhaps there’s an assignment to a different location. Every case is different, but I’ve found one recurring pattern: thinking the change is permanent.

It’s good to think ahead in your career. If you’re not happy with what you do today, you want to know that you’re getting closer to something that does make you happy. You want to have some intentionality so that you can influence your future instead of being the victim of circumstances.

It’s possible to make the opposite mistake though, which is to see a change as permanent. Part of what contributes to the struggle is that people don’t think “do I want to be a manager?” They think “do I want to be a manager forever?” Well yeah, that’ll stress anyone out. I mean, that’s your whole life. There’s a lot at stake! But that’s making it bigger than it needs to be.

I think the right time frame for decisions like this, assuming there isn’t one built in, is two years. Your question becomes “do I want to be a manager for the next two years?” “Do I want to live in Denver for the next two years?” “Do I want to switch to product management for the next two years?” Two years is long enough for you to explore the option pretty well and understand if it’s right for you. It also makes it more likely that you’ll take it seriously and really try to make it work because there’s not an easy exit.

On the other hand, in a 40 year career, taking two years to try something different is not a big deal. If it’s a mistake, you’ve lost a bit, but it won’t be a total loss. You can handle two years. Even if that’s not the right path, you’ll learn something from it, perhaps more than you would have learned without the risk. After all, just because it’s the wrong decision forever doesn’t mean it’s the wrong decision for now.

Early last year, I was stressed out because my managers in one office were stretched too thing. Early this year, I was stressed out because I had more managers than I knew what to do with.

I have teams that are overwhelmed with work. Just the projects we’ve identified today will keep them busy for the next year, forget about any new ideas we think of or emergencies that happen. Then there are other teams that are responsible for products that are active, but they’re scrambling to find useful things to do.

Some days I feel like I have nothing to do. Some days I feel like I have everything to do.

We seem trapped between two equally unpleasant choices: being overwhelmed or existential uncertainty. In none of these situations is there balance, even though we want it.

In struggling with these situations, I’ve realized that the balance I wished for is an unachievable fantasy. To achieve it means that three factors, our work rate, our backlog, and our idea generation rate, should be, well, balanced. Our backlog should be big enough to buffer hiccups but not so big as to impose excess pressure to work it down. The work rate should closely mirror the idea generation rate. Only it doesn’t work that way.

Work gets done in a lumpy, irregular fashion. The items are of varying sizes and complexity. The team’s productivity fluctuates with people’s moods, energy levels, absences, and the mix of different types of work. And then there’s idea generation, which defies predictability and consistency.

Our control over these factors is crude and incomplete. At best we have control over the distribution of values over time, but their values at any given moment are basically random and independent of each other. Viewed in that light, it’s easy to see why balance almost never happens. Just combining the probabilities makes it evident that balance is improbable. It’s not quite impossible, but for practical purposes, we should treat it that way.

Don’t strive for something that is so hard to achieve and so fragile and temporary when it is achieved. Don’t aim for balance. Aim for being marginally overwhelmed but still maintaining your sanity. It is better to be needed too much than too little. Just don’t be need too too much.

Every two weeks we do a review of progress against our Objectives and Key Results. It takes between 60 and 90 minutes and involves about 20 people. We go over the key results one by one, describe their current status, assess whether we’re on track to achieving them, and identify next steps.

Well, that’s not quite right. Key result owners populate a shared document before the meeting where all of those things are described. Then they’re stated aloud in the meeting. There’s sometimes discussion, but it’s not anything that can’t be done via email the shared document. A naive observer in this meeting would probably recommend this meeting be cancelled. This naive observer would be wrong.

When each person states their update aloud, they experience it in a way they wouldn’t if it was just words on a page. That also means that, before the meeting, they anticipate what they’ll do and how they’ll experience it. They do not want to show up unprepared. There are 20 of their peers who will be listening to them and possibly asking questions. If they haven’t done their work, it’ll be obvious, and it’ll be felt very differently than if they had simply not filled in some text in a document for people to read.

A less naive observer might also recommend that this meeting be cancelled. This less naive observer would recognize that simply cancelling the meeting would be insufficient. The forcing function of the meeting would need to be replaced with some other mechanism. That could work. It could be better. But it’s not free, and it’s not automatic. The value of this meeting is not what happens in the meeting. It’s what happens before the meeting because of the meeting.

Skills matter. They definitely matter. They just don’t matter as much as people seem to think. That’s because many important and valuable abilities are not a function of knowledge. They’re a function of attitude.

We’ve all been in useless meetings. What does it take to run an effective meeting? You don’t need advanced graduate work. You don’t need decades of experience. What you need is a clear purpose and agenda and the discipline to stick to them. Easier said than done? Sure. But the part that’s hard isn’t knowledge. It’s attitude.

What about listening? Being a good listener is a valuable ability. Exactly how much is involved in doing that? Look at the person who is talking. Hear what they’re saying. Think about what they’re saying. Don’t talk. You don’t need an executive MBA for this. You don’t have to be in the fast track high potential development program to get access to a rare opportunity to grow. You just need to control yourself and pay attention.

Then there’s being accountable to stakeholders. That’s simple also. You remember what you told them. You look at what you did and didn’t do, then write an email and click Send. And you do that every week or every month or whatever the right cadence is. You don’t need an executive coach. You don’t need a license from the state. You just need to value it, make time for it, and do it.

What about producing high quality code? Surely that requires otherworldly talent, a mastery of complex algorithms, and the ability to read binary faster than most people read prose. Except… it’s not. I’ve known plenty of incredibly smart people who wrote bad code. I’ve known numerous medium capable programmers, including myself, who produced high quality code. Most of the difference between producing poor code and producing excellent code is not whether you started programming at age 7 on your mom’s computer or whether you got a computer science degree at MIT. It turns out most of the difference is the same as the difference between poor work and excellent work anywhere: improving your work until it is excellent instead of letting it be anything less. Perhaps you have to gain some knowledge and experience to understand what makes code good and bad, but mostly this is not a skill. This is an attitude.

Skills are important. They are. But what skills do is mostly establish what the potential is. They’re like a driving test to get a license. They show that you can drive well. But will you drive well when you have your license and don’t have a test proctor in the passenger seat? You can tell just by watching the roads for five minutes how weak of a guarantee that is. The skills are required. They’re not sufficient. And it turns out for a lot of things, the skills are really, really easy. When someone still doesn’t do what’s needed as well as it’s needed? The answer is attitude. They just don’t want to.

Different levels of a career track have different expectations. One obvious difference is in the scope and scale of the job. While important, those are not the most important.

There are at least two more important ways that the job changes at higher levels. The first is in how the job is specified. At the lowest levels, what you specify is activities or tasks. Do this, do that, etc. Individuals at these levels will be productive, but often the purpose of these levels is learning by doing. Typically at this stage they’re executing someone else’s plan.

As you ascend to the middle levels, the job should specify the output. What should you be producing or delivering? To what standard? You are expected to know enough of the how at this point that the how doesn’t need to be given to you. You get the goal, and you’re expected to figure out the how for yourself. That’s in part to reduce the load on your manager, but it’s also because you may know how to do it better than your manager does.

Once you get to the higher levels, the job becomes about outcomes. You define what should be produced and delivered to achieve the desired outcomes. It doesn’t matter if you define “good” deliverables or execute well. If it doesn’t achieve the desired outcome, you failed.

The second way the job specification changes is in how specific it is. Lower levels will enumerate precisely what activities are to be performed and how. Definitions of the middle levels, focusing on outputs, will tend to be shorter. Briefest of all will be the descriptions of jobs at the most senior levels. At the top is the CEO’s job, which comes down to “make the company successful.”