I don’t know how many times I’ve wasted time, energy, and patience trying to solve a problem only to discover the problem I thought I had was not the problem I had. Maybe what I came up with was a good solution to a different problem, but it wasn’t the problem I had. This is more likely to happen when the stakes are higher and the problems more complex.

One of my big projects early in my career, which I called “Boxcar,” at Indeed was to finish development of a prototype for a service-oriented architecture. There were some really clever parts in this system (conceived by someone else, not me), but the cleverest part had nothing to do with the solution and everything to do with the problem definition.

The problem of distributing work reliably is surprisingly hard, and it’s one that many people have attempted to solve over the years. It will never be perfectly solved, and one reason for that is that people are trying to solve the wrong problem. What these technical architects are trying to do is to distribute load uniformly across a pool of slightly unreliable servers with optimal performance. Solving that problem would indeed be valuable, but it’s not actually the problem we need to solve. The problem we actually need to solve is easier, and that’s what made Boxcar so great.

The problem we solved was instead how to distribute load across a pool of slightly unreliable servers without overloading any individual server and achieving pretty good performance, probably. Note the two ways the problem statement was weakened. Instead of distributing the load uniformly, we’re trying to avoid overloading any single server. The former certainly achieves the latter, bit it’s not necessary.

Imagine we have a pool of four servers, and our current load is 20% of the total pool capacity. I guess it would be cool to have 5% of the load on each of the four, but 20/0/0/0 or 15/0/0/5 would all do fine also. Yes, a server that’s running at 5% will service requests faster than one that’s running at 20%, but the difference isn’t really meaningful. Nor is it guaranteed. Performance is complicated, and there are a lot of confounding variables.

By defining the problem down, we were able to create something that in practice had superior performance. Software engineering is rife with problems like this, where if you aim for perfect, you’ll never get there, but you can get a lot of value out of 99% perfect. There’s a mismatch here between the business goals and the technical problem definition. Often the business managers and the technical people are speaking almost the same language, but it’s that “almost” that’s a killer.

For a couple of years, I had this recurring experience of watching two people vigorously arguing about how to solve a problem and slowly realizing that the reason they couldn’t agree was because they were trying to solve subtly different problems. Maybe one had four features in mind and the other was thinking the same four and another one. Maybe their feature lists were exactly the same, but one was anticipating 10,000 simultaneous users and the other was anticipating 500,000. Maybe they had the same feature list and the same anticipated load, but one of them thought they could fix certain errors in the back end while the other thought they had to be prevented from happening in the first place. They were frequently sufficiently smart, sufficiently capable people, but could not agree on where to go because one person is thinking Cape Town, and the other is thinking Melbourne.

This is about more than just translating business requirements into technical implementations. This is a huge part of the value of an MVP. An MVP is not just about the refining the solution. It’s also about making sure the problem is what you think it is.

Experienced professionals have learned not to get too deep into trying to design a solution before asking, “what problem are you trying to solve?” It’s really easy to think that you’re all on the same page when you start a project only to discover six months and five person years later that what was obviously the problem to you was something different from what was obviously the problem to everyone else. It’s not just enough to say what the problem is. You have to describe all of what you think the problem is and also what it is not. Don’t get me wrong, you’ll probably solve it eventually, but it’ll take a lot more time, energy, and patience. Spend a few days nailing down your problem definition so you can save some of those five person years on solving more problems.

Reid Hoffman, founder of LinkedIn, famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” I’m not sure he’s right, but I’m also not sure he’s wrong. Whether your product is ready to ship can be broken down into some more focused questions:

• Does it do enough?
• Is it reliable enough?
• Does it need more polish?
I see people err too often in all of these. Number of features is one that trips people up because a product’s creator is likely to be full of ideas of all of the things the product can be extended to do in the future. They can be so excited that by comparison a single, simple, useful thing is underwhelming.

Reliability (or correctness) is another area where creators can be led astray. The quality bar needs to be high enough that the product:

