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 . 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. work 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 for the long haul. grit “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.
