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.
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.