Lots of people complain about meetings. I don’t. We are social creatures building something together. Meetings are how we get work done.

What I dislike are meetings that grow without enough thought. Everyone’s read or heard the trope about how much meetings cost per hour. There’s another cost that isn’t talked about as much.

Every added attendee of a meeting is a tax on the existing attendees. In a productive meeting, only one person can talk at once. The more people you have present, the more topics people will want to discuss, and the more aspects of each topic they’ll want to discuss. If the meeting stays the same length, that means everyone gets a smaller share. That means it’s less likely to reach resolution, and either the issue will be unresolved or you’ll need another meeting. Alternatively, the meeting is lengthened. Either way, it’s a cost that others will have to bear.

This tax is proportional to the size of the meeting. Adding another person to a four person meeting taxes four people. Adding another person to a ten person meeting taxes ten. When you add that person, your meeting starts off in the hole. To make it worth it, that person has to add value, and it’s not just some value but more value than they take away. Otherwise you made everything worse for everybody.

In management and life, I have failed many times. There is something that I want, something that’s important to me, but what I’m trying isn’t working. Persistence is an admirable trait, but sometimes the right thing to do is to give up.

We have a product generating job recommendations. The product seemed to be getting adequate results when examined in isolation. However, when we tried a blackout test, where the whole product was disabled, we discovered that the overall outcomes without this product were better than with it. While there were outcomes that could be attributed to the product, they were simple substitution or cannibalization of outcomes that would have come through other means. Many of us believed in the idea, but the product wasn’t working well enough, and we had no specific ideas or credible plans to make it substantially better. So we halted it, not because we didn’t believe in it, but because there was too big a gap between what we knew how to do and what we needed to do.

My son eats like a raccoon. Doesn’t use silverware, uses both hands, makes a mess. At every meal I would chastise him and remind him to eat one-handed or to use utensils. If I wasn’t watching, or a couple of minutes passed, he went right back to the way he was. Every meal for years. I think manners matter. I think his manners are poor. But what I was doing wasn’t working, and I didn’t have any better ideas.

Giving up now doesn’t mean giving up forever. Giving up on a tactic doesn’t mean giving up on a goal. It just means you recognize there’s no profit in banging your head against a brick wall. Use your energy on one of the hundreds of things you can make progress on. Don’t blow it on something that won’t budge.

I’ve interviewed hundreds of candidates for management positions. One of the questions I ask candidates is what their team thinks of them. I often get answers like, “I think they like me,” “they seem to respect me,” and the ever popular “my attrition is low.”

What’s astonishing about these answers is that they’re guesses. A manager, whose primary job is working with people, does not know what those people think. For some of them, it hasn’t even occurred to them to think about it.

The tragedy here is not just that the answers are important. It certainly is important. These are the people who have the best knowledge of how these managers work, and they’re also the ones most impacted by the manager. But the real tragedy is how easy the answers are to get.

I make it a habit to ask my direct reports what they think of my performance at least once a quarter. I typically do it in the middle of the quarter so that it’s not near any performance review period so they’re less anxious. I ask them if there are things I could do better, things I should stop doing, and things where I’m not active but should be. I also ask them if I am giving them the right balance of independence and direction.

Finally, I ask the most important question: “do you feel comfortable disagreeing with me or telling me when you think I’m wrong?” I don’t just listen to the answer. I watch them carefully and listen to how they answer. If they say yes, that they are comfortable disagreeing with me and telling me I’m wrong, I want to really believe it. If they hesitate, if they’re unsure, if they’re too quick to answer, then I’ll know they’re trying to tell me what they think I want to hear.

Between this and 360 feedback, I have a pretty good idea what my team thinks of me. If someone asked me, I could answer confidently and definitively. I wouldn’t have to guess. That’s not about being interviewed. It’s about being a little bit better of a manager every day.

