Professionalism and Developers Part 2

Software Developers are not hooligans.

Last time, I wrote about the three main factors which contribute to a lack of professional behavior among software developers.  For management which does not come from the ranks of engineers, it can feel like you are attempting to organize a group of soccer hooligans.  The good news is there are some simple techniques you can use to improve the professionalism of these challenging employees.  

Since developers are creative and intelligent, a pivotal approach to leading them is to show them what to do and let them take ownership of the details and deliverables.  For instance, we had a client that need to track bakery ingredients.  I said we are required to monitor the elements in a database and that some restful APIs in C# should be able to do the trick.  The development team asked about how they would enter data in the system. I said that we should be flexible and we should use the technology we already have. With that information, the team constructed an AngularJS application that wowed the client and earned us additional business; because I left the details and deliverable up to the team, they took ownership of the process.  

Next, developers crave autonomy.  The reason they specialize is so they can have mastery over a subject.  The ability also translates into others, trusting them to do the correct thing technically for the project and the business. Ability becomes autonomy to a software developer.  Giving team members freedom is going to be a challenge to business leaders accustomed to micro-management, but it will pay dividends.  Set clear deadlines and then allow developers to meet them.  Reward success with more autonomy.  It will become a positive cycle.  

Another proven technique is to allow engineers to automate everything about their jobs they hate.  If they do not like filling out time cards, ask them to write a macro to do it for them.   Instead of scolding people for not writing release notes, have them use the git repository to generate the notes based on pull requests automatically.  I was amazed when a developer created a build pipeline, which creates an excel spreadsheet with unit test results.  I asked them why they did it, and they said it was because they hated to do it each time a build happened. 

Finally, dole out perks and privileges based on professional conduct.  Let people go home an hour early on Friday if documentation is complete, timesheets submitted, and the build is working.    Perks do not have to cost money, and they can be an excellent way to encourage more professional behavior.  

By rewarding professional behavior with perks, allowing engineers to automate parts of the job they hate, granting increasing levels of autonomy, and giving people the flexibility to solve problems, you are creating an environment where developers want to become more professional.  Software engineers are some of the hardest employees to lead, but if you follow my suggestions, it will be much more comfortable than attempting to control a bunch of soccer hooligans. 

Until next time.