So your devs are underwhelming. They’re getting part of the way there, doing solid work, but then just not quiiiiiite meeting expectations. Maybe they’re not doing as much testing as they ought to be, or what they’ve built doesn’t match the designs exactly. A product manager in a community I belong to recently asked how to deal with just this problem, and I’m guessing it’s a fairly common one.
The key to addressing this issue is understanding why it’s happening. And there are four main possibilities:
The developers are underskilled,
They’re overworked,
They’re lazy, or
They don’t understand why it matters to get the details right.
Let’s explore these potential causes and how to ameliorate each one.
Underskilled developers
This one is fairly straightforward. Sometimes developers simply don’t have the skills needed to do their jobs. If this is the case, you can either invest in training them, or replace them. The option you choose will be based on whether the developers are employees or contractors, how long you see the relationship lasting, and how interested you are in working with them longer term.
You should have a gut feel for whether a particular person is committed to the team, to their work, and to learning and decide a course of action based on the likelihood that they’ll put in the effort to improve.
Overworked developers
Technologists can seem like magicians: they take concepts and turn them into reality. But, of course, they’re only human, which means they only have so many hours in the day, and they can only do so much in those hours.
There is a constant temptation to assign work to developers as though they’re bottomless pits of bandwidth. Whether that’s due to looming, very real deadlines, or just excitement to get stuff out the door quickly, the workload can overwhelm even the best developers.
Here again, you have some options. If budget allows, you can staff up with more developers. More realistically, you can scale back the workload by buckling down on prioritization activities.
Are your developers lazy?
Realistically, probably not! I’ve worked with a lot of developers over the years and have seen very few, if any, who were truly lazy. I like to operate from a place of assuming the best of people. So when it seems like someone is being lazy, try to get to the bottom of why they’re just not putting in the effort.
Often, what we perceive as laziness is actually a lack of motivation (subtle difference). So your job here is to uncover where that lack of motivation stems from.
For one team I ran, it was that their previous manager had been borderline abusive, from disparaging their work to shouting insults at them in meetings. No wonder they weren’t passionate! Fortunately, I was able to shield them from that manager and show them that I would treat them right. Within a few weeks they were super productive.
If you do actually have a lazy developer, obviously you need to replace them. However, I strongly believe that soft skills go a long way to improving the attitude and the output of a “lazy” developer.
What if it’s just not right?
Here’s where things get a little tricky. There can be disconnects in what you expect in a developer’s output, versus what they think is important to deliver.
I’ve had developers put a logo in the upper left corner, but not line it up with the items below it. I’ve had them add extra little features because they seemed cool, even though they weren’t right for the task flow or the problem we were solving. I’ve seen them make things the wrong color, because they saw “blue” in the design and didn’t think it mattered that the color was specifically hex value 0b5394.
Using the wrong color isn’t a bandwidth or laziness issue; it takes just as much work to make up your own shade of blue as it does to copy/paste the correct value from specifications. And it’s not a skill problem, because they were clearly able to specify a color.
So we can guess that the problem may simply be that they didn’t understand the need for exactness.
From an architecture perspective, developers may not have a clear picture of how their code will fit in with others’ code and how they all need to work together. Therefore, they may deem it less important to get specific details right, or to put in a lot of testing. They may make decisions that make sense for them personally, while being wrong for the product as a whole.
Changing mindset
This can be the toughest of all four problems to crack, because addressing it requires getting very detailed, which is time-consuming, or changing the mindset of the developers and the larger team, which can be tricky.
You can start getting extremely detailed – in specifications and in acceptance. Point out every little thing explicitly instead of assuming that a developer will notice that these five things are aligned in the wireframe. And then stay on top of all those details, pointing out every single deviation every single time.
I prefer a different approach: working on mindset. Ideally, you want your developers to understand not just what they’re doing, but the larger context in which they do it. You want them to know why they’re doing these tasks and why it’s important to get it right. It can also be helpful to explain to them why the little details are important, and guide them towards taking a little more care with the specifics.
This approach works because not only will developers start to look for the little details, but they will also start proactively asking clarifying questions. “Hey, these five items are aligned in the wireframe, but that’s going to cause problems at this screen size; could we line them up differently?” That allows you a chance to collaborate with the developers on solutions, instead of having to tell them how wrong they are all the time.
Ultimately, the goal is for developers to feel ownership in the finished product. It’s a more time-consuming approach up front, but you should find that over time, you spend less time having to review everything and follow up on errors.
Comments