You're hiring a development team. But what are all these roles? Who does what?
Here's a plain-English guide to software team dynamics.
Core Roles
Developer (Software Engineer)
What they do: Write the actual code that makes software work.
Subtypes:
- Frontend Developer: Builds what users see and interact with (buttons, forms, screens)
- Backend Developer: Builds the behind-the-scenes logic (data processing, business rules, APIs)
- Full-Stack Developer: Does both frontend and backend
What to know: Developer skill varies enormously. Junior vs. senior is often a 5-10x difference in productivity and quality.
Designer
What they do: Design how the software looks and works.
Subtypes:
- UI Designer: Visual design — colors, typography, layouts
- UX Designer: User experience — workflows, usability, user research
- Product Designer: Combines UI and UX, often involved in strategy
What to know: Design is not just making things pretty. Good UX design significantly impacts whether software actually gets used.
Project Manager (PM)
What they do: Keep the project on track.
Responsibilities:
- Planning and scheduling
- Tracking progress
- Coordinating team members
- Managing risks
- Communicating with stakeholders
What to know: Not the same as technical lead. PM manages the project; technical lead makes technical decisions.
Product Manager
What they do: Define what should be built and why.
Responsibilities:
- Gathering and prioritizing requirements
- Defining features
- Representing user/customer needs
- Making product decisions
What to know: Often confused with Project Manager. Product = what to build. Project = how to get it done.
Technical Lead (Tech Lead)
What they do: Guide technical decisions.
Responsibilities:
- Architecture decisions
- Code quality standards
- Technical problem-solving
- Mentoring other developers
- Code review
What to know: Usually the most senior developer on the team, with leadership responsibilities.
QA/Tester
What they do: Test the software to find bugs.
Responsibilities:
- Writing test cases
- Executing tests
- Reporting bugs
- Verifying fixes
- Automation testing
What to know: QA is not just clicking around. Good QA requires skill and methodology.
DevOps/Infrastructure
What they do: Manage the systems that run the software.
Responsibilities:
- Server configuration
- Deployment automation
- Monitoring and alerting
- Security infrastructure
- Performance optimization
What to know: Often overlooked until something breaks. Critical for reliability.
Team Structures
The Solo Developer
One person does everything.
Pros:
- Cheap
- Simple communication
- Single point of accountability
Cons:
- Single point of failure
- Limited skills breadth
- No coverage for absence
- Quality may suffer
Best for: Very small projects, prototypes
The Small Team (2-4 people)
Typical agency or freelance team.
Common composition:
- 1-2 developers
- 1 designer (often part-time)
- Project management (often shared or part-time)
Pros:
- Good balance of cost and capability
- Direct communication
- Flexibility
Cons:
- Limited surge capacity
- May have skill gaps
- Vulnerable to turnover
Best for: Most small to medium projects
The Full Team (5-10 people)
Dedicated project team.
Common composition:
- 3-5 developers (mix of senior and junior)
- 1-2 designers
- 1 project manager
- 1 QA
- DevOps (often shared)
Pros:
- Full skill coverage
- Faster delivery
- Built-in review and quality
Cons:
- Higher cost
- Coordination overhead
- May be overkill for simple projects
Best for: Larger, complex projects
Team Dynamics That Matter
Communication Patterns
How the team communicates affects delivery:
- Daily standups: Quick sync on progress and blockers
- Sprint planning: What to build next
- Retrospectives: How to improve
- Demo sessions: Show working software
You should be involved in demos and key decisions.
Decision Authority
Who decides what?
- Technical decisions: Tech lead or senior developers
- Product decisions: Product manager or product owner (often you)
- Schedule decisions: Project manager with stakeholder input
Clarity prevents conflicts.
Quality Culture
How does the team ensure quality?
- Code review (developers review each other's code)
- Testing practices (automated tests, manual QA)
- Standards and conventions
- Documentation practices
Ask about quality practices before hiring.
What Size Team Do You Need?
Factors to Consider
Project complexity:
- Simple internal tool: 1-2 developers
- Business application: 2-4 developers
- Complex platform: 5+ developers
Timeline:
- Tight deadline: More people (up to a point)
- Flexible timeline: Smaller, focused team
Budget:
- More people = higher cost
- Senior people cost more but deliver more
The Mythical Man-Month
More people doesn't always mean faster delivery.
Adding people to a late project often makes it later (communication overhead).
For most projects, a small senior team beats a large junior team.
Questions to Ask
- "Who will actually work on my project?" (Not just who's available)
- "What's the team structure?" (Roles and responsibilities)
- "How do you handle [role] if you don't have a dedicated person?" (Design, QA, etc.)
- "How will I communicate with the team?" (Direct access or through PM)
- "What happens if a key person leaves?" (Continuity planning)
Red Flags
🚩 Can't tell you who specifically will work on your project 🚩 One junior person for a complex project 🚩 No QA or quality process 🚩 No one with architecture/technical leadership experience 🚩 You can only talk to sales, not the actual team
We're a small, senior team that delivers. Let's talk about your project