Often requests come to us from stakeholders that are vaguely stated. That does not mean they won’t have expectations. It just means that they haven’t taken the time to think them through and articulate them. When you deliver, they’ll discover what their expectations were, and they’ll give you the hairy eyeball if you didn’t meet them.

There are two possible solutions to this problem. The first is to try to discover their expectations. Dig into the request. Understand its background and its purpose. Find out the parameters of the deliverable. This can work, but it requires them to be cooperative and to know what they want. If they had the patience and knowledge to do that, they probably would have done it from the beginning. So on to plan B.

Plan B is to tell them what you’re going to deliver. If they know what they want or at least can figure it out, they’ll correct you. If they don’t know what they want, you will fill the void. That way other notions can’t sneak in when you’re not looking. Either way, you’re better off than you would be if you guessed at what they wanted.

A manager’s job is to deliver results in the short-term and the long-term. There’s a lot that goes into it, but ultimately the manager is accountable for the results, not for the effort. Being accountable does not mean the manager gets credit for them. There’s a contradiction at the heart of being a good manager: if things go well, it’s because you hired a great team. If things go poorly, it’s because you’re a bad manager.

The first part requires a recognition that the manager doesn’t actually do the work. You plan, coordinate, coach, communicate, and so forth, but you don’t make the deliverable. You need the team for that. In addition, if you want credit, you shouldn’t be a manager. Being a manager is about other people not about you.

The second part is because you’re ultimately accountable for the results no matter what. If there’s a problem with someone on the team, it’s your job to fix that problem, work around it, or replace the person. Most failure modes for the team and the deliverable are in some way your responsibility and within your power to fix. If there’s a proximate cause to failing to deliver, there’s likely an upstream failure that you didn’t address or prevent.

This contradiction may seem unfair. Maybe it is. If that apparent unfairness makes you not want to be a manager, perhaps that’s for the best. If you’re willing to accept it, maybe you have the right mentality. Also, it’s not like it’s truly unfair. In most organizations, you can advance further on the management track than you can on the individual contributor track. That means more money and more authority. That makes up for quite a lot.

Every leader thinks they want high quality work. They often overestimate what it takes to get high quality work. Getting high quality work is one of those things that is simple but difficult. All it takes are three things:

• Assign the work to people who are capable of high quality work
• Reject anything that is not high quality work
• Pay what it takes in money and time

Almost all of the time that someone is not getting high quality work, they’re skipping at least one of these.

A lot of leaders emphasize the importance of hiring the right people. That’s necessary but not sufficient. Even the best of us gets lazy sometimes and needs some reinforcement to keep our standards up. They may want high quality work, but they don’t have the discipline to insist on it. They aren’t willing to reject low quality work because they think they’ll be a jerk. There’s certainly a jerky way to do it, but you can reject work without being a jerk.

Then there’s cost. What’s often happening when leaders complain about not getting high quality work is that they’re really complaining that they’re not getting high quality work cheaply and quickly. That’s just not being in touch with reality. Complain all you want, but if you’re not willing to pay up, the people who can produce high quality work won’t bother with you. They’ll go with someone who appreciates what it takes.

The royal “we:” I. “We will have crumpets at tea” means “I will have crumpets at tea.”

The common “we:” you and I. “We should go to the beach this weekend” means “you and I should go to the beach this summer.”

The managerial “we:” you. “We’re going to have to stay late to finish this project” means “you’re going to have to stay late to finish this project.”

The most valuable technologies I have built had at their core some pretty clever ideas. That wasn’t all of it, though. They also had some stupid ideas. Not stupid bad but stupid crude and stupid simple.

For instance, I worked on a load-balancing system with some ingenious methods for distributing load across a pool of servers. I also had a service registry. Kind of. They were text files with hostname:port pairs, one per line. The core idea was really clever. The service registry? Dumb as a sack of hammers. This is the sweet spot.

The easy case is something that is stupid top to bottom. If there are no clever bits, what is it doing for you? It might be doing something useful, but it’s probably not that useful. It’s probably inflexible and narrow, like a basic shell script.

