At the suggestion of a colleague, I have recently started reading a book called Drive: The Surprising Truth About What Motivates Us. If you are interested in this post and want to learn more about employee motivation, the book can be found here: Drive: The Surprising Truth About What Motivates Us
Daniel Pink makes the case that the way we attempt to motivate employees is very outdated. He makes the case for three different types of drives:
- Biological needs: hunger, thirst, sex
- Responding to rewards and punishments in our environment
- Intrinsic motivation (autonomy, mastery, purpose)
Many companies are stuck in attempting to create rewards and punishments for good or bad behaviors at companies. This is no longer working as well for jobs that require a lot of creativity. The reasoning is that providing a reward for certain behaviors (dangling a carrot in front of the employee) automatically makes the task undesirable. If you reward a behavior, that means it is not a fun thing to do. While rewards help in the short term, over time they drive the wrong behavior. Rewards of this type stifle creativity and demotivate workers to get a task done. I haven’t done a great job of explaining this, but Daniel Pink does a much better job in his book.
Instead, intrinsic motivation drives many creative people. Consider open source code. Many developers work outside of their normal working hours to provide some useful code for seemingly no reward. They don’t get paid to do this (such as Wikipedia articles). And yet the open source community is huge and has created tons of good work that is used by many people. Intrinsic motivation – particularly autonomy and mastery, in my opinion – drive creative types like myself (and programming is a creative activity – or at least it should be).
If you aren’t convinced that autonomy and mastery are important for creative work, I will again encourage you to read the Drive book. It’s a very interesting read.
Now consider autonomy and mastery in the context of automation. The whole point of automation is to take something that is manual and not have to do it anymore. Perhaps a button can be clicked to do it for us. Perhaps we don’t even click a button – stuff just happens. This is the case with continuous integration, where we do nothing different than our normal development behavior, and a CI server automatically does stuff when we commit code.
I would argue automation is a HUGE factor in making a business a lot more productive. Investing in automation infrastructure makes teams so much faster over time. So I believe automation is important for business. So that being said, autonomy and mastery are very important enablers for automation to happen.
When workers are allowed to do things the way they think works the best, they are encouraged to experiment more. In order to learn new things, autonomy encourages the experimentation while mastery encourages using that experimentation to develop great things. Over time, that experimentation leads to mastery. Mastery leads to automation that makes everyone’s lives a lot easier.
Let me give you an example. Jenkins is continuous integration software that runs in a web server. It can help with several automation tasks. I learned about this because of my first job. At my next job, they had this build server, but no one used it very much.
I had a lot of autonomy at that job. As a result, I learned a whole lot of things about Jenkins. That autonomy allowed me to explore what Jenkins could do. I created jobs that ran automatically when code was committed. I made those jobs compile code, unit test code, and send out notifications. I learned about Jenkins potentially deploying software to nodes (not really its primary use case, but interesting nonetheless). This autonomy led to my mastery of Jenkins.
Now, both in that job and at my current job, I use Jenkins to create automation tasks that save us minutes and sometimes even hours every time it is run.
The time it took me to learn Jenkins? It’s hard to measure, but let’s say it took 3 months. 40 hours/week * 12 weeks = 480 hours. That’s obviously a lot of time.
Let’s make a conservative estimate that those jobs that run unit tests catch 1 bug per month. For each bug that it catches, it saves a developer and testers down the line 5 hours of debug time (because it was caught right when they initially commit it). This is probably a very conservative number. Let’s also consider that there are 10 jobs doing this.
That’s 50 hours every month being saved. So after 1 year, 50 hours * 12 months = 600 hours have been saved. 600 – 480 hours = 120 hours, or 3 weeks have been saved.
Again, those are very conservative numbers. More than likely, that 5 hours of debug time may be less for the developer but much greater for a system tester. If it catches a critical bug that would have made it into the customer’s hands, it could save days/weeks/months of effort. Seriously.
This is a long-drawn out example to prove a point: autonomy is very important if you want to drive automation. As I said earlier, I believe in automation very strongly. It is the key to keeping employees focused on what they are good at rather than stupid manual things. You also need fewer employees. Not only will those employees be happier doing the more worthwhile work, they will be producing more value for the company.
But it requires autonomy. This can be scary for those used to the typical workday. Pink’s book describes cases where developers don’t come to work and don’t even have set hours when they work. They don’t even work 40 hour weeks! It is more focused on getting a job done rather than the amount of time worked.
This is very liberating for those employees. It also encourages creativity. This same company allows developers 20% time to work on whatever they want. Some of the best products at Google came from 20% time (Gmail came from this).
Have I provided enough examples yet? I hope so. Regardless, here are some takeaways based on this:
- Creative Employees
- You are a professional. Managers can tell you what to do, but don’t allow that to dictate how you do it.
- Sometimes you can go outside what you are supposed to do to explore new ideas and approaches to doing things. These are some of the most valuable things you can do when game-changing results come from these.
- If you are stuck in a position where this absolutely, positively is not possible, and you can’t change it… either accept that fact and live with it, or find somewhere else to work.
- Allowing full autonomy is scary. If you allow employees to work from home on their own schedule, you’re going to need a way to track progress that differs from the traditional “Oh, you worked 40 hours this week.” What is really important to your business? The number of hours worked, or the work that gets done?
- You’re going to have to promote this type of culture. It runs contrary to what most of us grew up learning and what most businesses currently do. But some of the best allow a lot more autonomy. It is definitely not the norm. Do you want your business to be normal or extraordinary?
- Be very careful in how you encourage employees.
- Encouraging “hard work” when they worked overtime – and working overtime happens as a norm – you are encouraging wrong behavior. By its very nature, working overtime means you did not plan appropriately. Which means you are potentially going to let a date slip.
- Instead, encourage high quality in the products.
- Encourage new ideas that make the team more productive.
- Encourage learning new things.
- Help employees develop professionally.
- Determine what motivates each employee, and use that information wisely (NOT just short-term, but long-term).
There is a lot of information to unpack from encouraging autonomy and mastery. I strongly encourage those of you who want to excel to look more into this. Read Daniel Pink’s book. Think about how you can implement this in your day-to-day business. Break out of the normal patterns of thinking and find new ways that work better… particularly for things that just aren’t working.19