Software Architect as a Developer Pension Plan

I’m pretty sure that I’m going to get myself in trouble with this one.  Before I get started and the gnashing of teeth and stamping of feet commence, let me offer an introductory disclaimer here.  What I am about to say offers no commentary on people with the title, “software architect” (a title that I’ve had myself, by the way).  Rather, I offer commentary on the absurd state of software development in the corporate world.

The title “software architect” is silly (mostly because of the parallel to building construction) and the role shouldn’t exist.  Most of the people that hold this title, on the other hand, are smart, competent folks that know how to produce software and have the battle scars to prove it.  We’ve arrived at this paradoxical state of affairs because of two essential truths about the world: the corporation hasn’t changed much in the last century and we software developers have done an utterly terrible job capitalizing on the death grip we have on the world’s economy.

A Question of Dignity

I’m not going to offer thoughts on how to correct that here.  I’m doing that in my upcoming book.  Today, I’m going to answer a question I heard posed to the Freelancer’s Show Podcast.  Paraphrased from memory, the question was as follows.

I work for a small web development firm.  I was in a meeting where a guy said that he’d worked for major players in Silicon Valley.  He then said that what web and mobile engineers offer a commodity service and that he wanted us to serve as architects, leaving the less-skilled work to be done by offshore firms.  How does one deal with this attitude?  It’s a frustrating and demeaning debate to have with clients.

This question features a lot that we could unpack.  But I want to zero in on the idea of breaking software work into two categories: skilled work and unskilled work.  This inherently quixotic concept has mesmerized business people into poor software decisions for decades.  And it shows no signs of letting up.

Against this backdrop, “major player’s” attitude makes sense.  Like the overwhelming majority of the business world, he believes the canard about dividing work this way.  His view of the unskilled part as a commodity that can be done offshore smacks of business wisdom.  Save the higher-waged, smart people for the smart people work, and pay cheap dullards to do the brainless aspects of software development.

Of course, the podcast listener objects.  He objects to the notion that part of what he does fits into the “cheap commodity” category.  It “demeans” him and his craft.  He understands the complexities of building sites and apps, but his client views these things as simple and best delegated to unskilled grunts.

Why the Obsession with Splitting Software Work?

It bears asking why this thinking seems so persistent in the business world.  And at the risk of oversimplifying for the sake of a relatively compact blog post, I’ll sum it up with a name: Taylor.  Frederick Taylor advanced something simultaneously groundbreaking and mildly repulsive called Scientific Management.  In short, he applied scientific method principles to the workplace of the early 1900s in order to realize efficiency gains.

At first, this sounds like the Lean Startup.  It sounds even better when you factor in that Taylor favored more humanizing methods to get better work out of people than whacking them and demanding that they work harder.  But then you factor in Taylor’s view of the line level worker and you can see the repulsive side.

The labor should include rest breaks so that the worker has time to recover from fatigue. Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation is that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is unable to understand the real science of doing this class of work.

Basically, you can split industry into two camps of people: managers who think and imbeciles who labor.  Against this backdrop, the humanizing angle becomes… actually sorta dehumanizing.  Taylor doesn’t think grunts shouldn’t be whipped like horses because it’s dehumanizing, but because it’s not effective.  Better ways exist to coax performance out of the beasts.  Feed them carrots instead of hitting them with sticks.

Depressingly, the enterprise of today looks a lot like the enterprise of 100 years ago: efficiency-obsessed and convinced that middle management exists to assemble humans into bio-machines that needn’t think for themselves.  Nevermind that this made sense for assembling cars and textile manufacture, but not so much for knowledge work projects.  Like the eponymous cargo-culters, modern corporations are still out there waving sticks around in the air and hoping food will drop out of the sky.

Splitting Simply Doesn’t Work

The modern corporation, like Taylor before it, loosely divides into three categories of humans: owners/executives, managers, and grunts.  Owners own and charge executives with executing their will.  Executives delegate to managers. Managers think and assemble the workers into org charts designed to optimize efficiency.  Workers keep their simple heads down and do as they’re told.

Theoretically, proponents would say, this applies to any domain and type of work.  Corporations form themselves into these pyramids without considering any other options, whether they’re private military outfits, gigantic manufacturing facilities, or companies designing and selling software.  Of course, the reality turns out to be that not all operations do well splitting thinking and labor.  Let’s pick one at random. Oh, I dunno, say, writing software.

We try it.  We hire junior developers to be directed by senior ones.  And all of them fall in line under the watchful guise of a “tech lead,” who defers to a council of architects.  And somewhere at the center of the organizational maelstrom stands The Lead Architect, directing elaborate bucket marches, water flows, and all sorts of magic, like Mickey Mouse in Fantasia.  It’s a beautiful, cascading symphony of work flowing from the cleverest down to the simplest.  Or… at least, that’s how it goes on paper.

