In the first part of this article on motivation and innovation for software development leaders, I talked about what motivation is, how your working environment can affect your motivation, and how to get into the zone whilst working. In this 2nd part of the article I want to discuss some of Edmond Laus’ Strategies for finding meaning in your work from his blog post, “What research on happiness and motivation can tell us about finding meaning in our work.”, and how Me and My team have applied some of these strategies.
Strategies for Finding Meaning In Your Work
In Edmond’s his article he proposes 5 strategies for finding meaning in your work. I want to list them here with my own thoughts, but please check out his article to get his own thoughts on them.
Validate new ideas early and often with simple proofs of concept
This strategy really speaks for itself. Before investing a large amount of effort into something that may not work out, you should try out a proof of concept first. Generally a proof of concept will be a throw away piece of code just to prove whether a theory will work or not. When my team write proof of concepts, they don’t even bother writing unit tests for them, as the code is never destined to be production code. You can even take this POC idea further by following some of the Lean Startup ideas and produce a larger working mock-up of a system, or a minimum viable product as described in the book.
We tried this in my team. We had a project that our debt recovery department wanted to initiate, which is a self-service portal on the web to allow customers who are already in debt to make a payment online, and therefore avoiding a difficult conversation with our debt collectors over the phone. The idea made a lot of sense, but before investing a large amount of money in building the portal, we did a lean start-up style set of experiments to test the theory against a minimum viable product.
A couple of my guys put a basic set of pages together that hooked up to SagePay. We had a system that could send out SMS messages from a CSV file so we could limit the pool of customers who tried the system. This system sent a message to a customer with a URL that contained an encrypted query string. This query string contains their account balance, and authentication details so we could do a basic security check on the customer. Once a customer has passed the security check they could make a payment via sage pay. Then via a manual process we could pull a list of the payment and apply them to our debt management system. The system wasn’t perfect by any stretch and it had a number of manual processes, but it only took a few weeks to get live and we tested it against different target populations of customers.
From this we learned that if you removed some of the barriers for a customer who are already in debt (missed their normal repayment dates) and allowed them a way to pay without having a difficult conversation, then they would be more likely to engage with us and pay. They just didn’t want to talk to someone on the phone. We even had customers who were over 3 months delinquent come to the site and clear their balances because the barriers had been removed.
Now we have a larger project underway to build the actual site. This experiment could have easily gone the other way though. We could have built the experimental site, tried it with the same demographic of customers and no one would make a payment. It is better to try this via a series of experiments first than to pay for a much larger and expensive project only to have it make no impact at the end of the project.
The net effect of this project at the moment is that everyone is pretty energized about working on it as they have seen the benefits of the proof of concept.
Iterate quickly and often
Iterating through your work quickly will help give you rapid feedback against the tasks you are doing. This can be achieved by using shorter iteration times (if you are running an agile project) of 1 or 2 weeks, breaking tasks down small enough that you can get feedback sooner that everything is working. When working with shorter iteration times you get more opportunity to show what you are doing to your peers, business users or customers. By performing these reviews you can ensure you do not head down the wrong path and therefore write code that could get wasted further down the line.
When I am coding, I like to check in little an often. I may check in 8-16 times in a day. I will write a small piece of functionality with tests, check in and let the build run and move on to the next part of the task. Using a tool like NCrunch also helps me reduce my iteration times as my tests are constantly running as I am coding. In the example above with the debt recovery portal, my developers had something running in a few weeks because we removed a lot of the barriers that they would ordinarily have around our release process. This was a proof of concept, we didn’t need to follow the exact process to the letter, so this allowed us to iterate quickly. In fact the business where a little shocked at how fast we managed to move with the POC. It’s always good to surprise them once in a while!!
Work under decisive leadership
There are many different leadership models like Autocratic Leadership and Servant Leadership (which I will talk about in a later article), but no matter which style you adopt, as a leader you will always need to step in and just made decisions for people. This is especially important if you have a few developers who can’t agree on an approach and you just need to make a decision to keep things moving.
As well as making decisions for the good of the team, you also need to be able to shield your developers from influences from above. One of my adopted roles for my team (along with our long suffering project manager) is to act as a filter to what comes from senior business and IT leaders. Your developers don’t need to know everything that is going on, and they certainly should be shielded from any politics as best as you can. I am not saying you keep things from your team all the time, I believe transparency is important, but you do need to act as a filter so stop your team from becoming distracted.
Automate un-meaningful work
Have you ever had that horrible sinking feeling when you have to run a report, or kick off a series of steps to collate data when something goes wrong? I have and it sucks. Don’t let repetitive and un-meaningful work drag down your day. Automate it out of existence. You can reduce the time of having to carry out these tasks by writing a small program to do it for you, or a PowerShell script etc. I did just that at my current place. We had a number of old legacy systems that kept on failing, but the log files where so complex, it was virtually impossible to decode them by eye and work out what had gone wrong, so no one bothered. That’s when I wrote some code that became one of our monitoring platforms. The system would scan log files all through the day, and then email out summary reports which would alert us to any problems.
I didn’t stop with that system though. Once we had the logs for that system successfully parsed, I moved on to other systems and added them into the monitor. Some of the systems had very poor log files, so this was a good opportunity to improve log file quality. I turned something that was mundane (looking through log files) and created an opportunity out of it, which was something I found very motivating at the time.
This article has talked about Edmond Lau’s 4 strategies for finding meaning in your work and how I have applied them myself and with my team. In the next article in this series I will start to cover innovation and how you can encourage your team to innovate.