Why is Staff Aug a Dirty Term?
“Don’t worry. We’re not a staff aug firm or anything like that.”
Years before this would matter to me, I remember some recruiter saying this to me on the phone. I didn’t know what “staff aug” meant, so I remember looking it up afterward. I won’t force you to do that, though.
Staff Augmentation: a Definition
“Staff aug” abbreviates the longer form term staff augmentation. Wiki attempts to utterly crush readers’ souls by calling it:
“[an] allocation of dedicated technical resources, usually offshore, hired as overseas development extensions of in-house application development teams on fixed or flexible terms and conditions.”
Jargon aside, it refers to hiring a relatively disposable contractor in lieu of a more permanent employee.
Over the course of the decade following that recruiter call that I never pursued, I learned a great deal more about this subject. In the world of custom app dev (er, excuse me, “consulting”), you have two types of firms.
First, you have staff aug firms, and then you have firms that scream from the rooftops that they would never stoop to the gutter of staff aug. Apparently, there’s nothing in between.
Don’t believe me?
Check out this post from an app dev shop. In 2015, they derisively called the staff augmentation firm a “body shop” and declared it dead.
“The recruiting and staff augmentation model is losing popularity in the industry – they are going the way of the dinosaur. Dunzo.”
Two years later, it turns out that reports of its death may have been greatly exaggerated.
Still, why all of the hostility and scorn? Why does the industry split this way?
Staff Aug from the Client’s Perspective
Have you ever worked alongside some guy who seemed unremarkable until you learned that he didn’t really work for your company?
He could have fooled you, though. He came in every day, attended all of the meetings, and exhibited consummately middle-of-the-pack amounts of skill. But in spite of looking, walking, and quacking just like a fellow employee, he turned out to be contractor.
To make matters even more mystifying (and aggravating), you subsequently learned that the company pays a lot more for him than for you. At some point, you probably (half) joked to a coworker that you should quit and return as a contractor to make twice the money.
Inside, you may have seethed at the injustice of it all. Why should he make so much more when you do better work?
You may not like the answer.
In my answer lies the first whiff of Developer Hegemony concepts. Your relative programming skills matter far less to the organization than your relative risk as resources.
As an employee, hiring and firing you becomes messy. Not so the contractor. So the risk comes out of your paycheck, and the lack of risk goes into his. Ironically, his risk doesn’t climb too much higher than yours.
Remember, he looks, walks, and quacks like an employee. So managers often express less trigger happiness than the contractor designation warrants, making his expected value greater than yours.
And so long as this relative arbitrage exists, hybrid recruiting/staffing agencies are most certainly not, “dunzo”.
Staff Aug from the Agency’s Perspective
Let’s return now to our two types of (loosely considered) consulting firms:
- Staff aug
- Those that rail against staff aug
Staff aug firms, like recruitment firms,offer a middleman matchmaking service, like a temp agency. They do the dirty work of recruitment, hiring, HR, and all that, allowing their clients to truly view software developers as fungible commodities.
Staff aug makes this pretty turnkey for the clients — staff a department without the messiness of employees. The agencies claim a bit of margin off the top for the administrative cost. They operate a business that thrives at high volume and low margin, sort of like fast food joints selling burgers for slightly more than their cost.
App dev agencies, on the other hand, take a different approach. They also save clients the dirty work of HR considerations.
But, on top of that, they also save the dirty work of another layer of expertise. They at least participate in project management, and they agree to a stake in the outcome of the project or initiative in question. While they also earn margin on labor, they tend to do so in a way aligned more with big picture outcomes, such as projects and programs.
They also like to staff project teams or even whole programs, rather than supplying labor force at arbitrary granularity. They thus prefer a lower volume, higher margin approach.
Like a steakhouse.
How Firms Catch Fish
With these two business models in mind, consider how the two different types of firm go about selling. To aid with this, I’m going to enlist a bit of metaphor.
Staff aug firms have apparatus wherein they drag massive nets behind them, scooping shrimp en masse from the sea floor. App dev consultancies, on the other hand, go deep sea fishing for ocean monsters.
The sales staff of a staff aug firm plays a numbers game. Their sales operation orients around low touch, high volume activities. Cast a wide net for resumes, advertise digitally, and generally engage in activities with low cost per match made.
The sales staff of a custom app dev shop plays a different sort of numbers game. Heavily occupy meat space, do a lot of personal schmoozing, and generally spend money and effort landing big clients, because one success pays for days and days of failures.
In reality, this means different philosophical sales approach. For the average staff aug firm, you’ll have lower stakes, more digital presence emphasis, lower touch, and more systemized approaches.
For custom app dev shops, you’ll have higher stakes, more one on one chats and schmoozing, relationship building, and more conception of prospects as unique snowflakes.
So, Why Is Staff Aug a Dirty Term?
Alright, now we can talk meaningfully about the source of this disdain.
If you look at the contrast I’ve drawn, you’ll notice a meaningful contrast. Their sales staff and approach offer philosophically different approaches businesses can take for the same basic problem. And, while custom app dev shops may directly compete with one another for a given client, they compete more existentially with staff aug firms.
If MegaCorp selects Alice’s Awesome App Dev instead of Carl’s Coding ‘n’ Consulting, both firms still live to fight another day over MegaCorp’s next RFP.
But, if MegaCorp instead staffs up through Steve’s Software Staff Emporium, Alice and Carl will have a much harder time catching massive fish. Alice and Carl know how to compete with one another, and tailor their approaches accordingly.
But they simply cannot pivot and start to compete with Steve because they have entirely the wrong sales and marketing approach and personnel.
So they adopt the motto, “if you beat ’em, and you can’t join ’em, drag ’em through the mud.”
The higher margin firms adopt a stance toward these competitors reminiscent of brand name medicines or food talking about generics. Well, sure, go with that brand — I can see why a few measly dollars matter more than the health of your family.
Beyond the Marketing Pages
Okay, so we can see why a custom app dev shop would take a shot across the bow of staff augmentation (“body shops”) and, like a dad trying to sound cool to the whippersnappers, go so far as to use the groan-inducing neologism “dunzo”.
But they don’t control everyone’s attitude. A decade ago, a recruiter assumed that I, as a software developer at a product company, would not want to dirty myself working as a staff aug.
Why?
Here, I’ll dive fully into the world of Developer Hegemony. And I’ll use my previous definitions of the corporate hierarchy.
The organization’s opportunists manufacture superficial corporate culture to convince the other players that the company’s best interests are their best interests. Idealists buy in and pragmatists go along with it whatever they believe.
So what we have here is opportunist-manufactured culture at the industry scale.
The opportunists at non-staff aug firms understand the threat dynamic of a bargain brand to a premium brand. So they convince all players of the inherent superiority of the premium model.
Part of this comes easily with the disparity in bill rates alone. It feels better to have labor worth $150 per hour than $80 per hour.
But the rest gets tricky, since staff aug firms have virtually no politics or culture to speak of by their very nature. Their culture is the client culture.
And so the cultural challenge for the custom app dev shop involves the delicate act of serving while simultaneously asserting superiority over their clients.
Hierarchy in the Client-Provider DMZ
For idealists, this happens almost automatically. Idealists tend to believe in the inherent superiority of their own organization as a matter of course.
This makes inferiority of staff aug a veritable tautology for them. “If staff aug were good, our company would do it. But they don’t and they say it’s terrible, so it’s terrible.”
For journeyman idealists, organizational leadership has a similarly easy task. Simply offer the ready-made conclusion that client’s developers (and staff augs) fall below them in the grand universal stack ranking of all programmers.
Again, you have a near tautology. “If staff aug programmers were good, they’d come here where the good programmers are and then wouldn’t be staff aug anymore.”
Pragmatists, on the other hand, have too much perspective for easily swallowed cultural/meritocracy narratives.
You culturally appease them with perks. Pay them better than client’s folks, give them better tools, better benefits, and flexibility to move among situations until they feel comfortable. Superior culture for them happens via feeling relatively content and stable.
But it gets more interesting with non-leadership opportunists. Why?
Because they don’t care a lick for culture narratives. In fact, they’d go work at the client in a hurry as an employee or staff aug if that seemed a better situation. Keeping these folks in the fold requires more tangible considerations and meaningful differences.
Opportunist Lessons from the Staff Aug/Project War
Put on your opportunist hat and look at the two different firms with their two different sales models.
- The staff aug firm sells individual people (or enough of them to constitute a group). These people will then do whatever custom things the client wants, under the direction of a client manager.
- The custom app dev shop sells project teams and work. These people will then do whatever custom things the client wants, under the direction of a project manager from the custom app dev shop…. but ultimately that falls under some kind of client manager a little higher up.
So, really, both kinds of shops do custom things for the client under the direction of a client manager. And both do it on a time and materials basis because both sell labor as a product.
The main difference is that the custom app dev shop employs a more hands-on sales staff to sell it in a larger unit and a more impressive package. The opportunist then realizes that staff aug is a dirty term only because of effective marketing.
In fact, there’s nothing remotely “inferior” about selling yourself as a pseudo-employee as opposed to selling yourself as part of a temporary project team.
Efficiencer Lessons from the Staff Aug/Project War
Yesterday I publicly defined the term Efficiencer (a lot more detail in Developer Hegemony).
You can think of this as someone with software development skills that wants more autonomy and agency in their career. You can also thing of an efficiencer as a business-savvy automation professional for whom programming is just part of a consultative skill set.
With that in mind, what lesson does the efficiencer learn from this positioning battle over staff aug?
Simply put, the efficiencer realizes that all custom, open-ended, time and materials work constitutes staff aug.
You bill hourly for custom work when you have no idea how to value it for clients. “I don’t know what this is worth, but I know my expenses, and I know that I need to bill $120 per hour to break even. So… let’s call it $150 per hour so I make money.”
Oh, I realize that’s not what the client hears, but it’s how the thought process goes.
When you punt on knowing the value of your labor and leave that to someone else, you are, by definition, a resource. And, since you are also a human, this makes you de facto staff.
And, while taking work on a project basis rather than a quasi-employee basis means relatively more trust and influence, you squander that to some extent by acting as staff en masse.
So the efficiencer lesson is simple but challenging.
Until we become expert enough in an automation niche to price based on something other than our time, we’re all doing staff aug, whatever we might want to call it.
No Fields Found.
So…the Staff Aug problem (of charging time and materials) in a way becomes a root of all estimate hell. The project calculus MUST have an estimate in order to place a cost on the desired result. Since firms bill hourly and the true cost could never really be known, the risk of slippage costs falls on the product shop’s books (unless the client is clueless). Therefore the product shop must charge more to compensate for risk. But a staff augger probably won’t carry as much risk, since the project is going to be run internally. Worst case is the augger(s)… Read more »
It’s sometimes hard for me to speak about this in anything other than the abstract, because I’m really experimenting and figuring it out for myself as I go. But I’ll try to address it in a way that doesn’t feel like pure fluff. I completely agree with what you’re saying here about risk, and the tradeoffs between who assumes it. Anything we do that amounts to “do a huge, custom app dev project” will have, for all intents and purposes, unknowable cost. The prospective value to the owner of the project will probably be a little bit more knowable, but… Read more »
Very good point here! As I read the article you linked to, I nearly chuckled aloud from the combination of FUD and “methinks he doth protest too much”. I’ve worked for both types of firms. All else being equal, the staff aug feels like a step closer to true consulting. At the very least, it puts one less layer of management between me and the folks who need software. It depends a lot on the individual client, but so far there’s been quite a lot of leeway to sit down with the stakeholders and have some good conversations about what… Read more »
So when you do staff aug roles, does an agency place you in them, or do you negotiate them on your own terms with clients?
It’s a little bit of both. Usually, the client has a specific, finite-term project in mind that they are bringing to my agency. It’s typically something along the lines of “We are migrating our SaaS platform from self-hosting to AWS, and we are wondering if you have an AWS expert available for a few months”, or “We need to add additional 3d capabilities to our in-house CAD package, and Ted, who’s been maintaining the CAD package, just gave his notice. Do you have anyone who could help?”. Usually, then, the agency plays match maker. I talk with the prospective client… Read more »
I really like this angle of staff aug agencies flipping over to efficiencer match making agencies. I hadn’t thought at all about that, but it’s a much more natural fit than app dev agencies trying to change their spots. A matchmaking outfit that’s either taking a small margin or getting a referral fee would have a lot less trouble switching over to applying that same model to an efficiencer firm offering fixed contracts or productized service offerings. I can see them saying, “sure, if the client buys, we’ll take a cut of that.” I could even see them beefing up… Read more »