In Consulting, Human Capital Matters More than Financial Capital

When was the last time a technology consulting company had an Initial Public Offering (IPO)?

Exactly.  It rarely happens, and when it does, it is the exception, rather than the rule.

However, back in the pre-dot-bomb era, you had these things all the time.  Remember Scient, Viant, Sapient, MarchFirst, and a plethora of other companies that either ceased to exist, or significantly scaled down during the tech downturn of 2000-2003?  Boy, how things change.

So what changed?  Well – we have to imagine why companies decide to do an initial public offering.  In theory, it should be to get a large source of capital with which to quickly expand and gain marketshare.  Of course, we know the real reason, in a lot of the cases, was simply to get the founders very, very rich… but lets play along for a bit.  Anyone investing money in a company like one of those aforementioned consultancies was based on the premise that a consulting company can leverage the additional money to hire hordes of programmers and bill them with large margins – creating truckloads of profit.  Of course, it didn’t work, and the rest is mostly history.

One of the things we learned is that there is a constraint on how fast a consulting company can grow.  Simply put, in a well run consulting firm, your growth will be more constrained by the speed at which you can acquire human capital far more than the speed at which you can acquire financial capital.  Put another way – if you had a billion dollars, you could not create ThoughtWorks out of thin air – in a year, or probably even in five years.  Why not?

There are a couple reasons.  Even if you wanted to, you could not immediately hire 1000 great software developers who work well together, have decent client skills, and are smart enough to command the rates required to make consulting work.  You also could not simply hire 50 top partners/client principals/or “rainmakers” at once (or if you did, without massively overpaying and killing your margin).  And even if you did all that, you would not build an instant cohesive culture that creates the kind of cooperation across groups that are required to compete.

This is not to say financial capital does not matter.  It clearly does, especially on the 1st and 15th of the month when you need to make payroll.  But that said, the right combination of human capital is much harder to nurture over time and create than simply writing a check.  Put another way, MarchFirst had financial capital – lots of it, and lasted barely a year.  On the other hand, companies with Human Capital will generate the financial capital to keep things going.

This, of course, has important implications, which I will explore in the next post…

In Consulting, Human Capital Matters More than Financial Capital

Consultopia – The Worlds Most Ideal Consulting Firm

A shorter version of the essay I wrote in The Nomadic Developer: Consultopia, is up on

Of all the things I wrote in my book, I think this essay was the most fun for me to write.  It is not every day that I get to yell out to the world that mission statements are basically BS pieces of marketing, or call out the inefficiencies of capitalism as it relates to pursuits that are more about intellectual capital than financial capital.

Go ahead – give it a read!.

Consultopia – The Worlds Most Ideal Consulting Firm

Three Key Technologies Your Clients (Should) Care About

My second InformIT article is now up, this one, focusing on some conversation starters you should be having with clients.  There are a lot of things out there that are going to capture imagination, but I think these three that I allude to after the jump are particularly meaningful in this year of shrinking budgets and needs to “do more with less”.

Three Key Technologies You Should be Pointing Out to Your Clients

Three Key Technologies Your Clients (Should) Care About

Technical Fraud

Most of us understand the idea of, what here in the US, we like to call a lemon in the context of purchasing a car:

lemon is a defective car that is found to have numerous or severe defects not readily apparent before its purchase. Any vehicle with these issues can be termed a ‘lemon,’ and, by extension, any product which has major flaws that render it unfit for its purpose can be described as a ‘lemon’

We all know the lemon.  Usually the guy who sells it to you looks like this:


And we know the results too.  Unless there is a “Lemon Law” that allows you to return the defective car, what you are given upon delivery is a monstrosity that has maintenance costs that eat 80% of your budget.

When you engage in the practice of loading a software project with undisclosed Technical Debt, you are engaging in exactly the same practice.  You are selling lemons.  This practice of delivering projects with undisclosed technical debt is what I call Technical Fraud.

Technical debt, by itself, is not a bad thing.  Technical debt, as I have pointed out in the past, can be seen as leverage – which in software, allows us to get a prototype up and running quickly, or otherwise express an idea to an audience.  The problem isn’t inherently technical debt, the problem is loading an asset with high amounts of debt.  Of all the issues I have with waterfall software development, one of the biggest ones is that it almost invariably leads to Technical Fraud, especially when done in the context of consulting.

Why is this an epidemic in technology consulting?  Well, when a project is sold, it is often done so on the basis of:

a.) Price

b.) Surface level confidence of the person selling the project that all ambiguities are covered (think of the picture of the guy, above, telling you “everything is fine, can’t you smell the fine Italian leather?”)

If you don’t account for technical debt; and let’s face it, most organizations, despite spending 80% of the software budget on maintenance, do not account for technical debt; you will probably get loaded with it.  It should surprise nobody that Technical Debt becomes the software equivalent of the Enron off balance sheet entity during a Waterfall software project – something not on the balance sheet (not disclosed) that nonetheless, you end up paying interest payments on.

Let me cut to the brass tacks… we need to start accounting for technical debt. We need to have contracts that specify the allowed level of technical debt. And we need to get, as an industry, much better at recognizing technical fraud. Spending 80% of the development budget maintaining buggy software, which blocks companies from taking up new initiatives that might involve writing code, is an unacceptable state of affairs.

Technical Fraud

Agile is a Means, not the End

At ThoughtWorks, my role is technical, however, as do many ThoughtWorkers, I do work on things like proposals or business development opportunities from time to time, especially when between assignments.

One thing you might be surprised about with ThoughtWorks is that the value proposition isn’t that “We are The Agile Company”.  This makes sense if you think about it – as good as Agile is, it is but merely a method.  It isn’t a destination.  Value to the client is the destination.  Agile is – at best – a means to an end.

There are clients – who… gasp… don’t care how we get the results.  We could get them by hanging bats upside-down in a glowing cave where we serve coffee to leprechauns.  They don’t care how (within, of course, the bounds of ethics and law) – they just care that they have a quality solution that meets their business needs at the end of the project, while not burdening them with endless technical debt.

Results matter more than process.  The problem, historically, with waterfall, and more recently, it’s uglier twin, scrummerfall (the process of doing scrum without TDD and other quality oriented practices) … is that at best, when they work, they give you a solution that might meet the business needs as they existed at the start of the project.  The traditional constraints of software development dictate that when you have quality, scope, and time each in contention (as they always are) – the one that is hardest to measure typically loses.  In software, quality is historically hardest to measure, which means it is the first to go.  Viola, unmanaged, hidden, technical debt.

So what do you do when your client does not want to see the sausage factory?  Well – that is where you have to focus on quality.  What I want to see more of in contracts are success criteria that state a required level of quality, measured by (albeit imperfect) metrics that help us get there.  Test coverage is a good start – but there are many others.

Another success criteria is that a late change of some definable complexity should be achievable at some definable, lower than what it would be without TDD, cost.  I would love to see some work done to find a way to put something to this effect in a contract clause (maybe some friendly contract attorney can help me there).

Competition will always, at some level, come to price for a solution.  However, smart procurement folks will make sure to ask that the quality and adaptability variables be controlled, so that when prices are compared, they are comparing the price of Morton’s Steak to Ruth’s Chris, not Morton’s Steak to Sizzler.  Agile is just a means to delivering a solution that scores well not just on the cost variable, but on the quality and changeability ones as well.  The business value that comes from solutions that do not take on unmeasured and ill understood technical debt?  That is what, in my opinion, a significant part of the ThoughtWorks value proposition.

Agile is a Means, not the End