When someone asks you for help solving a problem, ask them, “what have you tried so far?” People asking for help are going to fall into two rough categories.

In the first category are the ones who came to you for help only after they failed to solve their problem on their own. These people are hard-working and earnest. Often they’re smart and capable. Finding out what they’ve tried so far saves you from wasting your time trying things that won’t work.

Then there’s the second category. Those are the people who haven’t put in the effort. Maybe they’re not hard-working, maybe they’re not capable. Those people should not be coming to you for help, but it’s not nice to say so. But if you ask them what they’ve tried so far, and they say “nothing?” Well. That sets you up to politely refused to invest any more time into their problem than they have. Pretty soon they’ll figure out this is what you’re going to ask. Either they’ll try harder, or they’ll stop coming to you. Either way, you’re better off.

I was talking to someone who worked on Microsoft Word early in his career. He joked that, if there were any irritating bugs in there, it was probably his fault. My instant internal reaction was that it was definitely not. Individuals don’t cause bugs. Systems cause bugs.

When people encounter buggy software, the often complain that the software engineers must be bad. It’s possible that the software engineers were bad. After all, someone had to write the bug in the first place*. That doesn’t mean it had to go to production.

Maybe there was a bad engineering manager at work. They made commitments without consulting the team, signed on to features without scoping them, and thought design was a waste of time. Maybe they drove the team to work twelve hour days for months on end. You take a great software engineer and put them in that situation, and you’re going to get bugs.

There are also other individuals involved. Maybe the designer came up with a bad UI. Maybe the product manager always pushed fixing bugs to the sixth subbasement of the backlog. Maybe the QA team isn’t being thorough enough.

More likely it’s a higher level leadership problem. Maybe there’s an executive sponsor who thinks software engineers and product managers can do the QA in a short-sighted attempt to constrain costs. Maybe they don’t believe in training. Maybe they insist on hiring only lower cost new college graduates rather than experienced engineers. Maybe they create perverse incentives, where teams are rewarded based on hitting dates but not on the quality of what does hit that date.

That’s often where the root of the problem lies. A good leader will certainly push for substantial delivery quickly, but a good leader will also be in touch with reality. They’ll know that people need training to build their skills. They’ll know that the team needs to be able to influence the feature list or the deadline and probably both. They’ll know that non-feature work, like writing unit tests or refactoring messy code, will pay off eventually. They’ll know all these things and they’ll fund them, with money, staff, and time.

When you try to use buggy software, it’s okay to be frustrated. Just recognize that it’s not an individual problem. It wasn’t one person that released that bug. It was a whole team that did it.

* assuming it’s even that kind of bug, with explicitly incorrect behavior, as opposed to something else, like an unexpected consequence, platform limitations, or a missing feature.

There are two questions/frustrations I frequently hear from leaders about the work people are doing in their organizations. One is “why are they doing that [thing that I don’t think is important]?” The other is “why aren’t they doing [that thing I think is important]?”

There’s an easy answer to both: because you didn’t tell them what you thought was important. I’m sure your immediate internal response was, “I can’t tell them everything!” You’re right! You can’t. Realistically, we actually only say maybe 10% of what we mean. We rely on context, precedent, and people’s good judgment to fill in the rest. If they can’t do that, it’s a real problem.

But that’s not the same as expecting them to be able to read your mind. For one thing, you may be saying the wrong 10%. Or you may be saying it wrong. Even if you’re saying it right, you can’t realistically expect people to guess right on the unsaid 90%. This is inescapable trade-off of working with people. They’re going to make different decisions than you. Sometimes they’ll be better ones that you would have made, but even if they’re always worse, you have to accept it. They’re not going to always fill in the blanks the right way. As the leader, this is your problem. Find a way to fix it.

When I first became a manager, three of my direct reports were new college graduates. The start of my professional career had been rocky. I was clueless, and my managers were not very good at coaching. Oh, and then there was the dot-com bust, which derailed me multiple times. I often think about what my career could have been with more support and without the external shocks. I was determined to do better for my new recruits.

What I realized was that my previous managers weren’t invested in me, and they didn’t seem to appreciate what was at stake for me. They chose what projects I worked on, how much I had to work, what I learned, how to help me, how much I got paid, and whether I had a job. That is an immense amount of power, but it was actually even more significant.

When I compared my career to my peers, it became apparent to me how important the first job was. That first job was key to my understanding of what a job was like, what it took to succeed, and what I was capable of. Unfortunately, I didn’t learn any of those things from that first job. Maybe it was mostly my fault, but my managers didn’t seem to try either.

That’s when I realized that being someone’s manager is a sacred trust. As a manager, you have massive control over someone’s present. Even more, when someone has little other professional experience, you have massive influence over their future. What do they learn? What can they demonstrate? What can they brag about? Do they look forward to their career with optimism, as something that can help them fulfill some greater purpose? Or do they see it as a necessary burden to keep from starving?

If you screw up, sure, they can recover. With a lot of luck, I did. But did I recover to where I would have been otherwise? And what if I hadn’t quite been so lucky? If you don’t do well for them, they’re going to be in a hole.
It’s your responsibility to keep them out of that hole and then ahead. That first job affects the slope of their career. One day, they’ll leave you. If you did your job right, it’ll be after a good long time, and they’ll leave on a much steeper trajectory than they came in on. It’s more than just paying money and getting work. You are influencing the shape of their entire life. If you don’t treat that responsibility with reverence, perhaps this is not your calling.

A determined professional will strive to keep learning throughout their career. Sometimes that learning is easier. Sometimes it’s harder.

If you focus on facts, you’ll find learning gets easier. The act of learning makes you a better learner, and you can build on previous knowledge. Learning your fifth programming language standard library is going to be easier than learning your first programming language’s standard library.

