Staff Augmentation is as Staff Augmentation Does
For those who work at custom software companies, you may not want to read this.
Join the DZone community and get the full member experience.Join For Free
I'm in the process of drafting a post entitled "What Do You Know That People Would Pay You For?" But what I'll put here in this post, combined with the material for that one, is shaping up to be long. So I think I can carve off an initial, coherent point here about staff augmentation.
That one figures to be uplifting. This one? Perhaps not so much. But I think it's important to establish a premise.
If You Write Code in Exchange for A Salary, You're Either Staff or Staff Augmentation, Depending on Who Signs Your Paychecks.
Now, for those of you that have worked for product/service companies with a software component, you're probably shrugging and thinking "Yeah, no kidding, I'm staff." Ditto those of you who have toiled in a cost-center capacity, maintaining some internal software the company would sooner eliminate.
But those of you that work for custom app dev agencies are probably feeling a little huffy, since most places that sell custom app definitely (i.e. staff augmentation) go out of their way to state righteously that they most certainly DO NOT do staff augmentation. Bear with me, though, all of you.
I don't actually think there's anything wrong with staff augmentation. In fact, I think it's a substantially better model, in most cases, than staff. In accordance with the spirit of Developer Hegemony, I think we, as an industry, should strive to move from staff to staff augmentation, at least as an initial step.
What is Staff Augmentation, Anyway?
I owe you some definition here, especially since I'm going against the established grain. Although, I submit that I'm doing so in the same way as someone objecting to the definition of "literally" now including "not literally."
Go out and look up staff augmentation, and you'll find a good bit of jargon. But the gist of staff augmentation is that a company fills labor needs by hiring a contractor instead of a permanent employee. Companies do this when they have a temporary need for additional help. They don't want to fill the role with employees and then lay them off. So, staff augmentation it is. They hire a contractor on a (theoretically) temporary contract.
Now here's where things get interesting and where I submit that the generally accepted definition gets a little, well, unhelpful. Something becomes outsourcing instead of staff augmentation depending on the granularity of the engagements. If the company pays a firm to send them six individuals, that's staff augmentation. But if those individuals come as a package, that's outsourcing.
Why do I find this strange?
Well, because with either staff augmentation or outsourcing, the goal is to augment your staff, rather than add to it. But if you augment your staff one at a time, it's staff augmentation, whereas if you augment your staff in batches, it's not staff augmentation. And if you ship a project or line manager along with the whole kit and kaboodle, it's most definitely not staff augmentation.
Splitting Hairs Around Staff Augmentation Shortchanges Programming as Knowledge Work
If you do a quick perusal of the top 10 search results (at the time of this writing) for "what is staff augmentation" you'll find that most, if not all of them, specifically talk about software and IT. In other words, "staff augmentation" seems like it should be a universal concept. But in practice, people only talk about it in the software world.
Put a pin in that for a moment, and let's come back.
In the last section, I talked about this granular bit of differentiation. Send over individual software developers by the truckload and have the client manage them, well, that's staff augmentation. But send them over as a package deal, presumably with some set of governing principles or, better yet, with a project manager, and suddenly you have something altogether different.
So staff augmentation is a term that is (1) relatively unique to software and (2) used exclusively to describe not the mechanics of augmenting staff, but rather to (pejoratively) describe a situation where software developers are shipped over without proper supervision. In other words, whether or not something qualifies as staff augmentation depends on a question that should be relatively meaningless: "Who is managing these people, client or vendor?"
For a knowledge work profession, that sounds kinda not at all like actual knowledge work.
Let's Stop Kidding Ourselves about Corporate App Dev
Go look at the other professions listed in the definition of knowledge work. Some of them include CPAs, doctors, scientists, lawyers and architects (actual architects, not software architects). And in none of those professions do we define the nature of their roles by the relative distance from and relationship to a line manager.
So let's get more realistic about our current state, with the goal of improving our future state.
Those of you working for custom app dev shops, stop pooh-poohing staff augmentation as if you were doing a different thing. You're not a contractor, and you're not a consultant. Consultants don't let people pay them to code.
Who cares which company appoints your line manager, or if you come individually or part of a boxed set? You're writing code for a company other than your employer, and you're doing so because they need to flex up their labor temporarily — augment their staff — if you will. That's what you're helping with. And that's perfectly fine.
And for those of you who are staff software developers, waiting patiently for how this applies to you, I'd say that in many situations you'd be better served augmenting staff. I say this whether you want to go free agent or whether you want to work for a custom app dev shop. If you're working for a firm that builds and ships software as a product, then have fun and stay put. But if you're working for a firm that doesn't, then you're a cost center and a commodity.
Staff to Staff Augmentation to Consulting: Looking Toward the Future
So what's my point here in the end? Well, originally it was in the service of the mega-post I'd been banging out. I think we need to move toward a world where we, as software experts (efficiencers) find ways to get paid for what we know, rather than what we do. But that's a story for another day soon.
In order to move toward that goal, we need to stop kidding ourselves about the present. That means not sitting in an office all day with headphones on, banging out code for a customer that we've never met, and calling ourselves "consultants." It means not settling for meaningless moral victories about the nature of our engagements. And it means not working as staff for firms that view us as commodities and cost centers to be phased out.
I titled the post the way I did to suggest that it's the nature of your work, rather than what you title it, that matters. So let's look at the nature of that work and think of a progression toward expertise and authority.
Going from staff to staff augmentation means going from cost center in a non-software firm to a professional provider of software labor. Going from staff aug to consultant means that people start paying you for expertise instead of labor. And that's a powerful position to be in. But we're never going to win the race until we stop calling wherever we happen to be standing the finish line.
Published at DZone with permission of Erik Dietrich, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.