My fellow devs want me to give them a project/challenging task
Posted by writeahelloworld@reddit | ExperiencedDevs | View on Reddit | 47 comments
hi,
I am a lead dev that delegates tasks to the devs in the team. I got feedback from my manager that some wanted to work on something big like a project or a challenging task. Something that is end to end, or high visibility to clients.
What i observed previously is that when i gave them a medium difficult task, they remained silent for days, no questions, no progress updates (unless i asked). One of them has a habit of saying it's in process or nearly done at every daily standups. When they say the job is done, the job is actually not done. Either they misunderstood the job or didn't cover all cases. So i am hesitant to give bigger tasks. I want them to learn to communicate more and ask questions, and i certainly don't want them to be stuck in a harder job (and become depressed and more silent)
So how do you deal with this situation, how to balance their desire of working on a bigger task vs my confidence in their previous 'work behaviour'?
thanks
morswinb@reddit
Silent for days on a medium task?
How many days? 2-3 days? Messured from evening day 1 to morning day 3 with weekend included?
Sounds like the problem is that you don't trust your devs to do the work, and in return they are not motivated to do any work.
If you don't deliver anything for a few weeks, how bad does it actually get? A few weeks is actually the timeline to deliver some medium visibility task.
Pitch some ideas to your devs on what the clients want or complain about. Let your devs write a few bullet points of a plan on how they can do something about it within a few weeks, and then let them execute it.
Then the hardest part, sit back and do nothing. Wait for the devs to notify you once they make some progress.
_f0CUS_@reddit
You seem to be arguing against a strawman.
morswinb@reddit
What's the strawman here?
_f0CUS_@reddit
2nd and 3rd paragraph. You are just assuming/making things up and using that as the basis for your comment.
You are also assuming that a medium task for them is the same as a medium task for you.
Your actual advice is also not going to work, as you can see OP is explaining that they are not successfully completing tasks.
morswinb@reddit
Na you are gaslighting me.
It's a valid question to ask what's the actual situation there. With no clear details it can go both ways. Could the dev disappear for weeks with nothing to account for or the manager constantly pinging because of trust issues.
You don't know.
Also I gave the definition of a medium task, something that can be done within a few weeks. If you think differently then that's fine but so can OP think medium size is different.
While my advice does not guarantee 100% success on the next medium task, it's still better than trusting reddit more than your own devs.
_f0CUS_@reddit
Now you are using psychology terms incorrectly, to try to discredit me.
We do know that OP is not constantly pinging them according to their 2nd paragraph.
OP has already tried giving them medium tasks, which they fail to complete. So letting them define and them try to complete a medium task is not going to work.
You are also still talking about not trusting, like it is an established fact. OP does not mention lack of trust. He is stating what he has observed.
morswinb@reddit
"my confidence in their previous work behaviour"
"medium difficulty tasks ... failed"
Explain to me how that does not imply a lack of trust in the team.
It's like all that remains on the plate are easy tasks with no real impact. And this is what the team complains about.
And again "medium" can mean so much. How can you know that dev wasn't actually done with the task, but discovered a number of extra edge cases that needed to get covered? Dev needed to spend extra time covering all of those, but the manager failed to understand the service handles 99% of the cases? This stuff happens all the time.
You don't know for sure, and without more details we don't know if OP actually knows for sure.
writeahelloworld@reddit (OP)
Please see my updated post
morswinb@reddit
Thanks those details are important.
But now context is way different. The system is legacy and it takes experience to move around. This is something that you have, not the other devs.
I assume mainly because you worked on this project for much longer? Otherwise you don't have any other fundamental advantages?
Personally I would count it as my failure if other devs can't work out how to rearrange item order. This should be an easy task, 1-2h to modify the sort order in that DB query. With a new dev I would take a day sitting next to each other and pair programming the solution. Make sure they look at the same stuff that I would do, and watch what they get actually stuck on.
But the world is obviously more complex and far from ideal. Have seen teams trying to build ordering solutions spanning over multiple microservices, to then ultimately failing and leaving an unmanageable mess behind.
Look at this from the devs perspectives. Here they are working under your leadership, fixing something that might be your mess, and being viewed as not worthy to take on more engaging projects. This is what they might actually think.
How time have you invested to spread the trial knowledge? Was the legacy system reviewed by other devs? There are team leads that don't do that. I don't mean it personally but it just life l, stuff happens.
_f0CUS_@reddit
It does not imply anything, it is something that CAN lead to lack of trust. But that is not described, you are assuming.
OP is a lead dev, not a manager. That is a senior dev role, where the developer is actively doing dev work while being responsible for a team.
"How can you know that dev wasn't actually done with the task"
Well, OP said "When they say the job is done, the job is actually not done. Either they misunderstood the job or didn't cover all cases" and "they remained silent for days, no questions".
So unless you think OP is lying, we actually do know.
Anyway, I see no value in continuing this.
chikamakaleyley@reddit
but... isn't that what trust is?
OP finds it difficult to trust his devs with ABC because they fell short the last time they got ABC
...right?
I think there's fault on both sides * OP hasn't taken any bigger action to address the real issue, they just withhold bigger work and then it's finally communicated to the manager that they want to do bigger things, then its revealed what the shortcomings are * the devs aren't meeting the expectation, and whether or not that is clear to them, what's more tangible is when things fail because something is missing, something is coded incorrectly, etc. Like, do the devs even have the awareness that this can't continue to happen?
and thing i don't even know is, if these tasks aren't being assigned to them, who is doing that work?
_f0CUS_@reddit
Oh, OP is definitely doing something wrong. I gave my input on that in an other comment.
Maybe it is 2nd language or cultural thing. But what I'm reading in the 2nd paragraph of OP, is just a description of behaviour, and just because you have observed something that MIGHT break trust, does not mean it is broken.
chikamakaleyley@reddit
ok when you put it that way, i think that makes a little more sense but i'm now actually more curious about your thoughts on OP 2nd paragraph
cuz when i read 2nd paragraph this is what i see: * medium task isn't really that important, that could be different everywhere * silence/lack of updates: this is behavior but for myself if i were to join that team, I think opening up the comms more is important * 'in progress/almost done': hard to say, usually okay if you already have context; we dont * misunderstood req / coverage: this one seems more of the dev thing under-delivering... like is this behavior or is this capability?
writeahelloworld@reddit (OP)
Please see my updated post
gyroda@reddit
I would also encourage them to take charge of various aspects of the process - if you use scrum, get them to write tickets and plan out how many sprints this will take. Give input where needed/appropriate (e.g. "don't forget we need X capacity reserved next sprint because we have to do the other thing") but let them drive it.
morswinb@reddit
using scrum here is a bad idea, its likely to end up with morning status checks and explaining each ticket in detail
Sooner or later the manager will step in and play with those tickets themselves, since it's their toy
Honestly why not just create an epic, project hackathon, make it 3 weeks long and say bye to scrum antiagile abomination?
AssaultLemming_@reddit
Scrum in general is a waste of time unless you actually are working on a product that you plan to iterate on. If you are building something that isn't iterative then just do waterfall. If you are a team where other things often interrupt your work then do kanban. Scrum is honestly the least efficient agile method.
gyroda@reddit
You don't always get to pick your processes
If you normally work in scrum, this can work with scrum. If managers can't respect boundaries and avoid playing with dev tickets you have a different problem, if this is a product ticket the eager dev must learn to work with the managers.
chikamakaleyley@reddit
I will add that one of the biggest things needed in order for any of this to work, is that you need devs that buy-in to the game plan, and set aside their preferences. the "i actually don't like writing it this way but whatever, i'm not trying to die on that hill. LGTM!"
morswinb@reddit
People over process.
That's my point.
chikamakaleyley@reddit
personally i think that letting the engineers manage themselves is one of the best team settings, if not the best, you could ask for
it's empowering to feel trusted by our EM this way, and thus we make the processes that works for us. The thing is we can't just be okay with lackluster updates because we all have more or less the same skillset, meaning anyone of us can take on someones tasks if needed (or help the other person get ahead), and we all have an awarenss of whats going on in our product (this works a bit better in microservices)
This way our EM can focus on the things we need them to - like protecting us from silly requests, or prioritizing us when a more critical shift needs to be made, and most importantly, managing the the relationships btwn engineers, making sure we have what we need to get the job done, and supporting our growth. Or, the opposite, they're real with you when you're not meeting the expectations.
Our planning/pointing is streamlined. We schedule 30 min for our planning sessions, we're usually out in 15. We did pointing for a sprint in 5 mins once. Team of 8.
btwn the devs we aren't concerned about having all the details explicitly outlined in the task before we'd start. we just know the work involved, we handle biz.
juusorneim@reddit
What's an example/description of a medium difficult task in this context?
writeahelloworld@reddit (OP)
Please see my updated post
_f0CUS_@reddit
You need to give this feedback to your devs during retro, and more specific at individual 1 to 1.
And let your manager know about the level of the devs on your team. That they are not ready for senior level work, so you would not be comfortable delegating it to them yet
chikamakaleyley@reddit
oh yeah, this is it
originalchronoguy@reddit
Ambiguity is king. I give big tasks and let them flop through the initial out-of-gate. It is a learning exercise with a real teachable moment. I let them spin their wheels for 2 weeks (on a largish project that has a timeline of 3-4 months). At the two week mark, I reign back in with clearer direction.
They all see the mistakes in poor planning and bad assumptions. I want to trust them enough after a few tries, they can own everything from end to end on their own. You need to walk before you can run.
chikamakaleyley@reddit
i love ambiguity in tasks because i feel the responsibility to go and get the answers myself, like i can be assigned something and just be trusted to deliver. it's a great feeling when you hit the goal
when you don't, you're the closest to the code so you have the opportunity to identify and fix those issues, instead of that data being tallied over time and then suddenly it's evidence of a subpar review
lokaaarrr@reddit
The job of the lead engineer and manager is to give people work that is a good match for them, challenging but workable. And to provide the right oversight and support.
Not intended as criticism, but it seems like on a past project you (or the manager) missed the opportunity to provide direct feedback and advice. Nothing drives growth like a manageable failure paired with feedback and advice.
honestduane@reddit
OK so find something with your technical debt in mind and have them work on it
chikamakaleyley@reddit
i almost feel like.. you might be too nice, or you want to be... the cool lead buddy buddy dev
and, maybe i'm totally wrong but like...
why else would they get away with this behavior? why do they collectively think this is good enough?
this isn't just a poor habit, they literally aren't fulfilling their duty. The repercussion can't just be withholding bigger tasks
feverdoingwork@reddit
Should the feedback come with a lashing? You just tell them to review the requirements and to ping you when everything is 100% done and ready for review 😆
I think its easy for devs to get tunnel vision and forget some of the smaller things.
johnpeters42@reddit
Everyone overlooks stuff once in a while, you just catch it and fix it and move on. But if (as I suspect) these devs are missing or misunderstanding fairly substantial things-- that's still okay, they're still progressing, but if they communicate more often (not just "almost done" but a summary of what they actually did so far) then you can probably catch some oversights sooner, and hopefully they can progress that much faster as a result.
writeahelloworld@reddit (OP)
Nothing wrong with being the cool friendly lead dev :) we are all fellow devs in the same team.
On the point of not finishing a job properly, i could've let the jobs go to QA and let them fail the jobs, this would probably look bad on standups and the team as a whole. Would some of you think this is actually a good idea so they learn??
chikamakaleyley@reddit
no sorry, you're right there's nothing wrong with that.
and i wouldn't just let it PASS, just because I think it's wasteful of time - like it would have to do a round trip just to prove a point.
You can totally be the cool dev, but that's actually when you have the power to level with them, or like switch to serious mode and back. For me, without knowing the finer details, that looks like:
The thing that young folks w decent comp - sometimes they need to be reminded -
"We are professionals. We are paid nicely, sometimes generously for our expertise. This is not the quality of work that I will sign off on. If we're being called the owners of XYZ, we better look like we own it."
so hopefully you can see what i'm kinda getting at. sometimes, folks need a straight up reality check. it doesn't have to be confrontational, but you have to tell your team that i need this from you, i'm not getting that from you
labab99@reddit
In my experience this can be addressed through planning.
Breaking apart the feature into its constituent subtasks, which ensures there is a regular stream of information regarding progress. Hurdles get detected quickly.
Using dependency points and external blockers as another factor to determine how you split things up.
Account for the worst case scenario, and also bake in time for whiteboarding and fixing whatever surfaces during the code review.
As you can imagine, our planning takes a lot of effort. But we’re nearly always on schedule. No one has to feel like they’re dropping the ball. And with time, you can drill down on these patterns and delegate this planning work to the developer.
srlguitarist@reddit
I’m intimately aware of this cycle. They probably have impressions that seniors/leads can take on large tasks and just figure out problems without having to bug everyone all the time, and when they (jrs & mids) inevitably get to a blocker that they genuinely aren’t sure how to overcome, procrastination and self doubt set in, but now that they’ve already gone several meetings saying they were “almost done” they can’t back away from that messaging without feeling like a fraud and damaging their perceived reputation.
They also may tend to overestimate how quickly they would complete the task because they were assuming best case scenarios and also thought their hazy mental models on how to implement would go off without a hitch. They forget that simple tasks often bloat because if you double the time of a 2 hour task it becomes 4 hours (easy to dismiss). But working on something complex, doubling from one week to two weeks feels like an epic failure.
I think sometimes it’s nice to give them enough rope to hang themselves with but still push them to finish, refrain from heavy negative judgement. Do a one-on-one retrospective on what happened and what could be better while focusing on the core drivers of this behavior like over estimation of speed, not breaking down large tasks into gated sub tasks, or communicating obstacles especially if they’re driven by ambiguity (I say this on purpose because in my experience, the unknown is what truly cripples). Share empathy (you understand, because you’ve been there too), and reaffirm that asking lots of questions is expected of any dev performing at the highest level.
Over time and with good positive reinforcement, they will continue to do it less and less until they’ve internalized the lessons along the way. Each dev at their own pace.
writeahelloworld@reddit (OP)
The 'asking lots of questions' is a great point, i said it is not weak to ask questions, it's a sign of being confident and shows maturity as a dev.
johnpeters42@reddit
Up to a point, anyway. "Asking lots of questions" can also be a symptom of "didn't even try to figure it out", but you can probably figure that out from context.
AssaultLemming_@reddit
In general I hate when engineers want to work like that. I run a team of engineers and as much as possible I encourage working together at least an hour per day.
The best way to start this is with detailed requirements sessions. All the engineers together work on the design and the very specific requirements. If you have broken your project down properly into epics and stories with proper acceptance criteria then after that developers can work in isolation on stories.
You should have clear design documents, that you put together in a shared session as a group, that show the data flow and the components of the project and how they will pass data between them.
You should have one person whose job it is to integrate, or supervise integration, between the different components of the project. If part A has to output a JSON and part B has to accept one, then that person makes sure the format is consistent.
Basically, communication, shared understanding of the design, and very well written acceptance criteria will get you 90% of the way.
chikamakaleyley@reddit
This is what you tell your manager.
The habits have to change before you can trust them with more substantial work.
I do think that giving them these projects as a way to force the better habits could work but its like... def not for them all at once, def not if you can't afford the risk.
You should give the chance... but not if the vibe is "well if you give us these projects we'll do it that way"
I have 4 y/o twins, I'm literally dealing with these attitudes right now
gyroda@reddit
This is something that you need to do something pro-active about.
Make sure the definition of done is well understood. I like it when I'm in a team where this doesn't need to be too formalised because we're all on the same page, but sometimes you need to go back to basics. Have a meeting, go through your definition of done. Start putting it into tickets if need be. All of the assumptions that you take or granted (you need unit tests, you need QA sign off, you need to make sure it's been deployed, you need to test it locally first) can be made explicit.
chikamakaleyley@reddit
this is my current and previous and its like, you hope you never experience any of the horror stories you see here lol
gyroda@reddit
I am unfortunately not in this position currently. Lots of changeover ATM. It will probably improve with time and effort, but for now I'm having to push back on "did you even test that this validation is having any effect?" (No, because it isn't configured correctly)
starquakegamma@reddit
You need a Definition Of Done.
implicit_return@reddit
Have you told the other engineers what you told us?
morswinb@reddit
Obviously not :)
writeahelloworld@reddit (OP)
I told my manager