Staying motivated in the uninspiring phases of long projects
In April 2015, I was the technical project manager of six software teams all working on one gigantic project. It was the biggest challenge the company had ever taken on. The goal: create and stand up a transaction account product for small and medium business so that we could apply for an unrestricted bank license.
We were 12 months in and were about to finish the project bang on the week weâd estimated, when the inevitable happened: we received a new raft of requirements that would add at least another 3 months of work. The extra work wasnât glamorous; it was mostly security enhancements, disaster recovery preparation, and a complicated behind-the-scenes tweak of the product that added little benefit for users but was a requirement from a regulatory point of view.
Understandably, morale took a hit, but we needed to keep the pace up or weâd risk missing the deadline weâd been set for acquiring our license. After an interesting discussion with my father-in-law about the project, I found a new perspective on where we were at, and it prompted me to write the internal blog below to help motivate the team towards our final goal. A few people told me they appreciated it, and grumbling seemed to subside as everyone hunkered down and pushed towards the finish line.
Just recently, though, I was surprised when I overheard a colleague, in a team that is in a similar last-20%-grind scenario, recommending this three-year-old blog to a newer comrade and looking it up for them to read. Curious, I went back and had a re-read of it myself, and I found that what I thought was a point-in-time pep talk for a particular team, was actually a fairly general motivational piece.
So, whether youâre currently in a team slogging its way through the boring final stages of a project, or in the exciting first phases of something that will eventually end up in the same place, I hope you find this useful in granting you some perspective and grit for the long haul.
âThis work kinda sucks right nowâ
Hi folks,
Iâve had a number of people comment to me over the last month or two that [Project T] work âseems to be drying upâ or âwe seem to be just doing lots of little thingsâ.
I can understand where these sentiments are coming from. Over the last year, weâve builtâŚ
- a transaction account, integrated with our payments services;
- a phone app;
- integration with Xero;
- a new accounting system;
- an on-phone registration experience;
- an application processing and customer support web app;
- account provisioning, orchestrated across a distributed system;
- bank statements and other crucial regulatory reports and features;
- undoubtedly a whole bunch of other stuff Iâve forgotten.
But now, over the last couple of months, each team has been moving onto the huge mound of security remediation work we created for ourselves. Some of this work has been large and somewhat interesting, for example the principal propagation with [technology redacted] piques my interest. Other parts have been less glamorous, like preventing log files from having newlines or dodgy data injected into them. (You win some, you lose some, hey [team who did the log filtering, but also some of the most interesting early work]?)
At the same time, many of us have been tying up a lot of loose ends: pact tests, tools for Ops to configure Rabbit MQ or firewalls, build processes for iPhones, preparing SIT and Production environments with test data, and documentation. Documentation, for goodness sake! How un-Tyro of us.
Big Projects
I was chatting with my father-in-law about this âlarge projectâ of ours last weekend. He used to build roads. Big roads. He built the F3 from Sydney to Newcastle. (Not by himself of course.) He has some great stories about tricking magpies to come and sit on explosives just when they were going to blow them. But I digressâŚ
He said they had exactly the same circumstance when building freeways. At the start there was all kinds of interesting stuff going on: blowing up mountains, building bridges, levelling huge swathes of bushland and surfacing them with huge machines that were the latest technology.
As the project neared the end, though, it was the little things that started to become important. On-ramps to local roads were built, safety fences had to be erected, road signs put in place, paint laid down for the lines, and yes⌠documentation. The project tailed off with the little things, but theyâre still crucially important. Without onramps, you canât get on the road in the first place; without safety fences, the road is too risky in the infrequent but inevitable occurrence of an accident; without road signs, the road canât be navigated and drivers might drive at unsafe speeds; without that paint marking the lanes: bedlam! These arenât jobs anyone would write home about, but without each one being completed, not a single public car would be allowed to drive the road.
And so it is with our project. These âlittle thingsâ we have been focussed on for the last few months, and will continue to focus on for a month or two ahead, are no less important than those big things that have come before. Theyâre no less important because, without doing them, we have nothingâââwe will have no license and without a license we have no product.
A few of you may have been down this road before, but some may not. Some whoâve been at Tyro for a while may have forgotten what the end of a project feels like, because itâs rare for us to batch this much functionality into a single âreleaseâ. The fact is, the end of projects always has this runoff, and itâs often a hard slog and seems like itâs never going to end.
Iâve been through this experience personally a couple of times in recent years, having developed and released both an app on the App Store and a commercial Atlassian Stash [now Bitbucket Server] plugin. In both situations, developing the product was only 50â70% of the work, and the rest was âadminâ: creating icons, setting up accounts, writing marketing copy, making web sitesââânothing to do with the interesting coding problems that got me started in the first place. It was super hard to be motivated while doing this stuff, especially as I was spending my minuscule spare time on it. I literally considered giving up a number times with each project, but I kept going, spurred on by the idea of finishing something significant and seeing it released into the wild, in other peopleâs hands.
So what am I really writing about here?
Three things:
Firstly: What is a Software Engineer? Itâs more than a programmer, or a software developer. Itâs a T-shaped role with very long sleeves, and thatâs why we use that âEngineerâ title rather than other ones. We donât have architects or designers or DBAs or performance tuning gurus[1]âââthe software engineers do all that. At the same time, we donât have a security infrastructure team, or a security logging team, or an iPhone build maintenance team, because, as Software Engineers, we can stretch our arms to those skills as well. The role is broader than a full-stack developerâââitâs a technologist that does a lot of programming but can also do lots of other things. Sometimes those things are big and exciting, sometimes theyâre neither, but the people we hire here have the skills and the attitude to get stuff done that needs to be done. And youâre doing that, so well done.
Secondly: I think quite a few people are struggling to feel motivated about the work weâre doing right now. I get that. Iâve been there. Eight and a half years Iâve worked at Tyro now and Iâm not going to pretend that every single day has been a mind-blowing celebration of awesome coding fun. One of the great things about Tyro, though, is that, a lot of the time, the work is interesting enough that it really is self-motivating: you want to get in to work each day and start coding on that feature or solving that problem. Right now, a lot of you may not be feeling that.
So, how can you stay motivated? My suggestion is to focus on the end goal, which is not that far off. Think about the collective thrill weâll feel when the first pilot merchant deposits their hard-earned cash into a Tyro Account and then uses it to pay a bill through our app with just a PIN number and one tap. This is history in the making. Thatâs worth repeating: This is history in the making. Youâre a part of it. The work youâre on right now might not be stimulating your mind, but without it weâll never be able to step across that finish line and launch this awesome product that weâve spent the last year on. This is the last 500m of a marathon. Keep your chin up, look at the goal, and keep moving.
Thirdly: What comes next? Weâre clocking through this security work at the rate of one person-month per day. (Yes, between 6 [Project T] teams you do a month of work every day! It stresses me out!) What are we all going to do as we wrap this stuff up? Well, that is not up to me, and not entirely decided yet, but [the Head of Product] has lots of ideas for where to go next and is working right now on picking exactly what the next priorities are going to be. Heâs kindly offered to do another âstate of the [Project T]â session and share some of the ideas about where release 2 might head. Weâre going to do this at the end of this weekâs Tech Talk after lunch this Thursday.
tl;dr
⢠Youâre Software Engineers. You can do anything, big or small. Sometimes that means doing small stuff.⢠If the âwhatâ of your work sucks for a little while, try to focus on the âwhyâ and push ahead towards the goal. Stick in there. Itâll get better. (If it doesnât, tell us so we can fix that for you.)⢠[Project T] release 2 is right around the corner. Stay tuned.
Finally, if you want to talk about any of this, or about how youâre feeling about work, feel free to come and grab me for a chat any time.
By the way, we got across the finish line, and we got a banking license. We made history. But thatâs another story.
This story was first published on grahamlea.com
Image credits:
Tired man running, public domainâColleen is boredâ by Jason ScragzâExcavator Working to Remove the Road Base on Rim Rock Driveâ by NPSâVictorinox Swiss Army Knifeâ by James Case
[1] Since 2015, we have hired architects and DBAs, though delivery teams are still largely responsible for designing their own software and databases.