Magento Role and Seniority Checklist

01 / RECORD

One record per proposed person

Create a named-person evidence sheet

A company capability statement cannot replace the evidence for the person who will do the work. Complete one record for each engineer, architect, QA specialist, DevOps engineer, analyst, project manager, or delivery lead.

Named-person proposal record
Field	Proposal answer	Evidence and buyer check
Full name and contractual role	[Name, exact role, employer or contracting party.]	[Match the person across proposal, interview, contract, and access request.]
Magento work scope	[Backend, frontend, full-stack, architecture, QA, DevOps, analysis, or delivery.]	[Map the role to specific outputs in the team-gap brief.]
Claimed seniority	[Provider label and level.]	[Record the decisions, risks, and comparable work that support the label.]
Relevant recent work	[Project, platform edition, role, systems, dates, and outcome.]	[Ask what the person personally designed, changed, tested, reviewed, or operated.]
Credential requirement	[Exact credential or “not required for this role”.]	[Record the official verification link, identity match, credential name, and visible status.]
Allocation and other commitments	[Capacity, period, known leave, and other client commitments.]	[Put the accepted allocation and change process in the contract.]
Working window and location	[Person's location, local workday, buyer overlap, and holiday calendar.]	[Test the exact proposal with the working-window planner.]
Fit boundary	[Tasks, systems, decisions, and access outside the person's role.]	[Name the person who covers every excluded responsibility.]

02 / ROLE

Test the work, not the title

Match each role to specific Magento decisions

Backend developerModules, service contracts, APIs, queues, cron, checkout, data flows, extensions, upgrades, tests, security, and production diagnosis.

Frontend developerTheme or framework, JavaScript, templates, design system, extension compatibility, accessibility, browser testing, and performance.

Solution architectRequirements, system boundaries, data ownership, integration patterns, non-functional needs, tradeoffs, decision records, and technical governance.

QA specialistRisk model, test strategy, regression assets, integration and checkout cases, automation, environments, evidence, and release gates.

DevOps engineerBuild and deployment path, environments, cloud boundary, observability, secrets, backup, recovery, release controls, and access removal.

Business analystBusiness rules, process maps, data definitions, requirements, acceptance cases, traceability, decisions, and stakeholder alignment.

Project or delivery leadDependencies, capacity, risk, ceremonies, decisions, reporting, escalation, release coordination, and handover.

Full-stack developerOnly use this label after listing the exact backend and frontend depth required. Confirm what remains outside the person's tested scope.

03 / LEVEL

Seniority is observable responsibility

Replace years-of-experience labels with evidence

Years can provide context, but they do not prove role depth. Ask for a recent example at the same risk and complexity as the buyer's gap. Verify the person's decisions, constraints, review responsibilities, failure handling, and handover.

Evidence that distinguishes role levels
Observed responsibility	Evidence to request	Buyer test
Executes bounded work	[Completed task, tests, review comments, and escalation example.]	[Can the person explain inputs, definition of done, and when to ask for help?]
Owns a component or flow	[Design, dependencies, failure modes, deployment, monitoring, and maintenance.]	[Can the person identify risks and make a safe plan within known architecture?]
Leads across systems	[Architecture decision, data ownership, integration tradeoff, migration, or incident review.]	[Can the person compare options, expose assumptions, and set review and acceptance controls?]
Raises team capability	[Code reviews, standards, mentoring, documentation, and knowledge-transfer examples.]	[Can the person make the wider team less dependent on one specialist?]
Operates under business risk	[Peak event, regulated workflow, payment path, rollback, or recovery evidence.]	[Can the person connect technical choices to operational exposure and approval boundaries?]

A “senior” label should never grant automatic architecture, production, security, or release authority. Name those permissions separately and keep buyer approval where the risk requires it.

04 / CREDENTIAL

Verify the individual claim

Check Adobe credentials at named-person level

Partner status, a company certification total, or one specialist's credential does not prove that every proposed person holds the credential required for this role.

Name the requirement. Write the exact credential and explain why it is needed for the assigned work.
Request the person's official verification link. Do not rely only on a logo, screenshot, CV line, or provider summary.
Match the identity. Confirm that the verified name belongs to the same person in the proposal, interview, and contract.
Read the visible record. Record the credential name, level, status, and any dates shown by the verification source.
Test relevance. A credential can support a knowledge claim, but the buyer still needs evidence for the exact role, systems, and recent delivery context.
Save the check. Record the verification URL and check date with the procurement decision.

Named person: [Full name]

Required credential: [Exact credential name and role reason]

Official verification URL: [Link supplied and checked]

Identity and visible status: [What the buyer confirmed]

Check date and reviewer: [Date, buyer name, and decision record]

05 / TEST

Use the buyer's real constraints

Run a bounded role-specific interview

Give context: provide a sanitized architecture, workflow, or code fragment that resembles the actual gap without sharing secrets or customer data.
Ask for questions first: strong candidates expose missing requirements, ownership, failure modes, and acceptance before proposing an answer.
Request tradeoffs: ask for at least two options, risks, assumptions, validation steps, and the condition that would reverse the choice.
Test communication: ask the person to explain the same decision to engineering, product, and operations audiences.
Keep it bounded: do not turn the evaluation into unpaid production work. Use a short exercise with a clear purpose and review standard.

06 / DECIDE

Record why this person fits

Use a pass, conditional pass, or reject decision

Named-person decision record
Decision	When it applies	Required record
Pass	The named person meets the required role evidence, working boundary, allocation, and acceptance model.	[Evidence links, interview notes, approved role, allocation, and contract reference.]
Conditional pass	A specific gap can be closed by adjacent support, limited access, pairing, training, or an explicit approval gate.	[Condition, owner, deadline, evidence, and consequence if it is not met.]
Reject	The evidence does not match the required work, identity, role level, credential, allocation, or risk boundary.	[Reason tied to the brief, not a vague preference or company brand.]

Return to the dedicated Magento developer comparison after every proposed person has a complete record. The team-gap worksheet defines the work this checklist must test.