Development team capacity: what to check before hiring an engineer
The promotion already has a date, but changes to the basket are once again missing the release. Everything on the task list is marked urgent, the technical lead is constantly busy, and the simplest solution seems to be hiring another developer. Yet development team capacity is not determined by headcount alone. If completed code is waiting for review, access to a test environment or a decision about discounts, a new engineer may only make the queue longer.
Before opening a vacancy, establish what is actually missing for the next useful release: implementation time, a particular skill or the ability to finish work already started. These are different problems with different budgets. Below is a way to distinguish them using evidence from your own online store and prepare a reasoned decision about reinforcement.
First, name the outcome that is not reaching the customer
‘We have too many tasks’ is a weak basis for hiring. ‘We cannot release payments for corporate customers in time for the agreed launch’ is a situation that can be analysed. Identify one business change and its path: who clarifies the rules, who writes the code, who checks it, who accepts the result and who authorises publication. This reveals where an additional specialist could genuinely work independently.
Draw a simple diagram of the actual path a change takes, including returns for rework. DORA’s approach to mapping the flow of work helps reveal waiting and handoffs between participants. A board and task history are enough for an initial discussion; buying a separate analytics system is not essential.
Separate work from waiting
Take a small group of recent, comparable changes from one store. Do not mix a banner replacement, payment integration and emergency recovery: they have different dependencies. Look at unfinished changes alongside completed ones, or the longest delays will disappear from view. For each change, reconstruct the dates of transitions between states and the reasons for stoppages.
It is useful to distinguish active time from waiting time. A status of ‘in testing’ does not mean a tester is working continuously. It may include a queue, missing test data and clarification of expected behaviour. If precise logs are unavailable, ask participants to reconstruct the picture and label the estimates as approximate. Do not turn imprecise recollections into employee rankings.
- Record when the task became clear enough to start, when implementation began and when it was handed over for checking.
- Record waiting for code review, a test environment, a response from an adjoining system and business acceptance separately.
- Note returns for rework: an implementation defect, a rule change and an overlooked scenario require different solutions.
- Add unplanned work: incidents, consultations and help for other teams, even where no tickets were created.
Look for a recurring point where work accumulates, not the most conspicuous isolated incident. Regularly diverting an engineer to support may conceal a genuine capacity shortage that is not visible in the plan for new features.
Four queues that look like a shortage of developers
Before hiring, check what is actually growing: the backlog of clearly defined tasks or the number of unresolved questions. The table below is a diagnostic aid, not an automatic conclusion based on a single symptom.
| Where work accumulates | What to check | First action |
|---|---|---|
| Before implementation | Whether rules and completion criteria are agreed | Assign an owner for the business decision |
| Before code merge | Who has the authority and time to review | Provide a reviewer and a backup |
| Before testing | Whether the environment, data and adjoining services are available | Resolve the specific dependency |
| In the ready-for-development queue | Whether there is work that can be done independently | Assess an additional engineering role |
Review: written code has not yet increased throughput
If one technical lead reviews every change, another code author also creates additional demand for that lead’s attention. Check whether the reviewer receives a compact change with an explanation or a large package containing several unrelated features. Agree on review time, priority order and a competent deputy for the relevant part of the system.
A code review queue does not always mean slow communication. In GitHub, protected branch rules may require approval from designated code owners and successful automated checks. Establish the actual reason for the blockage. Disabling protections so a new employee can close tickets faster is not a way to demonstrate the value of hiring.
Requirements and access: a newcomer will inherit the same stoppages
The phrase ‘add a dealer discount’ leaves questions open about combining it with a promo code, rounding and the source of the price. This calls for acceptance criteria for changes, not a second pair of hands to make guesses. The product owner should agree on expected behaviour, and the developer should identify technical dependencies. Do not shift commercial decisions onto a candidate merely because they are experienced.
Check access to the repository, logs and test environment: a new team member should be able to run the project and reproduce the agreed scenario using permitted data. This does not require opening up the live order database or issuing a shared administrator account.
How to test the hypothesis without a new vacancy
Choose one recurring obstacle and change the conditions for the next comparable piece of work. This is a small management experiment: it should show whether removing the blockage helps get features to users. Set its duration according to your release cycle, not a universal promise to ‘fix the process in a week’.
- Describe the starting situation: which changes are delayed, at which transition and what evidence supports this.
- Agree on one action, such as reserving a reviewer’s time or preparing a test dataset. Assign someone responsible.
- Limit parallel work at the problematic stage. Do not start something new merely to make everyone look busy.
- Follow the next comparable changes through acceptance and release. Record waiting, rework and the technical lead’s involvement.
- Compare the result with the initial observation and check whether the queue has shifted to testing or business approval.
DORA recommends accounting for support, meetings and technical debt in available capacity and applying work-in-progress limits. The point is not to leave people without tasks: spare attention helps finish blocked work. For example, an engineer can prepare test data or split an oversized change instead of starting another feature.
When an additional engineer really makes sense
Reinforcement is justified when there is enough agreed work, a clear boundary of responsibility and people able to accept the result. A separate reason is a skills gap: for example, the team maintains the storefront but lacks experience with a required integration. A generalist developer will not necessarily replace a specialist in that particular system and its operation.
Define the role through an outcome: ‘implement the agreed order-status exchange and hand it over to support’, not ‘help with everything’. For Magento or Adobe Commerce, a request should specify the edition, version, deployment approach and components the work will affect. The word Magento alone is not enough to describe the project environment and expectations of the engineer.
Assess the cost of onboarding an engineer: environment setup, architecture explanations, a joint walkthrough of the first change and review time. A new person’s calendar availability does not mean immediate independence. If the release is tomorrow, reducing scope or postponing a non-critical feature may be more realistic than expecting an instant benefit from hiring.
A permanent role suits a long-term need, while a limited engagement suits a particular skill or temporary workload. If analysis, testing and release management are all lacking, do not bundle these responsibilities into one programmer vacancy. Procuring work is discussed separately in the article on choosing a contractor through an RFI, RFP or RFQ; here, the decision starts earlier, with identifying the missing role.
Example: a new delivery method stalls before a promotion
A hypothetical example: a store is adding delivery to a pickup point, but the task repeatedly returns for rework. At first, it seems that the developer cannot keep up. Analysis reveals something else: there is no suitable address for testing, the business has not yet decided what to display after the delivery service rejects a request, and the reviewer is available only after finishing other work.
For a task like this, behaviour is agreed first: the customer selects a pickup point, the address is included in the order, and service unavailability is handled with a clear message and an approved alternative path. A delivery service representative confirms the test scenario, the store owner accepts the rule and the technical lead schedules the review. This does not replace programming, but it removes guesswork.
How to assess reinforcement after the first completed change
Agree on evidence of the engagement’s value: the change has been accepted, released and handed over to support. Compare similar work on the same product: smaller task scope or the absence of incidents may also explain an improvement in speed.
Do not confuse the full journey from requirements being ready to launch with DORA’s change lead time metric: the latter measures the time from committing a change to version control to deployment in production. Both measurements are useful, but they answer different questions. For a staffing decision, it is also important to see the waiting that occurs before the first code change.
Alongside time, track the quality of released changes and the load on the mentor. More releases accompanied by frequent emergency fixes do not mean sustainable reinforcement. Checking procedures and restoring the system to working order are covered in the article on safe online store releases. Do not remove them from the plan to improve speed statistics.
The owner’s decision: pay to remove the cause
A reinforcement budget includes more than the engineer’s pay. Account for task analysis, internal mentoring, testing, environments and post-release support. A process-change budget includes the time of those responsible and the work needed to remove blockages. Compare options for the same outcome: what it costs to bring the required feature to an accepted state, not what an hour of different people’s time costs.
GL.ua (Glyanets) specialises in Drupal: support covers functionality improvements, testing and integrations. For a Drupal store, you can discuss a specific development plan and technical dependencies rather than an abstract increase in team size. For a Magento store, look for a specialist with the appropriate profile: diagnosing the flow helps formulate their task regardless of platform.
Start with one release, its queues and the people responsible. If your Drupal store needs reinforcement, discuss technical website support and development with GL.ua: include a description of the required change, known blockages and acceptance conditions in your enquiry. This provides a concrete basis for estimating the work, timeline and roles needed.
Just one step to your perfect website
