Team Augmentation Has a Leadership Problem

Team augmentation is one of the two services Rock Agile offers. We do it well. We have clients we've placed engineers with for years at a time. Some of those engagements are the best work anybody at the firm has done.

I still push back on it more often than I sell it. Because for a lot of the companies that call asking for a contractor to plug into their team, team augmentation isn't going to solve the problem they think they have. It's going to hide it.

Here's what I mean.

What team augmentation actually is

Team augmentation is when a company hires a contractor (or, in Rock Agile's case, a Rock Agile engineer) to sit inside the client's existing team. The contractor takes tickets from the same queue as the internal developers. Attends the same standups. Reports to the same project manager. From a project management perspective, they're a developer. From an accounting perspective, they're a contractor. That's the entire distinction.

The pitch is that you get a senior developer faster than you could hire one, without a full-time commitment. Which is true. And in the situations where that's the actual problem you have (genuine capacity constraint, work that will taper off in six or twelve months, a specific technical gap that's cheaper to rent than to hire), team augmentation is the right answer.

But that's not why most companies reach for it. Most companies reach for team augmentation because they can't ship what they said they'd ship, and they think adding engineers will fix it.

The one cause of headless development

There's one cause of a development team that's spinning without making progress, and it isn't developer capacity.

It's leadership.

When developers are working hard, shipping code, closing tickets, and yet the project isn't moving toward completion, that is by definition a failure of goal-setting, priority-setting, and decision-making. Those are leadership functions. If you're the CTO or engineering manager watching this happen, the fact that it's happening is diagnostic. The question isn't "how do I add more developers." The question is "what am I not doing that would let the developers I have make real progress."

Adding an augmented seat to a team that isn't making progress doesn't fix leadership. It just adds another developer to the failure. In many cases, it accelerates the failure, because now the team has more code to manage and a bigger surface area for context loss and coordination breakdown, but still no clearer goals.

And here's the darker part. When leadership doesn't want to name the failure as leadership, they name it as developer performance. The pattern is old and universal. It reliably rolls downhill. If the augmented developer isn't shipping the miracle that internal developers weren't shipping either, the augmented developer becomes the story: contractors are lazy, contractors are expensive, contractors don't understand the codebase, we should hire full-time next time. None of that is what actually happened, but it lets the underlying problem stay unexamined for another cycle.

I've watched this happen more times than I want to count. It's not a bad-actor story. Most of the leaders I've seen do it are decent people who genuinely believed they had a capacity problem. They didn't. They had a decision-making problem, and they solved for the wrong thing.

Where project-based work is different

I don't want to claim that project-based work is inherently superior. It isn't. It's harder. It requires more up-front planning. It requires the client to commit to a scope and a timeline, which is exactly the thing they were trying to avoid by hiring an augmented seat in the first place.

But that's why it works.

When you engage Rock Agile on a project instead of an augmented seat, we don't start until you've defined what "done" looks like. That forcing function is doing most of the work. If you can't tell us what done looks like, we know before we start that the engagement isn't ready. That's a favor to you. It's a lot cheaper to find out you can't articulate the goal in a scoping conversation than to find out three months in with an augmented developer.

Project-based work forces decisions. It forces goals. It forces deadlines. It forces the client to name the tradeoffs they'd prefer to leave unnamed. Every one of those is a place where team augmentation lets the client stay comfortable and where project-based work makes them uncomfortable in a productive way.

The 40/60 rule that nobody wants to hear

Here's an uncomfortable truth about what senior software development actually is: forty to sixty percent of it isn't writing code.

It's getting requirements clear enough to be actionable. It's reporting progress in a way stakeholders can react to. It's escalating problems before they compound. It's negotiating tradeoffs with people who own budgets, deadlines, and other teams whose work affects yours. It's diagnosing when a working relationship has become the actual bottleneck and doing the political work to unstick it.

Good developers can do some of these things. Rare developers can do most or all of them. This is the actual filter that separates production-grade senior engineers from people with the same title who never quite deliver.

The reason project-based work exposes this and team augmentation hides it: in a project engagement, you have to do the communication work, because you own the outcome. The 40-page system architecture document that nobody reads except the one IT guy who's floored that somebody wrote it down. The 52-page post-mortem that names what came from the previous contractors, what came from client-side negligence, and that one page you really hope nobody reads about what you did wrong. The three-page executive summary that translates the 52 pages into a decision the executive team can actually make. All of it. That's the work.

