How to Motivate and Innovate Part 1

In this series of articles I want to discuss some topics for software development leaders around motivation, innovation, and the different leadership styles you can use to support your team.  When you are leading a team of software developers, or indeed any knowledge workers, you need to keep them motivated to continue getting the best out of them. There are many ways to do this, and they don’t always involve paying people more money. In the rest of these articles I am going to discuss some thoughts on motivating developers.

Motivating Developers

When I started planning this series, I was mainly going to cover how to get the developers in your team to innovate in a safe and controlled way. Then I came across an article called “What research on happiness and motivation can tell us about finding meaning in our work.” By Edmond Lau.

Motivation - Getting in the Zone

Motivation – Getting in the Zone

It is a really good article and I want to pick up on a few points and discuss them further. There are many different ways to get someone motivated, but by far the biggest for a knowledge worker is to give them meaningful and challenging work.

People lose motivation with work that they perceive to be pointless. For an employee at a company, the most powerful and sustainable motivator is the sense of meaning derived from work. Meaning comes from working at a company whose mission and long-term vision you believe will have an impact. It comes from working with and building a team whose members you respect, who continually challenges you to learn and get better, and who you can’t bear to let down.

The first statement is very important, you can’t keep someone motivated if the work they are doing has no meaning.  This could be getting them to do tasks just for the sake of doing them and they have no perceived value. It could be getting them to write code which they know will only be short lived before it is scrapped. A developer may also think that the project they are working on, whilst important to the company, feels meaningless to them. This is most probably because the senior leadership hasn’t managed to get them bought into the idea of the project first. This is something I have seen many times where project sponsors have failed to really get people engaged and sold into the idea of a project before expecting them to commence development on it.

It may also be difficult to keep a developer engaged if the company doesn’t have, or doesn’t actively push a mission statement and a vision for where the company/department is going. It can be hard to give lots of effort, and even additional effort outside of your contracted hours if you don’t know of or believe in the company’s mission and vision for the future. I have worked for some companies before where they don’t have a vision that is published to the staff, so it can feel like you are just a cog in a machine and not feel like you are a valuable part of that machine.

Financial Reward is Only a Temporary Motivator

Financial Reward is Only a Temporary Motivator

I often hear money as an excuse of de-motivation, and whilst I think a developer should definitely be paid at least market rate for their skills and experience, just solely using money as a reason for motivation is a bit of a weak argument. You may feel that you will be more motivated if you get a £3000 pay rise, and you probably will for a few months, but how long will it be before you start to think that you deserve another rise. Edmonds article discusses a study that took place by Nobel Prize winner Daniel Kahneman in 2010. The study found that an annual income of $75,000 (around £46,000) was the threshold at which additional income ceases to correlate with additional happiness. I won’t go into much detail of the study as you can read about it in Edmond Lau’s article.

Get in the zone

One ways of telling how meaningful you find a piece of work is by how engrossed you become with it, or getting in the flow as Edmonds’ article puts it. I have always called it getting in the zone.

“Flow is a state of deep enjoyment and total involvement that happens when you’ve found the perfect intersection of challenge, creativity, and skill in an activity. It describes an activity where you’re so engaged in what you’re doing that you lose all sense of time. Given the number of waking hours that everyone spends working, finding flow and meaning in work therefore becomes critical to achieving happiness.”

When working on large tasks, to get into the flow I find it best to break the task down into smaller units with a defined goal at the end. For example, I will first start off by writing the DoWidget() method which is a much smaller part of the larger WidgetFactory class. When I have written this method it will mean I can add a set of Widgets into WidgetFactory. That would be one very small part of a much larger task, but by mentally rewarding yourself after each little milestone, you automatically start to motivate yourself into the zone by the little rush of excitement you feel when you get something working, no matter how small that “something” is.

Sometimes it can be difficult to get in the zone though if there are many distractions around you. This could be because you work in a noisy office, you are a subject expert and people keep on disturbing you to ask you questions, or it could be the distraction of email or alerts from your social networks like Facebook.

Use core hours as a way to focus on your work.

Use core hours as a way to focus on your work.

A practice we try to uphold at the company I work at is the concept of core hours. What this means is that between set hours in the day, you turn off your email, close your browser, put your phone on silent, and don’t talk to anyone unnecessarily, unless it is about the task at hand, and concentrate only on your immediate task. We try to do this or 4 hours a day. We do, 10am until 12pm for the morning and then 2pm until 4pm in the afternoon. During this time you just focus on nothing else but the work you need to get done without any distractions. Outside of these core hours, you will work the same tasks, but you allow for other distractions, like people asking you questions or a support query from another department. When we first floated this idea, the senior management went ape, they thought we meant the developers were only going to work for 4 hours a day on capitalised projects, but this isn’t this case. It just means for 4 hours you focus ONLY on that work with no distractions, so be careful how you pitch this idea to senior leadership if you want to try it.

The Work Environment

So far we have discussed about the importance of meaningful and engaging work to keep developers motivated, and this is still the single most important factor in motivating someone, but there are other factors that contribute to someone’s overall motivation. The environment you work in is just as important. By environment I mean things such as, the physical environment like the office, desks, chairs, equipment etc and the people you work with.

If you have to spend 8 hours a day in an office you want it to be as comfortable as possible. You need a decent chair, preferably with good back support. A lot of this job is spent sitting down so the last thing you want is a bad back. Your office should also provide lots of natural light via windows. It is already a known case that natural light can improve your workplace performance. I have worked in places before where there are not many windows and you have to spend the day under fluorescent strip lights, and it really does affect your mood. It certainly did with me.

An untidy office can be very demotivating

An untidy office can be very demotivating

