DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Why Software Development Leaders Should Invest in Continuous Learning and Growth Opportunities
  • Building and Sustaining an Open Source Community in the Context of Organizations
  • What Do You Mean by Debugging in C?
  • How to Effectively Manage a Remote Software Development Team

Trending

  • A Better Web3 Experience: Account Abstraction From Flow (Part 1)
  • Freedom to Code on Low-Code Platforms
  • Supercharge Your Communication With Twilio and Ballerina
  • Parallel Sort

Use the Staffing Pyramid to Structure Teams

Use a pyramid to determine how manager managers, programmers, testers, and requirements engineers should be structured on a team.

Allan Kelly user avatar by
Allan Kelly
CORE ·
Jan. 28, 16 · Opinion
Like (2)
Save
Tweet
Share
13.02K Views

Join the DZone community and get the full member experience.

Join For Free

When I see development teams I expect to see more programmers than requirements people (BAs, Product Managers, etc.), and I expect to see even fewer management types. Think of it like a staffing pyramid structure:

Programmers (and often testers) should form the largest group (without programmers there is no software), and while in an ideal world there is no need for testers the reality is the absence of testers is usually a sign of problems (though not always). I’m not the only person to have observed high performing development teams where there are no testers but these are the exception.

Although you occasionally here stories of IBM or Microsoft employing more testers than programmers, I’ve never seen this situation. The nearest I’ve come to it is teams with one tester for every two programmers. The ratio of testers to programmers should be a function of the initial quality produced by programmers, but it more often than not is a function of how seriously management takes testing and the regulatory environment the company operates in.

Anyway, programmers - the people who produce the raw produce, source code - should be the largest group. Testers are a little way behind but together these two groups should form the bulk of the development team. After this I expect to see some requirements people (Business Analysts, Product Managers, Product Owners, Requirements Engineers — whatever titles they go by.) There may be some other people in this mix: customers, business sponsors and so on.

(Conceptually user experience/design people are the same layer as programmers but usually they are there with requirements people. Either way, you don’t expect to see many of them and they certainly shouldn’t outnumber programmers on a team.)

On top of this there are a few management types, whether these be project managers, development managers or some other type of manager. I know some people want to remove all managers. I don’t agree with them but I do agree there shouldn’t be many.

In a healthy team there are lots of doers (programmers, testers, UXD), fewer people feeding these people (requirements) and even fewer people managing everything. Requirements people and managers act as a multiplier to programmers (doers). These guys lay the golden eggs. By organizing them well and asking them for the right golden eggs, the value of the golden eggs should be higher.

By the way, when I talk of people I’m thinking absolute numbers, not “full time equivalents” or even “full time dedicated staff”; the people higher up the pyramid may well be multi-tasking. What is important here is not the time devoted to a piece of work but the number of voices who have a say in what happens - the number of people who have a finger in the pie. So part-time people (those with dotted lines, those with responsibility and concern but no responsibility) all count in the pyramid numbers.

And then…

Periodically I meet companies who have an inverted pyramid. This is almost always a bad thing...a really bad thing.

In the extreme there is one programmer at the bottom, no testers, and lots of people who have an interest in what is being created. Lots of people who have views — they have Product Owners and Product Managers and Business Analysts and Subject Matter Experts and Business Partners and  Requirements Experts, Project Managers and Development Manages and (maybe) Team Leads.

These pyramids seems to come from a mentality thats says:

Software development is really expensive, and really slow, and really painful, and so we must absolutely do as little as possible

Many of these people who have a finger in the pie of “what is built” are part-time to the work, they have the right to interfere but no responsibility for what happens. Work takes years to get started and never seems to finish. Perhaps the developers are split between projects.

When I see the inverted pyramid I feel these companies are scared of their own shadow. I’m reminded of the old Woody Allen joke about the two old women at a restaurant:

First lady: The food here is so awful

Second lady: Yes, and the portions are so small

To be brutal (and to repeat something I said in Business Patterns) when you are developing software there is only one role which you absolutely must have — programmers. All other roles are optional, or perhaps context specific. (Even if you outsource the actual coding there is still a programer. If there is no code there is no program, without a programmer somewhere it is not software development.)

The programmer is the role which makes the product, and they are the ones who lay the golden eggs. If you have no one to lay the golden eggs then it doesn’t matter how well the other people push paper - there is no value creation. (For Hitch Hiker Fans: programmers are on the C Ark, everyone else is one the B Ark.)

teams Programmer (hardware) Software development

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Why Software Development Leaders Should Invest in Continuous Learning and Growth Opportunities
  • Building and Sustaining an Open Source Community in the Context of Organizations
  • What Do You Mean by Debugging in C?
  • How to Effectively Manage a Remote Software Development Team

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: