Managing Managers

A note of caution here is that if your manager is a project manager, do not ever aspire to take that seat. In good software companies, I believe that role would disappear in near future. It’s as redundant as “ueue” in Queue.

Managing Managers

For this post, the definition of a manager is the person you report to. Could be an engineering manager, a senior engineer, a technical manager, a product manager, a program manager, a CEO, or a project manager.

In a corporate company, the crux of managing managers is to make their jobs easier. The golden rule of thumb is to do what would impress the manager’s manager. A friend of mine worked in a corporate company. One of the interesting things he does is that he has a better relationship with his manager’s manager than his direct manager. This is a direct corollary of the fact that you should make your manager’s job easier but a few shades darker. This is nearly essential in big companies because they are all about hierarchy. Most of them. Ideally, you should work like your manager doesn't have to manage you at all.

In most companies, every person would get promoted until they are doing a job that they suck at. This is paradoxical yet so true. We do not appreciate a person doing his best job by paying them more but instead we put them in a position where they are not the best. This goes both ways. People think that climbing the career ladder is essential. People rave about titles so much so that a quarter of Goldman Sachs employees are Vice Presidents. Epic... This tendency makes companies promote people and especially award inflated titles. This is why your manager might suck at his/her job but suck it up. To do well, or to get promoted, help your manager get a promotion so you can take that seat.

If you report to the CEO, you don’t have that problem because you can’t be promoted. You have to do what’s expected of you and you would do great. Consequently, you will be compensated in terms of salary and/or equity.

A note of caution here is that if your manager is a project manager (someone who just does project management), do not ever aspire to take that seat. In good software companies, I believe that role would disappear in near future. It’s as redundant as “ueue” in Queue.

I often say that hire people you don’t have to manage. Fire people, you have to manage a lot. This is why you should aim to make your manager redundant. Make it so smooth that they never have to bother managing you. Be self-managed. Communicate what you are doing upfront. What you are thinking. When you are done with work, seek work. You will always have to work more than you can deliver. Work through it one task at a time. If you think something would be delayed and is urgent, tell them upfront. If someone is dependent on you, unblock others first. What we keep for retrospectives should be discussed when needed. Raise points of concern when you see them happen. Be clear, transparent, and straightforward with your manager.

I once worked in an organization. They measured engineers' performance on various scales. One of them was a tool that measured the code output in terms of quality, quantity, and complexity. If I were to rank better among my employees, I had to produce more code. I had to work on complex pieces of code, do more code reviews and request for changes on PRs more often. Doing something along these lines would rank me better. Knowing that that tool is in use, I felt discouraged to work on tasks that wouldn't produce much code. For example, brainstorming about unifying complex features from the product's perspective. Something that would make the product simple and reduce the code's complexity. Churning more code/PRs would look better but pondering over improving the product and simplifying the code base would help business in the longer run. This conflict is an example of the principal-agent problem.

The principal-agent problem is a conflict in priorities between a person or group and the representative authorized to act on their behalf.

Sometimes, the KPIs you have to optimize to get a raise or promotion is not in the best interest of the company. When faced with such a situation, be kind to yourself and the company. Do what is best for the business and don't over-optimize on getting a promotion or a raise. In the long run, you will reap great rewards. You will develop a sense of finding and working on the stuff that matters instead of working to make vanity metrics look good. It is a lifelong skill. Instead of working for a few peanuts worth of raises at your current company, become a completely leveled-up being and apply for better companies/roles. More on the topic of getting promotions and raises later and why you shouldn't chase them.

Having an understanding of what you work on and making the manager redundant in that regard will pay dividends. Imagine you are stuck under a bad boss who doesn't have their priorities aligned. Let's say they suffer from a principal-agent problem and optimize on the wrong end of the spectrum. In presence of such a boss, you should be able to derive what's the best use of your time. You still might need to do what your boss tells you. You will learn an important skill. How to work under a bad boss and still level up.

Working with toxic managers helps a bit. It will give you an understanding of how it feels like and what not to do when you are managing someone. But don't stay in that position for too long. If you are starting out even if you think you have the best manager, don't stay in your first company for too long. There is a possibility that you have a toxic workplace and manager and you don't even realize because you haven't seen the other end. So move around and explore.

Managing CEOs is a bit different than you would manage a line manager. CEOs are busy people. Being an individual contributor it’s not easy to imagine what it feels like being bombarded by information of 20 different kinds coming from 10 different people who expect you to solve their problems. Before sending a message, think about that.

Good communication is about trying to put yourself in your audience’s shoes and then opening your mouth/hitting that send button. A word of caution; as much as this will help you become a better software engineer, this might not be the optimal strategy when you are the CEO.

CEOs, the good ones, usually want you to answer one question. What can they do for you? As much as you are working for the CEO, CEOs are working for you. When you approach one, be clear about what you want him/her to do. Don’t be a forever harbinger of bad news, a whiner, or a status reporter. It falls as white noise on busy ears. Approach with a clear ask.

A fitting example to explain this is the time I worked in a development agency. At one point in time, a big agency could be working on 40-50 different projects. Services companies have their own challenges and in many projects, there is some level of firefighting going on. The projects are outsourced. Requirements and expectations are not aligned correctly and it creates all sorts of tension between the client and the agency. In our company, each project had its project manager assigned and they reported to a senior manager who in turn reported to the CEO. Each manager was used to complaining about their problems and how they are understaffed and needed more people to take care of the worries of clients. Most senior managers there were the people having the least skin in the game and they would just give a perspective of an outsider and somewhat from their experience as a manager in an attempt to steer things in a better direction. The company held a management meeting every week in which they presented a status report to the CEO for each project. They used to discuss important problems and try to hash out action items to fix them.

As the company expanded and went aggressive in sales, over time the status reports were so full of problems that every other project had many issues to be discussed in a one-hour meeting. A CEO can’t comment on all of those issues with a minimal amount of context. Over time they added a green, yellow, and red status to each project. They would only discuss the red projects as they are the ones on brink of failure. It started well but with time the number of green projects became a single digit. With all these issues and problems, a lot of what project managers said was white noise for the CEO. I believe, in most software teams, the role of a project manager is redundant and there is hardly a justifiable need for it. They are just messengers at best and epic time-wasting productivity killers at worst. This is not a global phenomenon but this does happen in many companies around the world. Project managers in our company certainly did not go to the CEO with a clear ask. They would regurgitate status reports and problems while being oblivious to the fact that they have become white noise. The number one reason they did so was to offload the burden from their shoulders as a mechanism to cover their ass when it comes to that. I had heard recordings of some of those manager meetings. I bet the signal-to-noise ratio approached zero. This is when some senior managers and the CEO started talking directly to technical leads to get a better picture of what was going on.

While talking to the CEO, consider how many people is he/she working with. Couch your ask in a way that makes the most impact. TLDR first and then details if necessary. Get to the point fast. Really fast.

If you are the only other employee then consider yourself a co-founder. That would be good for your startup. You and your CEO can exchange imperfect ideas and casually talk as a form of brainstorming about various matters at hand. As an engineer from a big company would rarely get a chance to talk to your CEO. When you do, make absolutely sure you don’t screw it up.