DaedTech

Stories about Software

By

Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development

Well, today we officially launch the book, Developer Hegemony.  I’d like to thank everyone who followed along, offered feedback, bought books, and generally supported the efforts.  I’ve enjoyed the ride and I hope you all love the book.  Also, congratulations to the winners of the Thunderclap raffle: Justin Neff, Jim Wang, and Gintautas Miselis!  I will be sending free copies their way.  Thanks to them and to everyone that participated!

In the final days of writing Developer Hegemony and throughout launch preparation, I wrestled with an elevator pitch.  As regular readers know, you wouldn’t find “brevity” listed on my resume, even if making resumes was something I did.  And so I struggled.  But I think I have it now.

“Why aren’t software developers in charge of the software development industry?  Developer Hegemony explains why not, and it explains how we fix that problem.”

Today, I’ll explain the book by expanding on this elevator pitch a bit.

Who’s In Charge Here, Anyway?

So, if software developers don’t run the industry, who does?  To answer that question, understand the context in which most developers write software.  It happens in the corporate world, which consists of companies shaped like pyramids.

 

Reminiscent of military organizations, a tree-like chain of command serves as the scaffolding for most companies.  The CEO gives orders to a handful of C-suite members.  These people, in turn, give orders to a larger number of vice presidents, who then give orders to a whole bunch of directors.  The directors then give orders to hordes of managers, who pass those orders down to legions of grunts.  Finally, with the grunts, you arrive at the leaves of the tree and the bottom of the pyramid.

And those leafy grunts write the world’s software, carrying pyramids of management upon their backs.  So who is more important than software developers in the business of software development?  Literally gigantic pyramids of management.  Oh, and you can also toss in some people who technically exist in the same level of the reporting organization but have titles like “analyst” or “project manager.”

So the question shifts from “who is more important than software developers in the business of software development?” to “who isn’t?”

Anatomy of Shot Callers

If you think I’m gearing up for an anti-management rant here, I’ll disappoint you briefly.  I’ve enjoyed writing this book, I feel optimistic about the future, and I like my life.  From that vantage, I have difficulty summoning the requisite vitriol to blame players in this game.  And if you read the book, you’ll know that I blame the corporate structure itself and not any of the players.  Who would have guessed that a structure for organizing militaries throughout history might not make the best structure for writing software?

So how do the people occupying these layers of the pyramid profile?  Who are they?  Well, I’ve done it in my career, for one.  And I’ve worked with plenty of others too.  I can split them into two broad camps, vis a vis software development.

  • People that once wrote software but stopped in order to go into management.
  • People that used to manage other types of work and transitioned laterally into managing software development.

So, working backward, you have two paths to meaningful influence in the software development industry.  You can enter software as a software developer and then look for opportunities to stop writing code and start supervising.  Or you can enter never intending to write code, just looking to supervise.  (This also applies to the path of entering as a line-level project manager, which is more or less a sort of internship for line management.)

Global Manufacturing and Hyper-Specialization

Have you ever heard Conway’s Law?  Roughly translated, you can interpret it that organizations will build systems that mirror the structure of their org charts.  And throughout the 20th century, the rise of global manufacturing outfits gave us some unimaginably complex org charts and corporate structures.

You could think of these things as intricate machines, where each line-level employee represents a component or cog.  They have extremely focused specialties and, like a resistor or a spring, they provide only that narrow functionality.  It then takes layers and layers of managers to build a coherent, well-oiled machine out of these human cogs.

Some of the cogs know COBOL, and others know Java.  Some of them know mechanical engineering, and others have experience as power users of Salesforce and SAP.  Maybe some of them know how to test hardware and to test software.  Others know sales tactics, and, of course, some do nothing but exhibit a knack for organizing the office.

Management exists to forge weapons from the fires of this chaos.  When you create structures with hyper-specialized people as cogs, then experts with experience, domain knowledge, and leadership skills assemble the cogs.  Cogs don’t assemble themselves any more than one of the screws in a drill press operates the drill press.

Knowledge Workers Aren’t Cogs

You’ll notice I talked about corporate management throughout the 20th century.  Humans worked as specialized cogs, doing things like working assembly line stations.  Management worked to build and refine efficient systems of humans and machines working in concert, as well as supply motivation and the like.

But as technology emerged, the need for knowledge work moved down the pyramid.  Today, we have the same structure, but the people doing the actual knowledge work of reasoning about and designing complex systems now sit at the bottom.  They have titles like “software developer” and “mechanical engineer,” and they plan intricate and elaborate structures.

The people in management roles, however, continue to apply traditional 20th century management practices.  They try to create intricate systems of people who create intricate systems of logic.  The result tends to go poorly.

We call it “waterfall,” and we laugh at the inevitability of it slamming through its budget and deadlines like a runaway battering ram.  Then we try to fix it by “transforming” it to “scaled agile,” but that doesn’t really help very much.  What we tend not to do is ask whether our fundamental premise — the structure itself — has fatal flaws.  Nobody seems to ask about the emperor’s clothes: “does it makes sense to treat creators of complex systems as specialized parts in larger complex systems?”

Who’s In Charge, Revisited

The managers, directors, and executives that create these complex systems call the shots.  They set strategic direction, approve budgets, evaluate technologies, and make organizational decisions.  Perhaps they once earned a living programming, or perhaps not.  But now they program systems of humans who program systems of machines.  This is how they call the shots in the industry, and they do it with the effectiveness of you using a marionette to indirectly change a watch battery.

