# How Do You Structure an Engineering Team? | LinearB Blog

> An engineering team structure is about finding a way to provide autonomy, mastery, and purpose to its team members. Let’s explore more.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._

[Blog](https://linearb.io/blog)

/

How Do You Structure an Engineering Team?

# How Do You Structure an Engineering Team?

![Photo of Mario Fernandez](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/logo-mark-lg?_a=BAVMn6ID0)

By [Mario Fernandez](https://linearb.io/blog/engineering-team-structure#mario-fernandez)

|

July 13, 2021

![structure_office_55d48cb90f](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/structure_office_55d48cb90f?_a=BAVMn6ID0)

In my previous piece, I talked about choosing an [engineering organizational structure](https://linearb.io/blog/engineering-organizational-structure/). Once you have this structure in place, the internal structure of the engineering teams comes next. What does a high-performing engineering team look like?

Organization and team building are similar but not the same. The design of an organization focuses on the interactions between teams and high-level areas of ownership, whereas building a team involves thinking about the interactions of individual contributors. In this post, I want to discuss how to enhance a scalable organization model with agile, cross-functional teams that practice [continuous delivery](https://continuousdelivery.com/).

![linearb pull quote](https://assets.linearb.io/uploads/LinearB-3.png)

## Think Products, Not Projects

A common mistake in some older approaches is treating teams as fungible. Management decides to build something, forms a team for half a year, then disbands it. This approach doesn’t work for long-lived software applications. [Agile development](https://en.wikipedia.org/wiki/Agile%5Fsoftware%5Fdevelopment) relies on constant iteration. A project-based team won’t have enough time to gel. With little cohesion, it will struggle.

[Product thinking](https://www.interaction-design.org/literature/topics/product-thinking) has replaced this approach. Long-term teams based around products (or at least [streams of work](https://teamtopologies.com/)) enable the people working on it to iterate and collaborate effectively. Over time, they acquire a deep knowledge of their domain to the point where they are best equipped to make decisions about the product.

## Agile Cross-Functional Teams

A cross-functional setup formed around a defined product is the most effective way of building software development teams. Before getting into team composition details, let’s mention three principles. They are an excellent guide to forming this kind of team based on the research of Daniel H. Pink, compiled in his book _[Drive](https://www.danpink.com/books/drive/)_:

* _Autonomy_. To be effective, a team has to be autonomous. Dependencies are the blight of high-speed delivery. Empowered contributors with ownership over their work are much more likely to be effective than somebody who is just there to execute other’s people ideas.
* _Mastery_. The team needs all the necessary skills to deliver their product. If the team misses some skills, a culture of continuous improvement helps cover the gaps.
* _Purpose_. Knowing the big picture is crucial to making good decisions. Clear, measurable, team-wide goals prevent unnecessary politics. Additionally, people like to know the context and reasoning behind the goals and the decisions of the organization.

Keep these principles in your mind at all times as they’ll guide you toward building teams that require little oversight.

## Team Composition

First of all, teams can’t be too big. Fred Brooks wrote about this in _[The Mythical Man-Month](https://en.wikipedia.org/wiki/The%5FMythical%5FMan-Month)_ as early as 1975\. Pairwise interactions grow quadratically with the number of team members to the point where communication degrades. As a rule of thumb, five to eleven people per team is a reasonable number.

You need all the necessary roles in a team if you want it to be cross-functional. Here are some typical ones:

* Developer
* Product owner
* Business analyst
* UX
* QA specialist

This list is not comprehensive because it greatly depends on the mission of the team and the type of work they tackle.

What about more specialized roles? For instance, infrastructure experts, security specialists, or data scientists. A team might not need such people full-time, but some of their skills are surely needed occasionally. In this case, my recommendation is to treat them as advisors. These folks provide advice and enablement so the team can integrate the related cross-functional requirements in their flow.

Involving external parties is a sensible idea. However, it’s important to note that a team shouldn’t relinquish the ownership of its product. Having an external security team that tells the team what they can or can’t do is a common anti-pattern. While their advice is invaluable, you shouldn’t let them be gatekeepers.

## Generalists Vs Specialists

Did you notice that I said “developers?” No mention of front end or back end whatsoever. I’m a strong believer in having full-stack engineers on a team. Users don’t care about the division anyhow. It’s my experience that separating developers strictly across technologies encourages siloing. Ensuring that everybody is working on the most impactful chunk of work is much harder if parts of the product are only known to one of two people, a problem known as the [bus factor](https://en.wikipedia.org/wiki/Bus%5Ffactor).

Some people think the full-stack mindset means every developer has to know everything. That’s not the point! It’s pretty much impossible anyway. Modern software engineering has so many moving parts that you can’t hope to learn them all. People tend to be more familiar with or more interested in certain parts, and that’s fine. Aim to be [T-shaped](https://en.wikipedia.org/wiki/T-shaped%5Fskills).

This is a controversial point in some organizations, so be prepared to make compromises. Don’t give up the fight to avoid and break silos.

## Technological Leadership of an Agile Team

How do you handle the role of a technical leader of an autonomous team? Funny you should ask. I recently wrote an[ article](https://linearb.io/blog/software-team-lead-responsibilities/) about that. There’s much to say about this topic, but I’ll limit myself to three points:

* Leadership isn’t restricted to a role. Everybody can and should show leadership on a team. Taking ownership of parts of the delivery is a perfect example of leadership.
* Having said that, bringing a person to the team to fill a dedicated leadership role is often beneficial. Those skills are different than just having more experience or more tenure.
* Putting a tech lead on a team doesn’t mean abdicating collaborative decision-making. On the contrary, a [good tech lead](https://linearb.io/blog/tech-lead-responsibilities/) should enhance that aspect by practicing servant leadership.

## A Set of Rituals

We’ve talked about principles and team composition. But a team isn’t a static entity. A team is defined not only by _what_ it does but _how_ it goes about it as well.

The ways of working on a team are fundamental parts of its identity. I’m sure you know these agile rituals: a daily standup, regular retrospectives or reviews. Those are tools to [sharpen your saw](https://blog.codinghorror.com/sharpening-the-saw/), make you more effective as a team, share information, and broadcast the team’s output to the outside.

Agile rituals don’t guarantee success. Just because you do a daily in the morning doesn’t mean that you’re getting anything out of it. Think critically and go past the surface to ensure that collaboration or autonomy aren’t just buzzwords in your day to day. While I don’t think a team needs an agile coach to practice agile, it may make sense for a less mature team to get support from a specialist until they’re ready to roll on their own.

## Measuring the Effectiveness of a Team

If teams have clear, measurable goals, everybody has an easier time deciding how to invest their time effectively with little outside guidance. Objectives and key results ([OKRs](https://www.whatmatters.com/faqs/okr-meaning-definition-example)) are a popular framework to set actionable goals. Honestly, it’s not about the framework. It’s about the commitment to set goals for a team and evaluating the team and the goals regularly.

I’ve been part of teams that had completely unreasonable targets set by management without any transparency. If you’re trying to demotivate your engineers, that’s exactly the way to go.

Be very careful with goals. Ask if they’re forcing team members to choose between their and the team’s best interests. If that happens, it’s a failure, and it’s the fault of the people setting up the organizational structure.

## Seek Feedback

To summarize, structuring engineering teams is about continuing the work that you begin when you structure your engineering organization as a whole. My advice is to have _autonomy_, _mastery_, and _purpose_ as your guiding principles. Start from there and iterate constantly.

[![How Drata's Unicorn Engineering Team Scales with LinearB](https://assets.linearb.io/uploads/LinearB-Youtube-Card_-Daniel-Marashlian-How-Dratas-Unicorn-Engineering-Team-Scales-with-LinearB-1024x576.png)](https://linearb.io/blog/how-dratas-unicorn-engineering-team-scales-with-linearb/)

Want to learn the secret to great developer experience and productivity? [Check out how unicorn Drata uses LinearB to scale rapidly.](https://linearb.io/blog/how-dratas-unicorn-engineering-team-scales-with-linearb/)

## Improve developer productivity with LinearB

Find us on

[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)

## Your next read

[![Cover image for AI as a value multiplier: a human-centric approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Servant_Leadership_2400x1256_0cfd4e2a0c?_a=BAVMn6ID0)](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership)

Leadership

[AI as a value multiplier: a human-centric approach to engineering leadership](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership)

Super.com's Matt Culver explains why AI should be used as a value multiplier, not a cost-cutter, advocating for a human-centric approach to engineering...

[![Cover image for The Moneyball approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Balancing_Technical_Depth_2400x1256_b56d93a733?_a=BAVMn6ID0)](https://linearb.io/blog/moneyball-approach-engineering-leadership)

Leadership

[The Moneyball approach to engineering leadership](https://linearb.io/blog/moneyball-approach-engineering-leadership)

Rethink engineering leadership with Transcend's Minh Nguyen and learn how to balance hands-on technical work with strategic leadership, communicate with a...

[![Cover image for Strategic lessons from Google on improving engineering teams](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Strategic_Lessons_From_Google_2400x1256_1_cd28b7242d?_a=BAVMn6ID0)](https://linearb.io/blog/strategic-lessons-google-engineering-teams)

Leadership

[Strategic lessons from Google on improving engineering teams](https://linearb.io/blog/strategic-lessons-google-engineering-teams)

Learn key lessons from Google on aligning engineering with business goals, boosting developer productivity, and building sustainable team culture.

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How Do You Structure an Engineering Team?",
  "url": "https://linearb.io/blog/engineering-team-structure",
  "author": {
    "@type": "Person",
    "name": "Mario Fernandez"
  },
  "datePublished": "2021-07-13T16:49:43.000Z",
  "dateModified": "2021-07-13T16:49:43.000Z",
  "image": "https://assets.linearb.io/image/upload/v1720000000/structure_office_55d48cb90f.jpg",
  "publisher": {
    "@type": "Organization",
    "name": "LinearB",
    "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png"
  },
  "description": "An engineering team structure is about finding a way to provide autonomy, mastery, and purpose to its team members. Let’s explore more.\n"
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Register now](https://linearb.io/event/engineering-productivity-gap)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)