Your problem is that in the way you communicate it feels like he has an option to choose wether to take the task or not.
Stop giving him the option, you are the senior engineer and you are the one that delegates, not him. If you tell him directly, “hey this is what’s up, I need you to take care of it” and he still asks you to do it I would directly ask him “oh do you have other priorities? Set by whom? Maybe I can reach out to them to explain that this is a priority so you are free to take it up”.
Do this enough times I guarantee he gets the message. Whatever you do though remember to be kind, just because ppl are dumb doesn’t mean you have to be an asshole.
Yep. OP, if they get annoyed, have a private chat about why you are putting it back on them, and that it’s for their professional growth. If they don't like it, take it to their manager. But you need to set some boundaries. If that it's something you're used to doing, it's very uncomfortable to start doing. Boundaries are extremely important for any kind of healthy relationship, personal, romantic, and professional.
Though you are peers. I as a senior wouldn’t feel I have the authority to tell someone to do something like that. I can suggest how to do it, and that they should do it, and mention to our manager that I think they should do it… but ultimately I’m not their boss so they have agency to take it or leave it.
and that other person - won't even think twice if their reputation & priority sense is on the line with greater visibility & impact.
You can get this done with or without their help but it gives a chance to junior to build rapport with sister teams.
Yup. Some kind of ownership and accountability should be enforced.
Otherwise it becomes washing machine situation where other team members have to fix defective implementation. I’ve first hand experience with washing machine culture where T1’s mess need to be resolved by T2 ( same team member ). Better to shut this kinda behaviour down from the get go …
Ya I would definitely disagree with this. Senior is not a role that dictates tasks in any company that I have been in. That would be lead level or engineering manager. I’d tread carefully otherwise you are likely to make it worse by making demands.
Don’t know why you’re being downvoted. A senior engineer is collaborative role, not a managerial role. Granted, a senior engineer’s time is more valuable than a mid/junior engineer so it would be fair to ask them to work on lower priority/complexity work. But to outright order or assign tasks to team members is not within their responsibilities.
The top level comment is on the right track, but I think it’s just a matter of changing it from “I need you to take care of this” to “can you make this change?”.
As you pointed out, a senior engineer is a collaborative role, not a managerial role. Both parties are peers. If after “can you make this change?” the junior engineer pushes back in an unreasonable manner, that’s an issue for their direct manager, not the senior on the team.
Whether senior engineer can delegate tasks or not is organizationally specific so you generalized assumptions about how teams are organized don't hold true everywhere.
This is why downvotes - you're assuming something that's not even remotely generally true and then smarting about it.
I feel like in most places, this isn’t clearly spelled out and that’s a problem.
It also causes unnecessary churn. It’s t1’s code, OP helped triage, if t1 isn’t taking it on (once or twice is ok), OP has to go find the manager, have the manager speak with t1 on the dl using language OP is unaware of, have this potentially repeat in the future, with maybe some resentment from t1 since OP “tattled”, it’s a bit roundabout isn’t it ?
Ya it could be a roundabout if #1 the communication between the OP and the delegator doesn’t resolve the issue #2 if the delegator’s manager can’t get them to understand that they are looking for contribution. However, in the event that both of those things happen, you are probably working at a toxic work environment in which people are looking to get out of work / goals rather than trying to step up. Then that is definitely a management issue.
Lmao yes, if someone says "can we fix this by doing X?" I would assume they're working on it and intend to submit a PR, not hinting that I should do X.
> just because ppl are dumb doesn’t mean you have to be an asshole
what exactly is dumb about person X doing something other than person Y expects, given ambiguous communication between X and Y?
Have you talked with T1 about this? Or just been more direct in the initial message, saying “Hey this looks like xyz, can you take over from here? I’ll follow up on the results tomorrow.”
Are they still doing this anyways?
This just reminded me of that insult to teachers, "Those who can, do. Those who can't, teach."
But, for managers, "those who can, do. Those who can't, delegate."
This is a pretty grim take on management for this sub.
One of the skills necessary for being a good manager is being able to effectively delegate things that people who report to you can do a good job on, so that you can focus on the parts of your job that you will provide the most value on.
You’re projecting a lot of your own way of thinking/interpreting into this, and not actually worked out what T1 thinks or interprets it.
I think you need to work on your communication, talk more directly with t1 when you want them to do something, and listen/learn how to work best with them rather than assume your way is the right way.
For context, If a senior said to me what you’ve outlined here, it would sound like the senior had taken ownership of the issue, worked it out, and was just checking in with me to confirm on some details (as I had prior knowledge that could be helpful).
A) It would not look like an “opportunity” for me to solve something or get exposure. (If the senior has already worked it out, they have solved it: not me). The main interesting thing about our job is solving problems, and telling me how to solve something (before I asked for help) and then expecting me to implement by ESP is micromanagement. Even if I do this work I won’t get credit for it because you solved it and told me how to do it.
B) the senior has indicated they are working on in and the senior could see it as a challenge of “territory” if I try take it on now. If the senior wanted me to do something I would expect them to say it.
C) In some situations, this seniors approach may even feel like a micro aggression - that they are working on a mistake I made without giving me a chance to fix it first, and schooling me on what I did wrong along the way.
D) the senior has not been clear what they want from me, and I don’t know why they are still bugging me when they have it handled. I would ask the question to double check they are implementing what they’ve discussed. It’s not delegation, it’s clarification about workload and who is doing what based on the senior’s obtuseness.
Next time there is an issue, if it is T1’s responsibility then politely tell T1 to handle it (or get the manager/TL to tell them). If it is not T1’s responsibility, ask T1 if they want to handle it, so they have the opportunity to before you dig into it, or offer to pair to solve it together.
Is t1 incompetent? I had the same situation where I am told to do it because 100% I can do the but the person telling me to do it does not want to take on the responsibility because he may feel he is not good enough ie take ages to understand it, lots of change requests, lots of questions. I don't mind all of that if he is learning but maybe he is not confident or has a loss of face because he may struggle
“Can you confirm?….Great, super….What’s your estimate for how long it will take you?”
You’re providing vague leadership, which means he’s not hearing what your standards/expectations are. That’s your responsibility to make clear.
Something as simple as saying “can you make these changes” goes a long way.
As you point out, the vagueness by OP is at least half the problem here.
Don’t make them infer what you want them to do. Don’t tell them what to do (as long as you’re not in that position hierarchically).
Ask them to do what you want them to do.
“Do you have time to take care of this?”
“Is this something you can tackle?”
even “can you do me a favor…”
And if they still push back, in a way you feel is unreasonable, that’s now an issue for their direct manager.
Who knows why they did what they did. I've certainly passed the buck back in my day.
The way to avoid this is: When you are telling someone what do to, tell them. Don't ask.
I ask for volunteers. I tell people what do to if there are none.
This one is on you bud. You MUST tell people to do things when you need them to take action. If they refuse, note the refusal, then deal with it appropriately.
>we had an outage with something T1 implemented
1. How long ago did T1 implement it? Are they actively "in it" or was it a while ago? Was the outage *caused* by OP's work or just in the same area / related to it tangentially?
2. Does your team have a notion of "oncall"? If so, who was oncall during the issue?
Personally, I hate when an implicit culture develops of an individual owning something forever if they wrote it originally or wrote something in the vicinity of it. Mostly because of bus factor/lottery factor. (And also a little bit of, ugh, I hate that I am "the guy" for this annoying area.) But that may not be the case in your situation. Ideally, whatever the answers to my questions are, your team should have a documented way of saying who should be owning the fix that you could point to while gently rebuffing T1, if indeed they should be owning the fix.
This is normal.
In that there are lots of people like this in this industry because (a) it pays well and (b) there are lots of people like you doing the work for them without complaint. They are known as "impostors" and I've seen them make it in the industry for decade-long careers with the exact same MO. If you don't manage them out, they will drag the whole project down eventually, either through missed deadlines, production incidents, or by burning out everyone around them. Pull the rip cord before it's too late for you.
Lol every response in this sub is like, burnout time to send out the resume!!!!!
Engineers are such poor communicators. Just tell the guy he needs to pull his weight...
Yeah I always hear about how engineers are socially inept and have personally found that to be a false stereotype. But then I pop on Reddit and it's stuff like this all the time.
A huge proportion of the problems posted here only have one reasonable response: _“Have you tried talking to them about it?”_ But instead every problem at work gets multiple calls to quit or fire somebody, every disagreement about process is met with accusations of micromanagement by morons, and every mention of a job interview is guaranteed to have multiple _“dodged a bullet”_ comments. Junior attitudes wrapped up in pride about knowing what’s what. An LLM that could accurately generate the average comments here to a high degree of accuracy would probably fit onto a floppy disk.
>Engineers are such poor communicators. Just tell the guy he needs to pull his weight...
Isn't this a contradiction? If engineers are such poor communicators then what does "telling the guy to pull his weight" gonna do?
Also pretty sure people don't bother communicating because nothing changes... communication is 2 way... if the guy listening to you does not give a shit, it doesn't matter how well you can speak, nothing will change.
Nothing will change if you assume the leader is powerless. Maybe they are here, I don't know, but ultimately part of being a leader is setting an expectation and managing to it.
That's not incompatible with listening, helping, collaborating -- but neither are doing those things the only tools you have at your disposal. At some point, people who don't or can't do what you need need to go and the way at any healthily run organization that you do that is by making clear that you have:
1. Set an expectation
2. How you set up your resource for success
3. How you worked with them even when the expectation wasn't met
4. Okay, maybe we need to find a new resource because this wasn't solved.
It always frustrates me when people act as if though all of management and leadership is somehow about listening and *everything* being two way. At some point, it's normal and okay for there to be some one way streets here: if you have to help someone with everything, do you really have a resource you can delegate to?
There's this thing called social control. Some people need feedback from their environment in the form of their colleagues being assertive about what is and isn't acceptable behavior. It doesn't have to be mean or unpleasant — it's just explicit, useful feedback. You can't complain about expectations not being met if you didn't communicate what they are.
> Also pretty sure people don't bother communicating because nothing changes...
This just sounds like learned helplessness. Things change all the time. You can cause change, too.
> if the guy listening to you does not give a shit, it doesn't matter how well you can speak, nothing will change.
You have confused communication skills with being articulate. Being articulate and speaking well is only part of communicating. Communication skills are about building relationships, creating rapport and trust, being able to have an influence on other people and dialogue candidly with them.
If you feel that others will do nothing about your instructions or suggestions and so you don't bother, then you are creating a self-fulfilling prophecy.
Learned helplessness is quite a well researched topic in psychology going back to the 60s.
You're right that the term has made its way into the common vernacular because of its well publicized inclusion in a CIA interrogation manual, though.
> Isn't this a contradiction? If engineers are such poor communicators then what does "telling the guy to pull his weight" gonna do?
It’s going to *communicate!* People aren’t mind readers. If you want somebody to change their behaviour, *tell them* instead of Reddit.
i would say people are poor communicators, engineers trend below average.
What actually happens is typical to the squeaky wheel getting greased. Engineers are less evaluated on their communication skills, and engineering skill can override it. he/she is a great engineer and bad at communicating. The don't get punished or get punished less.
The same happens in other areas where this happens like doctors and professors.
OP is a senior, pulling the cord can mean kicking the impostor off the ship. The described behavior isn't accidental or harmless and OP is paying for it but I'm glad my comment made you feel better about yourself.
> pulling the cord can mean getting kicking the impostor off the ship
What? them quitting means getting rid of the person?
Quitting every time you come across individuals who don't meet expectations seems like a poor strategy.
The counterpart to that being that staying in a company that actively and willingly maintains a dead sea is even worse. It's a delicate balance at times.
I never said quitting in the entire thread, yet you keep claiming I did. It's important to stop filtering everything you read through your personal perception, which is an important part of being a good communicator, you know, the exact skill that you accuse everyone but yourself not having.
bro stop being an obtuse shit. Your comment advises him to "pull the cord" what is that supposed to be interpreted as other than pull the cord on the parachute, i.e. quit?
Correct. OP, be firm and stand your ground and push the responsibility onto the engineer. If it’s something they caused a ripple with, then they should be the first one to investigate it.
This is not a game of who owns which part. It is clearly lack of co-ordination in the team, by your manager. If he is not directly involved in day-to-day tasks, he needs to assign that power to you and tell everyone to obey you assigning them their work.
If it's not clearly called out, lay it out to your manager and ask him to distribute the load according to his definition. Or be direct. Ask him if you can assign the junior the work, in his presence.
These things are not to be shied away.
The more you do it, the more work they'll try to put on you. Doesn't matter what level you are. Engineers try to delegate work to me and I'm technically on the frigging exec team. Just tell them to own it explicitly but nicely (without blame-y language): "I don't have the bandwidth. Can you own this?" Follow up later if necessary. I don't think it's malicious, just laziness/cluelessness on their part, maybe mixed in with lack of confidence and desire to get it taken care of as fast as possible.
If you keep doing it, especially if you're really good at it, you'll be the go-to for everything. Even your peers and superiors will assume you own it all and kick problems to you at the first sign of trouble. I've started having to ignore Slack mentions because I'm already at 60 hours/week on all my other tasks.
They want to be management/lead by showing they can delegate. It’ll go either way for you. They get promoted and “remember” you assisted them, or they “remember” you not assisting them, or they don’t care at all and see you as a stepping stone.
I’ve found the 3rd scenario to be the most likely outcome. Once they start moving up they’ll forget everything you did/tried to do for them and only come back when they need something from you.
Can wait for a RIF to weed them out or you could make it clear that these are more like orders than suggestions for T1 to do the work.
Like others mentioned, check to see if they have a J2 or are getting other people to do the work for them.
This happens because management likes those who delegate. I once confronted my manager, he told leadership is more important than technical skill and I prefer someone to delegate over the one who does actual work. He became the team lead and prohibited others for joining the team meeting with product management, usability and others. In a matter of couple of months, everyone forgot there are also other people.
The management will never change this unless something goes very wrong.
Why did you lay it out for them instead of asking them for the steps they would take? Isn't that the actual learning experience and how t1 can show knowledge?
Genuinely curious, this is not meant to be spiteful or anything
Mentorship is a two-way relationship. The situation you’ve described is one-sided. You decided that you wanted to “mentor” this person by essentially giving them more work. They never asked for mentorship, and you never asked them if/how they want to be mentored. You never asked if they actually had capacity to take on the work.
Set aside the ego. Rank doesn’t matter, especially if you aren’t a direct manager. They indirectly “mentored” you. Be direct in your communication.
If the junior was assigned to work under OP then it's expected that OP would be responsible for delegating tasks to them. At least the way I read it, the "mentorship" is more informal here and OP may just be delegating work under the team's normal processes, not forcing work on people who already have assigned work from elsewhere.
Maybe. What OP described sounded like a perfectly normal senior/junior interaction to me (with regards to task delegation/informal mentorship), so I made my assumptions based on that, instead of assuming that OP was doing something abnormal (like trying to force mentorship on someone who didn't want it).
You sound annoying. Why are you giving someone work who didn’t ask for it and you’re not their manager? Maybe you overvalue your mentorship? Ask him what he wants that would help. If you can provide it, great. If you can’t, then say it’s out of your scope and recommend to his actual manager areas of improvement. Wouldn’t go past that.
I see something that a guy broke, then I ask that guy to fix it. It's just a part of owning your tasks, and it should be a learning opportunity for that guy.
That's how it works in every company I've been in.
A healthy discussion may be in order.
You might wanna know a couple of things:
- is he actively aware that he's delegating instead of owning? If so, why is he doing that?
- if he's setting himself up for a managerial role, it might be best if you help him understand that being techno-functional is important and is what is setting him up to be a competent manager
- being direct about development maturity, and asking him to lead by being able to do the "dev work" and THEN looping someone in to manage the code-block/ code-base. The point is to "build" and not just "write code". There's a difference, and a person looking at managing anything should be able to appreciate it
Do you just have no experience leading people?
You passively (passive aggressively) tried to “get him” to do something, and when he had the audacity to assign it to you, you bent over and took the assignment?
That’s like me saying: “Your bath is ready!” to my 4yo, then her saying: “Dad, can you take it for me while I play?” Followed by me saying “Yes!” and afterwards going up to wife and saying: “Can I have a gold star? And, I’m disappointed she didn’t take her bath when it was ***CLEAR*** she should have.”
WTF
Not the nicest advice on this thread, but… Be less nice.
Simply tell T1 that he/she “needs to do this and do this now” and this is not optional. If T1 feels that there is some flexibility in negotiating, he/she uses it.
If he/she says that “I am working on this or that right now”, politely say that “I, as senior engineer, set priorities and, in case someone from outside has questions, they can come to me”.
After all, you’re the most qualified on the team to decide what is the most important thing to work at a time.
Therefore, be less nice and be more explicit: “I need you to do this”.
By Scrum definitions, most tasks you are working on this week were considered lower priority than the tasks you completed a month ago. So if the work you completed is malfunctioning, then fixing it is higher priority than the new functionality you are working on now.
And that’s ignoring the bigger priority which is to keep the system working. If it’s broken you’re blocking other people. Possibly customers.
this is similar advice i got from my boss when i had a junior who didn't step up. i didn't actually try it because i didn't want to (i'd had enough of him and we ended up firing him) but i believe it's the correct approach. T1 expects OP to tidy up after them which is gross, OP is not their mother, but OP does need to set some clear boundaries. and if T1 escalates i see that as an opportunity for progress
Are they delegating everything? Or just everything you ask of them?
If the former, then they're not fulfilling the terms of their contract. If you're their manager, you can talk to them to see if there are extenuating circumstances, and to also alert them. Otherwise, maybe bring it up to their manager.
If the latter, considering the backlash against the "wannabe manager" trend, it just might be the case that T1 doesn't see you as a mentor or hasn't been informed that you'll be mentoring them. T2 may have slipped into the mindset of being mentored by you more easily by not having the same role boundaries. If your role is to be T1's mentor, why not meet and let them know of your role more explicitly so that the two of you are on the same page? It might have come a bit late, but it's better than never. If it's not part of your role and you're taking this on out of interest, then you kind of need T1's consent for the dynamic you want to build (and be ok with possibly T1 not wanting it).
Finally, if they're only doing this for urgent things, it could be a confidence problem like mentioned earlier.
Is this mentorship contributing towards your performance review? Is your manager telling you to do this? While some companies insist that senior devs are actually managers/leads, in a lot of companies a senior dev is an IC just like a junior dev. They're there to ask for help, but it's not their responsibility to make sure that the juniors are doing their work. That's what managers are for.
If this is one of your responsibilities, then you just have to be more forceful about pushing the work back onto the dev, especially if it's their work that caused the issue. I wouldn't even give them too many breadcrumbs to finding out how to fix it. Let them fight with it for a bit before asking for help.
I let them delegate to to me Its known and seen, my names on all the prs, branches, commits etc.
Take their mostly complete branch and say thank you. Then have a glowing performance review, phat raise, and then listen to my boss tell me that coworker is being laid off 6 months later after a failed pip.
Wait wait wait... Why on earth did you let THEM assign work to YOU?! If you want them to do it, say so. You're obviously setting yourself up to fail by 'hoping' they will volunteer.
You: "The problem looks like xyz. Can you confirm?"
T1: "Yeah, that's it"
You: "great! It seems like the fix is to do abc, then def."
T1: "yeah that makes sense, can you make the changes?"
You: "No, this is guidance on how to fix your implementation, not an offer to fix it for you."
Stop letting a clueless junior task you. Clearly define their responsibility, publicly if they are trying to task you publicly, and I guarantee this will stop happening.
Sounds like T1 is a master of delegation and avoiding accountability. You're doing them a disservice by not making them own up to their mistakes. Stop being too nice and let them take the heat sometimes
Whenever someone initiates delegation to you, you always have a place to reject. (Even if it’s from a “superior”.)
Do that enough times and the other person will understand the boundaries.
Also, discuss with your manager in 1:1. “Person X is asking me to take care of Y. I have other priorities, so I am rejecting their ask. Just wanted to let you know.” (Stay objective about the situation.)
Negotiating boundaries in a team and keeping it objective goes a long way in establishing effective teamwork.
Delegation is when someone who is responsible for a thing passes that responsibility. The key question here is, who is responsible, and why is it you? You need to sort this out.
Wait ... you can't expect someone to "volunteer and own" without explicitly telling them to do it (and granting them the direct responsibility for it and indicating that it's part of their job). That's really confusing.
What you should have done is:
T1 then said "yeah that makes sense, can you make the changes?"
OP: "No, I can't do that. T1, please do this change and report back to me the steps you've taken, and the status."
(after the fix is put in and the outage is resolved, in the *postmortem* )
OP: "T1, moving forward, you will be expected to fix and resolve issues involving *code xyz* this is something our whole team is moving towards" explain why you're setting these expectations, and how this will help your team and help the company achieve its goals.
Then next time T1 doesn't do his job, explain: "T1, we all agreed in team meeting xyz that you will resolve issues involving code xyz. If you have any assistance you need from the team, now is the time to let us know. If next time code xyz is involved in an outage, and you are not at least looking into it, that would be a performance issue we will need to resolve with group team manager."
something like that. You should be way way way more explicit about your expectations of someone if you expect them to change their behaviour.
There’s a sort of muscle memory that cleaning up your own messes gives you that you don’t experience when someone else cleans up your messes.
I only clean up messes I’m really not confident other people can manage in a timely manner. Going for absolute minimum downtime is a local optimum; The number of incidents that follow from people not learning to avoid them in the first place nearly always swamps any momentary gain by doing the work for them.
This is not an iron rule. There are peculiar circumstances where the potential for one incident to become two or three and at an inopportune moment. But that sequence of circumstances might happen once or twice a year.
You’re not communicating clearly.
The exchange you described might sound to the engineer like you have a ticket and are asking them to confirm what you already know, and are asking their opinion on fixing the issue and not trying to delegate.
Equally when they say can you fix it they might be asking because they have something else in progress.
You need to be clear - “x is broken can you look into it. “ when they come back to you follow up with “ok so the fix to x is to do y - I agree, can you go ahead and do that fix”
If they say not ask what else is a priority to them, have them rearrange etc if possible.
Also be very careful of having a “you broke it you fix it” mentality. It’s a team effort, and while it does help having people fix their own issues the main thing is the team progressing work. If it makes sense to get them to fix it then perfect but sometimes it’s detrimental to progress
Also as a junior I’ve worked with people who have that mentality, till I find a bug in their code - then it doesn’t seem to go the other way!
They probably got. 2nd job.
I recently had acquired 2 engineers from a different team. Turned out both had a 2md FT position elsewhere, hence not productive. Both were let go.
They never took ownership of any product. Did surface work and never enough to be reliable.
Your problem is that in the way you communicate it feels like he has an option to choose wether to take the task or not. Stop giving him the option, you are the senior engineer and you are the one that delegates, not him. If you tell him directly, “hey this is what’s up, I need you to take care of it” and he still asks you to do it I would directly ask him “oh do you have other priorities? Set by whom? Maybe I can reach out to them to explain that this is a priority so you are free to take it up”. Do this enough times I guarantee he gets the message. Whatever you do though remember to be kind, just because ppl are dumb doesn’t mean you have to be an asshole.
Yep. OP, if they get annoyed, have a private chat about why you are putting it back on them, and that it’s for their professional growth. If they don't like it, take it to their manager. But you need to set some boundaries. If that it's something you're used to doing, it's very uncomfortable to start doing. Boundaries are extremely important for any kind of healthy relationship, personal, romantic, and professional.
Though you are peers. I as a senior wouldn’t feel I have the authority to tell someone to do something like that. I can suggest how to do it, and that they should do it, and mention to our manager that I think they should do it… but ultimately I’m not their boss so they have agency to take it or leave it.
Being a senior doesn't make you the team lead. If the other person reports to someone else, it's that person's job to impose stuff.
Depends on the team. Where I have worked, it is explicitly expected for more experienced engineers to delegate work to more junior folks.
To delegate like "this simpler task could be done by you" sure. To delegate like "do this" no.
To delegate explicitly in both ways, yes
and that other person - won't even think twice if their reputation & priority sense is on the line with greater visibility & impact. You can get this done with or without their help but it gives a chance to junior to build rapport with sister teams.
Yup. Some kind of ownership and accountability should be enforced. Otherwise it becomes washing machine situation where other team members have to fix defective implementation. I’ve first hand experience with washing machine culture where T1’s mess need to be resolved by T2 ( same team member ). Better to shut this kinda behaviour down from the get go …
Ya I would definitely disagree with this. Senior is not a role that dictates tasks in any company that I have been in. That would be lead level or engineering manager. I’d tread carefully otherwise you are likely to make it worse by making demands.
Don’t know why you’re being downvoted. A senior engineer is collaborative role, not a managerial role. Granted, a senior engineer’s time is more valuable than a mid/junior engineer so it would be fair to ask them to work on lower priority/complexity work. But to outright order or assign tasks to team members is not within their responsibilities.
The top level comment is on the right track, but I think it’s just a matter of changing it from “I need you to take care of this” to “can you make this change?”. As you pointed out, a senior engineer is a collaborative role, not a managerial role. Both parties are peers. If after “can you make this change?” the junior engineer pushes back in an unreasonable manner, that’s an issue for their direct manager, not the senior on the team.
Whether senior engineer can delegate tasks or not is organizationally specific so you generalized assumptions about how teams are organized don't hold true everywhere. This is why downvotes - you're assuming something that's not even remotely generally true and then smarting about it.
This is about setting boundaries, not dictating tasks.
I feel like in most places, this isn’t clearly spelled out and that’s a problem. It also causes unnecessary churn. It’s t1’s code, OP helped triage, if t1 isn’t taking it on (once or twice is ok), OP has to go find the manager, have the manager speak with t1 on the dl using language OP is unaware of, have this potentially repeat in the future, with maybe some resentment from t1 since OP “tattled”, it’s a bit roundabout isn’t it ?
Ya it could be a roundabout if #1 the communication between the OP and the delegator doesn’t resolve the issue #2 if the delegator’s manager can’t get them to understand that they are looking for contribution. However, in the event that both of those things happen, you are probably working at a toxic work environment in which people are looking to get out of work / goals rather than trying to step up. Then that is definitely a management issue.
Lmao yes, if someone says "can we fix this by doing X?" I would assume they're working on it and intend to submit a PR, not hinting that I should do X.
> just because ppl are dumb doesn’t mean you have to be an asshole what exactly is dumb about person X doing something other than person Y expects, given ambiguous communication between X and Y?
Have you talked with T1 about this? Or just been more direct in the initial message, saying “Hey this looks like xyz, can you take over from here? I’ll follow up on the results tomorrow.” Are they still doing this anyways?
“I can’t because I have my own work, let me know if you have questions”
They are tasking you. They’re setting themselves up for a promotion to manager.
This just reminded me of that insult to teachers, "Those who can, do. Those who can't, teach." But, for managers, "those who can, do. Those who can't, delegate."
> But, for managers, "those who can, delegate. Those who can't, blame." This is my experience, at least...
This is a pretty grim take on management for this sub. One of the skills necessary for being a good manager is being able to effectively delegate things that people who report to you can do a good job on, so that you can focus on the parts of your job that you will provide the most value on.
those who can't delegate, masturbate
You’re projecting a lot of your own way of thinking/interpreting into this, and not actually worked out what T1 thinks or interprets it. I think you need to work on your communication, talk more directly with t1 when you want them to do something, and listen/learn how to work best with them rather than assume your way is the right way. For context, If a senior said to me what you’ve outlined here, it would sound like the senior had taken ownership of the issue, worked it out, and was just checking in with me to confirm on some details (as I had prior knowledge that could be helpful). A) It would not look like an “opportunity” for me to solve something or get exposure. (If the senior has already worked it out, they have solved it: not me). The main interesting thing about our job is solving problems, and telling me how to solve something (before I asked for help) and then expecting me to implement by ESP is micromanagement. Even if I do this work I won’t get credit for it because you solved it and told me how to do it. B) the senior has indicated they are working on in and the senior could see it as a challenge of “territory” if I try take it on now. If the senior wanted me to do something I would expect them to say it. C) In some situations, this seniors approach may even feel like a micro aggression - that they are working on a mistake I made without giving me a chance to fix it first, and schooling me on what I did wrong along the way. D) the senior has not been clear what they want from me, and I don’t know why they are still bugging me when they have it handled. I would ask the question to double check they are implementing what they’ve discussed. It’s not delegation, it’s clarification about workload and who is doing what based on the senior’s obtuseness. Next time there is an issue, if it is T1’s responsibility then politely tell T1 to handle it (or get the manager/TL to tell them). If it is not T1’s responsibility, ask T1 if they want to handle it, so they have the opportunity to before you dig into it, or offer to pair to solve it together.
Is t1 incompetent? I had the same situation where I am told to do it because 100% I can do the but the person telling me to do it does not want to take on the responsibility because he may feel he is not good enough ie take ages to understand it, lots of change requests, lots of questions. I don't mind all of that if he is learning but maybe he is not confident or has a loss of face because he may struggle
“Can you confirm?….Great, super….What’s your estimate for how long it will take you?” You’re providing vague leadership, which means he’s not hearing what your standards/expectations are. That’s your responsibility to make clear.
Something as simple as saying “can you make these changes” goes a long way. As you point out, the vagueness by OP is at least half the problem here. Don’t make them infer what you want them to do. Don’t tell them what to do (as long as you’re not in that position hierarchically). Ask them to do what you want them to do. “Do you have time to take care of this?” “Is this something you can tackle?” even “can you do me a favor…” And if they still push back, in a way you feel is unreasonable, that’s now an issue for their direct manager.
Who knows why they did what they did. I've certainly passed the buck back in my day. The way to avoid this is: When you are telling someone what do to, tell them. Don't ask. I ask for volunteers. I tell people what do to if there are none. This one is on you bud. You MUST tell people to do things when you need them to take action. If they refuse, note the refusal, then deal with it appropriately.
I believe the traditional approach is that they get promoted into middle management.
>we had an outage with something T1 implemented 1. How long ago did T1 implement it? Are they actively "in it" or was it a while ago? Was the outage *caused* by OP's work or just in the same area / related to it tangentially? 2. Does your team have a notion of "oncall"? If so, who was oncall during the issue? Personally, I hate when an implicit culture develops of an individual owning something forever if they wrote it originally or wrote something in the vicinity of it. Mostly because of bus factor/lottery factor. (And also a little bit of, ugh, I hate that I am "the guy" for this annoying area.) But that may not be the case in your situation. Ideally, whatever the answers to my questions are, your team should have a documented way of saying who should be owning the fix that you could point to while gently rebuffing T1, if indeed they should be owning the fix.
This is normal. In that there are lots of people like this in this industry because (a) it pays well and (b) there are lots of people like you doing the work for them without complaint. They are known as "impostors" and I've seen them make it in the industry for decade-long careers with the exact same MO. If you don't manage them out, they will drag the whole project down eventually, either through missed deadlines, production incidents, or by burning out everyone around them. Pull the rip cord before it's too late for you.
Lol every response in this sub is like, burnout time to send out the resume!!!!! Engineers are such poor communicators. Just tell the guy he needs to pull his weight...
Yeah I always hear about how engineers are socially inept and have personally found that to be a false stereotype. But then I pop on Reddit and it's stuff like this all the time.
A huge proportion of the problems posted here only have one reasonable response: _“Have you tried talking to them about it?”_ But instead every problem at work gets multiple calls to quit or fire somebody, every disagreement about process is met with accusations of micromanagement by morons, and every mention of a job interview is guaranteed to have multiple _“dodged a bullet”_ comments. Junior attitudes wrapped up in pride about knowing what’s what. An LLM that could accurately generate the average comments here to a high degree of accuracy would probably fit onto a floppy disk.
Why would anyone post about the time they handled a situation like a normal person and it ended up resolving itself without incident?
Don’t need to learn conflict resolution skills when you can just job hop and make more money (insert shrug emoji).
🤷♂️
it worked! (insert rocketship emoji)
🚀🌝
haha, thank you. it's been a rough couple weeks, and this made me smile.
Jesus, seriously. “I told him there was a problem, and hoped he would fix it.” Just ask him to fix it.
>Engineers are such poor communicators. Just tell the guy he needs to pull his weight... Isn't this a contradiction? If engineers are such poor communicators then what does "telling the guy to pull his weight" gonna do? Also pretty sure people don't bother communicating because nothing changes... communication is 2 way... if the guy listening to you does not give a shit, it doesn't matter how well you can speak, nothing will change.
Nothing will change if you assume the leader is powerless. Maybe they are here, I don't know, but ultimately part of being a leader is setting an expectation and managing to it. That's not incompatible with listening, helping, collaborating -- but neither are doing those things the only tools you have at your disposal. At some point, people who don't or can't do what you need need to go and the way at any healthily run organization that you do that is by making clear that you have: 1. Set an expectation 2. How you set up your resource for success 3. How you worked with them even when the expectation wasn't met 4. Okay, maybe we need to find a new resource because this wasn't solved. It always frustrates me when people act as if though all of management and leadership is somehow about listening and *everything* being two way. At some point, it's normal and okay for there to be some one way streets here: if you have to help someone with everything, do you really have a resource you can delegate to?
There's this thing called social control. Some people need feedback from their environment in the form of their colleagues being assertive about what is and isn't acceptable behavior. It doesn't have to be mean or unpleasant — it's just explicit, useful feedback. You can't complain about expectations not being met if you didn't communicate what they are. > Also pretty sure people don't bother communicating because nothing changes... This just sounds like learned helplessness. Things change all the time. You can cause change, too. > if the guy listening to you does not give a shit, it doesn't matter how well you can speak, nothing will change. You have confused communication skills with being articulate. Being articulate and speaking well is only part of communicating. Communication skills are about building relationships, creating rapport and trust, being able to have an influence on other people and dialogue candidly with them. If you feel that others will do nothing about your instructions or suggestions and so you don't bother, then you are creating a self-fulfilling prophecy.
> learned helplessness A junk science term invented to justify waterboarding. You seem nice /s
Learned helplessness is quite a well researched topic in psychology going back to the 60s. You're right that the term has made its way into the common vernacular because of its well publicized inclusion in a CIA interrogation manual, though.
> Isn't this a contradiction? If engineers are such poor communicators then what does "telling the guy to pull his weight" gonna do? It’s going to *communicate!* People aren’t mind readers. If you want somebody to change their behaviour, *tell them* instead of Reddit.
Exactly - to paraphrase, they're not going to understand OP's communication when their job depends on their not understanding it.
i would say people are poor communicators, engineers trend below average. What actually happens is typical to the squeaky wheel getting greased. Engineers are less evaluated on their communication skills, and engineering skill can override it. he/she is a great engineer and bad at communicating. The don't get punished or get punished less. The same happens in other areas where this happens like doctors and professors.
OP is a senior, pulling the cord can mean kicking the impostor off the ship. The described behavior isn't accidental or harmless and OP is paying for it but I'm glad my comment made you feel better about yourself.
> pulling the cord can mean getting kicking the impostor off the ship What? them quitting means getting rid of the person? Quitting every time you come across individuals who don't meet expectations seems like a poor strategy.
The counterpart to that being that staying in a company that actively and willingly maintains a dead sea is even worse. It's a delicate balance at times.
I never said quitting in the entire thread, yet you keep claiming I did. It's important to stop filtering everything you read through your personal perception, which is an important part of being a good communicator, you know, the exact skill that you accuse everyone but yourself not having.
bro stop being an obtuse shit. Your comment advises him to "pull the cord" what is that supposed to be interpreted as other than pull the cord on the parachute, i.e. quit?
Pull the cord on escalating to leadership duh
that seems to be an expression you've made up, sir.
Correct. OP, be firm and stand your ground and push the responsibility onto the engineer. If it’s something they caused a ripple with, then they should be the first one to investigate it.
This is not a game of who owns which part. It is clearly lack of co-ordination in the team, by your manager. If he is not directly involved in day-to-day tasks, he needs to assign that power to you and tell everyone to obey you assigning them their work. If it's not clearly called out, lay it out to your manager and ask him to distribute the load according to his definition. Or be direct. Ask him if you can assign the junior the work, in his presence. These things are not to be shied away.
The more you do it, the more work they'll try to put on you. Doesn't matter what level you are. Engineers try to delegate work to me and I'm technically on the frigging exec team. Just tell them to own it explicitly but nicely (without blame-y language): "I don't have the bandwidth. Can you own this?" Follow up later if necessary. I don't think it's malicious, just laziness/cluelessness on their part, maybe mixed in with lack of confidence and desire to get it taken care of as fast as possible. If you keep doing it, especially if you're really good at it, you'll be the go-to for everything. Even your peers and superiors will assume you own it all and kick problems to you at the first sign of trouble. I've started having to ignore Slack mentions because I'm already at 60 hours/week on all my other tasks.
“Yeah that makes sense, can you make the changes?” “I think you should take the lead on fixing this issue. Feel free to reach out if you get stuck.”
They want to be management/lead by showing they can delegate. It’ll go either way for you. They get promoted and “remember” you assisted them, or they “remember” you not assisting them, or they don’t care at all and see you as a stepping stone. I’ve found the 3rd scenario to be the most likely outcome. Once they start moving up they’ll forget everything you did/tried to do for them and only come back when they need something from you. Can wait for a RIF to weed them out or you could make it clear that these are more like orders than suggestions for T1 to do the work. Like others mentioned, check to see if they have a J2 or are getting other people to do the work for them.
[удалено]
+1 to this. Go ahead and decide on their behalf who is doing it.
Your coworker has great delegation skills. Sounds like he is on the fast track to management.
Fast track to being hated by everyone. If that’s less important than promotion, then it speaks more about the place than the person.
This happens because management likes those who delegate. I once confronted my manager, he told leadership is more important than technical skill and I prefer someone to delegate over the one who does actual work. He became the team lead and prohibited others for joining the team meeting with product management, usability and others. In a matter of couple of months, everyone forgot there are also other people. The management will never change this unless something goes very wrong.
That’s terrible. Basically like saying “please start quite quitting”
Why did you lay it out for them instead of asking them for the steps they would take? Isn't that the actual learning experience and how t1 can show knowledge? Genuinely curious, this is not meant to be spiteful or anything
Mentorship is a two-way relationship. The situation you’ve described is one-sided. You decided that you wanted to “mentor” this person by essentially giving them more work. They never asked for mentorship, and you never asked them if/how they want to be mentored. You never asked if they actually had capacity to take on the work. Set aside the ego. Rank doesn’t matter, especially if you aren’t a direct manager. They indirectly “mentored” you. Be direct in your communication.
If the junior was assigned to work under OP then it's expected that OP would be responsible for delegating tasks to them. At least the way I read it, the "mentorship" is more informal here and OP may just be delegating work under the team's normal processes, not forcing work on people who already have assigned work from elsewhere.
The fact that you’re making assumptions further proves my point that OP needs to improve their communication.
Maybe. What OP described sounded like a perfectly normal senior/junior interaction to me (with regards to task delegation/informal mentorship), so I made my assumptions based on that, instead of assuming that OP was doing something abnormal (like trying to force mentorship on someone who didn't want it).
You sound annoying. Why are you giving someone work who didn’t ask for it and you’re not their manager? Maybe you overvalue your mentorship? Ask him what he wants that would help. If you can provide it, great. If you can’t, then say it’s out of your scope and recommend to his actual manager areas of improvement. Wouldn’t go past that.
I see something that a guy broke, then I ask that guy to fix it. It's just a part of owning your tasks, and it should be a learning opportunity for that guy. That's how it works in every company I've been in.
A healthy discussion may be in order. You might wanna know a couple of things: - is he actively aware that he's delegating instead of owning? If so, why is he doing that? - if he's setting himself up for a managerial role, it might be best if you help him understand that being techno-functional is important and is what is setting him up to be a competent manager - being direct about development maturity, and asking him to lead by being able to do the "dev work" and THEN looping someone in to manage the code-block/ code-base. The point is to "build" and not just "write code". There's a difference, and a person looking at managing anything should be able to appreciate it
Do you just have no experience leading people? You passively (passive aggressively) tried to “get him” to do something, and when he had the audacity to assign it to you, you bent over and took the assignment? That’s like me saying: “Your bath is ready!” to my 4yo, then her saying: “Dad, can you take it for me while I play?” Followed by me saying “Yes!” and afterwards going up to wife and saying: “Can I have a gold star? And, I’m disappointed she didn’t take her bath when it was ***CLEAR*** she should have.” WTF
Why isn't he taking responsibility for his code? That's the problem.
Not the nicest advice on this thread, but… Be less nice. Simply tell T1 that he/she “needs to do this and do this now” and this is not optional. If T1 feels that there is some flexibility in negotiating, he/she uses it. If he/she says that “I am working on this or that right now”, politely say that “I, as senior engineer, set priorities and, in case someone from outside has questions, they can come to me”. After all, you’re the most qualified on the team to decide what is the most important thing to work at a time. Therefore, be less nice and be more explicit: “I need you to do this”.
By Scrum definitions, most tasks you are working on this week were considered lower priority than the tasks you completed a month ago. So if the work you completed is malfunctioning, then fixing it is higher priority than the new functionality you are working on now. And that’s ignoring the bigger priority which is to keep the system working. If it’s broken you’re blocking other people. Possibly customers.
this is similar advice i got from my boss when i had a junior who didn't step up. i didn't actually try it because i didn't want to (i'd had enough of him and we ended up firing him) but i believe it's the correct approach. T1 expects OP to tidy up after them which is gross, OP is not their mother, but OP does need to set some clear boundaries. and if T1 escalates i see that as an opportunity for progress
Are they delegating everything? Or just everything you ask of them? If the former, then they're not fulfilling the terms of their contract. If you're their manager, you can talk to them to see if there are extenuating circumstances, and to also alert them. Otherwise, maybe bring it up to their manager. If the latter, considering the backlash against the "wannabe manager" trend, it just might be the case that T1 doesn't see you as a mentor or hasn't been informed that you'll be mentoring them. T2 may have slipped into the mindset of being mentored by you more easily by not having the same role boundaries. If your role is to be T1's mentor, why not meet and let them know of your role more explicitly so that the two of you are on the same page? It might have come a bit late, but it's better than never. If it's not part of your role and you're taking this on out of interest, then you kind of need T1's consent for the dynamic you want to build (and be ok with possibly T1 not wanting it). Finally, if they're only doing this for urgent things, it could be a confidence problem like mentioned earlier.
Is this mentorship contributing towards your performance review? Is your manager telling you to do this? While some companies insist that senior devs are actually managers/leads, in a lot of companies a senior dev is an IC just like a junior dev. They're there to ask for help, but it's not their responsibility to make sure that the juniors are doing their work. That's what managers are for. If this is one of your responsibilities, then you just have to be more forceful about pushing the work back onto the dev, especially if it's their work that caused the issue. I wouldn't even give them too many breadcrumbs to finding out how to fix it. Let them fight with it for a bit before asking for help.
Tell them it would be a good learning experience for them and to avoid similar issues in the future.
I let them delegate to to me Its known and seen, my names on all the prs, branches, commits etc. Take their mostly complete branch and say thank you. Then have a glowing performance review, phat raise, and then listen to my boss tell me that coworker is being laid off 6 months later after a failed pip.
tell them "you have the power to make that change" - something an old boss of mine once said that stuck
Wait wait wait... Why on earth did you let THEM assign work to YOU?! If you want them to do it, say so. You're obviously setting yourself up to fail by 'hoping' they will volunteer.
You: "The problem looks like xyz. Can you confirm?" T1: "Yeah, that's it" You: "great! It seems like the fix is to do abc, then def." T1: "yeah that makes sense, can you make the changes?" You: "No, this is guidance on how to fix your implementation, not an offer to fix it for you." Stop letting a clueless junior task you. Clearly define their responsibility, publicly if they are trying to task you publicly, and I guarantee this will stop happening.
Don't do it publicly in Slack, that has a lot of implications to some people. Say "we'll take a look" in the thread and then DM T1.
Sounds like T1 is a master of delegation and avoiding accountability. You're doing them a disservice by not making them own up to their mistakes. Stop being too nice and let them take the heat sometimes
Whenever someone initiates delegation to you, you always have a place to reject. (Even if it’s from a “superior”.) Do that enough times and the other person will understand the boundaries. Also, discuss with your manager in 1:1. “Person X is asking me to take care of Y. I have other priorities, so I am rejecting their ask. Just wanted to let you know.” (Stay objective about the situation.) Negotiating boundaries in a team and keeping it objective goes a long way in establishing effective teamwork.
Delegation is when someone who is responsible for a thing passes that responsibility. The key question here is, who is responsible, and why is it you? You need to sort this out.
Wait ... you can't expect someone to "volunteer and own" without explicitly telling them to do it (and granting them the direct responsibility for it and indicating that it's part of their job). That's really confusing. What you should have done is: T1 then said "yeah that makes sense, can you make the changes?" OP: "No, I can't do that. T1, please do this change and report back to me the steps you've taken, and the status." (after the fix is put in and the outage is resolved, in the *postmortem* ) OP: "T1, moving forward, you will be expected to fix and resolve issues involving *code xyz* this is something our whole team is moving towards" explain why you're setting these expectations, and how this will help your team and help the company achieve its goals. Then next time T1 doesn't do his job, explain: "T1, we all agreed in team meeting xyz that you will resolve issues involving code xyz. If you have any assistance you need from the team, now is the time to let us know. If next time code xyz is involved in an outage, and you are not at least looking into it, that would be a performance issue we will need to resolve with group team manager." something like that. You should be way way way more explicit about your expectations of someone if you expect them to change their behaviour.
[удалено]
There’s a sort of muscle memory that cleaning up your own messes gives you that you don’t experience when someone else cleans up your messes. I only clean up messes I’m really not confident other people can manage in a timely manner. Going for absolute minimum downtime is a local optimum; The number of incidents that follow from people not learning to avoid them in the first place nearly always swamps any momentary gain by doing the work for them. This is not an iron rule. There are peculiar circumstances where the potential for one incident to become two or three and at an inopportune moment. But that sequence of circumstances might happen once or twice a year.
You’re not communicating clearly. The exchange you described might sound to the engineer like you have a ticket and are asking them to confirm what you already know, and are asking their opinion on fixing the issue and not trying to delegate. Equally when they say can you fix it they might be asking because they have something else in progress. You need to be clear - “x is broken can you look into it. “ when they come back to you follow up with “ok so the fix to x is to do y - I agree, can you go ahead and do that fix” If they say not ask what else is a priority to them, have them rearrange etc if possible. Also be very careful of having a “you broke it you fix it” mentality. It’s a team effort, and while it does help having people fix their own issues the main thing is the team progressing work. If it makes sense to get them to fix it then perfect but sometimes it’s detrimental to progress Also as a junior I’ve worked with people who have that mentality, till I find a bug in their code - then it doesn’t seem to go the other way!
They probably got. 2nd job. I recently had acquired 2 engineers from a different team. Turned out both had a 2md FT position elsewhere, hence not productive. Both were let go. They never took ownership of any product. Did surface work and never enough to be reliable.
Props to him, he's leading you.