Rethinking What’s Rude
“Should we really be letting a developer who’s new to the team take the lead on this time-critical feature?” I asked this question during planning, after a few delicately-worded (for me, at least) questions designed to ascertain if Ted¹, despite having been on the team over a month with no meaningful work, had deciphered our code to the point he understood exactly what he was signing up for.
“I have to start somewhere,” Ted said, with that can-do attitude that can be endearing when it’s backed up with skills and hard work, but is an absolute disaster when it’s not.
“Jim won’t be able to do about half of his task until you finish yours,” I pointed out.
“I’ll help keep him on the right track,” added Bill, who, to my knowledge, had not yet successfully performed a task similar to what Ted was signing up for.
“Ok, then,” Mike, our manager-cum-scrum master, decided, “He has to start somewhere. Story WTF-12345 is assigned to Ted.”
It would have been rude at this point for me to continue to question whether Ted could get up to speed enough to finish this task on time, especially with help from Bill, an established member of our team. Everyone else in planning had the same information I did about Bill’s relative lack of experience with this task, whether or not they’d thought through what it would mean.
Besides, I’d written a bunch of code templates to automate much of the task. If Bill pointed him to those and filled in the gaps that needed skill and knowledge, maybe it could work?
I’m not rescuing anyone this time, I sent in chat to Mike.
Two days later, at standup, I was pleasantly surprised when Ted said he expected his task to be finished the next day.
“That is good news,” said Mike.
Unfortunately, that was Ted’s status every day for the entire rest of the sprint and a couple more into the next sprint. And when he did finally check something in, he had done entirely the wrong task, presumably without raising any red flags from Bill.
Luckily, we still had another sprint, Jim and another developer stepped up and worked a lot of extra hours to finish a feature that should have been finished easily in the allotted time, if a developer with the right skills had been assigned, or if Ted had had more skilled mentorship to keep him on track. As it was, we wound up being slightly behind schedule.
And poor Ted never did produce any meaningful work on that project. My theory is he might have been a perfectly fine developer, but sitting around for a month before being assigned a task way above his head and failing just crushed his willingness to try.
What Was Rude Here?
We were in a situation where the polite option led directly to failure. It looked like this:
- A new developer entering the team when we were under heavy pressure to perform and no entry-level tasks to pick up
- Developers with the most skills too busy to bring him up to speed
- Random assignment of stories, with frank discussion of whether the developer in question had the skills and experience to do them in a timely manner off-limits
- Management taking developer’s naïve self-assessment at face value
And what was the impact of observing politeness here?
- The feature was delivered behind schedule. At a minimum, this made the team look bad. Potentially it also had a financial impact on the company.
- The other two developers had to put their lives on hold and work extra hours to try to get the feature out on time. They were contractors, so maybe they were happy for the extra hours. But maybe they would have preferred not to spend their “free” time that way.
- Ted, himself, never became productive on the team. Maybe that was just him, but maybe if we’d been more thoughtful about how we integrated him into the team he might have been amazing. No one will ever know, least of all him.
So there were actual harms done here to the people on the team because I decided not to continue with a discussion others clearly considered rude.
What Could I Have Done Differently?
I think a lot about whether I should have pushed harder (not necessarily in this specific situation, but in these types of situations in general). Could I have headed off the problems? What would have been the cost to me, directly and in damaged relationships, if I had?
I had no availability to mentor him through it, which would have been the ideal, from my perspective. After months of being the one who put in lots of extra hours recovering these situations, at the expense of my health and family, I simply didn’t have it in me to do it this time.
What Could You Do Differently?
I’d ask you, when you’re faced with someone who seems to be being rude, to look at the entirety of the situation and see if they’re being rude because they are trying to avoid harm to themselves or others.
The woman who is literally shouting over that person who is in the process of interrupting her — is she being rude? Or is the person interrupting her and all the people who sat there and watched her be interrupted for weeks or months until she got to the point of yelling the ones who are rude? Or is the rudeness forced by the fact that the meeting is “time-boxed” and people are afraid their points will never be heard if they don’t interrupt?
Is the developer who “points the finger” at a different developer who closed a technical story without actually fulfilling all the acceptance criteria being rude? Or is the developer who punted half their work to whomever is unlucky enough to pick up the next story down the line being rude? Or is the person who’s rude the one who incentivized moving stories across the board without much concern for whether they lay a solid foundation for the next story in line (but everyone pretends stories are actually finished when they’re marked “done”)?
It feels to me that often the rules of what is and isn’t rude are there to maintain the status quo and avoid uncomfortable questions of accountability. Sometimes this means that people have to absorb a lot of abuse in silence if they want to be seen as polite. The ironic part is that often this hurts everyone, not just the person who has to make the choice to be abused/exploited or to be polite.
A lot of times, that’s because the situation is set up to bring people into conflict, and the way to prevent conflict is to look at what’s going on in the situation that puts people at odds. Whether it’s forcing one developer to start a task before the previous developer has finished work it depends on or setting deadlines so tight that no one can bring a new developer up to speed, a lot of these things come down to management. If people are being rude to each other or allowing disasters to happen because they fear being rude, that’s often a management problem.
So we as developers need to recognize that and be as kind as we can under the circumstances by trying to place ourselves into others’ shoes.
¹Names changed to protect the innocent/guilty, and discussion edited for brevity.
