Team Structure

Over the years, I've tinkered with countless dev team structures, and this is the approach that I like the best. The core concept is this: attempt to replicate the scrappy effectiveness of a company's founding team, even as the org scales dramatically in size.

It's a lofty goal, but achievable; I've done it. And yes, there are challenges as we move through the phases, but they're addressable.

In the Earliest Days

When our company is first founded, there's no notable structure. We know we can't do everything, so we pick the highest-leverage efforts, then divide and conquer. Our technical founding team does the best we can to balance front-end development, back-end development, product management (putting ourselves in the users' shoes) and user experience design. We're not the best at any of these domains, but we do what we can with what we have.

In the Establishing Phase

We are a single, small team of 8. Two of us are technical cofounders, myself occupying the VP Eng role, and the other occupying the CTO role.

We consider these peer positions:

• CTO is tech first, people second
• VP Eng is people first, tech second

The rest of the dev team is composed of mostly-senior talent that came in via my personal network. These are trusted engineers I've worked with in the past.

Besides the CTO, every engineer reports to me:

Full-Stack vs Specialized Devs

This small team needs to be able to deliver on both the front and back end; for maximum flexibility, I'd love for these to be full-stack (or at least full-stack-willing) devs, but I'm ok if we have at least one specialist in each domain.

Design, Engineering, and Product

I believe that the best products are built by balancing the expertise of designers, engineers, and product managers. In this Establishing Phase, we have a designer and a product manager who do NOT report to me (they’re probably somewhere on the marketing team), but we work closely with them on a daily basis.

Stay in your Lane?

Although other experts say that a Product Manager (aka Product, aka PM) is responsible for the WHY and the WHAT, Engineering and Design for the HOW, and the combination of all for the WHEN...I'm gonna weigh in AGAINST that hard line.

While it's a reasonable place to start, I champion the notion that good ideas can come from anywhere. From anyone. Since we are vocal and kind, we listen and consider feature concepts, go-to-market ideas, and implementation approaches from everyone.

Quality Assurance / Engineering

Wait...I haven't hired any QA (Quality Assurance/Quality Engineers) onto the team?

Not at this stage, no. Everyone pitches in to test the software we're building.

In the Growing Phase and Beyond

I seek to maintain our scrappy effectiveness even as our team, our product suite, and our demanding customer base grows. Here's how we evolve the team structure.