The general décor of your work environment will also have an impact. Are the walls tired and dirty? Does the carpet look as though it is desperate need of a clean? Is there junk scattered around all over the place. In the company that I currently work in, in our UK head office, all the buildings have been refurbished except IT where we still have drab walls and the whole place is dark and dingy. It really makes me quite jealous when I have meetings with the business in their nice and new shiny offices.

The physical environment is one thing, but the people you work with form another very large factor in your general motivation. If you get along with your colleagues and all respect each other’s skill sets and abilities you are going to have a better time at work. I find collaborating with people that I like and respect who have similar or complimentary skill sets very rewarding. I am very fortunate that even though my current office building looks a little like a cave, I have a lot of time for the people I lead and work with, and it is because of this that we have delivered very successfully many large-scale projects to the business, and you know what? We all feel pretty good about that.

The final part I want to mention about the work environment is the tools that you use. By this I am talking about both hardware and software. If you expect developers to be productive and motivated you need to provide them with the correct tools for the job. This starts with their computer, which should be a decent specification machine, preferably running dual monitors. You also need to provide the software tools that they need. It can be very unfortunate when getting tools that would have a huge productivity gain and only costs a few hundred dollars becomes a barrier. You wouldn’t expect a mechanic to fix your car without the correct sized spanners and wrenches!

Conclusion

So far we have talked about what motivation is and what motivates developers. People need to feel that the work they are doing is meaningful and important. Doing work that will eventually get thrown away is a key de-motivator. We have also touched on the fact that money is only a temporary measure to motivating someone, and that once someone’s salary hits a certain threshold, small pay rises do not carry the same impact. This article also discussed about how you can get in the flow and become engrossed in what you are doing. If you are at a point where you are so in to what you are doing that the day passes really quickly, then that is normally a sign that you are very motivated with the work you are doing as you can get into the zone. Finally we finished up on talking about the working environment around you and how that can affect your motivation and mood.

A large part of this article was a commentary response to a post by Edmond Lau called “What research on happiness and motivation can tell us about finding meaning in our work“. I really recommend reading his article as well as this one.

In this next part to this series I will covers some of my thoughts to Edmonds’ strategies for finding meaning in your work.

Participate with Coding in the Trenches on Facebook

Participate with Coding in the Trenches on Facebook by Click the button above.

This entry was posted in Leadership, Motivation and tagged , . Bookmark the permalink.

7 Responses to How to Motivate and Innovate Part 1

  1. Mark Jones says:

    Some interesting thoughts there.
    On the subject of keeping the developer engaged, I have found a number of times that a project may be of high value to the business, but the developers remain un-engaged because of poor planning. It is difficult to get a team motivated when they are up-against immovable deadlines that have been pulled out of thin air, and have not considered the actual effort involved. This is all too common, and I find it to be one of my biggest de-motivators. That and decisions being made by un-informed people. Or managers playing political games that have repercussions on the development team.
    Secondly the subject of money. I don’t necessarily think it is always about how much a person is paid, but about how that fits in with their peers. First and foremost, you have to be aware of the market rates. There is no better way to make someone feel undervalued than paying them less than the perceived market rate. Secondly people talk about how much they earn. They shouldn’t, and I am always very careful not to tell people. But that doesn’t mean that every so often people won’t tell me how much they are on. Sometimes right out of the blue. When this happens, if a disparity between skill level and pay level is obvious, then hearts will sink. Not long ago I was the technical go-to guy on a project with 2 other full time employee developers. Both of these developers relied on me for help and knowledge. When I was told one night in the pub that I was the lowest paid on the team, yet had the most responsibility and was in fact in-line for promotion. I felt cheated and used. I was constantly told I was valuable, but insulted with pay lower than the people I was guiding, teaching and supporting. Worse, the company would not do anything about it because of red tape and politics. It then took almost an entire year between being told I had to perform in a particular role and receiving any kind or reward for it, and constantly being told it was only a month or two away. It totally soured my experience to the point that I hated going to work even though I loved the work I was doing, loved the people and loved the environment. I ended up leaving less than 2 months after I finally received the pay rise. By then the damage had been done.
    Ordinarily I consider myself to be quite motivated and like to get on with things. But all too often the behaviours of senior managers and the business in general undoes the efforts of the Development lead/manager in motivating the employees. For me it comes down to feeling as though I have been treated fairly. After all, I give most of my waking life to the company I work for. Being treated with a little respect and fairness is the least that should be expected. Especially given the expectations companies regularly place on employees. Do on to others……….
    Ultimately, as a lead you can have all the best ideals in the world, but if you work in a company that doesn’t respect it’s staff, nothing you do will make a blind bit of difference in the end.

    • Stephen Haunts says:

      Yeah I understand your points. As I said in the article I believe developers should be paid a fair market rate for their position and skill set. It’s these people that I don’t think the pay scale should be used as a motivator.

      Your particular example is an exception to this where you wasn’t on the market rate for your skills and position, and in that case pay is a motivating factor because of fairness. In that case the company doesn’t sound like they were being fair.

  2. Duncan says:

    Core Hours? Madness – says this SENIOR (well quite old) Manager :P

  3. Pingback: How to Motivate and Innovate Part 2 | Stephen Haunts { Coding in the Trenches }

  4. Sarith Sutha says:

    Not able to make up my mind about the “zone”. I do get the rush of excitement and enjoyment when I’m in the zone and get something done. But, Uncle Bob in “The Clean Coder” suggests to stay out of the zone. It is only a false sense of achievement.

  5. Pingback: How to Motivate and Innovate Part 3 | Stephen Haunts { Coding in the Trenches }

  6. Pingback: How to Motivate and Innovate Part 4 : Leadership Styles | Stephen Haunts { Coding in the Trenches }

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s