Waiting too long to organize the team

I joined User Interviews as the 6th employee and 1st Product hire. This is somewhat unusual. A founder will usually play that role in such a small team. At UI, the founders were focused on building the network so the business could exist. You know, the cold start problem and all that. It takes a lot of hustle to kick start something that needs both supply and demand.

In any case, I was fortunate to be brought in to build the product and the team. I was on my own for the first year and change. This was fun and chaotic. I got (had?) to do a bit of everything. Research, strategy, feature specs, mocks, analysis, etc. I’d go from talking about high level goals to making a quick prototype to who knows what.

I share this because it gave me a ton of context on everything. There wasn’t a huge need for a lot of communication and coordination. It was me and a few engineers making things happen. It wasn’t perfect, of course. The app crashed every Wednesday for a few weeks in a row until we figured out why. I broke every email in production for 3 hours trying to run an experiment.

The point is when you’re working in a small, aligned team with knowledge of the whole experience then you can do what someone has described to me as “perfect prioritization.” You can move really seamlessly across opportunity areas. Whatever you believe will have the highest impact can become the thing you do next.

This was sort of addicting for me. “Ok, we’ll make this improvement to how we match researchers and participants… then we’ll add in support for custom branding… and then…”

The mistake was that I tried to keep us operating this way even as we grew into having multiple product teams.

I kept convincing myself that we could juggle the context switching. I did not recognize how challenging it is for new team members to yo-yo around like that.

Every time they start to feel oriented and effective in an area, you ask them to switch. And without excellent context sharing on why they keep shifting their focus to new areas, it feels like thrashing. You burn productivity and morale.

I thought I could make it work and I was reluctant to accept the trade-offs that come with having a team focus on a consistent outcome. This was a bad combo. I kept delaying making changes.

Thankfully, I ended up speaking to Alex Powell at Greenhouse. Greenhouse has a product that is complex in ways similar to UI so I was hoping I could pick his brain about challenges they encountered as they scaled.

The first thing he said was that they waited too long to organize their teams in a way that gave them coherent ownership of a strategic area. Ok, nodding. He shared that in retrospect, the biggest tell was their teams giving themselves random names – “the awesome squad” or whatever. They don’t know what they owned so they couldn’t refer to themselves in that sort of way.

At that time, we had two teams going by “JeJo” and “Gem”… so yea, this hit home.

Not long after, I started having conversations with the leadership team on how we should organize our teams in a more coherent way. This was productive! It forced us to make some tough choices and stop pretending that we could jump on any exciting opportunity that came up. We aligned on the top strategic areas and figured out the team structure to invest in them.

Spoiler – I also made a few mistakes in the first crack at organizing the teams around these areas and how we set their outcomes but that is for a future post.

To wrap this up, here is what I could do differently if I could do it all over again.

• The moment we had enough people for more than 1 team (something like 2 PMs, 2 PDs, 6-8 Engineers), I’d make sure 1 team is given a strategic area to own to introduce that approach.

• I would keep the other team flexing from priority to priority in the immediate term to ease the transition.

• But I’d make sure that the people staffed on that flex team are open to working in that way for a period of time. Some like it more than others.

• Estimate how many teams we will need to have “enough” surface coverage on the major experiences in the app to provide a clearer target for how the team evolves as it continues to expand.

And where are we now? We’re seeing the benefits of organizing this way. We have 4 pods (PM, PD, TL, 4 Engineers, Analyst – with a few open roles if this sounds up your alley). We also have 2 engineers allocated for more ad-hoc, internal needs to limit distractions for the pods.

Here are some of the highlights.

• Each team has developed a much richer, deeper understanding in their areas. It takes time to familiarize yourself customer needs, technical capabilities, etc. Breadth is great in the early days so you can move fast. But depth allows you to set better goals and deliver more value.

• It takes time to have an impact in an area too. By creating consistency, we’re seeing teams build up momentum month over month. Their hypotheses, experiments, and solutions all get sharper over time.

• The rest of the company has grown a lot too (>90 people!). Now it is easier for everyone to understand who focuses on what and who they should go to with questions, ideas, etc.

These lessons learned are rather specific to a very, very early stage team becoming slightly more mature but hopefully they are valuable in some way to your situation.

Drop a comment below. I’ll respond to all of them.

– JH ✌️