When companies decide they need to temporarily increase the capacity or speed of their software teams, they often reach for an arrangement called staff augmentation. And why not? It appears to be a win-win situation: you rent a couple of developers for a while and assign them some of your overflow work. Now your project should go that much faster, right?
Not necessarily.
While staff augmentation promises a quick fix to your output problems, the reality is often more complex. The truth is, companies that reach for this arrangement often end up spinning their wheels on feature development, stifling the progress of their team members’ development and, ultimately, wasting their money.
Luckily, there’s a better way to add temporary capacity to your team: an embedded team.
How is an embedded team better? We’ll get to that. But first, let’s take a look at staff augmentation and some of its pitfalls.
What is Staff Augmentation?
Staff augmentation is the process of bolstering your software team with temporary developers on an as-needed basis. Usually this is accomplished through a company that provides staffing services in exchange for a markup on each individual’s hourly rate. One or more temporary contractors join your team either remotely or on-site for an agreed-upon amount of time. Like your own team, you have the responsibility for tasking and managing them, and you’re charged for their time, as opposed to their output or the value they deliver. You sometimes have the option to extend their contract when it expires, but not always.
This arrangement offers the promise of an easy surge in development capacity without the hassle and risk of hiring full-time, but staff augmentation fails to consider the complexities of development projects. Because of this, adding more “butts in seats”—even relatively skilled “butts”—doesn’t mean your project will suddenly become more successful.
Four Realities Staff Augmentation Fails to Address
1. Progress Isn’t Proportional to People
If you add two people to a four-person dev team tomorrow, their project should proceed 50% faster, right? Probably not. As Fred Brooks discusses in his book The Mythical Man-Month, adding programmers to a behind-schedule project often makes the project even more behind schedule.
There’s even a name for this phenomenon: “Brooks’ Law.” It states that, “adding [person-power] to a late software project makes it later.” Brooks states that, because adding new people involves costly ramp-up time and increases communication overhead, the effect is net-negative on software team output.
Brooks knew in 1975 that throwing bodies at your software output problem doesn’t usually work, and yet there’s a billion-dollar industry that purports to do just that. Simply adding more people to a project is unlikely to help. However, adding the right people, those who can avoid the ramp-up and manage themselves effectively, can make your project better.
2. In Software, One Size Does Not Fit All
In seeking to be the one true solution to increasing your team’s output, staff augmentation looks at every problem the same way. If you need to get more done, staff augmentation says “we have developers who can do x … how many would you like, and for how long?”
But we don’t have to tell you that not all developers have the same expertise, experience, communication skills, and problem-solving capabilities. Developers aren’t fungible resources to be shuffled around and hot-swapped at a moment’s notice, but that’s exactly how staff augmentation treats them.
It offers a one-size-fits-all solution without investigating your specific context or addressing the reasons your project was struggling in the first place. If you’re lucky, your staffed developers will stay in their lane and write adequate code. If you’re not, your team might end up paying lots of money for the perverse privilege of going even slower.
3. Humans Are Not (Yet) Robots
When a new developer shows up to work with your team, they likely won’t know anyone other than the person(s) who interviewed them. As it turns out, people contain multitudes—you can be shy, introverted, egotistical, and/or talkative, depending on any number of situational factors. This means very few people (even from the general population, much less the subset of people who are programmers) are comfortable asking a total stranger a bunch of questions that might make them look dumb on day one.
So there’s going to be a learning curve where your new teammate has to get up to speed. Yes, your new staff aug’d developer has access to all the wonderful resources the Internet has to offer, just like anyone else. What they don’t have is the interpersonal relationships the rest of your team has, so when they get stuck on a programming problem, they are just another lonely person with a browser, googling around for answers (but mostly finding cat videos).
Meanwhile, the rest of your team is collaborating and commiserating and laughing at cat videos with each other and wondering what to make of the new, weird person in the corner you’ve asked them to work with all of a sudden.
4. Masking Deeper Issues Only Delays the Inevitable
In its valiant attempt to turn engineering effort into a liquid resource, staff augmentation can end up masking the more complex problems that are hindering your team’s progress.
The option to reach for staff augmentation every time things aren’t going as fast as you want allows engineering leaders to avoid dealing with their team’s deeper issues. When output is lower than you expect, you may think it’s because your team is too small or not skilled enough. But adding a couple of anonymous, temporary developers won’t fix your poor code hygiene, a busted deployment pipeline, or management shortcomings.
The crutch of staff augmentation can also cause engineers and managers to be less rigorous in avoiding technical debt (how many times have you said “we’ll clean it up right after this big push”), borrowing from future productivity, which of course only delays the inevitable reckoning. Fast-forward a few months, and you may wind up drowning in rework on features you shipped long ago. Time to push the bail-out button again!
How Can an Embedded Team Work for Me?
Staff augmentation allows a software team to increase the number of people available to get work done on a given project. Good contract developers will usually be capable of receiving instructions, pulling tickets, and writing decent code. So despite all the potential pitfalls, if it goes well, staff augmentation can have an additive effect on a team’s capacity.
An embedded team addresses the same set of problems as staff augmentation but does so much more effectively and with significant additional benefits that go far beyond increasing speed and capacity.
Let’s take a closer look at some of the benefits an embedded team offers.
Deeper, More Specific Expertise
Embedded teams are carefully vetted and work within a tight technical niche (in Tighten’s case, Laravel, Vue.js, and related technologies). The best agencies only work with groups that need the specific, deep expertise they have to offer, so if you find that right-fit agency for your team, their embedded team is highly likely to deliver good value. They have what you need and a ton of it.
Real-time Access to Collective Expertise
An embedded team is “embedded” in two different ways. First, within your team and project, and second, within the agency that employs them. At Tighten, our team members work on a single client project at a time, and they do so while situated in the Tighten Slack workspace with 20 other experts in the same stack. When they run into a tough problem, they don’t just go Googling around. They put the problem to the group of experts they are immersed in, leveraging its real-time, collective expertise on their clients’ behalf. You add two developers, but you gain the capacity of a 20-person expert team when you run into roadblocks and bottlenecks.
Reduced Management Overhead
An embedded team always leverages its talent collaboratively. To solve Brooks’ Law, where more people actually cause more delays, embedded teams are structured intentionally, with two developers and a fractional project manager forming the atomic team unit.
Beyond the obvious administrative benefit of having a project manager, developers need long stretches of deep, uninterrupted time to do their best work, and the cost of context-switching is very high. When a developer gets pulled away from their work for 5 minutes to handle an organizational task, that switch costs far more than 5 minutes of productivity. It could take as much as an hour for that developer to get back to the flow state they were in before the distraction.
Deploying as a team—two developers with a dedicated project manager—lets the team stay heads-down on the project, while the project manager handles the other equally important tasks that keep the whole project moving forward.
How Embedded Teams Level Up Your Capabilities
Embedded teams, equipped with deep experience, technical expertise, and an outsider’s fresh perspective, are trained not only to solve your development problems but to identify and improve the issues that hamper your team’s progress. With an embedded team, you not only level up your dev capacity, but you level up your team in a holistic way, gaining crucial insights into your codebase, processes, and even your team dynamic.
This can create lasting benefits you reap long after your embedded team has rolled off of your project. You might gain a new understanding of how to improve your development processes, how to improve your architecture, and how to create a more knowledgeable, fulfilled team.
Staff aug seems like the easy solution because the agency takes an oversimplified approach to providing dev talent. But at the end of the day, staff augmentation tries to solve your complex, nuanced codebase challenges with a standard-issue developer (or two or three) that might not have the deep skills you need.
Tighten’s method is designed to specifically avoid spending time and resources on a staffing situation that doesn’t actually make any progress (or worse, torpedoes the current project and sinks future opportunities into technical debt). When you need to add capacity with an embedded team, you get more than butts-in-seat. You get critical problem-solving brainpower. Learn more about how to deploy an embedded team to accelerate your software development process — without the traditional staff augmentation headaches.
Get our latest insights
in your inbox:
in your inbox:
Hey,
let’s talk.
let’s talk.