A character drawing a line around themselves with a neon yellow highlighter, a virus spread prevention, personal boundaries

Setting work boundaries allows team members to work their best

“We jump through hoops for you” was our long standing catchphrase here at Standard Beagle, however looking back over the past 5 years, it’s something that led us all to the brink of burnout.

We were so hyper-focused on jumping through hoops, we didn’t ever stop and look at what that sort of reactionary pace was having on our team and our productivity as a whole. Don’t get me wrong, we still want the very best for our clients, however now we focus on setting boundaries and expectations at all points of a project, and it has led us to work smarter and have higher quality of work.

So, how did we start setting boundaries?

The first rule we implemented was pretty simple – no Friday deployments. This is not a new concept with software companies, however it did take a shift in our process and our client communications. Why did we do this? Because if something goes wrong, we didn’t want to have to stress out and work overtime on Saturday and Sunday.

Secondly, we begin setting firm expectations with clients. If a feature needed to launch, or content edits needed to be made on an email, we asked for the final proof a day before deployment. This insures our team has time to fully test and work out any system issues, and also ensures we are not rushing in at the last minute to make any changes that could negatively affect the end product.

This is not saying that setting these boundaries has not been a major adjustment for our team, and our clients. There have been many times when I have broken these rules, such as trying to make last-minute changes before hopping on a plane, or making edits at 9 PM at night because a client needs something to go out at a certain time the next day, and honestly it’s not when I am doing my best work. Stress affects all of our brains differently, and being in crisis mode only opens us up to errors that we normally wouldn’t make. It’s instances like this that our team has had to make those hard choices to tell the client no.

We know that having our process in place insurers are in product is the best quality we can put out. In those moments that we deviate from our process, are those times that mistakes can occur.

So having those boundaries and the ability to say no to a clients has not only made sure our own code is tested and bug free, but that our team is not burning the candles at both ends and trying to do more then we possibly can do.

Similar Posts