Staff Augmentation is as Staff Augmentation Does

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, are 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 def (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.

Read More

Good Companies Don’t Ask You to Share. They Make You Want To

“So please, go ahead and share this with your social networks.”

I imagine that your company says stuff like this to you all the time.  So frequently, in fact, that you’re probably sorta numb to it.

• Hey, we’re hiring!
• Our company was just nominated for Who’s Who in American High School Students Companies!
• We’ve got a new product release coming up!
• Steve is talking at a networking event!

“So please, go ahead and share this with your social networks.”

It’s an Innocuous Request… And It’s Also Okay If This Rubs You Wrong

I can remember the first time I heard this.  Before, I’d spent the first part of my career working in companies that manufactured products, with software as only part of the equation.  Because of the developers’ relative anonymity and the relative newness of social networks, I never encountered any request like this.  It simply wouldn’t have come up.

But this particular year found me working at a shop selling app dev (and calling this “consulting”).  With the people as their product (or at least the people’s labor), the individual contributor software developers had more of a prominent role.  And so the request came.

“So please, go ahead and share this with your social networks.”

I don’t remember what it was that we were supposed to share or tweet or whatever the verb for that on LinkedIn is.  The company may have been asking for help with recruiting, marketing, sales, or something else.  It doesn’t matter.

For our purposes here, what matters to me is that this rubbed me the wrong way.

I didn’t really know why at the time, and it’s taken me years to start to understand why.  I wasn’t embarrassed to work there or anything.  It was… a place that gave me money in exchange for labor. And that’s a thing that most people do.  The request wasn’t onerous and it didn’t compromise my morals and ethics in any way.  Even the fact that it was a request to do something of value for free occurred to me, but didn’t bother me.

Still, though.  I didn’t like the request and didn’t do it.

Years later, this request is probably much more common.  For the rest of the post, I’m going to expand on why this might rub you wrong, why that’s okay, and what should happen instead.

Read More

How to Write Software: 5 Lessons Learned from Running Businesses

I used to write software for a living.  I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.

But I learned this from the perspective of, well, a wage software developer.  Today, I’d like to reflect on how my view has evolved over the last number of years.

Software as a Software Developer versus Software as a Business Owner

As longtime followers of this blog know, I’ve had a meandering career.  I started this blog as a software developer, new to moonlighting.  Eventually I moved into management and then started doing developer training activities.  From there, it was a number of years of consulting.  And finally, these days, I’m mostly running a business that is growing rapidly.

I say all this not to treat you to an unsolicited autobiography, but rather to set the scene and to help explain what I’ve been doing between my last full time software development gig and now.

These days, for Hit Subscribe, I’ve started writing software again.  I don’t do it full time, by any stretch.  But I am building a line of business app used directly by four of us and indirectly by something like 30 people.  So it’s not my primary living, but it’s not trivial either, in terms of importance or scope.

Dedicating some time to this has caused me to reflect on how my perspective has changed.  Don’t get me wrong.  I never stuck my head in the ground pretended “the business” didn’t exist or didn’t matter.  But then again, I never was the business, either.  It was never my money in play.

Now that it is, here are some musings.  And please bear in mind that I’m not teeing these up as lessons you learn.  They are simply how my perspective is different.

Read More

Coding as the Boss: My Story of Developer Hegemony

Last night (this morning), I clicked “publish” at about 3 AM and went to bed.  Now, those of you who follow this blog probably assume that I clicked “publish” in WordPress, firing off a 3 AM blog post.

Not so.

I did this in Visual Studio, where I published a little web app called El Dorado to Azure.  I source control the thing in Github and I publish to Azure, where it serves as a little line of business application for me and some of the staff at Hit Subscribe.  And, while a Visual Studio publish isn’t exactly state of the DevOps art, it gets the job done.

The significant thing here isn’t any of the techs that I’m using.  It’s also not the fact that I was up late coding, nor is it the purpose of the app.

What matters here is that I own a non-trivial and growing business and that I’m also writing code.

The Classic Management Track vs Technical Track Conundrum

Years ago, I wrote a blog post in which I told a story of something most enterprise-y/corporate programmers encounter sooner or later.  It’s the “where do you see your career going, management or technical” question.

Choose wisely, young programmer.  Down one path, expense accounts and Gantt charts await.  Down the other, UML diagrams, and… well, probably also Gantt charts.

I could never really wrap my head around this dichotomy.  I mean, I get that furiously banging out code and leading departments are somewhat divergent activities.  But I never understood why the line blurred so little and so infrequently.

I poked around the internet a little to see if this was still true, and I think it mostly is.  I found some posts like this one, talking about the coding dev manager.  But this has always seemed like just taking the role that most companies call “architect” or “tech lead” and having people actually report to it.  That just kind of kicks the can down the road slightly.  If you’re a “coding manager,” you’re probably in a fairly vertical, tech-focused organization where line managers still don’t really think about “the business.”

Are Technical and Business Savvy Mutually Exclusive?

So this begs an interesting question.  Are technical savvy and business savvy mutually exclusive?

Oh, I mean, don’t get me wrong.  I’m not honestly asking whether techies can become startup CEOs or whether leaders with f-you money couldn’t learn to code.  Of course those talents can both exist in the same human being.

What I’m asking is whether or not someone can do both of these things meaningfully, at the same time.  Can someone run a department (beyond a “tech-lead-y” line management role) and also have legitimate business reasons to bang out code, and do it halfway decently?

I have a hypothesis that the answer is yes.

Yes, people can run non-trivial organizations while having good reason to code.  And no, applied, simultaneous technical and business savvy are not mutually exclusive.

Read More

Transmuting Low-Value Programmer Cred into High-Value Status Illegibility

Not long ago, I wrote a post about that one, “top” software engineer role that companies don’t hire directly into.  I’m going to pick up where I left off there.

For a quick recap, recall the diagram I made (and my wife kindly GIF-ified for me).  In red, you have the positions that a company will hire into, and in white, you have that one position that they won’t.  It’s usually “Principal Engineer” or something like that.

A Recap of The Surface Narrative and the Real Motivation for This

In the last post, I talked about the surface explanation for this, accepted by idealists and pragmatists.

This role represents the most valuable software developers in the group to the company.  These developers combine technical skill with a certain je ne sais quoi that combines experience, domain knowledge, inside company baseball, and embodying the company’s values and training.

But I also talked about how that doesn’t stand up to scrutiny.  I talked about how if you picked the brains of leadership, you’d probably hear something like this.  (Assuming you also gave them truth serum.)

It seems like a win for everyone.  It rewards people for staying, makes us seem more prestigious, and it’s a non-monetary reward.  They love it, and it doesn’t cost the company anything to do.

Significantly, that top role that requires hanging around the company for years, serves a very pragmatic purpose.  It creates a position whose salary can creep up, unbounded, without dragging up the salary for the rest of the group.

In other words, create a bucket, put your lifers in that bucket, and give them 2% increases a year forever.  Without that bucket, you’d either (1) have to stop giving them increases or (2) potentially have to pay new hires a lot more.

So you create this policy to keep labor costs down.  And then you stand aside while the pragmatists and idealists manufacture and believe a merit-driven narrative.  Easy-peasy.

Read More