It’s easier to manage four people than one person
staysaasy.com
staysaasy.com
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.
But I think he did figure it out much like you described, and is successfully managing (and not micromanaging) a high performing team today.
So yes, I buy the hypothesis that 1:1 management grouping promotes non-ideal management behavior.
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.
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.
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 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.
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'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)
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?
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.
As someone who went through this myself, it's a lot easier to set up mentoring within the same team as just knowledge transfer at the beginning.
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.
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.
Not having someone whose full time job is being responsible for a project's success or failure has it's own set of drawbacks
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".
But 0.2(oversees 5 projects) -> 2 isn't necessarily better than .2 -> 1 -> 1
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.
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.
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?
Then, they'd blame the manager when the report screwed up, fire him, and bring in another manager...
Every tip is appreciated.
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.
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.
> Document every critique you make to create a code guidelines document.
It helps more to have as much of this as possible in lint and style checkers, so there's no arbitrariness at all.
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.
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).
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!
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! ;)
So, people in polyamorous relationships are just looking for more data points?
1) You haven't proven you can do something until you've done it a second time.
2) Anything worth doing is worth 2 people doing.
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.
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.
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.
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.
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...
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.
Maybe combined with the manager adding auto tests, to verify the things that get created work well
> My direct reports were very pleased with the way of working, and preferred it to some other working environments.
How did you find out about that? (Did you ask them?)
Maybe I was also a bit lucky to manage these eager young devs, full of energy to prove themselves.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A manager with a single direct report isn't a manager. It's a worker with an assistant and they should work accordingly.
Manager term only really makes sense with more reports.
This is crucial -- when these combinations happen they can drive people out of the field altogether.
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?