Staffing a build you have not designed yet

Staffing is often estimated too early and too generically. One architect, two backend developers and one DevOps engineer may sound plausible, but it says almost nothing about the system. A low-complexity API and a regulated multi-region data platform do not need the same delivery shape.

A realistic cloud delivery plan starts with the architecture. The design tells you where specialist work exists: data migration, backend implementation, identity integration, infrastructure automation, security review, testing, observability and release management. It also shows why an architecture diagram is both a technical map and a cost model.

Architecture changes the role mix

A design heavy on managed services may reduce operational effort but increase architecture review. A design with complex integrations may need more backend work than infrastructure work. A system with strict compliance requirements may need security involvement from the start, not as a late review.

Headcount follows the work. The work follows the architecture.

Separate roles from people

A role in a delivery plan is not always a full-time person. The same engineer may cover multiple responsibilities on a small project, while a larger implementation may split architecture, backend, platform, security and data work across separate specialists.

This distinction matters for budget and schedule. A plan that lists "DevOps" as a generic role can hide infrastructure automation, deployment pipelines, cloud networking, secrets management, monitoring and incident readiness. Those are different kinds of work, even if one person performs several of them.

Timeline is not just effort divided by people

Some tasks cannot be parallelized cleanly. Data model decisions may block API work. Identity integration may block frontend acceptance testing. Procurement or security review may sit outside the engineering team but still define the calendar, especially when early architecture inputs leave provider, integration or compliance questions unresolved.

A staffed plan should expose sequencing, not just estimate hours.

Map skills to architecture components

• Application work: APIs, business logic, workflow orchestration and integration handling.
• Data work: schema design, migration, retention, backup and reporting needs.
• Platform work: environments, deployment, networking, observability and secrets.
• Security work: identity, access control, encryption, audit needs and review gates.
• Delivery work: milestones, client decisions, acceptance criteria and handoff.

Once work is mapped this way, staffing becomes easier to review. A client can see which roles are driving the timeline and which assumptions would change the plan.

Use the first plan as a negotiation object

The first delivery plan should not pretend to be perfect. It should make assumptions visible: which roles are needed, where the bottlenecks are, what could move the date, and which decisions need the client. That gives delivery leads something concrete to adjust instead of a blank spreadsheet.

This also improves the Statement of Work. When roles, milestones and assumptions are grounded in the architecture, the SOW becomes a delivery plan a team can act on rather than a commercial document written after the real decisions were made.