• almost always succeeds at its core function with a relatively narrow range of inputs/li>
• doesn’t do anything catastrophic like delete files/li>
• doesn’t make your customers think you’re idiots

But it does not need to succeed at secondary functions or a wide range of inputs. It does not need to be bug free as long as it avoids causing harm. It does need to be good enough that your customer has some minimum level of confidence in your competence.

Polish is probably the most dangerous because something that looks ugly or crude is going to be most embarrassing. The other part of the danger is that it’s the one that matters least. When you’re building a new product, no amount of polish is going to cover up its uselessness or failures.

There’s definitely a bias toward waiting too long. While I’m not convinced I’d set the bar where Reid Hoffman did, my far is not much higher. Ship when your product does one useful thing with a low chance of collateral damage to the customer and without destroying their perception of your confidence. If using your product is an iota better overall than not using it, ship it, even if it’s far short of what it could be. Compare your product against what exists now, not what could exist. Otherwise you may not get a chance to build it into what it could be.

Being successful is not complicated. Work hard. Treat people well. Push yourself to keep getting better. Don’t permit yourself substandard work. Keep your commitments. Communicate often and clearly. Don’t give up. There are more elements, but they’re all common sense.

We see this in many fields. You want to run a marathon in under 3 hours? Run often and far, and push against your limits. You want to be a superb oboe player? Practice for hours every day, and focus on the parts that are most difficult. You want to be well off? Spend frugally, save diligently. Again, it’s all common sense.

The problem with common sense is it’s not commonly applied. Software engineering is a profession that gravitates toward complexity. As a result, we fetishize intelligence and cleverness. We do it to the degree that we forget what it really takes to be successful. We confused complicated with difficult, but complicated is rarely the key to professional success. If you think that complexity and cleverness are the key, you will overlook the simple things you need to do.

The simple things come up every single day with every single thing you do. The complicated things are rare, and they only matter if you’ve gotten the simple things right. But simple does not mean easy. They’re not just hard; they’re harder than the complicated things. Maybe that’s why so many people want the answer to be complicated.

What a leader needs is to change the behavior of her organization. That is the essence of leadership. The good news is that there are many companies lining up to help you exactly that. The bad news is that it won’t work.

There are masses of enterprise software companies that are selling change. They sell tools, services, platforms, workflows, something something management software, etc., and they want you to believe that those are enough for the change you seek. The problem is that you cannot write a check and get change. The absence of a good tool may obstruct change, but there are a whole lot of other things that also obstruct change: lack of talent, fear of failure, vested interest in the status quo, a broken culture, conservatism bias, magical thinking, lack of resources, conflicting messages, unclear strategy, poorly-defined goals, and yes, bad leadership. Buying a tool will not solve any of those problems. If the absence of the tool is the only problem, then it’ll work. But it probably isn’t what most needs to change.

The seduction here is that what you want is the results of change. But who really wants to change? Change is hard. Change is uncomfortable. Change is humbling. The vast majority of the time we only change against our will when there is no alternative. The rest of the time it comes from inspiration, and you can’t write a check to buy inspiration.

What these companies are selling they can’t deliver. It’s not because they’re lying. It’s not because their product doesn’t work. It’s because their product usually only solves the easiest part of a multipart problem. The harder part is making the people in your organization think and behave differently so that they are willing to learn this product and apply it. Given the choice, I will take an inspired organization with the wrong tools any day of the week over an uninspired organization with an unlimited budget for tools. Writing a tech for a tool is an easy answer that won’t work. Changing people is hard, but it’s the only way to succeed.

If you’re the leader of a large organization, pretty much everything is your fault. Major bug? You didn’t have proper training. Someone embezzled money? You didn’t have proper controls. Sexual harassment lawsuit? You didn’t keep out the douchebags. No product innovation? You didn’t foster a creative environment. COVID-19 crushed your business? You didn’t hedge your bets.

