What’s the Right Team Structure?

As I often note on this blog, I’m a rookie CEO who’s gotten very lucky. Much of the time, I wish I had more experience in other corporate and startup environments, so I’d better know what works and what doesn’t. I rely on other team members and a lot of outside advice for that, and I’ve been thinking that maybe, I can also ask on this blog.

From the comments both here and via external social communities, it seems that many folks who read this have a lot of experience, and I’d love to lean on you for some advice, suggestions and horror stories if you’ve got ’em.

We’re facing two challenges at Moz:

  1. In order to grow the team, we need additional layers of management, but I’m worried about creating tension when there’s a large distance between the c-level and individual contributors. Having 20 or 30 people report to one person, however, is totally untenable.
  2. I hate the idea that the only way to “move up” at a company is to enter the field of management and direct the efforts of others. Individual contributors should have equally salient ways to earn higher recognition, title (I know, titles are a tough issue, but they matter a lot to some people, particularly when thinking about one’s next gig), and compensation.

For #1, I came up with a really rough, probably not-ideal straw man structure that I’ve illustrated (poorly) below:


This is all wrong, actually. A better (though still not perfect) diagram is below:

This might support a team of several hundred, and is pretty classic and familiar, which probably means it has serious flaws. I’m just not smart/experienced enough to know what those are. In the shorter term (while we’re scaling from 80-200, we could likely remove at least one of those levels).

For #2, I made another straw man concept:

These might not be the right titles, and this might be the wrong way to go about it, but we want to make sure there’s a way for an engineer who loves coding or a marketer who loves working directly with the community or a product manager who loves specs & wireframing to gain expertise, advance their skill and have that recognized and rewarded just as much as someone who moves up in management responsibility.

I’d love your thoughts, feedback, suggestions and stories of what you’ve seen succeed and fail on these two fronts. I totally appreciate it 🙂

p.s. Mozzers, if you’re reading, your ideas are more than welcome here, too! I promise we’ll be really diligent and consider as many angles as we can before trialing anything.

UPDATE: I modified the management diagram, as I had it totally backward. Thanks to Judd at GNIP for the catch.