top of page
  • Writer's pictureSavita Ferguson

Setting Boundaries

I asked a teammate, someone I consider a friend, to suggest a blog topic. His reaction - "boundaries, you are always talking about boundaries". This post is dedicated to you bud.

I love boundaries for a couple reasons - they make autonomy possible in a corporate setting. They help different groups remain aligned. They even help with predictability and profitability..

But how?

You're reading my blog on building teams so I'm going to guess that you already read lots of literature on topics like how to be a more effective manager. Have you come across the ideas that autonomy, mastery and purpose are central to motivation; and motivation is the heart of great work and innovation?

Most managers know that they should be striving to give their employees autonomy, but autonomy is actually much more difficult to have in a corporate setting than one might hope - after all, we're by definition working toward a pre-defined goal that someone else dictates. Managers are constantly balancing between giving autonomy and giving clear direction to ensure we remain aligned. Establishing a framework for setting boundaries can help this.

"Team member, we need to build this feature, within this scope/time/cost budget". I listed all 3 aspects of the project management triangle there, but in practice you can fix max two and the third is where some measure of autonomy comes applies. Some teams choose to use appetites, fixing resources and time but allowing scope to be variable. Team members then have the ability to choose which scope fulfill the goal intended within the budgets set. I absolutely love this frame of working because it changes the conversation from 'when will it be done' to ' are we building the right thing'? That is a very useful frame of mind to keep your team in because the attention remains on the client and what we think is actually valuable to build. Of course a key aspect for getting this to work is making sure everyone understands clearly what the fundamental business goals are. Something like OKRs can work well when giving the team members that autonomy to design the solution for a problem, within a boundary set.

Setting appetite boundaries doesn't mean that you won't then know when things will be completed; in fact it's the opposite - you know when it will be done because the date was established up front. Not as an estimate, but a boundary. This allows you to more effectively plan the rest of activities around a product launch, or dependencies in case of an enablement team.

Setting cost budgets are important too in that it helps teams understand which options are on the table, like the classic "build vs buy" question - can we afford to pay for a SAAS product or should we build this feature ourselves. Remember also that costs are complex and you're not just thinking about the cost to build a particular feature, but to keep it running as well. Consider if there are boundaries to set about how much AWS spend is acceptable for example; or how much maintenance can cost us in the future.

There are other important boundaries to consider - security & quality. Some teams set boundaries here by establishing definition of done standards for things like code coverage. But it's important to recognize that even security and quality standards are actually a little bit flexible depending on the setting that the team works in. Financial organizations are by nature very very conservative when it comes to things like security as any vulnerability have huge financial implications. Similarly medical device companies or airplane software need to maintain high quality standards as any defects can lead to loss of life. Depending on the kind of organization you work for, there may be other established boundaries - perhaps contractually established in things like SLAs. These kinds of boundaries need to be clear and backed up with established processes.

But it's important to understand that every company has a certain risk tolerance threshold. They might be willing to skimp a little on quality in favor of expediency and that is entirely a valid choice. Help your team members understand where your company falls on this spectrum - what exactly do you consider important?

When boundaries are set clearly, managers are then free to focus more on other tasks because they know that the team is already on alert for those things which they would've spent their time to ensure - that the project comes in on time and in budget. That accountability / oversight responsibility now belongs to the team and you're one step closer to having a self organizing one.

If you've ever had the problem where an engineering team keeps going and going and it feels like they should be able to stop but they don't agree; there is a mismatch of expectations - and unclear boundaries. Help the team members understand how much this project is worth to the business and also how much they are allowed to spend on it before the ROI becomes negative.

Resources: Drive by Dan Pink

Measure what Matters by John Doerr

Shape Up by Ryan Singer

4 views0 comments

Recent Posts

See All


Post: Blog2_Post
bottom of page