How to Scale Your Dev Team in 30 Days Without Hiring Full-Time

A practical approach to increasing your engineering capability rapidly without waiting out a full hiring cycle.

Hiring takes time. Deadlines don’t. It might just be a few weeks until the next release as the team is already preoccupied with developing features, fixing bugs, resolving technical debt, and integrating new code. One way of dealing with the engineering bottleneck problem is to hire new developers, but the whole hiring process will be longer than what the project can afford.

External engineering assistance can fill that gap. But bringing on developers is only helpful if they are able to start contributing immediately. Repository access, environments, documentation, CI/CD, testing, and ownership all factor into a developer’s ability to contribute.

The point here isn’t just to bring on more people. It’s to bring in the right engineering capacity.

Short term augmentation will help only if the demand and shortage are known.

Release, migration, or rewriting of platform can cause a sudden surge that the internal team cannot accommodate. Hiring engineers for that time helps to avoid creation of roles which may be needed just temporarily.

There are situations where the project lacks cloud skills, DevOps, QA automation, mobile, data or security skills. The on demand developers can help in that situation for a limited period of time.

There is also justification of having separate streams. External team can have ownership of mobile application, migration, API layers or set of features, while the internal team has ownership of the platform.

It is important that we make a distinction here. Should both the parties continue to change their components and wait for each other, most of the capacity would be wasted on coordination.

Take, for example, a backend team that hires three more developers for a very coupled application. Modifications to the database have to go through a single senior engineer. The API docs are not complete, integration tests are not reliable, and the staging environment is shared.

The new developers can code. They just can't do so independently.

The bottlenecks are all over the place. An architectural team can turn into a review list. QA may find itself burdened with more regression testing. Deployment may get stuck due to manual procedures despite smooth development.

Identify the actual problem before hiring developers. Development may be the bottleneck, but not always.

Software development team augmentation fits teams that already own their product, architecture, and backlog but need additional developers.

A dedicated development team suits a stable group needed for an extended roadmap.

Outsourced development teams occur when there is an external partner who is able to take ownership of a well-defined workstream.

Architecture, code reviews, releases, incidents, and backlogs need to be defined prior to the start of development.

The 30 days ramp up is very dependent on preparation. Record the repositories, services, API’s, and other components that the new engineers will need. Ensure that all resources for source control, issue tracking, development, staging, CI/CD, documentation, and test data have been prepared.

Do not dilute security protocols in order to streamline the onboarding process. The individual access and credentials, MFA/SSO, role-based access, least privilege principle, secure repos, and secrets must remain the same.

It’s necessary for the new engineers to know the branch strategy, pull requests policy, the testing/deployment procedure, and the definition of done.

The documentation about the architecture design, including the services ownership, APIs, DBs, dependencies, and deployment procedure, will be useful during onboarding.

Understand the backlog, architecture, dependencies, technology stack, QA capacity, and deployment process. Understand what really needs more engineering capacity.

Assign roles according to the nature of the work done rather than just putting people into random roles. A feature enhancement requires two full stack engineers and one QA automation engineer rather than three identical engineers.

Set up repositories, environments, documentation, access to CI/CD, test data, and communication channels. The pull request that is reviewed will be used as an indication that the developer is capable of dealing with the process.

Allow the engineers to develop from production backlog stories after you provide enough information to them. The engineers should also follow the same coding standards, branching, testing, and release procedures as internal engineers.

Assess the lead time of changes, deployment frequency, PR lead time, blocked time, failures, and rework compared to previous baseline.

In case there is increased engineering productivity but there is no improvement in releases, seek another bottleneck apart from development.

According to DORA research, there was a 5% productivity increase for developers on both an individual and a team level when developers could complete work without using an enabling team.

This is important in case of involving external engineers. If developers have to wait because of the enabling team, some capacity that has already been paid for will be idle.

Scaling the development team won’t fix the issue of vague requirements, unstable architecture, inadequate tests, and unreliable deployments.

Scaling will even further complicate everything in case of poorly documented projects. In case these new people spend the whole month understanding the codebase, they don’t become an additional resource for the roadmap.

In such instances, it’s preferable to stabilize the development process first.

A well-designed ramp will guarantee that there is proper ownership, adequate documentation, standardized onboarding process, and access control within the organization.

The external team must work as part of the existing architecture, testing process, security measures, and release process and not as an independent development organization.

Kombee assists organizations to increase their engineering resources by providing dedicated development teams as well as software development team augmentation.

Scaling up your development team within 30 days is possible as long as you have clear work to do and the engineering environment prepared.

Find the true choke point, select the right engagement model depending on the nature of the work, prepare access in advance, and get developers working in the existing flow quickly. Measure if delivery has improved.

Yes, it is possible as long as we know what we will be doing, and we have all the preparations done in advance.

During team augmentation, engineers get integrated into an already existing team and maintain product and technical ownership. During a dedicated development team, a team of engineers is hired from outside for a long-term period.

This is required in cases where I need some skilled developers for some time period. Some examples include DevOps engineers, cloud engineers, QA automation engineers, security engineers, etc.

Individual access, MFA/SSO, role-based access, least privileged access, secure code repository, separate environment, secrets management and code review and auditing.