Deeper hard skills are sometimes easier and sometimes harder. They can be easier when they’re just reformulations of stuff you already knew. They’re harder when they represent new paradigms unlike anything in your experience and thus contradict the intuition you’ve developed over the years. This can also challenge your ego, making you stay within your comfort zone of expertise so you never feel like a n00b.

What will keep getting harder to learn are the soft skills. One reason for that is that that type of learning often comes from mistakes, and as you become more established and more comfortable, you may make fewer mistakes. It’s easy to see that as a positive development. It mostly is, but if you’re not making mistakes, you’re not challenging yourself, and you won’t be growing.

But I think the biggest challenge is that, inevitably, what’s left for you to learn is what’s hardest for you to learn. Maybe there’s a problem or an ability that’s invisible to you, that you can’t even perceive, like color-blindness. Maybe you can see it, but you don’t understand how it happens. Or, perhaps you can see the problem and understand why it happens, but you struggle to exercise the self-control or skill to deal with it. The problems that you can readily see, understand, and deal with? You took care of those when you were 25, when you were 30. Once you get a decade or two into your career, those low-hanging fruit have been plucked, and all that’s left are the ones that are hard to reach (or in a different tree entirely).

What’s particularly galling is that the things you have to learn are yours to learn. Some things come easily to you and only with difficulty to others, perhaps never. The opposite is true as well. I have no idea what makes some things easy for some people but hard for others, but I do know it can be surprising what people have trouble understanding. I’m sure what I’ve failed to understand has been surprising for others.

I think this is one reason (of many) why many people’s careers stall out at a middle level. The way that you’ve been learning and improving stops working. The problem is nobody tells you it’s stopped working. You just… stopped, and unless you find a new way of identifying your blindspots, understanding what’s in them, and adapting your behavior, you’re going to stay stopped.

Life is disappointment. When you try to do hard things, you’re going to fail a lot. You’re going to get rejected a lot. Hearing “no” sucks. You have to get used to it and learn to deal with it, but it’s always going to be unpleasant.

The thing about hearing no is that it brings closure. Closure brings clarity. If I know one door is closed, I can explore other doors, even windows. If I get that no quickly, I can move on without losing time or emotional investment. Any long term goal I am pursuing will be achievable through multiple strategies. Plan A doesn’t work? Then I’ll go to plan B. Or C. Or D. But I have something to fall back on so I can at least make progress.

Compare that to a slow yes. Until you actually get that answer, a slow yes isn’t a yes, it’s a maybe. A maybe means you’re stuck. You have an unresolved possibility that keeps you from executing plan A but also falling back on plan B. Meanwhile, you’re burning time. You’re investing your emotional energy. And after all that, it could still end up being a no, just a really slow one.

I understand why it happens. You have hope. You don’t want to lose that hope, but you will if you hear that no. The person you’re waiting doesn’t want to disappoint you. They don’t mean to string you along, but they’re doing it. They think they’ll be hurting you by saying “no. Sure, it’s a disappointment, but it liberates you as well. You can put that maybe out of your mind and focus on the next step. You need momentum, and losing that momentum to a slow yes is going to hurt you a lot more than a fast no.

I’m not good at persuasion. I often get pushback and disagreement with the ideas I advocate. But, while I’m not good, I’m less bad than I used to be. I’ve learned a few things in that time.

Years ago I had a 1:1 with my then-boss. I had been mulling over an idea for weeks, and I was finally ready to talk about it. I pitched it to him. He had some questions, and we talked it through. And then… he wasn’t convinced. It’s not that he thought it was a bad idea. He just wasn’t ready to say it was a good enough idea that I should go and do. I was frustrated. How did he not see what a good idea it was. Then I had an epiphany. It took me six weeks to come to a conclusion, and I was expecting him to make that same journey in twenty minutes? The lesson I took away was that it takes time for people to get comfortable with an idea. You can’t rush them through the process.

Another lesson I’ve learned is that people need to hear an idea multiple times. As much as we might like to believe that facts only need to be stated once, it’s just not true. Repetition matters. Repeating an idea increases familiarity. When people hear an idea more times, they’re more comfortable with it, and they’re more able to conceive of it becoming a reality. This one is difficult for me, because I’m often worried about pushing too hard and coming on too strong, but I might be overcompensating. The important thing here is spacing it out. Take a break between repetitions. Days, weeks, sometimes months. And talk about other things; don’t just be about one thing.

Another tactic I’ve learned is ineffective is dropping the bomb. I blame television and movies, where in some dramatic scene our hero shocks and awes the audience and converts them to a hitherto unthinkable point of view. That’s not drama, that’s fantasy. You don’t want to introduce a new idea to decision-makers in a group setting. Group dynamics favor conservatism. Group discussions can easily get lost in the weeds. Discussions in general often lose a sense of proportion, but it’s harder to regain control in a group than one on one. Before the group discussion, talk to the stakeholders one at a time. Understand what they care about, what they need. Outline your idea. Get their feedback. Understand their concerns and disagreements and try to adapt. If it works, then you can go into the meeting with everything lined up. If it doesn’t, it’ll be frustrating, but it won’t be nearly as frustrating as swinging and missing in front of a dozen people.

It’s frustrating to have to do all this “extra” work. Why can’t they just get it? I don’t know, but I have a clue based on how easily I am persuaded of things, which is to say, not very easily. It’s just hard. People take time to adjust to new ideas (see above), they need to become familiar with them them, and they’re conservative, social animals who behave differently in groups than they do on their own. You can’t change any of that. But you can change whether you’re going to attempt the easy route of ineffective tactics, or whether you’ll grind out the extra effort needed to actually have a chance at succeeding.

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.