Large enterprises struggle to write software.  They optimize to manage risk and thus impose intense bureaucracy, regulation, and formalism on the software process.  They bring in specialists and consultants to help them with efficiency, augment staff, and furnish expertise.  And then they often give up and buy out a startup or something.  Programs fail, initiatives fold, executives lose their positions, and the massive, pyramid-shaped industry lurches along from one questionable effort to the next.

So, who’s really in charge of software development?  More and more in the world of the large pyramid-shaped corporation, the answer is no one.

Programmer Exodus

And what do you think happens with talented programmers during the course of this lumbering?  They perceive better options and they leave, in spite of the best efforts of even talented managers.  Why shouldn’t they?  They have options.

Talented programmers don’t want to stick around for bureaucratic facepalms and to serve as cogs in organizational systems.  They want to create systems rather than exist inside of them.  And so they leave, creating a vicious cycle for pyramid-shaped organizations.

Where do they go?  Well, so far, we don’t see a lot of rhyme or reason to this, other than away from hyper-specialized bureaucracies.  Some go to startups.  Some fancy big orgs like Google and Facebook.  Others still might go work for smaller app dev shops (“consultancies”) or just organizations with small, non-bureaucratic software departments.

The future I see and the future that I want, however, involves rhyme and reason.

The Start of Developer Hegemony

First and foremost, I propose that we continue and speed the exodus out of massive organizations who don’t sell software or software-based products.  This may sound harsh.  But it’s already happening, and allowing them to continue changing watch batteries with marionettes does them no favors.

But beyond that, I propose we move specifically to structures in which we call the shots.  I propose we work in app dev shops and partnerships, where we deal with the world at large not as bosses but as customers.

Recall the two types of people that currently call the shots: managers that used to write software and managers that transferred laterally into software management.  These folks can just as easily consume software as customers as they can commission it from the boss’s chair.

If you want a model to understand how such a shift might look, imagine the relationship between major corporations and law firms.  These corporations staff general counsel who reaches out to specialized law firms when needed.  They don’t look to hire legions of lawyers as line-level employees and have six layers of management above them.

What Developer Hegemony Requires from Us

We can vote with our feet, and this confers upon us great influence.  It almost, but not quite, lets us call the shots.  As we leave pyramid-shaped organizations and build our own workplaces, we start to call more shots.  But we still have work to do.

All of our issues in pyramid-shaped corporations stem from our role in them as cogs.  And we share a heaping helping of the blame for having this role.  We elevate technical arcania over business outcomes and taking pride in being well rounded.  Then we turn our nose up at parts of the business that do not involve code.  And finally, we fetishize coding skill to a self-destructive degree.  To achieve developer hegemony, we need to grow up as a profession and realize that we can’t just eat cake for dinner every night.

I cover an awful lot of tangible specifics in the book.  But we can really roll it all up to an attitude and to an awareness of our situation.  Why aren’t software developers in charge of the software development industry?  Only because we haven’t yet figured out that we can be.  I invite you to join me in spreading the message, both in the book and from here forward on this site.

Please share with anyone you think should hear this message.

No Fields Found.
12 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
John Siegrist
John Siegrist
7 years ago

Dear Erik, It is funny that you should compare the software profession to legal firms. What you probably don’t realise is that pyramid you posted at the start of your organization would apply equally well to the new software-developer world of software firms. What you would see is that the people who would make it to the top of the software industry heap would be the Larry Ellisons of the world or worse. Architecture firms are run by architects who treat their employee architects very poorly. Law firms are run the same way, except more ruthlessly. So unfortunately, the cure… Read more »

Serg
Serg
7 years ago
Reply to  John Siegrist

Remove ALL BAs and PMs they only generate noise and no value. Leave product owners who we can work with – the rest is just not qualified to be in the IT field. In all my 20+ years of experience this approach did wonders in both corporate world and in startups some of which sold at 100M+. Look at the architecture for example. To run a project one MUST BE a qualified architect, i.e their PMs know what they talk about and actually are practitioners with a hands-on experience. In other words, fewer talkers and more doers.

Ryan
7 years ago

what if in the history of software we have always struggled to adapt software development (science) to business…. what if the answer is…. it doesn’t.

Aaron Munger
Aaron Munger
7 years ago

Hey Erik – Looking forward to reading your book, but I was wondering: Do the proposals of Developer Hegemony rely on a large buy-in of the masses? If the large corps are allowed to continue to “recharge their batteries” and profit the way they do, does that put a damper on those who try to embrace your ideas? It seems like the large corporations just keep getting larger and the successful startups with unique org structures just end up getting bought up.

Titonus
Titonus
7 years ago

Maybe Domain Driven Design is key, searching allies because Computer Science manipulates information from different businesses domains where people who are in charge do not necessarily know about programming.

trackback

[…] few weeks ago, I officially launched my book, Developer Hegemony, on Amazon.  It went well!  For a while, the book was the #3 best seller in […]

Roland von Ohlen
Roland von Ohlen
7 years ago

An article I was waiting for to be written. Almost none of my skilled programmer friends wants to join a company with these old structures like you described anymore and the ones that do end up unhappy and do not stay for long. Consulting is one way to not get crazy in those structures, but it is not the solution. You just get better pay and a bit more freedom. For some people that are in management positions it is completely normal to fall out with the software developers/consultants. They have never experienced something else and new ones are being… Read more »