Consider a project that is clever all the way through. Maybe the core of it is some insane gradient descent algorithm, and that should be clever. But what about its logging? What about how it takes input? What about how it allocates and frees memory? Do those need to be clever? Not only do they not need to be clever, but it’s almost certainly harmful if they are.

Every bit of cleverness adds implementation cost, maintenance cost, failure modes, and difficulty debugging. Software programs follow the Pareto Principle, but to an extreme. Instead of 20% of the code contributing 80% of the value, it’s probably 4% of the code contributing 96% of the value. The rest is just bookkeeping and logistics. You certainly want those things done well and efficiently, but they’re clear candidates for satisficing. Save your maximizing for the 4%. Making the 96% fancy won’t make your product any better, and it’ll almost certainly make it worse.

Every plan has flaws. If someone presents a plan to you, it’s definitely helping them to identify flaws in their plan. When you do, though, distinguish between fatal flaws and fixable flaws. Does the flaw you’ve found mean the plan should be thrown out entirely? Or does it identify a way to improve the plan? What I’ve seen most often is that someone identifies a fixable flaw but it’s heard as a fatal flaw. This does not tend to be an enjoyable experience for either party.

I have a large organization to keep track of. It’s easy for me to get out of touch with the day-to-day work of people actually building the software that powers the business. It’s also easy for them to get disconnected from leadership. One of the ways that I try to address this is with periodic skip-level meetings.

A skip-level meeting is just a meeting with someone who indirectly reports to you. I have set up recurring 1:1s with every manager and senior individual contributor. I’ve set the schedule at one half hour every six months because I don’t have the capacity to talk to every one of those individuals more often. I think this is the lowest acceptable frequency Quarterly is good as well.

One thing I try to do is to sent them a message explaining the meeting when I schedule it. Getting an invitation to have a mysterious 1:1 meeting with your VP could be nerve-wracking. I want to prepare them so they’re not nervous, or at least less nervous.

I see the agenda as being similar to a typical one-on-one with a direct report. It’s primarily their time. I do go in wanting to know how they’re doing, both psychologically and practically. I also want to understand if there is guidance they want me to give to their manager. Other than that, though, I want to talk about what they want to talk about. Sometimes it’s questions about our strategy, sometimes it’s about their career and growth, sometimes it’s about policy, sometimes it’s about specific technology… It doesn’t matter to me. I tell them not to worry about whether something is important to me. If they’re in my organization, and something is important to them, it is at least important enough for me to spend a few minutes discussing it with them.

There are three things I avoid doing in skip levels. One is asking for status updates. I should be able to get information on the projects and products some other way. I don’t want to spend their time getting me up to date. That serves me, and the goal is to serve them.

I also don’t give them instructions. That’s for two reasons. I don’t want to spend the time that way, and I want them to lean on the organizational structure for that. I want them to see their direct manager as the primary source of instructions, and only in urgent circumstances should I give instructions myself. This is also why I prefer to do these no more frequently than once per quarter. If they have a 1:1 with me every few weeks, then there’s a higher chance they’ll come to me for something instead of going to their direct manager.

Finally, I don’t make any decisions or commitments to do anything other than to look into something. Maybe they disagree with a technology choice, think our strategy is dumb, or have a problem with their coworker. These concerns are all important for me to hear, but there’s no way I can expect to fully understand the situation just hearing it from them. I’m not going to make a commitment to do anything before I understand the situation, and often the circumstances where they most want me to do something are the ones that are most complicated where I need to get multiple perspectives.

When we finish the discussion, I stress to them is that the recurring schedule represents a minimum. They can email me, chat me, or set up a (currently virtual) meeting in a free slot in my calendar. I want them to know I’m available to them if they need me. They need to know that I’m not too busy for them overall. I may be too busy at specific times, but I’m nothing without my team. If I can’t make time for them, and there’s no emergency going on, where are my priorities?