Managing developers: improve everything you touch
Each time a manager imparts his knowledge, skills, or values to a group, his leverage is high, as members of the group will carry what they learn to many others.
High Output Management1
Since it can be high-leverage, training is a big part of managing developers. The reality is that often managers brainstorm ways for training to be delegated—rarely do they remember that they have a depth of experience to draw upon. Maybe you have a hard time picturing yourself in front of a classroom, but know that managers can teach in other ways.
In conversations and one-on-one meetings lately, I’ve been trying to teach a certain mental approach to a developer's work. Managing developers does not always mean a focus on technical prowess. Overall productivity involves more than that.
Let me tell you a story.
A QA leader named Jeff stressed to a group of us that our goal at release time was to have automation tests done. There are contingency plans where they come shortly after, but that needs be an actual contingency—not something we plan on doing.
At the time, my team had a tricky automation testing situation, and we were down the road of actually changing the code to make it more easily testable. The code was unnecessary for production, and that’s something our team dearly hates to do. There was irritation, there was an argument, but Jeff had a point.
It was in this situation that I really appreciated a dev lead's response. He checked out a repository that he had never seen before, wrote a better file comparison function with superb unit tests, and opened a PR within four hours of the conversation. The end result was that we burned the production code we had in flight. The problem was solved.
It’s easy to:
- Say that some other codebase isn't your problem
- Say that a bugfix isn't on your Kanban board
- Do just enough to get a feature out
What I want to teach...
If you walk through a park and see a coffee cup on the ground, do you throw it away? If a parked bike has tipped over and is blocking the sidewalk, do you prop it back up? Just take a moment to clean up the world.
You don't have to turn everything you touch into gold, just unwind the ball of yarn a bit more. When writing unit tests, consider first what potential future mistakes a developer could make that would make your code fail. The best unit tests are the ones that devs say out loud, "Thank you to whoever wrote that unit test."
If you suspect that someone is going to git blame your unit test and curse you, maybe work a little harder to make it useful and less brittle. Don't do just enough to check the box "has unit tests." That's just doing the minimum—throwing away your own garbage.
The list of things that we can get irritated about in day-to-day work is huge: bad code, broken tests, slow tests, downtime, grunt work, release acrobatics, half-baked, open-source projects, rapidly changing JS landscape, etc.
I love the idea of acknowledging these as crappy situations and responding with a calm "I can help this" attitude. I love managing developers that fix tests they didn't write and negotiate with release management and stakeholders to release smoothly—an attitude of improving everything you touch.
1Grove, A. (1995). High Output Management. United States: Vintage Books.