Chapter 24. Keep developers happy, reap high-quality work
While at Northwestern Memorial Hospital, I was an unofficial team leader trying to advance our team forward during a unique situation: we were a side project for our manager, who was largely absent due to other responsibilities. He had less and less time for us as the months went on (a scenario that was slowly rectified). Previously, I was the official manager of a small development team at another company, although, admittedly, I learned more about the needs of a development team in a situation with no manager than I did in my prior position. I have a natural inclination toward best practices and learning, and I tried to fill the vacuum on our team as much as possible.
One of the most important lessons I learned is that if you keep your developers happy and motivated, they’ll consequently do some of their best work and will contribute to the betterment of the team and the organization. The tricks involved with keeping them motivated may initially seem counterintuitive to developers and/or management.
First and foremost, you need an agreed-upon team coding standard, but then you can’t neglect it. You need to thoroughly enforce it. Although some developers may find that this gets nit-picky, it ultimately ensures your code base follows the same standards and patterns throughout, making it easier to maintain and train new staff in the future. This has the added benefit of enabling your developers to quickly turn out new code, because they aren’t getting hung up on fixing bugs with an underlying framework or trying to decipher a monster 1,000-line method. Being able to focus mostly on new applications or functionality keeps developers feeling productive and fulfilled.
Another beneficial tactic to keep the team happy is to encourage the team to use a set time during the workweek to learn new skills or technologies (as little as an hour, as much as a day). Management will frequently scoff at this, because they don’t want to see valuable development time spent on non-work. But there are multiple benefits to be had from this, resulting in a better end product and happier management. Being able to explore a new topic that interests the developer may be rewarding enough to keep them motivated to produce their best work. If it turns out to be something that can benefit the entire team, the developer can present their findings to the others, and the end product may improve too. Using new technologies often inspires developers, and management gets some new buzzwords to use in advertising the product.
Another motivational technique can also make management cringe: you absolutely must establish that you prioritize quality over quantity. When developers are encouraged to get projects done quickly, no matter what it takes, the end result is often incredibly sloppy coding and design, and you’ll end up paying for it down the line. Want to enhance your product and add new functionality a year later? Guess what—it’s now going to take longer to accomplish. The spaghetti-like code may have made sense to the developer(s) working on it at the time, but it’s almost guaranteed to require a great deal of study a year later in order to make sense of what it does, whether or not the original developers are still on staff. Your team has to focus on untangling the code before they can even begin to write a single line of a new feature. Focusing on quality up-front, at the cost of extra development time, almost certainly ensures dividends that make up for cost several times over time. Developers are motivated by producing quality work today that they’re proud to stand behind, and they will spend less mind-numbing time reworking a poor product in the future.
Overall, creating high standards for your team keeps your developers doing what most developers like doing best—creating new things. When they’re producing high-quality work and feeling happy, management is happy as well!
Roy’s analysis
This note contains lots of great nuggets. Let’s try to analyze why these ideas are good ideas, and why they could be effective in making a team better. We’ll analyze this based on the six influence factors model, and in the context of the three team modes.
Coding standard
Setting this guideline affects the social ability and social motivation influence forces:
- Social ability means that it’ll be socially difficult to behave outside the standard, assuming everyone else is using the standard. When you get into an elevator, you’d find it difficult to face the opposite way when everyone’s facing the door.
- Social motivation means that if the people you respect and follow on the team adhere to the coding standard, you’re likely to think it wise to do the same.
Dedicated learning time
Setting these guidelines affects the environmental ability and motivation influence forces:
- Environmental ability means that you’re physically able to take time to learn new skills. Many developers don’t feel they have time, or they’ll be berated by managers for taking the time to learn new things.
- Environmental motivation means the company might reward (or at least not punish) you for taking the time to learn. Celebrating developers’ achievements in learning new skills, by their managers, would help a great deal. Tying bonuses to learning achievements can help as well, although you might find that sometimes money corrupts the pure nature of loving to learn. You’re better off rewarding with symbolic gestures (trophies, awards, and T-shirts) rather than money.
Prioritize quality over quantity
Here we arrive at the real elephant in the room. Quality-over-quantity is one of those “holy grails” that many leaders believe in but have a hard time advocating. The thought’s good and pure: we want to affect the environmental motivation influence force to reward people for quality and discourage the opposite. Easier said than done, but there are ways to go about it. Lots of the topics in this book can help. At the end of the day, it takes courage to stand up for the things you believe in. Sometimes it takes guerrilla warfare.
I make sure my estimates contain the quality built-in. For example, I don’t say, “It’ll be X days total, and X+3 days with testing.” My X is always inclusive of testing, TDD, coaching, and pairing time. I don’t mention it because it’s part of the work. I also don’t mention how much of the time I’ll spend debugging. That’d be ridiculous. Yet we treat writing tests, pairing, or coaching differently than debugging, when all of these things are facets of the same important work. We allow those who don’t understand the work to tell us how to do the work. This is the stand that must be taken, even if quietly, to start making a difference here.
I believe the fault of many projects’ horrible quality lies not in the managers, for they know not what they do when they ask for “skipping the testing.” It lies with us, the developers, the coders, the testers. We’re the ones who should be judged when quality is diluted, because we’re the ones who allowed alien hands to smudge the quality that we’re responsible for.
That isn’t to say that great quality is always the standard. Short-lived code doesn’t need tests, if it’s only designed to be shown in demos to see if you’re even on the right track. If it’s adapted to become long-lived code, there’s no excuse for failing to bring quality back to the forefront and becoming fully responsible for it again.
DEREK SLAWSON has a natural inclination toward best practices and learning new things. He uses lessons learned through the art of improvisation to provide workshops to organizations that wish to increase the effectiveness of their teams.