How Shifting the Frequency of Development Updates Drastically Improved My Business
Multiple times over the past couple years, I’ve found myself contemplating quitting web development completely. I was regularly getting burned out and thought maybe walking away was the answer. I initially tried to focus on different aspects of my business processes, convinced my problem was caused by not using the right tools or could be course corrected if I just tried to automate more things.
Don’t get me wrong, I definitely had areas I needed to improve in my business (and I did!) No matter what changes I was making though, even if they yielded huge improvements somewhere in my business, ultimately it felt like a bandaid before I was quickly back to feeling stressed and unhappy with my work as a whole.
To see if there was something I was missing at the root of my work issues, I decided to once again get serious about tracking my entire work day for a few weeks.
I’ve time tracked before, but very rarely was I tracking my entire day, just something like a specific task for a project being billed hourly.
I had attempted time tracking my full work week a couple years back but this was around when COVID-19 first exploded in 2020. Pro tip: time tracking insights may be different or missed altogether if you pick the start of a global pandemic to attempt to closely examine where your time is being spent. My days weren’t typical when I had last looked so, while the data did identify a few things, it just wasn’t a good representation of where my time went if I was balancing a completely full workload.
With desperation, determination, and a completely full schedule, I put aside my utter loathing for time tracking and monitored my workweek — every day, all day — for a couple consecutive weeks. Then, I took a look at what I found.
It was a giant arrow pointing at what might be behind a lot of my issues: my time was being overwhelmingly spent not on coding, but on writing & responding to development updates for clients.
The best of intentions gone wrong
From the moment I started my career as a developer, it was easy to see there were a lot of bad actors in the space. There were developers who would straight up disappear in a project timeline or overpromise and underdeliver. It wasn’t uncommon for me to work with clients who were coming to the table with their own bad development experiences. I knew I wanted to set myself apart from this type of developer as fast as humanly possible. Quite simply, I wanted to be the developer who did what they said they were going to do when they say they were going to do it.
So I completely overshot and overcompensated, deciding I would update clients all the time during a build. I was sending updates to clients at minimum 3 times a week, sometimes more often. This wasn’t a huge issue when I was early in my career with 1-2 projects simultaneously, but as my demand grew, it had become all-consuming and unsustainable.
In reflecting, this frequency of updates had clearly been a major source of stress for awhile. While the overall timeline of any project was never in threat, delivering updates at a daily, or near-daily, frequency felt like I had a million mini-deadlines on my plate every moment. I had trained my clients to expect updates constantly so if anything unexpected happened in my day, it was insanely stressful because of this need to always be turning around forward motion across the board.
It was relentless and, looking back, incredibly easy to see why I was repeatedly burning out.
How long do frequent updates REALLY take?
Some may be thinking, “C’mon, how much time can writing a simple development update really take?” It sounds like it should be simple enough: just plug in the links to view some progress and fire off an email. Boom, done.
Development updates aren’t just a matter of quickly sharing new features or layouts developed; I also need to clearly spell out features not yet done or anything partially developed to where it may not be fully functional. If I don’t take the time to do this, I frequently, and understandably, get met with an email to clarify why something isn’t there or isn’t working. Sometimes even if I DO these things, I’m met with an email to clarify why something isn’t there or isn’t yet working.
This area is also an automation dead zone because there is no way to magically assemble individualized updates of a build in-progress. I’ve tested client portals (no one logged in) and a ton of different project management tools (tended to introduce more questions, along with varying levels of willingness to use the tools so then I was both using the tool AND still emailing.)
With multiple projects at varying stages of development and communicating with clients with different technical skillsets, I was essentially manually doing detailed breakdowns of every single project I had with these updates.
Email replies don’t write themselves either
If it was just the time spent to write the original updates, it would be one thing. However, these time tracking insights also made me painfully aware of how much time was also consumed responding to any replies from a client stemming from an update.
This is not the fault of any of the amazing clients I get to work with as it’s only natural to have questions during a build or feedback on progress. However, what was problematic is I was putting myself in a position to be constantly fielding this on top of actually coding my projects.
To do development well, it takes focus. The tiniest of errors can take down an entire site. I was not building a communication schedule that promoted focus. To make matters worse, when my focus would get broken, which was often, I found myself prone to losing even more time to other focus stealers before I could finally get back on track, whether it was a social network, Slack, or something else.
Figuring out a solution
Clearly, something had to change. I knew I didn’t want to completely eliminate development updates during a build and go dark for the entire development timeline. I explored a couple different frequencies of development updates, with weekly seeming to be closest to feeling right but I still was getting pings from clients during the week asking how a project was going, what was I doing next, etc.
I took my situation to Jennifer Bourn, who runs Profitable Project Plan (which is amazing and I cannot recommend enough), essentially explaining that I was drowning in updates and the issues I was experiencing when shifting to weekly updates. She suggested adding in a Monday update explaining where development would be focused in the upcoming week and then the Friday update would complement that, sharing the links to view those completed pieces.
This was the missing piece that made the change work for me. The Monday/Friday update bookending of the work week was a big winner as soon as I started rolling it out. Clients were happy, as they were still getting regular updates and knew what was on tap next. They might not be hearing from me every day, but they always knew what I was working on. The Monday/Friday duo also set up a schedule that had me constantly reinforcing the idea that I am a reliable development partner by delivering exactly what I said I would, week after week.
Reaping the benefits
I could ramble on for days about all the differences this shift has made in my business, but the biggest is definitely the drastic increase in the amount of focused coding time I have per week. My productivity each week has sky rocketed and that nets benefits for every single one of my clients and their project timelines.
What my workweek looks like feels more in my control and more pliable if something unexpected pops up. There is greater flexibility in my approach and I’ve found that key to my overall happiness level. I want to be able to get into the flow state on a project and have the freedom to stay there versus feeling like I have no choice but to shift gears so I have something new the next day for every single client. There’s breathing room.
My clients are always in the loop on their build and I now have a starting point every week on each project and an end point for the week on the project and how I get from A to B is completely in my court. I need it to be in my court. And for the first time in what feels like a long time, I actually feel like I want to keep playing the game.
Have a design you need developed in WordPress or Shopify and want to get a piece of this Monday/Friday update action? Every Monday, you’ll get a breakdown of everything I’m coding in the upcoming week. Every Friday, you’ll get links to view exactly that. No wondering what’s going on with a project, but visible progress throughout the entire development timeline. Let’s build something together!
Also, massive thanks to Jennifer Bourn for the assist solving this issue. If you are a designer and/or developer looking to improve your work life and dig in deep on your business processes, check out Profitable Project Plan.