Scaling Your Organization and Operations Together

Because every organization has unique challenges, there is no defacto one-size-fits-all approach when it comes to successfully growing and scaling your company. If there was, turning a startup into a unicorn would be much less stunning and rare. There would be unicorns everywhere, and it would be nothing out of the ordinary to see sharp, spiraling horns in the streets every single day.

Yet billion-dollar companies have been built with Shortcut. We love our long-term relationships with customers, and love getting to watch great companies scale into greater companies.

Generally, we try to stay out of your way, so that you can focus on planning, building, and shipping software instead of noticing your project management tool (that’s us). But we’re also here to help, and we’ve captured some key trends around scaling your organization and operations together that may be useful to you.

The process may feel like a long and winding road, but, like unicorns, shortcuts also exist. This blog will explore some of these shortcuts and other thoughts on how to scale smartly based on our data-driven insights that we’ve gained by helping our customers grow right alongside us.

On team structure

Great products are not built by individuals; they are built by teams, and these teams have an organizational structure. As your company’s needs evolve over time, you may try out several different iterations of your team structure. Starting out, your company may have just a couple of people and a few individual contributors working together toward the same mission. As more individual contributor roles are added, it’s common to form teams to focus efforts around a particular feature, function, KPI, or other goal.

As more teams are formed, they are assembled into what we call “team groups”, where each team is focused on a slice of a large and complex problem space or business opportunity, while collectively, all the teams in the group share the same high level mission and goals.

When your company expands further, especially if you add multiple brands or business lines, those team groups are typically collected into what we call “portfolios”. In this scenario, each portfolio has its own strategy and may or may not share team members with other portfolios within the company.

While every company will have their own terminology and variations on this structure, we have found that this is a good generalization to help us understand our users and predict your needs as you grow. Shortcut currently supports teams of up to around 1000 users, with many of them being individual contributors or leaders within the team or team group layers.

On teams using Teams

Earlier this year, we rolled out our Teams feature. In Shortcut, a Team is made up of a group of users and the Stories and Epics and Iterations they’re working on. By providing this thread between people, their work, and their processes, the Teams feature gives an organization its operational foundation.

What we’ve seen is that, unsurprisingly, larger companies tend to create more Teams than smaller companies. We see a nice step progression in the average number of Teams per organization as their size increases.

As you can see from the data, as a company scales from 1-25 users up to around 125 users, the average team size also scales.

Below, you can see that for each org segment up to the 100-125 segment, the average team size continues to grow. After that, the average team size appears to level off.

We believe that companies in this first group of segments are rallying their limited resources around a core set of problems. And as they are able to scale their company size by hiring more people, they are also scaling their team size, devoting more team members to that core set of problems.

Once an organization reaches over 100 users, we’re seeing the average Team size plateau as the number of overall Teams continues to increase. This suggests that as organizations continue to hire, rather than continuing to expand their existing Teams, at this point they are creating new Teams to focus on new problems, or to break down an existing problem set into smaller chunks, allowing Teams to be more specialized.

This is an important insight, because it quantifies what we hear in user interviews, which is that smaller orgs have rapidly changing needs and challenges related to fast growth that often outruns their operational support structures.

On reorganization

It’s common to see an organization set up their Shortcut account one way, and as they grow, to see them reorganize their Stories, Epics, Iterations, Teams, Workflows, Backlogs, Roadmaps, and more into new formats that match their scaling organizational structures.

If you are in a small, rapidly growing organization, and it feels like every few quarters you’re changing your organizational structures, your processes, and in general lots of things feel like they’re in flux, just know that you’re not alone. It’s actually a pretty common situation.

On work hierarchy

Organizations will add work hierarchy structures as their work becomes more complex and focused on long-term planning. When we think about work hierarchy here at Shortcut, we typically think about that work in 3 phases.

The Strategy Phase is where product, design, and engineering visions all come together to make up the overall company vision: i.e what do we want to build, who do we want to build it for, how do we want to build it, and who do we want to be in the market?

