I've been on the junior report side of this in my first job, and these points really resonate with me - it was the worst manager situation I've ever had, due to the situation-induced micromanaging and my having no one else in the same situation to validate how bad my experience was, or share a different perspective.
I switched teams as soon as I could, and I and that manager have both gone on to be reasonably successful - that manager has a lot of reports now who seem to really appreciate him, and I haven't had a bad manager since that situation. I think the bad manager-report scenario wasn't really about either of us nearly so much as it felt at the time.
It is validating to read this is an anti-pattern observed by a lot of people; it was hard not to take things personally at the time or blame the manager for how unhappy I was.
I've seen this several times when newly promoted managers are given 1 or 2 reports. Specifically individuals that are high conscientiousness, i.e. hard working, detail oriented, organized. Then they are promoted, and put into stressful position where there previous strengths can become liabilities and they spend all there time making sure their reports do the job in the same way they would have done it. And if they had more reports it would quickly break them of this micromanaging habit because they just don't have the time.
I found that more relaxed/laid back managers tend to do better with a 1-2 reports but then quickly start to run into issues as the team size grows and overwhelms their organizational abilities.
Yeah, I think that's about exactly it. He was micromanaging and also somewhat randomizing, asking me to switch focus often when he thought something else was higher priority, which doesn't work well for my work style in terms of actually getting things finished. And to my non-credit I didn't really communicate this issue to him at the time.
But I think he did figure it out much like you described, and is successfully managing (and not micromanaging) a high performing team today.
Once in a similar management dynamic, at my manager's request I compiled a presentation of several key points for a one-hour discussion, that my manager immediately hijacked for the first 15 minutes to lecture about why in the world I had started the numbered list of issues with the numeral zero rather than the numeral one. (It was a gating issue that was background to the others!)
So yes, I buy the hypothesis that 1:1 management grouping
promotes non-ideal management behavior.
It's worth taking a moment to identify what's so bad about micromanaging -- which turns out to be a serious fail for multiple reasons.
First is the obvious day-to-day impact on the subordinate, who finds it exasperating to be second-guessed so much on little stuff, or to burn up so much time briefing the boss on things that don't deeply matter.
Second is the inability of both boss and manager to focus on the big picture. Ten tiny tweaks on a misconceived project measure up poorly vs. one bold decision to redefine (or kill!) that project.
The third factor is subtler but perhaps even more important. People grow by making a certain number of fixable -- or unfixable -- mistakes on their own and then figuring out what to do next. That's how we build up a full repertoire of tacit knowledge that lets us make good decisions going forward. If we're getting micro-calibrations all the time from someone else, our ability to have confidence in our own decision trees never takes shape.
I spent three years in my 20s working on a big U.S. company's expansion into Europe that had only middling results. Our targets were high and the bosses had only a faint idea of what initiatives we were trying. That meant there was unlimited room for learning by doing. I came out of that with an enduring sense of "Yeah, that usually works," or "No, you're going to add a week of redo to the project if you try that."
And no amount of micromanaging would have got me there.
I wholeheartedly agree with these impacts. I feel like the 3rd by far the most pernicious... more than the job itself, the employee learns the bad behavior and hopefully how to avoid/manage rather than repeat the pattern when they are in a position of power.
When something is bad, I like to frame it in the context of how it robs value from a situation... in this case micromanagement takes away agency from the reports. It sub-communicates a lack of trust and essentially poisons a relationship from being much more than transactional.
Having been in the position with a single person under me before, the biggest challenge was that we had just enough work to do that it was too much for one person but not so much work that I could easily fill this other person's time. I am sure this was bittersweet especially for someone new to industry.
I expect there would also be the effect of every time you need something from him, it was the first time, so he had to wing it or think on his feet.
With 4 people, you've got a good chance that you're at least the second person to ask the question.
In a situation where he's harping on you for something, it would be hard to tell if this is just how he is, or he's specifically picking on you. If everyone is getting the same grief, then it's just how he is, not how he is with you.
Additionally, how many times do you want to give the same speech? Either you give up on something, or you gather everyone and address it at once (at which point you are not necessarily the target).
A big theme that my co-author and I write about is that process / incentive / team structure problems can easily masquerade as people problems. That is, it's common for someone to appear to be incompetent or a jerk as a person, when in reality a poorly designed system has incentivized them to behave in a certain way. This is one example.
I've experienced this with doctors, who apparently are incentiviced to "treat" many people fast, so they've relatively often given harmful or meaningless advice, they want to be done quickly.
I think those doctors are good people, it's a system problem: taking ones time (as a doctor) and looking for feedback the weeks after, to find out if they did right or not, isn't associated with any "reward" / kpi.
100%, this problem is endemic to human society. Generally most people are reasonably smart, are not assholes, are doing their best. But the incentives and team structures inherent to any organization make people behave in bad ways.
Yeah, it's usually a mistake for a manager to have 1 report, except in temporary situations like you are planning to have a 6-person iOS team, the team started off with just a manager and a budget, and they just hired the first person.
An org chart is like a B-tree; if you split it up and create a new node too early, you'll have more inefficient hierarchy than you need. Wait until one team is getting large before splitting it into multiples.
I agree. If you're leading a team of one, you're better off re-structuring things so that both you and the other person fall under your manager, and you can instead offer to mentor the other person if necessary. This strategy even works if it's a transient phase: you just acknowledge the transition plan with upper management and the other person so that they don't feel slighted when things get re-structured, and this enables someone who would be under your management to feel at ease talking to their "n+2".
(I'm of the firm belief that if you can't go and reach beyond your direct chain casually, something is wrong with the culture. This doesn't mean that one should be doing that, it just means that one can. Apply your best judgment to the situation of course)
This can be an issue because now the person who has decision making ability is now someone who has less project context, takes more time because they are busy with other projects, and has not nearly as much time to think about the project as the two people on it.
Not having someone whose full time job is being responsible for a project's success or failure has it's own set of drawbacks
But there is someone responsible for the project's success: the person who set up a team where one person would have only one other person under them.
Fix that and you'll ensure the project of setting up the team actually works, therefore as the "n+2" it's your responsibility until then. Managing is also about ensuring that the people who work under your management have all the tools to succeed, and a badly formed reporting structure for them is on you as a manager.
At the very least, in a situation where that 1 -> 1 -> 1 thing might occur, a conversation including all three parties should occur, where everyone can acknowledge the situation, voice their wishes or concerns towards a structure or another, and go forward with a shared understanding. That way, even if it doesn't please someone, they consciously "disagree and commit".
It'll take the same time for that person who's stretched between many projects, since they need reports from the person they're managing anyway.
It will take more time for the two people since one more people will be included, but that's where opting-out is more comfortable than opting-in: you could have a discussion about the reporting part together and figure out what's most comfortable for everyone (whether it is only sending one person regularly or if both are there, etc). It can even be an opportunity for growth for the more junior person if they take on the reporting duty, since they'll have the help of someone more experienced and they'll hold more responsibilities than they otherwise would have. And all this can be decided by the people involved, who will know better than anyone else what they've actually done.
It's not about reporting, it's about decision making. Who is making the decisions? Who is deciding if a feature is worth postponing the deadline? Who is deciding when good is good enough? Who is deciding how to structure the teams? Should we write unit tests? How many? What should be unit tested? What's the software architecture? What DB to use? If you take any two devs there are a million things they'll disagree on. And someone just needs to make a choice.
For expediency, so you don't spend too much time bike shedding, and for consistency so you either deliver a polished and robust application late or a rough application on time instead of a half reliable, half polished application a little late.
Most of these decision should be made at the organization level or by a person full time on the team. And usually the person who makes these decisions(the product ones not necessarily the technical ones) also reports up the chain to make sure theses decisions are aligned with the organization.
Again, this is not an issue. You could make up a bunch of questions about pretty much anything, it's always going to be questions and answers in a management chain.
The point is that all this stuff can be answered by the two people as a team, and if they disagree they have to figure out a mature way to present their disagreement or manage to convince each other. If you're an experienced engineer and you think your solution is better than the junior's, then by all means just lay it out for your teammate to understand and accept it. If you can't even convince your teammate, I'd be worried about what you're going to do about your superiors all the way to the CTO.
Ultimately if there are a couple paths then you end up listing the trade-offs together as a team, genuinely, and you present THAT to your superior so that you can have a higher-level discussion about what they see and want from their perspective. You do the homework together, and you do it well enough so that your manager doesn't have to work for you.. Which you should be able to do anyway if you were about to be the manager, right?
I have worked under managers where you designate a point person for a project who can review and as a process mentor people.
But I have also worked under managers who have some kind of subconscious pressure to treat all reportees equal so they hesitate in even acknowledging that 2 people have different calibre and thus everyone either works independently or collaborates : so if you find something bad, you either fix it yourself and move on, but you don't talk about it (part of this is driven by the need to protect bad hiring decisions but if you do not mentor them you make things even worse a year down the line - ok this may be my bias showing up here but hey we are all biased) except in a weekly staff meeting where with many people and limited time you can cover very little.
So just curious what mechanisms do people set up to mentor people within a team without designating a reporting relationship?
I think that's a problem where you don't have well-defined ladders, so there's no "obvious" way to distinguish newgrads from greybeards.
There are lots of teams at Google where an L6-7 manager has reports who are anywhere from L3 to L7; this, in fact, has been my experience the entire 5 years I've worked there. This shouldn't be a problem at all, and hasn't been in my experience.
I have, in fact, been in exactly the situation where I'm mentoring a new-grad who is assigned my subteam. I'm the TL, but not their manager, so the relationship and responsibility is very clear.
In one place I worked it was about helping junior engineers reinforce the things that were otherwise a difficulty for them, and it happened with both sides wanting it and evolving goals throughout the months. Assess the needs and discuss them if there is a disagreement, establish actionable items, set up metrics together that can be tracked more or less loosely depending on the subject and the people, and when necessary figure out ways to communicate to the team or to higher up any request related to that project for growth (time to learn, structural change, etc). And when it doesn't make sense to do the mentoring anymore, just stop. It doesn't have to be a permanent thing at all.
Sometimes practically it might have been about technical stuff, but really it was mostly about helping people communicate better and helping them navigate the structure of the company to feel more at ease with its different parts. Sometimes it enabled them to bring to the surface skills they weren't confident they had or that they had but weren't being put to use. People outside the team would also tend to notice the change positively, which can have an impact on a junior's career path.
IMO, for most people in tech the problem is fairly frequently anything-that-isn't-tech-itself.
It can be very empowering within a team to have people who grow beyond their comfort zone with the perspective of a more experienced person who also knows your day-to-day struggles.
Of course that implies working in teams where there's an investment in the teams, in the individuals, in the value of long-term returns of such growth, etc. Not a fit for every company - I just happen to have experienced such things at a very nourishing place.
> I have also worked under managers who have some kind of subconscious pressure to treat all reportees equal so they hesitate in even acknowledging that 2 people have different calibre and thus everyone either works independently or collaborates
IMO that kind of manager is just a bad manager. Same with school teachers who treat to treat all the kids exactly the same. I get the sentiment, but in reality everybody is different with different strengths and weaknesses, and also different needs.
> So just curious what mechanisms do people set up to mentor people within a team without designating a reporting relationship?
I think in many cases (esp. if there is a big difference in experience level between the mentor and mentee) it is quite similar to a reporting relationship. The main difference is that a mentor doesn't have the authority to make a mentee do something in the way that a manager does. If everything goes well, then such conflict should never arise, or only rarely.
I worked at a place where it was somewhat common to have a manager with one report. It was usually because the report was such a screw-up, instead of firing the person they would bring someone in to 'manage them'.
Then, they'd blame the manager when the report screwed up, fire him, and bring in another manager...
I've also worked at a similar place. I don't know why but somehow they never wanted to have teams with more than 1 person except maybe for a few months. Fluctuation was crazy. At the end the company was shrinked considerably from 30-40 people to 5 people and now they work only on projects with state funding.
You might also be able to say that if your boss has one report, then their boss is fucking up, and shit rolls downhill. Some large fraction of 'one report' situations are already going to be a dumpster fire by the time the boss and report have introduced themselves to each other.
Thank god for this article. I'm a new tech lead with 1 person in my team. This person is even from a different country, new to the industry and not that advanced in his programming skills. I noticed everything this article describes.
Although everything gets better day by day, week by week, it is still difficult and I sometimes even have the feeling "damn, do I really want to be a tech lead?"
There are hundred ways that you would have written any piece of code differently than your mentee. And if you correct all of them you will both be unhappy and unproductive. There are truly amazing coders who code differently than you or I. Focus on issues that materially affect the application(correctness, reliability, performance, security, reliability, maintainability - less important than the other) and give clear explanation of why you're making the critique and how it affects the application.
Also remember you're a team, and he wants the application to be awesome too. Approach critiques with "here's a way we can make the application faster" as opposed to "you wrote slow code".
Document every critique you make to create a code guidelines document. This will help anyone else who joins the teams, and will make your critiques feel less arbitrary, and help them remember and be able to lookup your critiques.
Make sure you have a standup every day to watch over their progress and code.
It's really easy to focus too much on getting your own work done and slack off as a tech lead or mentor. Always prioritize your mentee's work over your own. Don't start your work until you've set him up for success for the next few days. (code reviews, making sure he has work lined up and understands what he needs to accomplish and how he needs to accomplish it)
Maintain a positive attitude, remember to compliment them, err on the side of over complimenting than under complimenting.
Don't be afraid to ask for their advice or for them to do research.
Expect the quality to not be up to what it would be if you wrote it. Try to plan for this by increasing QA time, testing, and spending more time reviewing the parts of the applications where correctness is the most important. Also make sure to do performance testing in case he did something boneheaded.
Over communicate. Explain the why's of everything. There are 100 tech leads who under communicate for every tech lead who over-communicates. So chances are your team will run better if you communicate more.
>Over communicate. Explain the why's of everything.
I would like to second this, if your schedule allows it. Attempting to make sense of a large codebase (that likely has much domain-specific and even historical reasoning within) when you are inexperienced and/or new to the domain can be a much better experience if the information flows as freely as possible from the expert to the new person.
a junior-senior combination works well with pair programming.
i suspect your problem is that you can't yet judge what your junior is capable of, so you assign him tasks and then find out he is struggling with a task, or doing it wrong, and then you have to spend time correcting or teaching.
in pair programming these activities go hand in hand. you tackle a problem together. at first you take the lead, but ask the junior how he would solve it.
initially you drive (type the code) and he observes. once he has seen you code for a while, you can let him drive. as you work together you slowly learn about his abilities, and when tasks come up that you feel confident he can do by himself, then let him, while you bugger off to deal with your email.
depending on the nature of your work, you may need to spend some time doing managerial stuff that your junior can't help you with, or you have to attend meetings. (although for meetings about the code you write i'd take the junior along)
with only one person in your team i do hope though you get at least 50% of your time to code yourself, which you can use for pair programming. the other time your junior will spend on tasks on his own or learning something that you'll need next.
Junior-senior pair programming is different from managing one report, though the line is quite blurry. When I had a solo report it felt much more like a junior-senior pairing than being a manager (especially as it was their first eng job, and teaching them the basics was most of what I did).
Ultimately as a manager you're also evaluating their work and are in a position to decide things like if their employment continues, if they get promotions/raises, etc; that is what makes it distinct. Feedback in a junior-senior pairing is much more purely about helping them grow.
Dang though. 50% of your time to code... I'm an IC (as much as I want to be an EM) and that sounds really nice. I regularly have whole days where I don't get to code (in part because, as a potential future EM, I'm expected to mentor; I have 7 regular 1-1s, for instance).
how many people are you mentoring? obviously if it's more than one then you won't have as much time to code. i was thinking of the simple case where a team of two people is responsible for a single project. if one of them is the project manager, the other a coder, then the pm should not need all day to manage. unless of course they are at the kind of company that wastes everyones time with meetings and whatnot that prevents anyone from getting actual work done.
this is amazing advice. I figured this out the hard way as the manager just last week. Was initially apprehensive as I haven't done much pair programming before, but it was incredibly productive and my report loved it
not with a single report. the overhead is maddening. much better to have 2..3..4 where you can put them to plan/discuss/evolve solutions while you just update and evolve checklists. debrief daily, use their work. be consistent, write your own daily summaries for upstream. going from 1 to 4 should ~double the time you need while making you much more productive/deliver more comprehensive skills & results at the same time. make sure you get paid for keeping things on track while doing your usual! p.s./edit: four is a great size. 2x5 is the most i'd want to do. coordinate with hr but stay out of it.
OP here - glad that you enjoyed it, thanks for reading!
One thing I'll mention is that management is hard and largely a learned skill. I think of it like playing a sport. Some people are better than others due to innate ability, but everyone can improve with practice.
We've written / will write more on these sorts of topics if you're looking for more tips. Best of luck!
You really don't know anything when you have just one of anything.
The stock market went up after I flapped my arms! I might be controlling it or it might be a coincidence. Try it again a few times and you realize you're not gonna be rich.
I looked at one row in my data table and discovered that it has a wacky value! It might be just the one row or I might have bigger problems. Look at more rows to find out.
One witness tells the police "Jeff committed the crime!" Well Jeff might've done it, but maybe the witness just hates Jeff, or maybe they're the guilty one, trying to deflect blame. Detectives have to look for corroboration.
One plane crashes into one of the WTC towers! Could be an accident. Wasn't until the 2nd one that we knew it was intentional.
One person is dancing! Could be spontaneous, could be a planned routine. Add a second person doing the exact same moves at the same time, and now you know it's planned.
My wife sure is great, she's the best! Well maybe she's just one of many great wives. Probably she is, but in that case you just decide to ignore the other data points and provide your own corroboration! ;)
One interesting detail is that this describes 99% of internships in Tech. Interns are given to a single full time engineer who have never managed before because it is their first foray into management.
Yet I don't hear a lot of complaint about the program (or maybe I've not been listening hard enough). I wonder what the different about internships.
The biggest difference is that internships are short and low-stakes, so if something goes off the rails it isn't too costly for the managee or manager. Also, at least in tech, hiring is hard enough that interns tend to get the benefit of the doubt on "performance issues" in my experience.
I can think of a few things. Interns are even less experienced than junior engineers, so they might not know when they're in a bad situation. They also have a pretty decent incentive to not make waves, since they're typically being graded on their work, and evaluated for the possibility of a return offer.
On the other side of the equation, when I mentored an intern at my company, I was given a great deal of support and training in how to help them have a successful internship. This may or may not be the case for a new manager.
Anecdote, but when I was an intern back in college I had a single designated mentor but his job mostly consisted of getting me to be more confident and ask fewer questions when I could spend more time researching solutions myself.
My code was also subject to in-person code reviews by several engineers which was extremely valuable as it made me more comfortable with the whole team. This allowed me to become comfortable enough to ask other members of the team questions, freeing my mentor from being overwhelmed by me.
It was very much a "takes a village" approach and was an extremely valuable experience. Again, though, there was also a lot of emphasis on not wasting too much of any one person's time. Mostly because the team was a bit too happy to help me out for several hours instead of doing their own (much higher priority) work.
I think it's because being an intern is not as bad for a person's ego. Like if you have a manager and a report they are basically the same, except one is above and one is below. "Why me below?" Well in the intern case that question has a very obvious answer. Plus you know it's for a limited time.
> Avoid at all costs the combination of: new manager, 1 report, report is new-to-industry, manager is not a subject-matter expert.
This is interesting. Consulting teams are often structured exactly this way, with a Lead managing 2 "managers," each leading one Associate/Analyst. I wonder why that antipattern is so consistent...
The latter two would be more universally true in a consulting context, correct? Could be that managers at consulting firms have to manage their clients a lot more than a team normally would, so the extra managerial bandwidth could be dedicated to maintaining that relationship.
I suspect it's because the job titles are meaningless hierarchy to keep people happy, and collapse into a 1 boss N employees structure any time anything important happens.
OP's co-author here. This has been my experience in consulting as well. In practice, most consulting projects are led by the partners / seniormost managers in a tribal fashion so this distinction doesn't matter as much.
It is easier to handle 4 children than one as well. The realization came when I wasn't able to hold 3 children with just two hands and had to rethink my approach
I've done it a few times successfully. My direct reports were very pleased with the way of working, and preferred it to some other working environments.
How I worked was taken 100% from a section in "7 habits of highly effective people". This is how I communicate with them the first time:
1. X is the goal. How you get there is up to you.
2. If it was up to me, I would do Y, but of course you can choose.
3. Every x days you can show me your progress. Then we can see how far we are towards the goal.
4. I have x hours available for you. Tell me what you want me to do and I'll do it.
So the trick is basically to put them in charge, not you. You have the supporting role, they can request things from you. But the goal needs to be very clear.
One other thing they mentioned is that I set very clear objectives, and other projects they worked on were not that clear.
Dead on. My first time with a single direct report was a catastrophe. I was like a helicopter parent (as opposed to a micromanager). I did get feedback from him that we felt more like peers than manager/report, which he said felt weird but couldn't explain. He left the company, and I hope it wasn't due to me.
Fast forward two years and I was managing 8 people, and I didn't have time to helicopter. Just like this article: I was too busy rotating through each person to spend too much time on any one. Plus I had one really good report and one terrible report, so I had to spend more time with the latter. Just like the public school system.
Yeah, this is a great article. Short but important. Wish I had seen it ages ago.
It can happen when there are a lot of power dynamics that can create a dysfunctional org structure. In one company I worked the Director had like 20 direct reports, and then went 3 more levels deep with one or two reports each.
Hmm I've had new managers a couple of times. It's only now that it occurs to me that sticking a new manager with an intern/grad/early career is a bad idea. I've suffered because my managers weren't yet particularly good managers and in both cases they were new or newish managers. I never held it against them but at the time I never questioned it either. Looking back it seems kind an obviously bad idea to stick us together. The best manager I had as a grad was a super experienced manager who really helped me get my shit together.
He would have 6-8 Hour planning sessions 4 to 5 times a week. Nothing got done.
Later I realized I was providing him an education on project management and I’d experience.
This seems like pretty good advice, but what if you can't follow it? Say you're the one with ultimate responsibility for a tech team of exactly two. What's the least bad thing you can do?
First, per the article, I'd aim to become an expert in whatever your report is doing. Being able to just do the thing yourself is a great release valve. Things can get really hairy when you have the combination of high pressure deadlines/deliverables and total reliance on one report to fix it.
Second, look to set up things like performance calibrations where promotions and comp changes are decided by a collective group, even if it's just you and your manager. Partnering on raises/comp changes can help you both make better decisions and have your report more comfortable that the outcomes are high quality and the decision of the entire organization, not just you.
Typically it's a temporary, an intermediate step, or politics.
I managed several teams, and during that time I inherited a new team with 2 headcount, plans to increase headcount, and company initiative to grow that product.
I didn't have bandwidth to manage that team myself, so I turned one of those headcounts into a manager position.
In the world of startups, the first hire is often an engineer, who normally reports to the tech-cofounder.
Say a small company employs a single senior subject matter expert who successfully manages up the chain to make sure the right work gets done. A junior subject matter expert will do better work if they are placed under the senior, because if they are a peer, they are likely to not manage up as well as the senior, who will have to step in and de facto manage to fix that anyway.
A friend came from a very large family. I asked him how his parents coped. He said once you get beyond the first number of kids, it basically runs itself.
The first kid requires X attention. The second kid adds 0.7X. Then the third is like 0.3X, for a total of 2X. As you have more kids, the older ones can look after the younger ones. The amount of work actually goes down. You are basically the supervisor / police.
My instinct on this is that managing four people is coordinating a team, but having a single report is just having a servant. A manager performs a valuable service for a team of four, keeping them from having to confront/monitor each other when it would be uncomfortable/time-consuming to do so. A manager with a single report is at best a shield and champion against upper management, and at worst just a annoying/useless cop/scold.
Maybe the manager with a single report can act as a mentor, but it's a coin flip whether the manager is more capable than the report. It's not an apprenticeship.
edit: I was once the only report for a manager and it generally worked out really well, but it's because the manager had no professional ego and I was far more knowledgeable than he was, so he deferred to me whenever he had any ability to (i.e. the issue wasn't a mandate from higher up.) It still generated (well hidden) resentment because he was making twice as much as me. If I were less laid back about money, it still would have turned out ugly in the end.
C. Northcote Parkinson wrote about single reports in his 1995 Parkinson's law article published by The Economist[1]. That's the article that articulated in its first sentence the Parkinson's law we all know.
In the article he explains that a worker that feels overworked prefers to have subordinates rather than a peer of his own level that would be a rival for promotion.
A single subordinate is not ideal because the work would be divided between the two and the subordinate would assume an almost equal status in practice. With two subordinates each is kept in order by fear of the other's promotion and the new manager has the merit of being the only one to comprehend the work of the subordinates. This sets the stage for the two subordinates getting their own assistants. He explain how this new group of people make work for each other.
Great points. I've observed this myself for years as a Director in a tech co.
Only other thought about it: managers with 1 report are also very likely to be new managers. Experienced managers do not (usually) take on roles managing a single person.
To put it more generally: Good managers are unlikely to take a role managing just 1 person so therefore managers with a single report are likely not good managers.
My experience has always been that my happiness with a manager is directly related to the number of reports that they have. They rarely have time to "just check in" unexpectedly, so meetings and interactions tend to be scheduled. You're also afforded much more autonomy in every respect, so long as there are no complaints from others about your performance, they are happy.
And lastly, managers with a large number of reports have a more significant pool of talent to help you with a task that you're struggling with. Since your manager is directly in charge of the other person, you can be assured that the person knows the problem and that they will find time to assist.
Ouch. Yes I've experienced this. I struggled with my first experience supervising a team of one. We were also two people in different places in our lives and maybe less shared experience than I have with a fellow gamer or geek. And it was remote. We did build trust, but it was slow going. I pushed hard not to micromanage. Weird to see all the adverse incentives I experienced all lined up like this. Curious if anyone else has developed any strategies.
Interesting I've a similar take. To hire at least 2 people for the same position even if you need only one. This way you achieve redundancy, can manage the people using same tools and compare results, and they can collaborate between them.
I'm sure some companies have valid business-related reasons for having managers with one report, but the only times I've ever had one report was when my organization was testing me.
This is similar to what I’ve seen. Most toxic boss relationships are where the boss has only one person to dump on, or the other extreme of too many folks to stay on top of.
Not sure if you've read the article, but with benefit of doubt:
>What the fuck does "manage 1 person" mean?
"Manage one person" is relatively self-explanatory. On the org chart, you are designated as a team lead, with exactly one (1) person reporting to you. You are responsible for their work, career, and success. They have you as their boss.
It is relatively common in many organizations, including tech/software, due to (likely mistaken) belief that it will ease in a new manager/team-lead. Alternatively it could be circumstantial due to people leaving or weird teams forming or planned expansion that doesn't happen or difficulty hiring, or a natural hierarchy of a very senior and very junior developer, etc.
>>do some work yourself.
Typically, a manager or team lead of small teams absolutely does do some of their work themselves. In fact, usually they do ALL their usual work, AND now coach/guide/manage their team, in this case a single person. Usually the situation is the antithesis of "free loading".
Given such situations absolutely do occur, the post seems to be fairly realistic as to common ways they can go wrong, and how to address them.
> that’s 100% bad feedback from your reports. If the report doesn’t do well, that’s 100% of your reports that aren’t succeeding.
It kind of goes to show, if it's a bad measurement for N=1, just because it's a better measurement for N=7 it may still be meaningless. Your employees are not a science experiment.
Another way of looking at it is, if 100% of Mark Zuckerberg's employees, in say 2006-2007, were saying he was a bad manager, if 100% were "not succeeding," would it matter?
Another way of looking at it is, while 90% of businesses benefit from an objective look at manager performance, don't you want to work for the 10% where it doesn't matter instead of the 10% where it matters and they actually score well?
I switched teams as soon as I could, and I and that manager have both gone on to be reasonably successful - that manager has a lot of reports now who seem to really appreciate him, and I haven't had a bad manager since that situation. I think the bad manager-report scenario wasn't really about either of us nearly so much as it felt at the time.
It is validating to read this is an anti-pattern observed by a lot of people; it was hard not to take things personally at the time or blame the manager for how unhappy I was.