Trying to split software development into smart and stupid divisions of labor seems particularly poignant, and not just because most of you and I write software.  The proposition pings between the ironic and the farcical.  If you attempt to split software development into the part that requires thinking and the part that requires mindless repetition, you’re left with two parts: that requiring an intelligent human, and that which could be easily automated.

You see, the entire premise utterly defeats itself.  Assuming this split were even possible, the grunt portion would be an immediate candidate for being automated right out of existence.  In other words, if the Taylor-style division of labor were possible in software, then one could pay managers to automate programming (or at least to direct some mindless programmers to automate programming).

So applying Taylor to software development is paradoxical and absurd.  I’m pretty sure if you resurrected Taylor and explained to him how modern software shops were applying his techniques, he’d say these managers should handle pig iron and let the software developers run things.

But Developer Still Means “Laboring Grunt”

Now, even though organizations structure themselves this way, few would go so far as to claim that software development required no thinking.  And, in fact, many organizations are attempting to lurch away from this model and empower so-called “flat” software groups to self-organize to solve problems.  The going is rarely smooth, since the Taylorism runs deep.

And yet, in spite of this grudging, halting attempt to recognize software development as knowledge work, the line level developer role still carries heavy stigma.  Software developers remain Taylor’s pig iron workers to the world at large, somehow.  We easily command six figure salaries, we have recruiters begging us to return their phone calls, and we have pundits claim that we’re “eating the world.”  And yet somehow we can’t use this massive leverage to stop working for Dilbert’s boss.

Enter the Architect

This becomes a self-reinforcing problem.  But it’s a problem with a nifty deus ex machina.

You can’t write software your whole career and be considered a corporate success.  I loathe typing that sentence, and I loathe even more that it’s accurate.  It’s “common knowledge” in our industry that “you can’t program forever,” as though we were pro athletes or something.  If you enjoy success and notoriety for what you do, you’ll find that you wind up drifting toward leadership responsibilities and then roles.  The organization wants to reward you for exemplary programming by letting you retire from programming.

Now, because there’s a relatively limited need for developer managers, not all good performance can be rewarded with management promotions.  And then, of course, there’s the problem that not all developers want to manage and the problem that being good at programming doesn’t make someone good at managing programmers.

So what do you do with this surplus of high performing developers?  How do you give them leadership roles that aren’t management?  How do you let them ease out of the low-status, career-limiting business of programming?

You put them on a pension plan.  Enter the software architect.  He supervises without official reporting status. He answers questions.  He gets into the code as much or as little as he wants.  He gets out of the delivery trap and into a consulting gig within the organization.  He enters higher pay bands.  He becomes Mickey, and he embodies the “thinking” half of the split, while the lowly developers do the grunt work of typing code at his bidding.

An Answer, at Long Last

Recall that at the beginning, I presented a question asked to the Freelancer show about commodity labor.  The person asking the question was asked to serve as “architect” to an offshore group doing the “low skilled work,” and he found arguing against this to be frustrating and demeaning.  What’s a consultant to do?

Well, the first step is to understand that you’re dealing with a guy who thinks he’s a hotshot for applying a 100 year old management philosophy for manufacturing to software development.  If you want to have that “demeaning” discussion at all, then come armed with a succinct take-down of the idea that knowledge work can be parceled into the thinking part and the “commodity” part.  But I wouldn’t bother with that discussion at all.

And that leads me to step two.  If you’re a consultant tasked with delivering a project, then where your subs are located isn’t the clients concern.  I’d thank him for the ‘advice’ and simply tell him that you want to work with him to set a budget.  If he wants “commodity” work, buy a WordPress theme and charge him time and materials for all of the endless tweaks he wants to it.  “Hey, you asked for commodity and I gave you commodity.”

And the third thing you might want to do is pass on the gig.  If the guy’s vision of his needs and software in general is so very different than yours, then you’d probably both be better served to move on.  But if you’re hesitant to move on, the question you have to ask yourself is whether or not you want to be an architect.  Do you want to work in a Taylor-esque situation, knowing that you’re being put in a rule to supervise delivery of a commodity?  Or do you want to capitalize on your free agent status to forget the corporate structure, roll up your sleeves, and build a thing?

Snuggled safely within a large corporation, you can semi-retire from software development, supervising and advising from the architect role.  You can keep one foot in the tech while not being on the hook for delivery.  But in the world of free agents and small development firms, no such pension plan exists.