Guiding ambitious task-hogging beavers and their teams
Posted by niowniough@reddit | ExperiencedDevs | View on Reddit | 31 comments
No tokens were used in the creation of this post.
-------------------------------------------------
I've been musing on something and would be very interested to hear from fellow experienced devs who have been on either side of the scenario.
We know about the profile of a Hero, where a single developer repeatedly tries to uphold a metric or process despite systemic dysfunction, working evenings and weekends and investing a high amount of personal intervention, usually because they believe that upholding this thing is of the utmost importance. I want to be clear that this flavor of heroism is not the focus I intend for this post.
For this post I'd like to discuss an adjacent profile. Maybe it will help to give it a name to reference in discussion, so let's call it the Beaver. This looks like a single developer, usually somewhere between junior to intermediate level, trying to be personally assigned in some manner to a great number of things, holding more tasks than their peers. Such assignments are usually a mix of formally visible tickets and side tasks such as volunteering to help people achieve something which the Beaver wants to learn about. They are usually only marginally faster than their peers, so the degree to which they hog more tasks is not corollary to some nature of being a 5X dev. If they could finish 1 task per day, they'd hold 5 tasks and work on them all for 5 days, with a few of the tasks held inactive at any given time. This dev usually has a tendency to work more hours into late evening or the weekend, which may give the illusion that they are a 5X dev. They usually do this because they are voracious for personal growth and want to be involved in everything, and because they are passionate about the job. They are usually rewarded by management with attention as a rising star, and it can be a heady thing to feel so competent. Sometimes the individual also does this because they are desperate for promotion. This lifestyle is often not sustainable and results in burnout somewhere down the line. Some Beavers are very talented or courteous and do not make an outsized demand for the resources available (for example, taking up way more of a senior's time, or spreading many questions across many people), but some are less independent and need further descriptions and details for the more ambitious of their tasks, which are beyond the Beaver's skill level to readily implement correctly, so the Beaver's task becomes the senior's task as the senior essentially needs to spend 80% of the time that the Beaver is implementing the task to explain to the Beaver how to proceed.
I used to be this individual, worse on the task hogging and having my hand in every pie end, less on the monopolizing resources end. I did hit my wall, thankfully early enough in my title trajectory that the consequences of suddenly being too burned out to do anything did not impact too many people.
Years later, I'm now functioning in a senior dev role to guide the team. This comes with the onus to nudge more junior folks along functional paths of growth, and to help the team function more smoothly.
As you've already deduced, there is a Beaver on the team.
In the interest of guiding the individual, on the one hand, I see being a Beaver (at least one courteous about resource consumption, which this one is not) as a rite of passage for many passionate and competent devs early in their career. I believe the pathological parts of being a Beaver are self-correcting within the individual, because they will burn out and learn a lesson more concrete than any warning I may give. I also think that even if I steer the Beaver towards more functional ways to achieve their interests (for example, take fewer tasks but complete each faster, adopt a more focused approach to building a promo packet), it may yield near-term success, but I will not always be there, and it's better for the Beaver to learn what only the wall can teach while they are able to hit it without impacting as many people. This sounds dispassionate, but I'm genuinely looking at it as how to best help this individual and still come to the conclusion to let them have some space (where it does not harm the team) to make the mistake so they can learn. There are certain ways of trying to help that actually delay growth and I want to be mindful of that.
In the interest of helping the team, this Beaver is asking to do stuff that they need too much hand holding for. They take up a large amount of the available capacity of the team's seniors and have started going to devs in other squads to further spread the demand. The other devs are eager to help as it helps them build up examples of mentorship for their own promotion pathways.
I have some ideas but lack concrete experience dealing with a Beaver that spreads more dysfunction than simply hogging too many tasks. I favor fewer interventions with stronger rationales than trying to change who they are.
I'd like insights from the group on both ends:
- If you were like this in the past, what motivated you, and what could have inspired you to change short of hitting the wall?
- If you have experienced steering people like this, what sorts of issues did your Beaver create for themselves and the team, which ones did you choose to address vs leave be, what kind of results did you have?
Ideally I'd like a discussion which is not too tailored to my specific situation, I'd simply like to hear everyone's thoughts on this non-technical element of guiding a team as an experienced dev. Kind of like a "what is everyone doing about this?", "how does everyone reason about this problem space?", especially in a senior IC role.
I appreciate this community and thank you ahead for your time to read and comment. I may not be able to reply promptly during the work day.
drnullpointer@reddit
Hi. Been on both sides of this problem.
I will not explain what I did to solve *my* problem, I think recognizing and fixing own problems is out of scope of this discussion.
On how to deal with beavers... I don't find it particularly hard except the one problem of accidentally demotivating them. The first couple of times I tried to fix this problem I ended up demotivating those people and they eventually left. That was my fault in retrospective.
So right now I start with an intimate and explicit discussion of the problem. And a compliment sandwich.
I explain that I like their zeal, I see potential in them, I make sure they are not worried about their future. Then I explain why task hogging is a problem and why letting go may be hard but is a necessary part of the process. I explain what I would like to see. I try to discuss the problem and figure out why they are keeping *specific* tasks that are on them right now. I try to figure out the reasons for this (are they the only person who can do it or is there some other problem). Is maybe the problem that they get their self worth from being the only person that can perform the task? We go over some possible solutions but at this time I let them figure it out on their own. Then I make sure to compliment them some more to end it on a good note.
If this does not help, my next step is usually to starve them of tasks while continuously explaining that I do this for their own good and also because the team needs to also be able to handle those kinds of tasks. Typically what happens is I ask whoever is managing the queue of tasks to enforce a limit of 1 or 2 tasks for this particular person. Meaning, they are not allowed to take on a new task before they finish the previous one.
At the same time I am also trying to figure out what is so special about this person or the work they are doing and what are the causes of having multiple tasks. Frequently, when people are juggling multiple tasks this is a signal there is a lot of synchronous dependencies (for example on other people or tasks) that require understanding and fixing.
It is possible that the work is not prepared correctly. In general I try to explain to people that it should be possible to complete development tickets in a continuous session without synchronizing with other people. If you need sync communication, approvals, other things, it means something is not working right and may need improvement.
niowniough@reddit (OP)
Thank you so much for your thoughtful and detailed comment. I appreciate the extent of detail you've provided and that you were able to share the risk of accidentally demotivating them.
When you explain why task hogging is a problem, do you focus on how it impacts the team? If there's personal impacts that you try to explain to the beaver, which ones do you choose to list? Other commenters have pointed out that unless there are signs of burnout already taking place, talking about potential burnout can be condescending and assumptuous. Wondering if you'd ever warned about potential burnout and been received positively.
> Frequently, when people are juggling multiple tasks this is a signal there is a lot of synchronous dependencies (for example on other people or tasks) that require understanding and fixing. [...] we essentially try to make a note of what causes a blockage and then we try to sort out the most frequent causes of tasks being blocked on a retrospective.
Absolutely, this is part of the problem and we are working to solve it, and it affects more than the beaver. I like your idea of bringing attention to the nature of the blockages as a team in a retrospective, so that everyone is aware that these things aren't the fault of any individual dev.
Lastly, it's encouraging to hear that you have experienced people becoming more motivated as a result of your interventions. I appreciate the level of compassion you have expressed in all parts of your post, especially around helping people feel safe.
drnullpointer@reddit
> I appreciate the level of compassion you have expressed in all parts of your post, especially around helping people feel safe.
I am not a very compassionate. I am more of a "do not unto others what you would not like be done to you" kind of person.
Keeping people feel safe is a practical choice, borne from personal experience. When you try to give negative feedback to a person, most people do not try to think about the feedback itself. Instead, their mind jumps immediately to conclusion they are in some kind of danger and focus on the danger, not on the substance.
Assuring people that they are safe is an important step so that they can even hear what you are trying to tell.
I make it a big deal to ensure people they are safe so that they can focus on the job and not on negative feelings associated with not knowing what's going to happen to them.
> Wondering if you'd ever warned about potential burnout and been received positively.
I don't typically talk about burnout. Burnout happens after you have been doing something wrong for a long, long time. I don't want to be dealing with burnout, rather I would focus on things that cause it.
I don't warn about burnout. I can't tell if a person is burned out or not until it is too late. Heck, I can't tell if *I* am burned out, until it is too late. What I am talking instead is that we need to be working sustainably.
> When you explain why task hogging is a problem, do you focus on how it impacts the team?
Both. I do explain how it causes other people and task to also be blocked and also have to take on more tasks and why it is important for the tasks to flow smoothly through the process.
But I also try to point out that it is usually stressful for a person to have a lot of tasks and other people waiting for them, to constantly have to report no progress to the team. And while sometimes these situations can happen naturally, it is not fair for the person to be put in this situation permanently.
I also explain that by not acting on it we would be effectively giving approval to this situation and that is not ok.
dbxp@reddit
Yeah, I've had that before. 5 tickets on the board under my name but they're all waiting on other departments to get back to me
juusorneim@reddit
If I ask kindly, will you share? I think it could be valuable.
annoying_cyclist@reddit
I tend to view the concerns around burnout, sustainability, etc as mostly not my business, however well intended they may be. This engineer may or may not burn out (plenty of people work long hours without burning out), may or may not look back with regret on choosing to work nights and weekends early in their career, may or may not be thankful for the career trajectory boost they got from working harder earlier in their career. I only see the small part of themselves they bring to work, am ill equipped to judge their choices in general, and have no reason to think I'm better able to make that decision for themselves than they are. This changes a bit if I see concrete signs of burnout and I have a trusting relationship with them where I think they'll hear those concerns, but that's not the default and not something I bring up unless I actually see it starting. (I've been on the other end of "you're gonna burn out if you don't slow down!" at various points in my career and have always found it sort of condescending)
That leaves the impact on the team, which is also an easier problem to solve. If you see someone becoming a silo (common with folks like this), overloading seniors with questions on their multiple stretch projects, taking 20 tickets and shipping nothing, etc, point that out and reinforce how you expect them to participate as a member of the team, and don't be afraid to reassign or unassign work from them if you need to (e.g., to spread knowledge around). You're not trying to change them, you're making your expectations of being a good teammate clear and trusting them to figure out how to meet those expectations.
niowniough@reddit (OP)
Thanks for your warning that hypothetical burnout talks can come across as condescending, but that the calculus changes if we see actual signs of burnout, these points are useful to keep in mind. Sometimes at certain junctures in our career and life we happen to have the ability to work long hours for fun or for dysfunction, and we may even get rewarded enough for it to have been personally worth it, so long as it doesn't affect the team negatively (eg. giving an impression long hours are mandatory to get ahead) or result in a burnt out and thus 120% -> 20% throughput beaver, I am supportive of people silently working longer hours. I am a little less supportive if people start to make it obvious that they are working long hours by alluding to it in front of the whole team repeatedly, which thankfully hasn't happened in this situation.
I like your framing around expecting them to be a good teammate. It's a nice positive flip from simply pointing out that they are causing problems to the team.
annoying_cyclist@reddit
Focusing on how your team collaborates and coaching this engineer on that is cool because it uplevels everyone. A lot of the counterproductive or harmful tendencies of overachiever types show up in other engineers too. Maybe there's less impact when an underperformer exhibits them, but they could still benefit from coaching. Plus, you might get a nice onboarding artifact out of the effort (a "how we work" document), and it might help make your future interview loops more productive.
I think your point on expectation creep from having a single high performer visibly putting in long hours is well taken (also that long hours as an end in itself is not a healthy end or goal to value), though I also tend to view this in terms of team psychological safety first rather than an individual engineer needing to change their behavior.
In an ideal world, someone meeting their marks and not overachieving should feel proud of and recognized for their contributions, the overachieving new grad/junior/mid should feel proud of and recognized for their contributions, and neither side should feel intimidated or less than because of the other. Most teams fall short of this, in my experience usually because management exploits the performance difference somehow (not recognizing the good work done by normal employees, using the high performer as a bar to make others work faster/harder, etc). Probably obvious, probably (based on your responses here) something you already understand, but helpful to keep in mind when thinking about effort/hours and that causing problems for the team. You could be totally right about the read in terms of team dynamics, but it's helpful to keep responsibility/power in mind too (and, in particular, that an early career overachiever realistically has very little individual control over that). Feeling like your more senior colleagues are rooting for you, supporting your growth, and recognizing the good work you're doing is a lot more motivating as an eager beaver junior than feeling like you have to hide the extra effort you're putting in to avoid upsetting people.
Ailron09@reddit
I'll bite.
I am this Beaver. I genuinely hit a breaking point and am looking to burn out and away. I don't want to consider 5 years further into this career, I want to earn what the top 20% earn for maybe 2 years total, live like a hermit, and disappear into the woods to never be heard from again.
There isn't anything to do for someone who's underlying goals are to get far out and away, especially when theyve completely damned the entirety of modern civilization as it is.
I've: run my own tech repair business, worked as an easy tech at staples, spent 4 years across 2-3 help desks, 4-5 years as a SysAdmin, 2 years as a Sys engineer with a focus on automation and now 2-3 years as a DBE with a heavy focus on agentic workflows and orchestration on top of organized data. All of this after years of support in call centers and NOCs.
There isn't anything a senior can do to help me. There isn't an outside perspective that is allowed in. The minutiae of the job you're talking about mattered for a long time but just doesn't in a world where global super powers could pull the plug at any moment for all of us and some twat waffle still thinks it's some how helpful to another's growth to continue trying to improve the giant machines that are taking advantage of all of us by their very designs.
I have taken breaks, Ive plotted a career change, and I've started my own businesses to try and get away from exchanging my time and showing up for a shift for a paycheck that allows me to exist. All of that is predicated on being able to do anything with the time off, not just recoup and recenter to come back and work within the same dead or dying system that brought me to these perspectives in the first place.
I share this, because as an eager Beaver, you've missed what I and others like me have fueling us at our source. We grew up idolizing technology and what it could do for humanity, how it could improve lives, or how it would accelerate help to where it was needed. Quite obviously those were rose tinted glasses and the real world demands it's tribute via effort or cash in its exchange.
I take everything I'm not told "No" on because I have a track record of eventually landing and completing the tasks I pick up, that often are tasks left abandoned by others. I'll give the example of rewriting a decades old messaging system (all work associates with a ticket and stake holders) that isn't in use any longer... Except where it is and can't be worked around for internal political reasons. That sat 'needing done' for years and when I asked what the hold up was no one would be direct. Intro eager Beaver to figure out why (and figure out I did).
You're not going to find an answer for the larger-than-I-think-most-realize portion of "Beavers" that are smart (think and draw conclusions from patterns without assistance) and have sight on what's happening in the world and want out. I don't want to become a force in the white collar work world, I wanted my efforts to be rewarded through gratifying outcomes not just through personal progress and financial gain. I take every possible thing and work them to completion even when the current trend is to leave things be. I don't care for your or anyone else's stability, I was never allowed a stable place to start from.
I dumpster dove for project pieces to learn programming and hardware maintenance on when I was a kid. I now hate what I once loved, and don't care if what I'm doing hurts those around me at this point. I'm going to loudly solve the obviously wonky problem everyone's too inundated to deal with, do so with a shuck n jive in front of the first exec that'll praise it, all to earn 120-175 a year for 2 years and then peace out to the backwood.
I wanted a mentor. I wanted comraudery. I wanted friendship and peers to work on what I've been passionately chasing since I was a child. I have pictures of me in diapers and trying to dig through a computer tower, and pictures of me at 7 working with an old terminal system. I wanted to find and work with the Big Welds of this world, to only find they never existed in the first place, it's all bugs and BS the whole way down.
Now I only want some woods, a chair, and a shovel. I'll dig a hole to sit in front of til I fall in it. I'm an eager Beaver... Who's eager to disappear and never be seen again.
There's nothing to do about me or those like me, and there are more of us than you realize.
Enjoy your coffees...
niowniough@reddit (OP)
I am sorry to hear that you are feeling so burnt out and cynical (which is a symptom of the former). Having been there I can say it is not a great place to be in. I fully understand that some people just want to exit and I am supportive of that when they're meeting the requirements of their role. I'm fairly certain that simply sitting on more tickets has not yielded a higher short term income for the beaver in my situation, and they do not show symptoms of burnout. Nonetheless I appreciate that you took the time to share a perspective of what some beavers may be thinking internally.
Ailron09@reddit
Thank you for taking time out to read the giant wall of text! Also appreciate your considerate response, it's quite kind.
I am actively choosing to burnout, with increased short term yields that just aren't maintainable long term. That's on me and I own that, but it does result from time to time in my own hoarding of odd all problems/tickets. Not because I don't want anyone else to take them, but because they've either sat for so long or because I've actively been requested to take some time to dive into these niche areas given my history for doing just this.
That is squarely my case however, and this was pretty early in the day of clearly a heavy burning week. Were I managing better, I'd probably have championed burnout in a paragraph at most đ
If we were to talk for some hours, I might win you over as more an optimistic absurdist over pure cynicism, but I get that conclusion now having reread and sat after a day. While I might asterisk the heck out of that for clarity and specificity now that I've let the thought breath, I'd still stand behind it just probably written better in a journal than the internet. It's still yet a bonfire for the next weary reader so I'll leave it.
In your situation (this is your post and I'm bordering having overtaken with a vent):
If the person on your team isn't any kind of burned or burning out, it gets more cut and dry. In which case point to it, point out its impact to the team and why it's valued negative over positive, and if it's disagreed on then that's a different conversation all together. If it's understood then you should be able to work together to find a way to either shore up or offload some of their current back logs(heh) and work dynamically as the situation unfolds to either keep communication about it verbal or set some kind of recurring review if it really comes to that.
Really do hope everyone enjoyed that coffee, and I took the afternoon off.
GoonOfAllGoons@reddit
This is a lot of text for you to say that you think you're smarter than everyone else.
juusorneim@reddit
What exactly in the writing led you to this conclusion?
Ailron09@reddit
Yea, me thinks bots but who knows anymore. Thanks for the engagement internet stranger.
To any other "beavers" that may stumble on this: Don't give yourselves to systems that lack resiprosity. You will only find a hollowed shell of your formor self and 0 appreciation from the field, your peers, or the skill set you iron out at the end of that long and winding path. I was merely trying to offer the alternative perspective that should be considered when working on "solutions" to "Beaver" behavior.
That's the lesson to be learned by Beavers, and because that's theirs to learn what others have said is accurate: the only help is clear guidelines and expectations, even then you're mostly "helping" these people to their own ends. Don't worry so much about optimizing people and their efforts, worry about holding people regularly accountable and giving them freedom to either succeed or fail to that end.
I said what I said, and will stand on it to 8 billion down votes.
Ailron09@reddit
Who am I smarter than in this example? I've been passionately a team player my whole career and actively support seniors to learn. I'm not smarter than the solution that's right for the problem, I am absolutely jaded though.
This was a request for perspective and while it's not the explicit perspective requested, it's a share none the less.
This instant need to demoralize or dunk on others devs see as off base, over blown, or otherwise unrelated to the individual is exhausting as well. I didn't and am not trashing any people. I'm saying there isn't any hope left in my world view and it's attributing to why I Beaver. Is that explanation, in full and in earnest, not valuable?
juusorneim@reddit
I think they misinterpreted what you said. Not sure why or how...
roger_ducky@reddit
Easiest way is either a reframe:
Thank the Beaver for trying hard, but point out that âhaving time to review other peopleâs PRsâ is part of the capacity they have to account for.
Secondly, tell them that their work quality goes down when theyâre working for too long, and advise them to be well-rested.
If the Beaver still doesnât get it after that, start pointing out the ways theyâre impacting others on the team. Use that as a last resort.
niowniough@reddit (OP)
Thanks for your comment. It's a good reminder to thank them for trying hard. The beaver in mind does review others' work, so it may be more of the attention spreading issue you commented on below.
MinecReddit@reddit
to be clear: please only do this if you can actually show that it's true/prove it, often times this isn't true for many people who fit this description (the quality is just always low)
roger_ducky@reddit
I usually see the quality dropping to the floor because they have too much stuff on their plate. I see them improving quite a bit after just concentrating more on a few things per sprint rather than spreading attention on many things at once.
Now, if you find they donât actually perform better after concentrating on one thing at a time, itâs time for another conversation.
zugzwangister@reddit
What's the reward for the beaver to hog tasks? What metrics are you using that they are trying to improve?
You already talked about seniors spending time helping. That seems like the metric they're improving: mentoring others.
Introduce paired metrics to each: efficiency. Celebrate people who have the shortest time from taking a task to having it fully completed. And then you'll get cherry pickers. So need to add a complexity metric.
It seems like both problems are exacerbated because people are trying to improve what you're using to judge them on. Maybe that's the root issue.
OriginalEar5959@reddit
sounds like a dam problem to me
niowniough@reddit (OP)
Thanks for a good chuckle
niowniough@reddit (OP)
There isn't any specific metric that has been socialized, but the broader sentiment of your comment still applies - the incentives of the environment contribute to and are levers of the situation. The beaver gets praised for some things they are handling, it then follows that the beaver can get more praise by being associated with more things.
SeaObligation5693@reddit
i used to be that task-hogging dev too, learned a lot from burnout
MinecReddit@reddit
The way I see it, there is only one problem with the entirety of the profile you've described:
I would focus on giving feedback to beavers that do this - "hey, you are clearly owning a lot of stuff and that's great, but let's focus on one thing at a time and make sure that you have the ownership and depth that it takes to get XYZ promotion"
I think in practice, this can look like 1:1s where you talk about their active work as it applies to getting promoted, and where they are falling short. In terms of being courteous about taking up resources, I think it's moreso on the guiding engineers to push back if they feel they are providing too much support (and even set boundaries around their own work time if necessary).
There is a very fine line between a "good beaver" and a "bad beaver," someone definitely has to build the dam after all. Sounds like this beaver just needs greater pushes to be independent, taking up too much time of senior eng on the team should be communicated as bad ownership.
niowniough@reddit (OP)
I think that the beaver is highly independent for their level, but perhaps tries to take on some things which exceed their ability which leads to inability to be independent. Additionally, I think there comes a point where they have too many plates spinning, and that means those plates are not being picked up by others who have active time to move those forward. Providing feedback to them to do a few things with focus as you suggest would probably go a long way in addressing that. I can definitely see examples where fellow devs are enabling the spread of resource demand.
mirageofstars@reddit
Donât have more than two tasks. Have their manager or leader take tasks off their plate if they are above their skill level.
Do I let an intern take on complex stuff? No. âJerry, I appreciate the enthusiasm but that task is better suited for Gary.â
Then pull them aside and give them an opportunity to explain how they would implement a complex task before taking it on. If they can correctly articulate how to do it, then let them do it.
Also donât let them hog everyoneâs time helping them with their work.
I mean this is general people management. Either the guy can take direction or he canât. You donât have to wait for him to learn it on his own.
niowniough@reddit (OP)
I think your sentiment aligns with the other commenters in that guiding may be less effective than having a direct conversation. I like your suggestion of making them explain how they would implement the complex task, and failing that they don't get to do it. They may be able to do it once some concrete examples have been implemented by others.
dbxp@reddit
Why call them a beaver and not a hog? Taking up too many tasks and hiding them away sounds like classic squirrel behaviour, IIRC they don't find the majority of the nuts they bury
As for the meat of your post though I think it can be caused by there not being enough opportunities to get ahead or work on interesting things, this leads to people claiming tickets and being territorial. An employee is not intrinsically interested in the performance of the team, they have their own personal motivations. It's up to the lead to try to align those motivations with what the company wants. In this case the employee wants interesting work and chances to get ahead and the company wants them to take more responsibility for delivery. So I would give them lead on a small feature, this gives them the exposure to get ahead but that also means it's on their head if they don't deliver.
niowniough@reddit (OP)
I like how you have listed a whole gathering of animals here. I think beavers have a positive connotation as being studious in general, perhaps inspiring phrases like "eager beaver".
You're right that we need to align the incentives of the individual with the team.
This beaver actually has been given some interesting work, but it doesn't seem to satisfy them.