[HN Gopher] It's easier to manage four people than one person
___________________________________________________________________
It's easier to manage four people than one person
Author : chesterarthur
Score : 176 points
Date : 2020-07-27 13:34 UTC (9 hours ago)
(HTM) web link (staysaasy.com)
(TXT) w3m dump (staysaasy.com)
| phjesusthatguy3 wrote:
| 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_.
| rusabd wrote:
| 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
| mathattack wrote:
| 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.
| ck425 wrote:
| 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.
| [deleted]
| rdiddly wrote:
| 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! ;)
| hinkley wrote:
| Two different bosses weighed in on this:
|
| 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.
| irrational wrote:
| >Well maybe she's just one of many great wives.
|
| So, people in polyamorous relationships are just looking for
| more data points?
| agumonkey wrote:
| Maybe a root factor in societal structures too. 2 people is an
| unstable system, a third party helps.
| an_opabinia wrote:
| > 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?
| [deleted]
| corpMaverick wrote:
| 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.
| notenoughhorses wrote:
| Even worse, 2 managers, one direct report
| temporalparts wrote:
| 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.
| pmiller2 wrote:
| 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.
| hartator wrote:
| 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.
| lacker wrote:
| 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.
| hinkley wrote:
| 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.
| bluedino wrote:
| 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...
| kshacker wrote:
| Oh wow I just took the opposite view in
| https://news.ycombinator.com/item?id=23967235
| giancarlostoro wrote:
| Amazing the many ways companies waste resources.
| blablabla123 wrote:
| 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.
| cmehdy wrote:
| 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)
| kshacker wrote:
| How does mentoring work within the same team?
|
| 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?
| cmehdy wrote:
| 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.
| zem wrote:
| a "team lead" designation is useful for this
| nicoburns wrote:
| > 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.
| QuercusMax wrote:
| 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.
| WrtCdEvrydy wrote:
| > what mechanisms do people set up to mentor people within
| a team without designating a reporting relationship
|
| 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.
| JamesBarney wrote:
| 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
| cmehdy wrote:
| 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".
| JamesBarney wrote:
| If the person who setup the team is full time on the
| project, then yeah 1 -> 2 is better than 1 -> 1 -> 1.
|
| But 0.2(oversees 5 projects) -> 2 isn't necessarily
| better than .2 -> 1 -> 1
| cmehdy wrote:
| 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.
| JamesBarney wrote:
| 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.
| cmehdy wrote:
| 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?
| mywittyname wrote:
| 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.
| theredsix wrote:
| I've definitely noticed this in the past and it's good to see a
| concise logical reasoning of the problem.
| DDerTyp wrote:
| 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?"
|
| Every tip is appreciated.
| em-bee wrote:
| i have worked with a junior multiple times.
|
| 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.
| JimboOmega wrote:
| 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).
| bllguo wrote:
| 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
| staysaasy wrote:
| 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!
| JamesBarney wrote:
| I have a couple pieces of advice.
|
| 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.
| iooi wrote:
| This is great advice.
|
| > 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.
| JamesBarney wrote:
| Agreed, also saves a lot of time for everyone.
| michael-ax wrote:
| "damn, do I really want to be a tech lead?"
|
| 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.
| fizixer wrote:
| And how many angels can fit on the pin of a needle?
|
| What the eff does "manage 1 person" mean? I have to resist the
| temptation of reporting this post for how bad it is.
|
| When you're working with 1 person, stop being a free-loader (by
| calling yourself a manager) and do some work yourself.
| NikolaNovak wrote:
| 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.
| curiousllama wrote:
| > 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...
| Traster wrote:
| 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.
| bbu wrote:
| Why would you need a manager for 1 person? There are 0 benefits
| in creating a team like that.
| 1123581321 wrote:
| 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.
| balls187 wrote:
| 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.
| [deleted]
| softwaredoug wrote:
| Not sure, plenty of individuals have coaches to keep them on
| track. I personally do better with accountability systems to
| keep me on track.
| dougmwne wrote:
| 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.
| magneticnorth wrote:
| 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.
| JamesBarney wrote:
| Was the biggest issue just the micromanaging?
|
| 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.
| magneticnorth wrote:
| 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.
| hinkley wrote:
| 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).
| GCA10 wrote:
| 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.
| [deleted]
| birdyrooster wrote:
| 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.
| staycoolboy wrote:
| 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.
| encoderer wrote:
| 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.
| monkeydust wrote:
| Have min number of directs for anyone to become a manager, number
| of companies do this. Somewhere between 3 to 6 from what I hear.
| dataduck wrote:
| 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?
| staysaasy wrote:
| Author here - I'd recommend two things.
|
| 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.
| [deleted]
___________________________________________________________________
(page generated 2020-07-27 23:00 UTC)