Skip to main content

The balance between collaborative meetings and "heads-down" solo work

the breakdown can vary significantly by role, company culture, and the specific phase of a project.

Based on available data and common industry observations, here is a general breakdown, with the understanding that these are averages and can fluctuate greatly:

Software Engineers

  • Collaborative Meetings: 15-35% of a project's time.
  • Solo Heads-Down Work: 65-85% of a project's time.

Breakdown:

  • Meetings: This time is often dedicated to daily stand-ups, sprint planning, backlog refinement, sprint reviews, and retrospectives, which are core to your use of SCRUM. There's also time for ad-hoc technical discussions, code reviews, and cross-functional meetings with UX designers and business analysts. While a 15-minute daily standup seems small, the cumulative effect over a two-week sprint and the context-switching it requires can significantly eat into a day. For more senior or lead engineers, this percentage can be much higher due to mentorship, architectural discussions, and unblocking other team members.

  • Solo Work: This is the core of the role—writing code, debugging, testing, and creating technical documentation. The ability to have long, uninterrupted blocks of "flow state" is critical for high-quality engineering work.

UX Designers

  • Collaborative Meetings: 30-50% of a project's time.
  • Solo Heads-Down Work: 50-70% of a project's time.

Breakdown:

  • Meetings: UX is a highly collaborative discipline. A significant portion of a designer's time is spent in discovery meetings with business analysts, user interviews, usability testing sessions, design reviews with stakeholders, and providing feedback during agile ceremonies. They are the bridge between the user and the development team, which requires a lot of communication and alignment.

  • Solo Work: This includes the actual design work: creating wireframes, mockups, prototypes, user flows, and conducting individual research and analysis of user data.

Business Analysts

  • Collaborative Meetings: 40-65% of a project's time.
  • Solo Heads-Down Work: 35-60% of a project's time.

Breakdown:

  • Meetings: The very nature of the business analyst role is to gather, clarify, and communicate requirements. This is heavily meeting-driven. A BA's week is filled with workshops with stakeholders to elicit requirements, daily SCRUM meetings, demos, and one-on-one sessions with developers and designers to ensure everyone understands the project's vision and user stories. They are the primary communicators of the "what" and "why" of a project.

  • Solo Work: This time is spent documenting requirements, creating user stories, analyzing data, building process flow diagrams, and preparing for upcoming meetings.

Key Considerations from an Agile/SAFe Perspective:

Your understanding of SCRUM and SAFe is highly relevant here, as these frameworks are designed to optimize this very balance.

  • Timeboxing: Both SCRUM and SAFe use timeboxes for meetings (e.g., a 15-minute daily standup, a four-hour sprint planning for a two-week sprint). This is a deliberate effort to protect solo work time and prevent "meeting creep."
  • Cadence and Synchronization: SAFe's Program Increment (PI) planning is a great example of a large collaborative event designed to reduce ad-hoc meetings later. By bringing everyone together for a few days to plan the next 8-12 weeks, you front-load collaboration to enable more uninterrupted solo work later.
  • Role-Based Meetings: The data reflects that roles with a greater need for cross-functional communication and requirement gathering (BAs and UX) naturally have more meetings than a role focused on implementation (software engineer). This is a normal and expected part of an effective agile team.

Managing this balance effectively—especially when you're delegating and applying these principles to your own agency—is a key factor in a team's overall productivity and morale. Excessive meetings are a common source of frustration, as they can fragment solo work time and prevent the deep, focused work that's essential for creating high-quality web and app development solutions.