If you are a leader, and you collect the rewards that come with that status, you must accept that everything is your fault. You certainly get rewarded and take credit when anything goes well. That cuts both ways. There is almost nothing that is completely new and cannot be planned for. Whether it’s worth planning for is another question, but it should be a decision not an oversight. Everybody talks about how nobody could see COVID-19 coming, but Wimbledon had pandemic insurance!

Even if you didn’t know exactly what was going to happen, you’ve got to know that some kind of bad thing could happen. COVID-19 is a rare one, but bugs, outages, sexual harassment, and other types of failures are practically guaranteed. If they’re not prevented… it’s your fault. If you can’t accept that, you shouldn’t have the job.

Delegation is critical to scaling your leadership, but it’s so very easy to get wrong. You can give too much autonomy or micromanage. You can delegate to someone who isn’t ready for the responsibility or who doesn’t have the bandwidth. You may not give them the authority or political capital they need to get the job done.

There are many ways to go wrong, but there’s a minimum structure needed to make it work. I call it GODDAMN delegation:

• Goal
• Owner
• Deadline
• Delegation of authority
• Accountability MechaNism

Goal: ideally a SMART goal describing what success looks like.

Owner: the person responsible for getting it done. You can make this more elaborate with a responsibility assignment matrix, but this is the minimum.

Deadline: when you expect completion.

Delegation of authority: the ability to make decisions, direct staff, and allocate resources without requiring your approval.

Accountability mechanism: this is the most important overlooked one. How is this person going to make sure they’re on track? What are their obligations when it comes to reporting on progress, dealing with problems, and escalating blockers?

This is by no means sufficient for effective delegation in all cases. But I’d be hard-pressed to see any delegation reliably work without these key elements.

Across a large organization, you’re going to have to have many projects, some that are more important than others. Some of them will need you to guide them. Others are important, but the people managing it are capable, so they don’t need you. Or do they?

As clear as we try to be, we are sending many conflicting messages about importance. I remember an eight month period where, every one or two months, I had a key stakeholder tell me something was the highest priority. The only problem was that it was different every time. It sounds absurd, but smart but fallible people can fall into that trap because we can’t remember and think about everything all the time. So you can say something is important as much as you want, but sometimes the message will still get lost because that is not the only message you’re sending, and your messages are not the only ones they’re receiving.

You know what sends an emphatic message about importance? Your presence. Over the last few years, I have made it a point to show up in person to the status meetings of critical projects. I tend to be a minor participant at most. Sometimes I ask questions or am asked a question. Sometimes I’m not paying attention at all (but I try to minimize that).

I’d be hard pressed to say that my interventions were consistently needed or valuable. But I will say with confidence that my presence was needed and valuable. It was a powerful symbol that I chose to spend my limited time on that project. Everyone knows I could be focusing on any of fifty different things, but I can’t actually attend to more than a few of them during any given cycle. And everyone knows that.

Think about it. Your boss’s boss(‘s boss’s boss?) spends a half hour or an hour every week or two in a project status meeting. He doesn’t say a whole lot, but he’s usually there. Then there’s another project that you know of that has a similar meeting. He says it’s important, but you’ve never seen him in that meeting. Which one is more important?

It’s been easy for me to think that my value comes from what I say. It’s been hard for me to accept that I have stature and power. Once I did, though, I realized that sometimes my value didn’t at all come from what I said. It didn’t even come from what I heard. It just came from being visible, in attaching whatever stature and power I had to a project, establishing its importance to anyone on or around it, without even having to say a word.

Peter Drucker famously said, “Only three things happen naturally in organizations: friction, confusion, and under-performance.” This is what will result when people do what comes naturally to them. It is thus the purpose of a manager to induce, convince, cajole, bribe, influence, nudge, pressure, and otherwise persuade the members of their organization to act otherwise.

