There's an annoying aspect to induced motivation: It rarely lasts. It's an extremely temporary phenomenon. The crowd, after seeing a motivational speaker or after seeing a certain picture, is completely pumped up only to have the feeling completely wear off before they even get home. New Year's resolutions are forgotten. Deciding to go on that diet and finally lose those extra pounds is gone at the first whiff of a donut. The truth is that we're not motivated by things we want. We are motivated by things we need and are willing to make tradeoffs for.
I've always heard that it's the manager's job to motivate their people, but it's not. Because, for all intents and purposes, it can't be done. Not in our line of work anyway. Let's take a look at motivating software development teams. What do we want to motivate them to do? Most of us would say that we want them to be more productive, followed by being more technically skilled. Then there are the more specific goals like being competent at making estimates or keeping work items up to date. These things involve thought and are fundamentally different than, say, a factory worker getting paid by the piece. It's a very different kind of transaction.
How do we motivate people in our line of work? If you ask software development managers, usually you get pretty much the same list: Money, recognition, time off, autonomy, and prestige. There are a lot of studies out there that tell us what we already know, if we're honest with ourselves. These things aren't very effective in our industry. There is, in fact, often an inverse relationship between some of these rewards and the goal of increased productivity. By and large, this has been my experience.
I work at a place where our motto is: “We help people build better software.” Our goal, as an organization, is to help software development teams be more productive and to up their game in the skills department, and we're pretty good at it. Sometimes I think we're good at it despite our best efforts. Yes, we've offered money, recognition, time off, autonomy and prestige, but I can't trace any of our best breakthroughs back to any of those things. In fact, the only success we've ever had with those is in very short-term situations. I'll share with you what I've been able to trace breakthroughs back to: a personal desire to contribute. Let me offer one example:
One area where we excel as a company in helping people build better software is in helping them build Windows desktop applications with WPF. Desktop development is almost a niche now, as we've watched most of the love go to Web and mobile applications. We ourselves were struggling with being productive in this niche and that need led to an incredible productivity booster; the CODE Framework. What's interesting about the CODE Framework is that it was created out of a personal desire to contribute. Markus Egger, our Chief Software Architect, sat down for several days and nights on end and created a set of tools to make creating WPF applications easier, faster, less mysterious, and, well, better. Then he showed the rest of us how to use it effectively. It has been one of the most significant pieces in our ability to increase productivity in that particular niche. Then he turned around and made it open source and gave it away. Since then, many more days and nights have gone into expanding the Framework in areas like services, mobile, and the Web. There was no money, no recognition, the opposite of time off, and no prestige. None of those things drove him to create CODE Framework or to keep working on it.
Look at NuGet, CodePlex, GitHub, and Visual Studio Gallery. Look at the open source community in general. Most of what's out there is free and the vast majority of it is unpaid work. It was done out of a personal desire to contribute. More than that, there was a need to contribute. The more I thought about this, the more I came up with example after example where the best work I've ever seen or done was fueled by this personal desire to contribute. I can trace it back to the first piece of software I ever put my name to. I worked furiously on it. I put everything I had into it and not for money, recognition, time off, or prestige. It was some of the best work I've ever done. I was driven by that same sense of personal desire to contribute. I saw how I could take something I knew how to do and make it useful. I was driven for years to make that software increasingly useful. I put my heart and soul into it. Eventually that little program grew into a very successful company, but when I look back at what motivated me, success didn't even come into the picture. That's not why I did it.
This phenomenon isn't limited to coding, either. Software development is a thinking game. Finding a way to cut out unproductive meetings, finding tricks to creating a better rapport with clients, finding ways to provide a better product or drive more sales, these things are all very personally rewarding. These are all things that most people are more than willing to do in order to make a personal contribution. There is a drive and a need in all of us to contribute. In many ways, there's no better feeling.
The best work I've ever seen has almost always sprung from someone's pet project. Something they spent time on because of a personal desire to contribute. Something they saw that they could lend themselves to that would produce something useful. Something they did off the clock and couldn't wait to show people. Something they wanted to do. Something they needed to do, in a way. As a manager, there's nothing better than having someone pull you aside for a few minutes to show you something they've “been working on in their spare time.” It's usually very cool. Sometimes it's brilliant. Sometimes it's useful. Sometimes it's just cool.
It's not the manager's job to motivate their people; it's the manager's job to facilitate an environment where motivation can happen. Looking back at my management career, I've often been terrible at kindling productivity in this way. I've dismissed ideas out of hand, refocused work that could have led to great things, offered incentives that took all the motivation out of someone's potential contribution and turned it into work. Yes, I take a lot of pride in meeting deadlines and delivering what was promised and ultimately, that's 80% of everything we do that counts in our work lives. We can't go off chasing every great idea. But those little gems that come from a personal desire to contribute are often the reason we do this kind of work in the first place and somewhat ironically, they often lead to money, recognition, time off, and prestige. More importantly, they're what gives what we do meaning and what gives us satisfaction.
