Book Notes: Developer Hegemony

Where to find the book

  • Here - it’s free if you join the “Hit Subscribe” community. That’s a win win, it’s an amazing community tbh, I’ve learnt a lot from the people there already.
  • Goodreads

Opening chapter

Fictional story about the consultancy that’s run by a few partners. Outlining what things might look like in an ideal world.

A chat between consultant & potential client

The next way that we do things differently is that we invite our clients to consider software development as a service instead of considering software as a commodity

  • Commodity or a cost centre. Software tends to be treated as just another cost centre, in some business environments.

Unlike revenue generating activities and R&D, the sky is not the limit when it comes to cost centers. They have to stay lean and mean, lest a wave of management consultants be called in to trim them as fat.

You’re partnering with us to expand your organization’s capabilities

Tell me your goals, and I’ll lay out and oversee execution of your software strategy.

Spoken like a product engineer.

Talking money with the potential client

But really, we suggest that they start to think in terms of a monthly software budget. It’s a question of what you want departmental spend to be on growing your software’s capabilities versus maintaining existing software. And where we come in is on the capability growth end.

After setting up a corporate structure to DBA

DBA: Doing Business As

  • And after spending $120/month on a virtual assistant

Finally, I advised them(developers) to add “Managing Director, JaneSoft” to their resumes and list management of a global team as part of their day-to-day responsibilities.

On the topic of true ownership

  • And your typical advancement in a corporate, where you’re eventually placed in the management track. Reminds me of the post Management isn’t a promotion

Consider the word manager in non-corporate contexts. Actors and athletes hire managers and delegate non-domain tasks to them.

you hand him a placard that says “manager.” And what do you do to reward him? You’re not going to give him an ownership cut, and you’re not going to pay him a whole lot more.

So you give him what the corporate world has standardized. You give him faux ownership.

On Performance Reviews

performance reviews are determined more by the available budget for raises than by your performance

On loyalty

It was just that I exhibited loyalty to humans rather than to organizations

You need to stop viewing yourself as an employee of your (or any) company and start viewing yourself as the owner of your own personal brand and operation. You are an island.

“We’ll ask for estimates and then treat them as deadlines!”

Partnership is the key to removing the governor that the corporation places on your advancement.


We sell, to individuals and businesses alike, the ability to increase profits, to expand, and to scale.

Our value proposition is that we provide expertise in efficiency. “I help you have more time and money.

We specialize in making your business more efficient.

Team topology

In the enterprise, I’ve heard the term “T-shaped people” tossed around pretty freely. What this means is that you want people with a wide base of skills but who go deep in at least one specialty. If you have people like this, you can put together excellent Scrum teams.

Partnership between dev firm & clients

To put this concretely, if you started an efficiencer firm, you would not take specs, and you would not take wireframes, and you would not take direction on software. Software (and by extension, automation/efficiency) is your area of expertise, not your client’s. In the future, this is how more and more software will get written.

If you find yourself in the unfortunate position of getting divorced, you start asking people you know for referrals to divorce attorneys. If you have problems with your foot, you call up someone with the title “podiatrist,” meaning “foot doctor.” Those autonomous knowledge work professions organize themselves according to the problems their prospective customers have. They advertise in terms their customers understand.

Software developers and app dev firms fail spectacularly in this regard. We organize ourselves and sell labor on the basis of what tools we use while our customers tell us what to do

Productized services

This seems to be the most favoured form of billing in this book. I’m still trying to distill it, to the point where I can apply it to my favour in the real world.

If your firm adds productized services to its portfolio, it will, almost by definition, add an alternative billing model to its portfolio as well.

Let’s consider how app dev consultancies bill their clients today. Generally, they have two standard options: fixed bid or hourly/time-and-materials. Fixed bid offerings mean that the customer comes to you with a spec or a request for proposal (RFP). You size it up, estimate that it will cost you about $300K to develop, and then say that you’ll do it for $500K. If the customer agrees, you now absorb all of the risk with relatively limited reward. After all, you’ll get the $500K from them whether it costs you $300K or three million. For this reason, most firms avoid fixed bid arrangements for anything complex, and they foist all the risk onto their client.

If you bill for a rate of work, & not a specific deliverable, the client might agree, but that makes them really interested in how you’re spending those hours.