We received great feedback from the development community about “Your Developers Aren’t Slow”. This is a guest post by Matthew Wear where he responds to our post with insights learned from his own development career (he’s been an engineer for 10 years). Matthew currently works at WellMatch as an Android Engineer, and was formerly at OneLouder Apps and Evernote.
I recently read Your Developers Aren’t Slow by Justin Jackson (@mijustin) at Sprintly. Mr. Jackson analyzed a large dataset from the project management software he builds to determine inefficiencies in the typical software team’s process. The most interesting inefficiency he discovered was the large disparity of time it takes a story to go from completed to accepted; signaling that developers are not to blame for missing targets. Mr. Jackson then spends the rest of the piece offering stellar advice to product managers, designers and software managers on how to make sure stories quickly achieve accepted status once they are completed to spec.
Jackson’s advice can be summed up in these three points:
1. Write better specs
Spec writers need to thoroughly think through their feature before passing it off to the developer. Great quote:
“A developer needs to understand why the user needs the feature, what the feature does, and how it will be used.”
2. Don’t change the spec once it’s in development
This can be largely avoided by focusing on #1. Jackson gives the GENIUS ADVICE of encouraging designers and product managers to create interactive mocks instead of static ones to avoid fragile designs.
3. Have developers focus on one thing only from start to completion
“The problem arises when you, as a manager, switch your developers to new tasks mid-stream. If your priorities are always shifting, you’re introducing huge costs to your team.”
Jackson finishes the piece off with this bit of gold:
“Most of all, be very careful about blaming your developers for being ‘too slow.’ It’s very likely that it’s your workflow that is slowing them down.”
The piece went viral, which isn’t all that surprising, it’s well written, based on an interesting dataset and offers sound advice. But there might also be another obvious reason it went viral: it shifts blame that developers commonly bare for projects shipping late to everyone else on the team.
I understand the appeal to affirm blaming the process and those who execute it. My entire career I’ve seen developers unfairly take the brunt of missed release targets.
It’s comforting to see someone articulate so clearly why all these stories took longer than expected. There are many reasons why developers are easy to blame, some of which might be:
- They’re often the last person to touch a story in the process. When the deadline “whooshes by”, they’re on point for the story.
- The story is in their possession for the longest duration of the lifecycle.
- They’re often compensated higher than others on the team.
- They’re usually not present in the stakeholders status report meetings where product managers communicate any delays and why.
Unless someone digs deeper into the entire history of the process they’re unlikely to uncover how many times requirements and designs were refined while the story was in progress to achieve the final result.
Blaming engineers happens too often.
However, I wonder if the thousands of people who shared Jackson’s article are developers who feel shame about a missed target. Shifting some of the blame can feel therapeutic, but ultimately will not make you happier in your work.
I heard a wise manager say once that the most effective way to keep employees happy was not money, recognition, goals or relationships, but making progress in their work. Although I was skeptical when I first heard this, I’ve come to recognize making progress is critical to my happiness at work. The weeks where many meaningful stories were moved from done to accepted were better than that sprint where nothing was completed.
Product management advice for developers
Carpenters say, “measure twice, cut once; measure once, cut twice.” The same is true for software: take the time up front with your specs and designs to save yourself heartache later. This principle also applies to measuring inefficiencies in order to have meaningful data-drivien discussions with managers.
Vet your specs
It’s hard to know if a feature is fully spec’d, since often times you’re less involved with the domain with which you’re solving for than your product manager. Jackson gives advice in his article that PM’s should write requirements in a mad libs-style. If your PM does not do this, then try to translate it for them in the style in your clarifying questions about the spec. For example, if your story reads, “Put a bar graph on the dashboard to show sales for the last twelve months”, you can translate the story to your PM to try to clarify with “As a store clerk, I want to see a graph of my last twelve months sales, so that I can see how my customer service skills are effecting the bottom line?”. This might elicit a response from your PM like, “well, no, seeing the graph won’t help the store clerk, don’t add it for the store clerk, just the business owner”. Then you might respond with, “well, just to understand, why would you say it’s important for the owner to see it?”. This kind of dialog will lead to new stories being created and current ones being refined, and it will help avoid a situation where the PM goes to verify your story after it is marked done only to communicate at that point that “store clerks should not see the graph”. I’ve also seen a situation where the PM did use a mad-lib style, but in an unthoughtful way. I think it’s important for the developer to walk away truly understanding why and who they are making the feature, and until you understand keep asking thoughtful questions with the right motives (more about motive later).
Scour over your designs
The best advice of Jackson’s article is the bit about having designers do interactive designs. It is nearly impossible to communicate how software should work with static screens, especially now that animation is such an important component to a solution. I find that you end up with many “gentleman’s agreements” that may or may not be what the PM wants and will eventually require rework once you get to the done-accepted divide. Also, once a design starts to change state you quickly find the holes in it.
If your design team does not currently do interactive designs then they will be unlikely to start just because you suggest it. I am considering taking final static designs and using an interactive design tool to produce something the team can have a discussion around, but I’m currently unaware of tools that allow you to do this so can’t offer much advice here (recommendations are appreciated). I do recommend using your imagination to its fullest capacity to test the design in your head. Think through every button and text field on the screen. How will the screen change when each are clicked? How will the screen look in different languages? Different lengths of text? Just every configuration and state you can think of. I’d also say to make sure to have various permutations of the designs thought through for different types of domain entities. Then compile a list of questions around aspects of the design that might not be completely fleshed out.
As a solution to delaying the current story while the details of the designs are worked out I suggest creating new stories that will be used to define the use cases and variations that aren’t defined in the initial designs.
Track your task switching
Keep track of the number of times you’re interrupted per task. Make sure these are times that you had no choice but to switch tasks. Also keep track of the number of times you switch tasks, but no one necessarily forced you to switch. The hard part about knowledge work is your tasks aren’t always defined for you in the order they should happen. More responsibility is on the developer to make sure we discipline ourselves to work on the highest priority task. If your data shows you that yes, your manager on average is requiring you to switch tasks mid stream at an unseeingly high rate, use the data to communicate. Even if it doesn’t get better, you’ll always have the data to give yourself a little bit of comfort to why not as much progress was made.
Tracking goes with any problem. I like to create a Google spreadsheet when I sense there is an inefficiency such as task switching too often. Every time there is an occurrence I mark the date. It’s easy then to make a graph over time to distinguish if your intuition was right.
When communicating: be introspective about your goals
If your goal is to shame your PM or make your designers feel like you could do a better job than them, even if you succeed you’re going to feel crummy, and if you don’t feel crummy with those motivations, well, maybe you’ve seared your conscience. The motivation has to be (at least on some lower level) to make your life better because you’re able to make meaningful progress in your work, and to make the entire team better.
How you say it is important
Having the right motive will go a long way in communicating effectively to product managers, designers and software managers, and is by far going to help the most, but I’ve found a few specific additions in this area can help much.
Avoid informal logical fallacies, especially “ad hominem”, which is making your argument about your manager’s character more than the spec or design. I’ve seen some folks use this poster to say you should never use informal logic, but just because logic is informal does not make it fallacious, it just means it can be fallacious and not formally provable. Still, be careful with these, very careful with some of them.
Write down your arguments in text and charts before presenting them to your manager. This will help you clearly define the problems you have with the spec/designs/context switching. It might even make sense to present the chart you made if it doesn’t make you come across as over the top about your point.
Be willing to lose. This one is a little controversial because an engineers sense of justice will be hard to quell and we’re right dangit, but if you are willing to die on every hill so to speak, it’ll harder to be taken seriously because you won’t be seen as someone willing to dialog as much as someone who just makes demands.
Thanks to Matthew Wear for this post.
