Did I make the right move as a lead developer?
Posted by Constant-Listen834@reddit | ExperiencedDevs | View on Reddit | 52 comments
Currently I am the lead engineer for a project (the project is highly prioritized in the company and under heavy development), reporting to a manager who manages engineers across several projects. Recently a junior who I share a manager with, asked for a 'high impact' feature on the project I work on. They asked for this feature as a way to improve their visibility in the org and grow.
I decided to give them a pretty important feature to work on. I put a good amount of effort into helping this junior refine the feature. I sent them resources, met with them to give examples, explain the business domain, etc. They 100% understood the task at hand. Myself, I estimated it may take them 1-5 days to complete this feature given their experience. But I did not put any timeline expectation on them.
A month later, they still have not made any progress on the feature. I think that they mostly just became busy and did not have much time to start it. The feature is now blocking a bigger initiative and I need it now, so I just ended up implementing it myself and merging it. They were visibly upset that I ended up taking it from them.
My thought process here was this person explicitly reached out asking for a high impact feature to increase their visibility. In my mind they should have prioritized the feature and 'taken initiative' if they really wanted the visibility. I understand they may have been to busy, but they asked for extra work and therefore should have done the extra work.
Am I wrong with my thought process here?
ryry_reddit@reddit
Sounds like they got negative visibility. Time for a PiP.
TheMrBoot@reddit
For being set up to fail…?
leeliop@reddit
If someone has the acumen to request high impact work then they should have the sense to prioritise it, or at least pin down a timeline
Tough tiddies imo
TheMrBoot@reddit
If a lead thinks a task will take a week and they don’t check in for a month, there’s plenty of mistakes to go around.
timwaaagh@reddit
in my opinion, it is wrong to hand out features to people who want promotions just because they want to climb. so it was bad of you to go along with that request. this does not serve the needs of the business just those of one employee. but a month is very long, so it is not wrong of you to take it. you fixed it quickly, impressive.
TheMrBoot@reddit
Promoting employee growth directly helps the business. That’s some extremely short, narrow minded thinking.
betterlendingplz@reddit
you should have checked in with them more often. measure output and tell them if it's done by x date, you would need to start doing it.
you took the right steps proactively scoping it but the wrong steps not checking in
sd2528@reddit
In a normal scenario, yes. In a situation where they asked for the extra work to prove themselves and then to turn around an not work on it at all... That would confirm my initial instinct that they weren't ready for it. In that amount of time they can't just not even start or ask any questions.
TheMrBoot@reddit
They’re a junior. Yeah, they should have checked in, but as a lead not touching base for a month isn’t good either.
Constant-Listen834@reddit (OP)
Well, they had scoped it for their sprint. So I expected it to be done and for them to reach out for help if needed. Atleast that’s why I didn’t reach out. It then fell through 2 sprints but I wasn’t really paying attention to this person, which I’d say was my failure.
I guess I didn’t want to “micromanage” them with the work and wanted to be hands off. I’m not their manager
JimDabell@reddit
The whole point of being a lead engineer is that you lead people, especially juniors. Did you think being a lead was just sitting back and waiting for people to ask for your wisdom? “Hands off” is not leading, it’s avoiding your responsibilities.
I know there’s the occasional person here who will label any form of management at all “micromanagement”, but these are people with a dysfunctional relationship with management. The right amount of management is not zero.
infiniterefactor@reddit
You are not their manager. But this effort had to be managed by someone, either you or the junior developer or their manager. It looks like nobody did that. Then there is no mystery in this initiative failing.
Is it your fault? Definitely no.
But I think you all missed something here. Impact is not measured in the ability to do some coding or engineering. Impact is about delivering results and earning trust in exchange. If the junior developer is really junior, they wouldn’t know that and also they wouldn’t have top notch skills on capacity management. It sounds like their manager was out of the loop or was not involved much at all too. And you missed the chance of coaching them in this.
Everybody could have benefited positively from this, and you missed the chance. But there is no need to get upset. Just have a honest conversation with them. They would have other chances and now they know what they will do differently next time. That’s also a valuable lesson.
betterlendingplz@reddit
So when the feature wasn't checked in by the sprint and you didnt see progress via commits every 1-2 days, you should've reached out?
If you're a team lead everything is on you. Managers are for career growth. Team leads keep the train running
Constant-Listen834@reddit (OP)
That’s good feedback. To be honest, I wasn’t really paying attention to this persons work. I was more focused on my own work and the work of people on my project
betterlendingplz@reddit
I would recommend blocking 30 minutes a day to check status of other areas you're not directly leading.
Constant-Listen834@reddit (OP)
This is great advice.
sd2528@reddit
No. They asked for the project because they wanted the visibility to prove themselves. It sounds like it wasn't that long of a project and to make no progress at all in that long of a timeframe, they dropped the ball. They might not like it, but they blew their chance.
Constant-Listen834@reddit (OP)
This is true.
But I am also agreeing with some other feedback on here that I should have reached out to them more often. I am a new lead and am trying to be more “hands off” and act as a resource for engineers when they need help. But maybe that’s not the right approach and I should be more proactive in asking for updates?
DigThatData@reddit
It's a delicate balance, and different employees benefit from different management styles.
sd2528@reddit
That can be the right approach for more senior devs, but for juniors, frequent check-ins are best.
positivelymonkey@reddit
I don't think it's a senior vs junior thing. Some people call micromanagement what others call structure. As a manager you need to figure out which people need which management style and give that to them.
TheOnlyNadCha@reddit
One month and they couldn’t find a day to work on this? That’s suspicious especially if they requested it. Makes me think they must have been swarmed with higher priority work. You say it became a blocker unexpectedly so you had to do it kind of last minute. It sounds like they had no timeline and it was not prioritized until it became urgent. You are partly to blame for lack of prioritization and timeline.
Adventurous_Bend_472@reddit
No worries, they really learned something.
JimDabell@reddit
You need to set expectations, even for unimportant features. How can they succeed if they don’t know what success looks like?
How did it get to 4-30× your expected completion date before you realised they hadn’t done anything? You thought they could potentially do it in a day and you’ve let them spin their wheels for a month before stepping in?
Busy with what? You shouldn’t be expecting juniors to juggle multiple tasks, especially if you’ve given them something important that they need to grow into.
Did you tell them this, or did it stay in your head?
You have not described them asking for more work. You have described them asking for something with higher impact. This is not the same thing.
The impression you give is that you’ve been ignoring this junior for weeks. Juniors need supervision, and lead engineers need to lead them.
cleatusvandamme@reddit
I agree on the first part. However, I’m wondering what was the JR’s workload on other tasks. If the JR was tied up on other things and couldn’t get to it in a reasonable timeframe, everyone should reevaluate the goal.
NotNormo@reddit
You really needed it "now" and you weren't given any time to get its dependencies in place? Not even the few days it would take the junior to do it if they dropped everything else? Well if that's the case, then you didn't have any choice.
But when it became apparent that this was the only option, you should've immediately explained it to the junior dev.
What you should be doing now is thinking of a different project to replace that previous one, and work with the junior dev again on it. This time do a more thorough investigation into when it needs to be completed so you can give them accurate goals and expectations.
acousticpants@reddit
you're always responsible, even when others are too. junior should have got going on it and talked to you when they didn't, but this kind of mismanagement is part of learning. you should have checked in on it, and you should teach them to check in regularly - comms is more important than code, after all
iknide@reddit
I would say a <1 week feature is not high impact. And if you handheld through the design of it they didn’t exactly do it on their own
dmikalova-mwp@reddit
Responsibility goes both ways - they're not going to get the right visibility if all they produce is whining.
Few-Artichoke-7593@reddit
Visibility is a two edged sword.
Rain-And-Coffee@reddit
You both dropped the ball.
Him by not communicating and making progress.
And you for not checking on him.
Once you realized the featured was needed you should maybe did a quick call, before delivering it.
macca321@reddit
Remember to double your own estimate
IntermediateFolder@reddit
So you estimated this task as 5 days max and then didn’t check in with them or say anything at any point for a month with no progress? I’d say no, you didn’t make the right move, you kinda dropped the ball on this, both with the initial passivity and no communication and then taking someone else feature again without any communication. Did you even know why it was taking them a month? Were they stuck on something, busy with other work, something else? How far along were they when you decided to do it yourself? You should have checked in with them regularly or at the very least after those 5 days without any progress.
idgafsendnudes@reddit
Sorry if this sounds harsh but this basically reads as “was I correct, in allowing a developer who was trying to make career growth, flounder in the wind instead of being a team player about to em trying to grow their role.”
Textbook bad management. The only lesson that could be efficiently relayed to your team team is that, you will not be going to bat for them. If my manager did this to my team member, I’d be sending job apps or go for lateral transfers. You never want to be on the same team as someone who sees you as a stepping stone
tehdlp@reddit
If this is a highly prioritized project, it should be prioritized. It doesn't sound like it is if any aspect can be started and not tracked for a month.
Taking this from the junior, no, not a problem. There's a bigger problem here though.
derpinot@reddit
By week 2, you should've have asked what's been blocking them from completing the task. This is why daily stand ups or sprint reviews are made for.
behusbwj@reddit
You said they were “busy”. Was the prioritization / urgency not made clear? If not, you should have looped them in as soon as the priorities shifted (e.g. when you found out it was a blocker). In that sense, yes I do think you made a non-optimal move in the sense that this could have been a great mentorship or growth opportunity. That would have given them ownership and given you an opportunity to see how they do under pressure / shifting priorities. Then, if it was too much, you can offer to take it off their hands and apologize for the short notice so as to not make it seem like it was their fault.
imbrady@reddit
Yes you are at fault here, I’m not sure why you did not discuss timeline of the feature in question given it was going to be a blocker if not prioritized. You also failed to check-in on the progress of the feature the entire month it sat with little or no progress.
That being said it is odd for a junior to act hungry for more important work and put it off for an entire month. The situation is mind-boggling on both sides
Constant-Listen834@reddit (OP)
I didn’t know it would be a blocker until it become one unfortunately. True that I didn’t really check in with them. I try to be hands off and answer questions when they come to me. I leave the status reports to the manager
tcpukl@reddit
You shouldn't have left a junior for a month with no check-in when you estimate the work or a week. That makes no sense. You should have at least checked in half way through your estimate to check progress.
RoughCap7233@reddit
I think perhaps you should have had a word with the dev first before taking the task off them. Explained that the feature is now a blocker and needed to be done by time x.
I think it also would be fair for you to ask them why they were not able to complete the assigned task. After all you did them a favour and they did not return in kind.
imbrady@reddit
I understand your concern but there is a massive difference between pestering someone hourly for updates vs holding them accountable for not making progress or delivering on commitments during a sprint.
As a lead you are responsible for making sure projects and their dependencies stay on track. Take this as an opportunity for growth - set clear expectations up front and don’t be afraid to hold people accountable.
obscuresecurity@reddit
You made the right call if you thought they could do it.
You made the wrong call in managing it.
You needed to let them invest more, instead you invested, and did the lift and left the grungy code for them to do.
You took the upside away, the pride the things that drive someone to try hard away.
I'll push engineers beyond where they know they can go. I leave them thinking "there's no safety net." there isn't. I'm the harness attached to you with a wire you take for granted. ;)
You are the lead. You are ALWAYS to blame. Get it through your head. You LET them fail. You LET this get out of control. YOU FAILED.
There is no "we" in failure for a team. There is "I" failed as the leader, or "we succeeded".
Comprehensive-Pea812@reddit
you guys dont do daily huddle?
3 days into the ticket, draft pull request should be available.
or, ask them to tell you their plan on implementation. or their plan to do investigation.
dont accept update such as working it.
fnbr@reddit
I try to schedule regular check ins with the engineers on my team. Ideally weekly 1:1s (maybe biweekly if we don’t work closely together) and short standups 2-3x per week. That guarantees we’re all on the same page without having me harass them for updates.
serial_crusher@reddit
There’s a big gap between “this should take 1-5 days” and “I haven’t heard anything in a month”. You probably should have checked in on day 6 or 7.
How explicit was the communication that you expected this to be extra work on top of their normal responsibilities vs some backlog item you were tagging for them to do when it came up? It’s feasible that a product owner, scrum master, etc might have told them “not now, this other thing is more important” every time they tried to pull it into a sprint, and I think it’s reasonable that a junior would need some help pushing back.
A junior gets promoted to mid by doing good on a project without much technical handholding. Project planning, prioritization, removing blockers, etc is more of something you should delegate to a mid trying to become senior. So I think in this case, you should have taken charge of making sure the junior had time to do the work.
midasgoldentouch@reddit
This is a great point. OP, I would ask the junior if they were being told to prioritize other things over this and by who. I would also loop in their manager - generally, if you’re giving a junior a project like this to demonstrate their abilities, you want to make sure their manager is aware so that they can consider it as part of their review. Looping in their manager would also help make sure this was accounted for in planning, e.g. “Frodo is working on an important feature so that’s one less dev working on other important project during these 2 sprints.”
dfltr@reddit
A couple things here around communication:
Aggressive_Ad_5454@reddit
So, this young’un took on a challenge without the authority to budget sufficient time to get it done, eh? This visibility thing cuts both ways. Look at it like this: you saved his reputation by backstopping him.
It’s good to give people responsibility when they understand what they’re asking for. And this person seems to have fit that profile.
But they weren’t able to allocate the time, you say. Whose job is it to set their priorities? Is the priority-Setter in the conversation?
At any rate, there’s some learning here. Our craft isn’t just about understanding and expertise. It’s about managing time to meet expectations.
Give them another chance! Explain about blocking features and schedules and all that. It’s the engineering part of software engineering.
PeteMichaud@reddit
What you did wasn't crazy, but you could have handled it better. Keeping it in your rotation for things to check could have been good. Telling them explicitly that you're taking it because it has to now be done immediately would have been better than them finding out about it after it was already done. A different approach that MIGHT have worked if you really don't think them dropping the ball was primarily their fault (ie. they had no reason to expect time pressure on the feature and they were reasonably prioritizing other things up until now) is that you could have said something like
> Hey [junior], bad news: it turns out we need that feature like yesterday. We have to get it done literally today. I don't want to just take it from you, and I need to make sure it's done immediately and correctly, so my plan is to right now, today, spend half the day pairing with you to get it done together. The commits will be yours, and I'm happy to give you all the credit, because I don't want to undermine you. But it needs to happen now, so let's start in an hour and get it done.
ritchie70@reddit
I once took a feature away from a senior developer because every time he fixed one defect, the QA team wrote two more. He'd been trying to jam new functionality into unintelligibly complicated legacy code. I just threw it all away and rewrote in a day or two.
The only thing you did wrong was waiting a month before you took action. If you'd taken action earlier, you might have been able to get him to get it done.
oneMoreTiredDev@reddit
the only issue I see here is the lack of follow up, since it's a junior... this person might got blocked in the middle of it, didn't ask for help (or had no one available) and started working on something else