Staying Motivated
During my ten years of software development, motivation has often been a key factor of project success or failure. I have seen projects, which were relatively simple, fail due to some cause of demotivation. Often the disease originated externally in an organization. Some people were demotivated by limited compensation, long work hours, and some were just bored. The point is, no matter how many high-performance (read highly paid) developers or employees you have, if they cannot find motivation, the project will likely be over-budget, overdue, or simply fizzle out.
Agile software development methodologies, including Scrum, rely on motivated individuals. Take this quote from the Principals behind the Agile Manifesto:
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
This reminds me a bit of the Serenity Prayer. It is very easy to say, it is very encouraging, but it can be very hard to implement. The “motivated individuals” that you place on your project may be derailed for any number of reasons. One person’s motivational environment might be another’s jail cell. Trusting developers to get something done can also be challenging for a manager. Fortunately, Agile does support this with frequent feedback as a requirement. The problem arrises if things don’t get done. Any number of excuses exist since software development is an empirical process.
I use the term “excuses,” which may sound harsh. Professional, motivated individuals will almost always admit they could have done something better to lessen the amount of work carried over to the next iteration. Most developers, however, have been jaded by too many gestapo managers who don’t understand that software is empirical. In turn, it is almost a reflex to work up an excuse. Even new developers can pick this up from a jaded colleague. Maybe something wasn’t quite as complex as we made it out to be. It doesn’t make the developer a liar, it is simply a product of bad process and developers must be trained to tear down the wall.
So what does it take for a developer to be motivated, or any person doing work for that matter? My inspiration for this article comes from a book I recently read. Outliers: The Story of Success by Malcolm Gladwell is the first book that I’ve read that helped me understand the roots of motivation. The book hits it right on the head for me. Gladwell states:
Those three things–autonomy, complexity, and a connection between effort and reward–are, most people agree, the three qualities that work has to have if it is to be satisfying.
Exactly! My whole career I’ve tried to figure this out. I’ve seen motivation suffer due to lack of just rewards for effort, vapid maintenance development with no business growth, and everyone’s favorite, blatant micromanagers that are in your cube at least 6 times a day asking the same question, and the opposite which is managers who were so uninvolved that people had no sense of accountability. On the other hand, I’ve also seen motivation skyrocket from something simple as allowing a developer to learn something new, empowering them to make technology decisions, and performance based rewards.
Most developers need to be autonomous. Does this mean a developer needs to be a large, war-fighting Autobot as in the autonomous robots of transformers? Not quite. A developer simply needs to be able to make decisions within his realm of expertise. Did you hear that devs? I’ll repeat, within his realm of expertise. We are developers and not always businessmen. Aspire to be both, but realize when you are in over your head regarding business. Rely on the business side of your team for help. Likewise, business analysts must understand that if a developers is saying no, there might be a deeper meaning that might not be understood. Simply inquire and determine the root cause. What may appear to be obtuseness might simply be a developer trying to save you some time and frustration. Developers should also communicate a hurdle in a professional manner. Many times it is important to put the hurdle in terms of time and cost to have management realize its implications.
A developer should see his role on the team and learn to play that role. As developers we provide a technical service to businesses and should advise on those boundaries. You can step over that line once you learn more about a given business, as long as you are adding actual value from the business standpoint. If you are able to do this as a developer, then consider yourself autonomous. Autonomy doesn’t mean developers can choose to fly to conferences 6 times a year on company dimes. Autonomy for developers doesn’t mean you will choose your compensation, every hardware decision, or even every software decision. There are external motivators such as cost and compliance that could influence any of these decisions. You should expect to have plenty of independence on how you complete a given task within the bounds of what is good for your organization or customer. Autonomy doesn’t mean you can pick your projects unless you are an independent contractor or you own your own company. Even then external motivators such as economy and demand might force you to go with a project that is less than perfect.
A developer must be responsible with this gift. What causes managers to not allow developers to be autonomous? Maybe our feedback loop wasn’t tight enough and the project manager thought we were further along that we were. Maybe and addition feature snuck in and delayed the implementation, but only the developer and the BA knew about this. If you are going to be autonomous, ensure you are communicating effectively and think like a businessman.
This brings me to the second point, complexity. There was a time in my career where if I wasn’t working on the most newsworthy or challenging project, then I wasn’t motivated. I hated maintenance and debugging, I still don’t like long term maintenance, some do and that is fine. As a developer, we must look through any lack of marketing on our project and assess the actual value a project is adding to a company. If you have a project that has sputtered along because of bugs and technical debt, then my friend, consider yourself a refactoring/debugging rockstar. Yep, I used the word, rockstar, and you know you like to hear it.
As an example, troubleshooting is one of the most complex tasks developers will encounter in a project. All too often, debugging is considered maintenance and somewhat of a chore. Consider it a puzzle and a challenge. I’ve realized that I can learn more about coding via refactoring than by writing a new framework or learning to implement the latest and greatest open source widget. On the other hand, I’ve seen developers be resistant to learning new technology. A bonus to new technology is that learning it is often complex. Consider complexity to be fulfilled if you encounter a new technology. Don’t get caught up in the politics of the decision, simply go with the flow and make the best of it for you and your career.
Unfortunately, complexity isn’t the same across the board for all developers. Dave Thomas gives a presentation on Herding Racehorses, Racing Sheep. What seems complex to one developer may be overwhelming for another. A developer should have a good enough relationship with his manager to ask for help, and a manager should also realize that a developer might need some assistance with the current task if they are struggling. It is not an opportunity to beat down the ego of a developer or any employee, that should be handled separately if it is an issue. Teams should assess the skills of each member and assign work accordingly.
The third ingredient from Gladwell for making a big bowl of satisfaction soup is a “clearly defined relationship between effort and reward.” The first time I read this, I only thought about it from the viewpoint of monetary compensation. Fresh college graduates, including myself early in this decade, see dollar signs. They want to leave behind the taste of ramen noodles or macaroni and cheese for something more refined, and rewarding.
Due to the stresses and unknowns of software development, I believe that developers should be non-exempt employees or hourly contractors, because inevitably if you are motivated you will work more than 40 hours a week. Actually, the organization doesn’t even need to pay overtime, just pay for every hour. In an organization which pays hourly, there is a clearly defined relationship between effort and reward. If you work 80 hours a week, you get paid for 80 hours. Down the road you’ll be rewarded with an early retirement if you plan wisely. I would gladly cover my own insurance, benefits, and accept that any time off would be at a cost to me and not the company if developers can be hourly employees with a market hourly rate.
Unfortunately, it can’t always be that way. Developers are mostly exempt from overtime and are salaried employees. So, how do you establish a relationship between effort and reward? Did that night of extra work help you learn something which will further your career down the road? Will your employer compensate with extra time off? Can you have a flexible schedule to get back some of those hours? How about a bonus or a promotion? These are all options.
Often, these traits of satisfaction tie together. Maybe your reward for extra effort is to get promoted onto a shiny new project that will improve your skill set and resume, indirectly leading to monetary increases down the road. Some employers might allow you to contribute some on the clock hours to an open-source project if that is your passion. The best thing here is to find out what you consider a just reward for great effort. Work with your manager and always negotiate with new employers to ensure a good work/life balance or just reward in times when you are giving extra effort. Just as with complexity, you have to be a business man when negotiating a work/life balance.
Conversely, if you are cruising along at 35 hours a week, consider yourself blessed, and consider it “a clearly defined relationship between effort and reward” in that you spend less time at work and get paid to do so. Your reward is an excellent work/life balance. Of course, if that 35 hours a week isn’t the cultural norm at your company, then don’t expect a bonus or anything extra outside of your current compensation.
Due to geographical location and lack of choice in employers where I lived in my early career, often developers found themselves working 60 hour weeks for 3% raises, no external training, and often only received a raise when they threatened to jump ship. If you have experienced this, you cannot carry baggage. Live and learn. Once your move on to a new employer, ensure you won’t make the same mistake twice. Unfortunately, what we didn’t realize is that we all had a great deal of autonomy at this company, as well as complexity. Our boss said, “I need this” and the rest was in our hands. Having more of one trait might be satisfying enough to make up for a shortcoming in monetary compensation.
Whatever it may be, we must dig deep as developers and strive to be professionals, and strive less to be treated like rockstars. We must always remember that we provide a service that not everyone can do. That doesn’t mean the business-analysts have to wash our feet and bring us ice cream to get something done. It means that each developer is running his own mini-company and must do well to ensure that customers are happy, even if your customers are those coworkers around you.
Next time you find that your motivation has diminished, revisit the principals from Gladwell. Assess the root cause and determine if you can change it or at least admit it. Sometimes just breaking down and admitting to ourselves that we have been unmotivated can be a break through. If possible, find a new source of motivation to help push through a tough task. Who knows, you might help motivate others around you. Just as demotivation can be a communicable disease, progress can heal a whole team.
