I was thinking the other day about the importance of quality software architecture and about how the planning of such software architecture can fundamentally affect the success of a business. Indeed, the benefits of adequate planning are painfully obvious to those who have worked on projects- both badly planned and well planned ones.
The following question then occurred to me: “How does one motivate software developers to do the right thing while they are developing?” As we all know, there is an ‘easy’ way to do things and a ‘hard’ way. At this point it may be useful to use the analogy of building a house to explain my point. The first (easy) option of building a house would be to build it out of wood, with merely satisfactory foundations. The second (harder) option would be to build it out of cement and concrete, with deep foundations. Both options would serve their purpose; however, under extreme weather conditions, (and, in fact, inevitably over time), the first house would start to creak and no longer be able to perform its task, while the second would remain strong.
The same principle applies to software development. The question is thus raised regarding how to motivate the developers in a company (or on a project) to make the right choices; to lay the right foundations; and stick to these principles over time. Importantly, the issue is not simply how to motivate them to work, but rather, how to motivate them to do their job to the best of their ability.
I would argue that there are two major categories of developers. The first kind of developer is a developer who may have needed to make a career choice after school, and who chose IT because it was the option people suggested (s)he decide on. The choice to become a developer was, as such, essentially reducible to the choice to pursue a seemingly “good” job. The second kind of developer, however, is passionate about technology and would most likely be involved in IT regardless of any career potentials offered by the field.
I would not know how to motivate the first kind of developer in this example- I believe that these types rarely elevate themselves to the heights that are truly needed in the industry (unless they transition to the second type). I suppose that the pay-check at the end of each month would probably be enough motivation in most cases, although this is only likely to be motivation to simply show up at work; not to go the extra mile. If a company’s developers are of the first type only, the company or project would almost certainly need a strong architect to set policies and expectations in place, and to make sure that these are carried out.
The real question I would like to address here concerns the issue of motivating the second type of developer- the passionate one. (I believe that I am personally passionate about technology and software development so forgive me if I have related this question to myself too readily). Luckily, I work for myself now, so my motivation to offer excellent client service is certainly present. However, since I have begun to outsource more work, I have also been urged to think back to a time during which I worked for companies, and not for myself. In retrospect, a pressing question for me concerns what these companies did to make me lose interest. What would have kept me motivated? And more importantly, how do I keep my people motivated now? I have identified four issues that may help add clarity to this issue, and these are what I would like to share with you here.
At almost every company I have worked, there has been a power-struggle about delivery and priorities, between the top levels of management and development teams. The developers are desperate for time to update the architecture and design of software, while management push only for new features to drive short term sales. In the long term, if these managers consistently win this debate without making any compromises, the software will inevitably fall short, as developers are not able to see their proposals met and the architecture ultimately fails. Technology is ever-changing; and if you are still developing the same way you did five years ago, your competitors are getting ahead of you and your developers will remain frustrated.
Nobody who is passionate about technology wants to do the same thing for three years. They want to do new things; use new tools; use new technology and generally-speaking, innovate. This is not always an easy goal to achieve, but if followed out, it will serve two purposes. Not only will the developers be more satisfied with and excited about their day-to-day work, but innovation will also open up new revenue streams within a business.
By this I don’t mean giving someone a “Team Leader” title and telling them to run with it. I mean genuine ownership. I would suggest that software or technology companies should have an optional staff share plan in place. This would encourage developers to make sure that the work they conduct is sustainable for years to come, since they will benefit directly from the company’s success. Giving staff ownership options will ensure that staff remains motivated on a second account, too: When they leave the company, their software will continue to generate income for them.
In most organizations the senior developers are well aware of the kind of money that they are generating for the business. Therefore, if for example, a developer makes your business $10 million in revenue, why not give them a $100,000 bonus? Don’t base rewards on a percentage of their salary- base it on the revenue they generate. This will ensure that developers keep pushing to make your systems perform better, as well as ensuring that they are always available to do so, etc. (This is partially related to my third point, but direct bonuses are also a good way to keep the developer enthused).
In closing, I feel that any business that can develop these principles will create a place of innovation and of performance. And inevitably, this cycle is reversible, too. If for example, I was a developer and the company interviewing me had no passion, I would certainly pick up on that fact, and would no longer be interested in joining the company. If, however, they were genuinely passionate about their jobs, their rewards and their systems, that fact would be obvious to me, too, and would immediately incite me to become involved. Indeed, for a company to portray passion in interviewing potential developers is an invaluable objective, and will ultimately ensure that the right kind of developers enter the business.
If you’d like to share your thoughts on this topic with me, please don’t hesitate to do so. I would love to hear from other passionate guys out there, and to gain insight into what they think may be the motivating factors for software developers in today’s ever-changing, technology-driven society.