Yes, the job is also about strategy, communication, inspiration, accountability, and tough decisions, but all those are means the same end: modifying people’s behavior so they collectively achieve something more. Some of these are large scale behaviors, but mostly this is about behavior on a smaller, more quotidian scale. A leader should see her job as eventually shaping every aspect of every employee’s behavior. This is in part because there’s always room for improvement, but mostly it’s because the organization, its members, and its strategy are ever changing, so the leader must lead its members to evolve and adapt. Some people only need to change a tiny amount, while others need to change dramatically, but all need to change.

The leader’s job is to take an organization that doesn’t produce the desired results in the desired quantity for the desired cost and convert it into one that does. Those different outcomes can only come if the organization behaves differently. That organizational behavior is the combination of the behaviors of each member of the organization. The essence of a leader’s job is thus to cause change in the behavior of each member of the organization that leads to the whole organization becoming able to fulfill its ever-evolving purpose.

One of the most important parts of being an effective leader is choosing what to spend your time on. Just as important is choosing how much time to spend on it. The difference between the most effective leaders and everyone else isn’t that they’re smarter or harder-working. The difference is that they squeeze much more out of every hour they spend by focusing their energies where they can get the most impact for the effort.

The simplest way to understand this leverage is to look at every important project under way and assess what its current odds of success are. With rare exceptions, you ignore anything that’s likely to succeed. Those don’t need your time.

Instead, what needs your time are the projects that are probably going to fail. From those projects, choose the ones where you can improve their chances. The ones where you can’t, well, cancel those. With the ones that can be saved, you have a simple goal: take them from “probably going to fail” to “probably going to succeed.” Once you do that, you exit stage left and don’t come back.

This simplification is, like most simplifications, wrong. But it’s not that wrong. Any time you are considering putting your scarce time into something, ask yourself two questions. The first is whether the project is already likely to succeed. The second is, if it’s not, whether you can realistically hope to make it a probable success.

You can invest in probable successes and in likely failures and improve the odds. That may be worth it. But you need to think about what is losing your energy and attention for you to do that. There’s a nearly infinite number of things you can do, but everything you choose to do comes at the cost of what you don’t have time to do. If you invest your time into projects where you have low leverage, then you’re probably ignoring projects that would really benefit from your attention, whose paths can be changed.

I have a large organization that I’m responsible for. With so many different projects and layers of management, it’s really easy for me to get out of touch with the people doing the work of building products. It’s also easy for me to be a distant, unknown figure. To partly address both of these problems, I do regular skip levels with people in my reporting chain. Right now, I have it set up to be at least a half hour twice a year with every manager and senior individual contributor. I used to do most of these in person when I visited the various offices, though it’s all via video conference right now because of COVID-19.

I have a simple, informal agenda. Half of that agenda is for me. I want to know how the person is doing, both psychologically and professionally. I want to know if they have concerns about how the organization is running and being led. I want to solicit feedback on their manager to help me better coach them. I am not there to give instructions; that would undermine both the purpose of the meeting as well as their direct manager’s role.

The other half of the agenda is for them. What changes do they want to see? What do they not understand or disagree with in how the organization is running? What questions can I answer and explain? What do they want advice on? How can I help them be successful, both in their current role but also with respect to their professional goals? I emphasize that I want to serve them in the meeting. If something is important to them to bring up with me, I will consider it important enough to discuss with them. I try to establish a safe, casual tone from the beginning, emphasizing that I am there to help them and to become a better leader.

When I have a skip level with a particular person for the first time, I explain all of this. I also assure them that I’m available beyond the regular schedule. The schedule sets a minimum, not a maximum. It’s also not the only way to communicate. I want them to email me or chat or set up another meeting if they need to, so I try to make sure the ice is broken so they feel comfortable doing that.

I’ve been doing things this way for years, though some of the logistics have changed as my organization has grown and circumstances have changed. I think it’s working. This is a difficult thing to collect data on. The desired effects are that members of the organization feel like their needs are attended to and their concerns are heard, and that I am a more effective leader. Anecdotally, I have evidence for the former. As for the latter… I can only hope.