In team augmentation, the contractor doesn't own the outcome. The client's PM does. So the contractor doesn't have to do this work, and mostly can't (the political capital isn't theirs to spend). The 40/60 stays with the client, which is where it was already stuck.

The partnership illusion

There's a specific line I've heard from clients about their augmented engineers, and I've said it myself back when I was less honest about it: "You're not a contractor, you're a trusted partner."

It's a nice thing to say. It's almost never true.

Team augmentation, structurally, is an employer-employee relationship dressed up in contract-worker clothes. The augmented engineer is treated like an employee for day-to-day work assignment but doesn't have the standing of an employee for anything strategic. They're not in the room when the budget conversation happens. They're not asked about hiring or team structure. They can't push back on process decisions in the way an actual peer engineer could, because everyone knows they can be cut at contract end.

Over time, the relationship trends toward the actual power dynamic: transactional. Trust that was rhetorically claimed at the beginning of the engagement erodes without anyone noticing, because it was never structurally established. That erosion is what makes long-term team augmentation feel Sisyphean from the vendor side. You're pushing the same boulder up the same hill, and the hill is the fact that you weren't structured to be a partner even though you were told you were one.

The way to be a real partner is to own outcomes together. That's what project-based work is. That's what the contract structure of a project engagement does. It puts the vendor on the hook for a specific thing the client actually needs, in a way that creates real interdependence for the duration of the project. Trust in that relationship is earned, and it can compound. Trust in a team augmentation relationship is claimed, and it tends to erode.

When we still recommend team augmentation

To be fair to a service line we do sell: team augmentation is right in specific situations.

Genuine short-term capacity shortage. You have a defined amount of extra work over the next several months, and you can articulate what "done" means for it, but you don't want to hire full-time for a temporary need.

A specific technical gap. You need someone with a specific skill (Docker infrastructure, a Rails upgrade, mobile expertise) that your team lacks and that would take too long to develop internally.

A strategic knowledge-transfer engagement. You want a senior contractor to mentor your junior developers on a specific technology or practice, and there's a clear exit plan.

Bridge to a hire. You know you need a full-time engineer, you're actively recruiting for that role, and you need capacity in the meantime.

Notice the pattern. In each of these, the client can name the specific problem the augmentation is solving. That naming is what makes it different from team augmentation as a workaround for something else.

The honest ask

If you're considering hiring a contractor to plug into your team, ask yourself one question first: if the augmented engineer works out perfectly and ships everything they're asked to ship, will the project be done in the time you said it would be done?

If yes, you have a real capacity problem, and augmentation is the right answer.

If no, you have a leadership problem, and augmentation is going to make it worse.

That's the honest version. I've had that conversation a lot. Most of the time it saves the client from a bad engagement. Some of the time it converts into project-based work. Once in a while, the client hears it and hires someone else who's willing to be less honest with them.

That's fine. We'd rather lose that engagement than take it.

---

If you're staring at a team that isn't shipping and trying to decide whether to bring in outside help, it might be worth an honest conversation before you sign anything. That's the kind of scoping call Rock Agile does. Get in touch.

Kanban vs Scrum: Which One Is Actually Right for Your Team?

The most common answer you'll hear is "it depends," which is true and also useless. So let me be more specific: it depends on how much your team trusts each other.

Both are agile processes. Both are designed to be flexible. Both are meant to give developers ownership over how the work gets done. The differences are less about ceremony and more about what the process assumes about your team's culture.

Scrum in one paragraph

Scrum organizes work into sprints, usually two-week windows. You commit to what you'll finish in the sprint, work through it, review at the end, rest, and start the next one. The rhythm is the point. Developers get autonomy inside the sprint boundary, and everyone gets a predictable cadence for checking in on whether things are on track.

Scrum works best on larger teams and on longer projects, because the sprint boundary gives you natural checkpoints to reassess priorities without renegotiating every day. It's also better when the business needs predictable delivery windows for reasons beyond engineering: sales cycles, regulatory dates, customer commitments.

Where Scrum breaks: teams under pressure to squeeze more work into each sprint often skip the rest and review beats. Sprint after sprint of stretch goals with no recovery time is how you turn a healthy Scrum team into a burned-out one. Once the trust in the sprint boundary is gone, it doesn't come back easily.

Kanban in one paragraph

Kanban is looser. Work items sit on a board with fixed columns (backlog, in progress, review, done, whatever fits your workflow). Developers pull the next item when they finish the current one. There's no sprint boundary. The team's throughput is what it is, and you measure it directly instead of guessing at it in sprint-planning meetings.

Kanban works best on smaller teams that already trust each other. Without the sprint boundary, the rhythm is set by the team's actual pace, which means it only works if everyone shows up and does the work. A high-trust team gets more done in Kanban than they would in Scrum because there's less ceremony overhead. A low-trust team drifts.

Where Kanban breaks: if trust is uneven, the fast developers end up carrying the slow ones. Nobody talks about it in standup, because there's no natural moment to. The imbalance just accumulates until somebody quits.

So which one?

Honestly, ask this: does my team trust each other to do the work without external pressure?

If yes, Kanban is going to feel lighter and get more done. If no, Scrum's rhythm will do some of the work for you until you've built the trust to move to something looser.

That's the actual question. The methodology books frame this as a choice about the work (is your work continuous or bursty, is it high-volume or high-complexity), and there's some truth to that. But in practice, the deciding factor is almost always the culture and the trust level. Choose the process that fits the team you have.

What we use at Rock Agile

We use Kanban. It fits a small, high-trust team, and it lets us respond to whatever the client needs without renegotiating a sprint plan every two weeks. If that stopped working, if we grew or the trust changed, I'd switch without ceremony. What matters is the work getting done well and the client staying happy. The process is a tool, not a religion.

---

If you're rethinking how your engineering team plans and delivers work, that's the kind of conversation Rock Agile likes to have. Get in touch.

Inheriting a Dev Project: How to Not Blow It in the First Two Weeks

At Rock Agile, we do this a lot. Someone hands us a codebase they didn't write. The original developer is gone. The documentation is stale. The tests may or may not run. The business owners want progress soon, ideally last week. This is one of the specific things we're hired for, and after years of doing it, I've learned there's a shape to the work that keeps you out of trouble.

The shape has one non-negotiable at the front: you have to check yourself before you touch anything.

Start with your mindset, not the code

Developers are naturally judgmental. We look at somebody else's code and our first instinct is to see what's wrong with it. Sometimes the code deserves the judgment. More often, we're just missing context the original developer had, and our judgment is going to blind us to what the code is actually doing.

There's a Henry Ford story I keep coming back to. Ford would take job candidates to dinner. If they seasoned their food before tasting it, he wouldn't hire them. He wasn't afraid of change, he changed things constantly, but he wanted leaders who would understand what was on the plate before they started rearranging it.

The principle transfers to software. Understand what the code is doing, and why, before you decide it's wrong. Prejudgment on an inherited codebase is the single most common mistake I see, and it usually looks like premature refactoring or optimization on parts of the code we haven't earned the right to change yet.

Curiosity works better than judgment. Come in expecting to be surprised by what you find.

Understand what the software is supposed to do

Before you dig into how it works, understand what it's for.

The best case is a product owner who can walk you through the business logic. If you have them, use them. Ask why the software exists, what problem it was originally built to solve, and how that problem has evolved. Understand the constraints that shaped the original architecture, even the ones that no longer apply.

If the product owner isn't available, the next best source is any developer who worked on it before. Ask what was tried, what worked, what didn't, and what problems keep coming back. Repeated bugs and repeated attempts to fix the same thing usually point to something structural that the previous team knew about but couldn't get to.

If nobody is available, the code has to teach you. That's slower, but not impossible.

Get a working environment before anything else

Before you form opinions about the code, get it running. Bootstrap it. Run the tests. Click through the features. Take notes on what works and what doesn't. Test in multiple environments if you can. Differences between platforms are often where the most interesting bugs live.

The specific move I make early on a Rails inherited project: find the biggest files. That's usually where the core domain lives, or where things went wrong. Read the dependency graph next. The Gemfile tells you what problems the original team decided to outsource, and outsourcing decisions age faster than internal code.

Set a timer on rabbit holes. Early in my career I gave myself five minutes on any tangent while getting a new project running. That habit still runs in the background now. I'm faster at recognizing which threads are worth pulling and which aren't. It's a discipline worth building.

Work with the existing decisions before you change them

Now you know what the software is for and how it runs. Only now should you start considering changes.

Software development is trial and error, and it's a lot more of an art than most engineers admit. My rule for inherited projects is to prioritize working with the previous team's choices before replacing them. Sometimes the choices are wrong (plenty of them will be) but you'll spot the actually-wrong ones faster if you're not fighting the whole codebase at once. And sometimes what looked wrong at first glance turns out to have been the right call for constraints you didn't know about.

When you do start making changes, keep them small and reversible. The goal in the first weeks is to build enough understanding of the codebase that you can commit to bigger changes with confidence.

Take notes obsessively

I cannot overstate this. Write down what you tried, what worked, what didn't, and what confused you. This is partly for your future self: a month from now, when something breaks, you'll want to know what you were thinking today. But it's also for whoever comes after you. Somebody will inherit this project from you eventually. The notes you take now become the documentation they'll wish existed.

Share your findings

Software isn't a solo sport. Share what you've learned with the client, with your team, with anyone else who touches the system. Other people will see things you missed. That's what makes the process work.

The through-line

The pattern is: discovery before decisions. Every step above is really about earning the right to change the code. The developers who blow up inherited projects skip the discovery. They come in confident, refactor too much too soon, and then can't tell whether their changes broke something existing or exposed a bug that was always there. The developers who inherit projects well are the ones who move slower at the start and faster later, because by the time they're touching things aggressively, they know what they're touching.

---

If you're looking at a legacy codebase you inherited, or one your team inherited, that's the kind of work we do. We come alongside your team, do the discovery work, and either help you build on what's there or rescue what needs rescuing. If that sounds relevant, get in touch.