The Planning Phase is where that vision is broken down into objectives - usually based on some kind of OKR or KPI or other quantifiable goal. Ideas are then packaged into initiatives that the team feels will achieve the objectives, and then those initiatives are packaged into public releases.

The Development Phase is where work gets broken down into Stories and Tasks and sometimes grouped together into Epics.

While there are lots of different approaches and variations, this is the model that we’ve found best generalizes how our users think about and organize their work.

Of course, it would be fantastic if, starting out, you knew everything already that you would come to know later when starting out, if your plans and strategies never had to be adjusted, if you could follow a linear course from strategy to planning to development with little deviation, but this usually doesn’t happen. It’s very rare that an organization will start out with their full structure in place.

More commonly, organizations actually start in the Development Phase, rather than the Planning Phase or Strategy Phase, with just stories to define their work. As the work becomes more complex, those stories are then grouped into Epics. At this point there is a company vision, but this vision may be evolving quickly as you get input from your users and the market. All of this makes long-term planning and prioritization for feature development difficult. What we’ve found is that when the vision becomes more stable over time, that’s when long-term planning actually starts.

Once you have a need for long-term planning, you’ll start to need work structures like objectives and initiatives to plan, organize, and report back on the progress of that work. You’ll also need a way of tracking what will be included in a public release event in order to share that work, and the vision behind it, with your users. Finally, operational roles become critical when you want to unify processes and rituals across multiple teams.

On rituals & processes

As an organization scales, collaboration and communication become more complex and more important, and Rituals and Processes are meant to streamline this.

You may have faced a lot of resistance to implementing new processes for your team or company, and this is common. At one time or another, haven’t we all felt the drag of a poorly designed process that sucks up productivity more than it helps facilitate collaboration and communication?

With that in mind, here are some tips in thinking about “process”:

• A process is simply a social contract outlining how you want to work together.  It defines roles and responsibilities for who will do what, and when. And it outlines how we’ll share work with others.
  
• Rituals and processes can be very simple or complex, all depending on the needs of your team or organization.  What’s important is that everyone has an understanding of what problem a process is meant to solve and what goal it’s meant to achieve, and that everyone has input into the definition of that process.
  
• Iterate on your processes as your team or company size grows. As you scale the number of people and teams in a process, the underlying needs of those people and teams also change. And if the underlying need has changed, then a process may no longer be fulfilling its function.
  
• Apply product development principles to process development. The formula is not all that different. Just like when building a new feature, before you define any new process, it’s important to define what the goals are. What problem is the process looking to solve, and for whom? Does everyone agree that the problem is worthy of devoting resources to in the first place?
  
• Once you’ve completed the problem identification and validation step, you can continue with steps like brainstorming solutions, solution validation, and implementing that solution— possibly even A/B testing that solution with some segment of your organization. Then you can track how effective the new process is in solving the stated problem, getting feedback from people involved, and iterating as needed.  

On adding research & development operations

We’ve seen this vary quite a bit from company to company. But one leading indicator is that operational roles start to become critical at the point where you start to face challenges due to the fact that every team in your organization is following a different operational model.

Not having a shared operational model can make onboarding more difficult for people new to the company as well as for team members who change teams. It’s also challenging for those in roles like marketing, sales, and customer experience, who work across multiple teams, and have to interact with each team in different ways. This creates an administrative and operational burden for those support roles.

You might not be ready to have a full-time dedicated operations team right away. But if you’re struggling with organization-wide operations, it’s probably time to specifically call out R&D operations in the job descriptions for some level of design, product, and engineering leadership.

It’s great to watch our customers grow and to grow alongside you

Shortcut is built by our software team for your software team. Way back when we were founded in 2015, only a few of us worked at Shortcut. Many of our customers in those early days were also part of small teams. It’s been cool to scale our own company as you scale yours.

To engage in more meaningful conversations, share custom solutions, and learn best practices from your peers and the Shortcut team, check out our community forums. To get started with a free trial, sign up here.