I’ve posted a lot about all the weird and nerdy things I have been up to in the past, but something I really have not spent much time on is talking about is anything to do with time I’ve spent at work as a manager. It actually turns out to be a lot, maybe six or seven years in a couple of different stints, sometimes with as many as ten people reporting to me. I don’t write about it much though because I don’t consider it to be my “core thing” — as in, the thing I really identify as being my calling in life.
But I have done it, and by some measures, I think I did a good job. My reports, in general, liked working with me from what I gathered at least. But I was fatefully bad at “managing up” and routinely demonstrating my worth and the worth of my groups to those above. Probably not unrelated: I lost my management position twice.
The first time it was because the company decided to follow the G.E. Jack Welch model of having a flat organization, and when they flattened us down to a mandatory five levels or less, I was bumped back from manager to individual contributor. The second time I was “de-managered” was during the 2009 recession, and the teams I was in charge of were off-shored, making my position unneeded. Came pretty close to losing my job but was able to move again back into a technical position.
So that’s the setup for who you are getting management advice from; not exactly a ringing endorsement of my qualifications on the subject, I know. But I like to think I learned a few things along the way though. I am sharing them here, even if to be honest it is not very likely that I will return to a full-time management job and use them myself any time soon.
Should You Take That Management Position?
On one occasion I took a management job in another group in order to leave a somewhat toxic, high-pressure work environment that had developed within my current group. It was an escape, and allowed me to work for a manager that I admired. Getting out of a bad work situation was probably the right thing. But the problem was, it really was not a job I found very interesting.
This “Line Manager” job had me working strictly as a people manager for several small groups, with about seven reports under me. In my previous management jobs, my responsibilities included a mix of technical work and supervision of junior employees, but in this case, there was no technical work, just the people manager part.
That right there should have been a warning sign to me. Some people aspire to move up the ladder, considering the individual technical contribution phase of their career as a stepping stone to bigger things. What I eventually learned in my case was, being an engineer is my “core thing”, not a step on a journey somewhere else - and attempting to abandon it completely to be a full-time manager was a mistake.
The biggest problem for me transitioning from engineer to manager was having to give up some amount of creative decision-making that I was used to in my technical position. The parts I really like about being an engineer tend to be finding good ways to solve problems, thinking up new approaches, getting past roadblocks by finding a non-obvious path, and so on.
The manager position I held though ended up being largely administrative. Attending meetings, holding employee 1x1s, tracking progress, giving feedback to employees on their work. All of these are valuable things to be doing, but it felt very much to me like “turn the crank”, meaning it was just a job and required very little actual decision-making on my part.
Looking back, I was not very excited about my job during some of these years. In the case of my company, line managers did not have a budget to control, had very limited ability to unilaterally make hiring and firing decisions, and lacked a lot of power to start new initiatives. So not much ability to actually effect change. Perhaps in a startup situation or a different company culture I would have fared better in this position, but I learned in the end that technical contribution was a better path for me.
Be a Beekeeper
In spite of any misgivings I might have had over those years about my manager jobs, I did try to give them my all. What I found was that I was much better at managing people who were achieving their goals, than I was at managing those who needed help because they were not. For that former case, I took a page from the book of a couple of previous managers I liked, who were very hands-off. I tried to model my management behaviors around things I appreciated from these former managers of mine. Providing top-level guidance, acting as a shield from outside disruptions (usually from upper management), being a cheerleader and advocate for people in my organization.
There is an old post from 1995 by science fiction author Orson Scott Card that compares the job of managing software engineers to that of bee-keeper. I am not sure I’m 100% in line with his version of the analogy, but I do like the general idea of software managers as beekeepers.
When you keep bees, you cannot really direct each bee to do things specifically, and attempting to do so is pretty counter-productive. What you can do though is to provide an environment that bees like. Protect them from danger. Provide access to materials they need. If you do that, and you are gentle in your overall management of them, you can harvest the honey. It was the general approach I preferred as a manager, and still prefer as someone who is managed.
This works great for managing people who are doing well, and I think it made me a pretty likable manager that people wanted to work for. As a result, I found it was a lot easier to get tough projects done, like quality pushes to fix bugs where no one really was enthusiastic about it. I could carry my gentle beekeper capital into these projects and get people motivated to make the honey.
The Hard Parts of Managing
But of course this is the easy part of the picture. In my tenure as manager, I was called upon to have difficult conversations with people as well. There were employees who were not doing what they needed to be doing, and my job required me to tell them about it, and find ways for them to improve. Some people could manage to improve and produce satisfactory work, but others could not, and I did have to fire a few people. There were also times when I have had to lay people off, and sometimes it was just people in the wrong place at the wrong time, and not someone with a real performance problem.
I’ve had people crying in my office after learning they have lost their jobs, and I have seen people get really defensive or angry when given negative feedback, to the point of quitting. I have had to intervene in a physical altercation between two employees, one of which was mine, and sort the whole situation out. I have had to tell an entire group of people that their project had been moved to another region of the world. What I came away with is an enhanced appreciation of just how hard the manager job really is.
A lasting effect of this has been that I try when possible to make sure my manager gets positive feedback as well. In addition to being a hard job, managing is often a thankless one. It is usually a lot more obvious when a technical contributor does something well than when someone in management does. You can see a cool new product feature in action but things like boosting a group’s morale, preventing someone from quitting over a short-term problem, or even making a decision to let someone go who needs to go are invisible, but equally valuable things.
In one case, we had to let go of someone who was creating havoc in our code, but who also refused to accept any feedback or modify his behavior, and was doing things like checking in code without reviews and then lying and saying it had been reviewed. It went on for far too long, but eventually, my boss had to make the call and fire this person. It was very tough because my boss was a really nice guy, and the guy we were firing was also (on a non-work level), pretty easy-going.
At the end of the day after the employee had collected his things and left, I visited my boss and thanked him, and told him that even though I knew it was hard, I thought he had made the right call. I could tell he really appreciated my support, but that also it was pretty uncommon for someone to actually say.
The Disciplinary Bonus
I was going to call this article “Getting Good at Bad Reviews” but I like the current title better because I am not sure you ever really can or should get good at it. Getting criticism from someone, even constructive criticism, is very often hard for both parties involved. It is even harder when the summary of a performance review is that the person needs to improve.
In some ways, it seems to me it should remain a hard task to give a “bad” review, because it should be infrequent. If you are giving so many “needs improvement” reviews that you got good at doing it, this would be a lot like a teacher who gives the entire class an “F” on their assignment — Is it because the kids are all stupid, or is it that you are a bad teacher?
So as such, I don’t have any always-works strategy regarding giving negative feedback to people, but I definitely know of some things you should avoid, and in doing so can allow you to maximize the chances of things going as smoothly as possible.
The first thing is about not giving mixed messages. There is this management strategy you may know called “the compliment sandwich”, where you say something positive about someone’s performance, then a criticism, then something positive at the end. So basically, good bread with bad meat. I am not going to completely condemn the idea, because it is good to highlight both positive and negative things in a performance review.
But the compliment sandwich can be confusing or even patronizing if done in an insincere or formulaic way. If someone thinks you are just throwing in positive feedback to make the negative more palatable, they are going to be less likely to listen to the message you are trying to give. Better in a lot of cases just to have a dedicated discussion about things that can be improved that is separate from the discussion and acknowledgment of the positive things.
Another example of mixed messaging that really bothered me a lot as a manager was how our bonus program was structured at one point. People would get a bonus, that had an ‘individual multiplier’ in the bonus calculation, based on the person’s performance. So the average guy got 1.0, but a good employee might get 1.1 or 1.2, and an underperforming employee got 0.9 maybe.
I have some issues with giving bonuses to underperforming employees, to begin with; I feel bonuses should be discretionary and not an entitlement. (I wrote about some personal experiences I had with bonus entitlement disasters before.) The real issue with this bonus plan though was the formula for your bonus was included in your bonus letter. So you would have the situation where someone got a “disciplinary bonus”, where the company gave them money, but also a message that they were getting less-than-average 0.9X bonus, because of their performance.
This confusing of incentives and performance review was (to me at least) a super-bad idea, because of the mixed message it gave. Bad idea for a company policy, and equally bad as a managerial strategy.
A Review is Just That
Aside from avoiding mixed messages, it turns out that I only have one real piece of advice left for managers regarding giving difficult reviews, and it is the idea that a review should actually be a review. What I mean here is, you should not be saying anything at an annual (or periodic) performance review that was not already covered in previous discussions with your report. It should literally just be a review of things you’ve talked about over the year, and no new criticism or negative feedback the employee has never heard should be given at it.
That sounds super simple, but I cannot tell you how many managers I have seen that violate this, and spring surprising, previously-undiscussed negative feedback on employees at their reviews. No one wants to be blind-sided by something during their review, much better to just go over known things from the past with an eye towards improving them.
I had an employee reporting to me who was going through a rough patch. He was burned out, was in the middle of a messy divorce, and had a previous boss who was quite critical of his missteps, regularly ranking him as “needs improvement”. When I took over the group he was part of, he was “acting out” on a routine basis, getting in heated arguments with people at meetings, and was in fact the person previously mentioned who got into a shoving match with an employee from another group.
In that incident, it had escalated and was about to go to HR when I stepped in, and my employee was actually thinking he had probably lost his job. That was a distinctly possible outcome, but in this case I talked with the other employee’s manager and we determined that an apology from my employee to the other would be sufficient. In my conversation with my employee, I was pretty blunt about the fact that his behavior was not acceptable, and that while he would keep his job, he had to apologize to the other employee, a plan to which he readily agreed with.
None of what I said then was really surprising information, it was already somewhat of a review and summary to my employee, and although blunt feedback, it was accepted. The same guy had a few other things go wrong later. In one notable instance he got mad one day and named an LSF queue job he submitted to our division’s compute farm “sh*t-f*cker”
, except without the stars, which immediately drew the wrath of our IT department staff that regularly monitored our farm jobs.
We worked through that one too, and I maintained a position of making it clear what is and is not acceptable, but also trying to be an advocate for him to improve. When review time came, we covered his accomplishments, which in spite of these incidents was actually impressive. But we also spent time reviewing the things that went wrong. None of what I brought up though was news to him. He acknowledged struggling with anger issues and that he was working to address them, and I gave at least an open-faced compliment sandwich by saying while he still should work to improve in this area, there had in fact been good progress.
In the end this person met somebody new, resolved some other personal things, and took on a new role in the company in a different group. We’re still on great terms, and I see someone now who is basically a different person than when I met him. This is another great takeaway - the idea that people can drastically change from a problematic employee, to a great one, just based on the situation they are in. In this regard, it is often worth giving someone another chance, even if they struggled in a previous job. People are not doomed to be bad employees forever.
Not every story ends this way of course. It’s not possible to have everyone you manage be happy with the feedback you give, or even agree with the feedback you give. The best you can do is to be consistent and predictable in how you go about it, stick to facts whenever possible. I would keep a little file of review topics for each of my employees - not something I archived or curated like a CIA dossier, but just simple reminders with concrete information like dates and details of things that happened, good and bad. This helped focus on the facts and issues rather than get in arguments about subjective things, like were you a “good employee” or not.
So that’s pretty much it. Predictability is king, I think, when it comes to being a manager. It is a basic building block of trust. If you know what your manager wants and can be sure they are being forthright and honest with their opinions of your work, you can build a great trusting working relationship, even if in some cases you do not see eye-to-eye.
All the best to my manager friends out there. You have a hard job, but an important one. Keep on keeping the bees in the best way possible, and we’ll try to send some honey your way.
Explore Further
Next Time: A follow-up on a previous article about weird and old storage systems, with a discussion on moving/magnetic storage systems and some strange reader contributions as well (clarification: the contributions are strange, not necessarily the readers). Time to get your magnets moving, moving for, Old Memories 2: Magnetic Boogaloo !
The Mad Ned Memo covers topics in computer engineering and technology, spanning the past forty or so years. Get your weekly dose of nerdy computer tales and discussions delivered right to your inbox, and never miss an issue! This newsletter comes to you ad-free and cost-free, and you can unsubscribe at any time.
The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information,
click here
.