What I Learned Helping Teams Scale

Teams don’t need someone yelling feedback from the sidelines. They need someone running ahead and building the path.

Originally published on Medium.com at What I Learned Helping Teams Scale

'Paving the Way' Image Created by Julie Fleischer Using Canva

I enjoy that liminal space organizations occupy right after their initial successes and as they are starting to scale.

These are the teams I tend to run towards, chaos and all, to help them create enough structure for success.

While every team is unique with their own specific chaos and own distinctive needs for structure, I have noticed recurring patterns.

Namely, by the time teams start to scale, they’ve also usually adopted some habits they won’t be able to sustain: working crazy hours, leaning heavily on key talent for output, and, especially, doing too much due to the perceived high cost of taking the time to discern which actions truly move the ball forward.

These habits can be helpful, sometimes they’re actually necessary, to get those initial wins. But, they aren’t how you build a company or team with the stamina to last.

This is the space I gravitate towards. I can’t resist the delightful and perplexing puzzle of figuring out how to establish sustainable practices that enable teams to run faster.

I have enthusiastically said yes to job offers where I heard during interviews the team “is a pressure cooker where things are behind” or “needs way more structure” or “has leaders that will need a lot of your coaching”.

That said, what I frequently found was that the skills that some of my interviewers told me I would need on the job weren’t the same ones that I leaned on for success.

I would often be told that the team had so many problems, I would need to be good at “telling people what to do” and “standing my ground”. I’ve never found those to be the most effective skills when driving change. What I have found is that empathy and listening help ensure that whatever improvements I roll out are things people naturally want to do without me needing to tell them. And I have found that the ability to pivot or modify my approach based on new data is more effective than doggedly standing by an outdated opinion.

More than that, I have found that, even if my title isn’t “Engineer” but is actually “Engineering Manager” or “Technical Program Manager” or “Product Manager”, having enough engineering expertise to understand what the team is delivering and how they are delivering it as well as the technical basics of my role, including management, program / product management best practices, is the best way to ensure I put in place solutions with staying power.

Teams Need Someone Who Can Sprint with Them

When teams are running fast, they need someone who can start sprinting alongside them and then start paving the path in front of them so the team can run even faster.

This means anyone who wants to help the team needs to be running just as fast as everyone else. They can’t be standing on the sidelines giving orders. They also can’t create a fully paved path in a spot where the team isn’t headed.

What do I mean by this?

Standing on the sidelines looks something like telling a team that appears to be struggling with scope: “Your requirements are a mess. You don’t even know what you’re building.” In a talented team that has had initial successes, if this is a true blocker, then they already know this. They just don’t have the bandwidth or, possibly, the skillset to solve it. Telling them it is a problem, even if you give them pointers on how to address it, doesn’t get them any closer to a solution.

Creating a fully paved path on a part of the trail the team isn’t headed looks something like creating an entirely new “requirements management system” and putting all the team’s requirements in it without first understanding the team’s workflows or, worse, without truly understanding the team’s requirements. If you create a system without understanding the team’s needs or how they are likely to use it, the likelihood of adoption is low regardless of how well one “stands their ground” or “tells people what to do”.

So, how do you avoid staying on the sidelines or creating a path that will never be run on?

Solve a Pain Point the Team Recognizes

Every team I have joined that is running fast has many pain points that they clearly recognize need to be solved. In fact, I’ve found I can usually identify the majority of these during the interview process. What doesn’t come out during the interview process usually comes out within the first week or so of being on the job.

It usually happens that I’ll be sitting in a meeting and get a flurry of IMs. For example, in a meeting discussing a new feature, I could get something like:

From the engineers: “They’re strong-arming us into adding features we don’t have time for again.”

From the customer representatives: “They’re saying ‘no’ to features our customers need. They don’t have a customer-mindset.”

These are the signals towards the problems that need to be solved first. In this case just mentioned, the team needed a better, more transparent and realistic, way to assess new customer features against existing workload and make optimal decisions.

Connecting the Dots Back to Pain Points

In the previous example, rolling out a solution that would be adopted involved connecting the dots for the engineers on how a more robust requirements and change control process would help them manage their workload as well as connecting the dots for customer representatives on how a trade-off discussion was in the customer’s best interest because it ensured realistic plans not empty promises.

If you’re trying to roll out a solution to a problem the team doesn’t yet recognize as a pain point, you may need to dig deeper to see what pain points they do recognize. What may look to you like a struggle with requirements management may look to the team like they are always delivering late because someone identifies a feature that was “supposed to be in” the product. If so, the “requirements management” solution needs to have as its primary goal a path to get early alignment on release contents so that last-minute surprises don’t appear. Once those dots are connected for the team, it is much easier to get them to embrace a process that provides clearer requirements.

Don’t Be Afraid to Be Hands-On or to Be Simple

Finally, sprinting alongside and then ahead of the team to create the path means you’re a builder, just like the team. This is especially true for small, nimble startup teams where everyone is already wearing many hats.

We already mentioned that a team that needs a requirements management system but doesn’t have it likely doesn’t have the bandwidth or skillset to create it. This is where a leader who can be hands-on and create the initial system, populate it, and role-model using it, can drive change quickly.

When you’re the one owning the system, you’re also less likely to over-engineer complexity into the system. The last thing a scaling team needs is unnecessary complexity. A spreadsheet may be a perfectly fine requirements management system for the first few years of a team’s life. Even when using a more complex requirements management database, not every field may be needed. Designing a system at the right level of complexity for the team’s needs helps ensure the team will embrace, rather than reject, the tool.

Creating the Shift

When you’re able to identify the key pain points the team sees, design a lightweight solution that meets their needs, and then connect the dots for your stakeholders on how the solution you created addresses the pain points they see, you can feel the shift. Instead of resistance, you tend to get encouragement. More than that, because you’re sprinting with the team as fast as the team, you’re unequivocally part of the team. You’re not on the sidelines and not on the bench.

And, this, more than anything, is why I run towards the chaos. The chance to get on that rocket ship just as it’s about to take off is hard to pass up. More than that, getting on the ship as a structure-creator gives you a chance to help a team shift the habits that helped them create the rocket ship (the long hours, the heroics, the “doing it all”) into the habits that will help that rocket ship survive the, hopefully, multi-year journey it’s about to embark on.