Stories about Software


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.

newest oldest most voted
Notify of
Pop Catalin
Yup, I’ve had countless discussions with management about, “You should only build the architecture, leave the project and let some team in another (cheap*) country do the grunt work! That’s the future”. I’ve failed miserably at making them understand why this won’t work for so many reasons …. Or “You have tremendous knowledge, we wan’t you to stop coding and teach others everything you know … in two weeks… or is that going to take longer?” There’s one thing I disagree though with the article. Software Architect position is not a comfortable retirement plan. I’s a new position where you… Read more »
Andy Bailey

How true, one reason why I would never “officially” become one.

Erik Dietrich

Is this relationship between architecture and management something you’ve experienced across multiple companies, or is it more localized, out of curiosity?

Pop Catalin

It could be more localized and a more subjective experience. However I’ve occasionally learned about similar experiences. But it’s not something I would call common.

Erik Dietrich

Understood. It’s been my experience that, more often than not, management and the people with architect titles tend to be relatively cozy. There’s something I kind of like about architects serving as a shield for the development organization… I mean, that’s a dysfunctional organization, but I like that the most experienced technical people are sort of defending the group.


I’ve seen both. Generally, if the architect still codes in any way and they have some spine, then they are constantly battling management.

Individuals in roles like “Enterprise Architect” or the like appear, at least from the position of line developers, to be indistinguishable from managers.

Erik Dietrich

Agreed, particularly on the EA count. When I see that, it appears to me that the devs tend to think in terms of having an HR manager and a “technical manager” if the EAs are hands on. If there’s a team of them, the devs tend to think of them as management consultants they don’t really need to listen to.

Andy Bailey
I could be considered to be of an age where “Software Architect” is a position I should be occupying. But Software Architect is a role I already take on as part of my role as “Software Developer”. Is there a clear description of what a Software Architect is? Apart from the ephemeral job descriptions you see on the ‘net from companies looking for something they are not entirely sure about I have yet to find one that meets with consensus. I have long bought into the idea that Big Corporation has no idea about us Knowledge Engineers and where we… Read more »
Erik Dietrich
I think the answer will come without any overarching or centrally planned movement. As an individual, with one (or maybe a few) vectors of bargaining at the moment, it’s easy enough to be risk averse when it comes to the idea of undercutting with cheaper labor. But I drift around from large org to large org, watching them clean up outsourcing messes, vowing never to do it again, and also struggling to convince someone, anyone to come work for them. On top of that, I see the overseas firms in places like India become so expensive that the value proposition… Read more »
Andrew Powell
Excellently articulated article, and well-written. But I couldn’t disagree more 🙂 I’ve worked with too many “developers” that couldn’t put together a well-constructed solution to save their lives. They can write oodles of code, they may have all kinds of algorithms memorized, but the organization of that code is severely lacking. In our org the folks who are architecture-minded, with regard to software, don’t just plan the structure; they work on the structure and future-proof the structure. In many cases we provide the structure on which others write supplemental code. I held a title of “UI Architecture Engineer” for a… Read more »
Erik Dietrich
I think we can agree on a problem space, but maybe not the solution. What I mean is, I wouldn’t argue the point that many developers make short-sighted decisions, nor would I argue the point that at least some people on the team (if not all) should take a strategic look at where things are going. In other words, I’m not arguing against architecture to software. I’m arguing that the business shouldn’t artificially create two different roles, with different titles, pay bands, levels, and measures of respect. Couldn’t the problems that you mention all be solved by hiring a better… Read more »

A little bit of perspective: the hiring process is very expensive, and in some areas (industry and geography) it’s excessively expensive to find “better caliber of developer”, specially because some people are very good interviewees but poor professionals, adding risk to the price. When you have a high-level label, you start off with a much more narrow sample of people to look at. It’s obviously not a silver bullet, but is a potential way of making things easier economically.

David Ferreira

The hiring process does not have to be as expensive and time consuming as it is. And there are numerous paths to finding a better caliber of developer. In the end, the company has to commit to creating a better hiring pipeline, has to better understand how current methods lead to bad hiring decisions, and most of all be prepared to be competitive in every sense of that word – salary, open to remote work, assessment of skills necessary, and understanding what a “good” developer really is as opposed to what we accept as the current flawed definition.

David Ferreira
What I have seen is that the reason we have developers who are unable to put together a well-constructed solution is that we approach hiring those developers in the wrong way. We value memorization of largely irrelevant algorithms over the craft of software development, and so we hire accordingly and wonder why we get such crappy results. Software Architects (of which I am one) grew up as an internal defense mechanism in corporations to protect the company and its customers from the software product the company produces. Basically the internal development community collectively threw up their hands and asked management… Read more »
Alexander Hansal
This article (and the book, can’t wait) is so spot on, thank you. I do not even know where to start commenting, but I couldn’t agree more. The construction analogy does not hold up, but construction industry has a concept of the site manager who usually has technical education, long experience and knows the details good enough to keep the concrete pouring. So apart from architects (they are sure needed), we might need more site/construction managers, even if the job title is less appealing. Having said that, software (it’s ‘soft’) never compares fully to the hard world, it changes more… Read more »
Erik Dietrich

Thanks — I’m glad you like!

The subject of metaphors for software is one that, as a writer and developer, I often wrestle with. I’ve sort of come to the opinion that some are better than others, but with just about all of them, people cling so hard to them that bad things result. I don’t have a great solution for this problem, even though I suspect it costs the economy billions, if not trillions of dollars.