Developers as Code Artists
Earlier this summer, I gave several talks to different groups of technology professionals about humanizing the project and product management experience. As a digital project manager, it’s my job and ultimate goal to make sure projects stay on track, on time, on budget. When I tell people what I do for a living, I envision them seeing Gantt charts dancing in my head 24-7 and aggressively – almost neurotically – checking milestones and deadlines. “Launch on time! Launch on time! Where’s your code?!”
This is far from the case. The reason why is that although I do have an unhealthy obsession with spreadsheets, I have one main goal. Happy developers.
Why? If you give good people the tools to do their job, and keep them happy, they will do good work. Period. That’s all you need to do.
So what about the engineers who resist? It’s far from futile, because these are the women and men who are the digital artists, weaving their lines of code together. If they resist, I will have problems. The conductor can’t control the orchestra if the violins go rogue halfway through the symphony.
The main reason my code-artists dislike the “time box” is because they are just that, artists. I know one developer who, had I allowed him to, would never finish a project. Not because he can’t or struggles or is a slacker – far from it actually. He is an artist, genius and perfectionist. It will never meet his high standard. There will always be something he can improve. It’s like my home improvement endeavors – I don’t have a milestone for anything so it forever gets tweaked.
We need these kind of people in tech. It’s how innovation occurs. So how do you attempt to manage that zeal? Three things:
Always say why.
Whether it’s creating a deadline, moving a milestone or implementing a feature, tell your engineers why things happen and why things are needed. Sometimes just knowing why something needs to occur can click the priority switch to “1” instead of “0.”
Get people involved. Early and often.
This helps create ownership. And not in that dry “who owns this task” kind of way. It makes everyone on the team connected, involved and inspires pride in the process and the finished product. Who feels the most pride, the second runner of a relay team or the one who takes the baton over the finish line? On digital development teams it should be everyone who ran a leg.
Treat them like people.
This is the simplest to implement, the easiest to overlook and the most important. Ask your engineers how they are doing – and not in a “how far along is this code” kind of way. Bring them a donut. A Red Bull. A hug. These individuals are not code vending machines – they are people. And when you show that you recognize their humanity and their value you have given them the final tool to do good work. Hopefully great work. And hopefully work that everyone can be proud of at the end of the day.