In Consulting, Human Capital Matters More than Financial Capital, Part 2

In the previous post in this series, we explored the relationship between consulting and financial capital, and how the latter often is very harmful to the former, particularly in large amounts.

The real question, though, is what that implies.  Indeed, the chief reason given of why companies must always grow, is that:

  1. Capital seeks the highest possible rate of return
  2. Companies, who need financial capital, must compete for capital to expand
  3. Expansion raises the rate of return, based on economies of scale
  4. Higherrate of return attracts more capital
  5. Go back to step 1.

This is, of course, why you and I are not as rich as the heirs to the Walmart fortune.  Traditionally under capitalism, more capital meant you were more competitive, and you would grow, edging out all your competitors until either a.) the anti-trust police get you (from Standard Oil to AT&T to IBM to Microsoft) or b.) you somehow screw up and lose all your customers (GM, Chrysler, PanAm, Arthur Andersen).

Of course, if you consider the size of financial capital as only a minor factor, then you would want to look for other factors that control how a consulting firm differentiates itself.  How might such a firm do that?

Well, that depends on the kind of business you are.  The success of a technology consulting organization is going to depend chiefly on:

  • Relationship building capabilities of the consultants and demand generation teams
  • Brand reputation – being known for solving hard problems
  • Recruiting capabilities – ability to attract people who have both technical aptitude and relationship skills

So how does one increase those?  Especially if you can’t buy it directly?  Well – you have to become very good at attracting the best people, and once they are there, keeping them engaged.  If people matter most – you have to wonder how you attract and retain the people you want.

Can money buy people?  One approach to building a great consulting firm might be to offer to pay everyone $1 million us dollars per year.  People have done studies that indicate money does not, in fact, buy happiness.  If suspect what occurs in this scenario is you end up with a bunch of very rich, but very nervous, consultants who still will search for meaning in their work after a few months of “being rich”.  If anything, my experience with people who have sudden wealth is that they either become people you would rather not work with from sudden materialism, or people who suddenly retire and do something else to find more meaning once they have enough money to not worry about work.  I doubt you build a successful technology consulting firm that way.

On the other hand, my sense is that if you provide a real mission – not one of the fake mission statements that most companies have… but a real mission that matters, you will get levels of workplace engagement that exceed those workplaces where the mission is mercenary.

What happens when you have high levels of engagement?  You get more work out of people.  People row the boat harder.  They may work more hours, they may not (personally, I hope they don’t work more hours and burn out)… but you are highly likely to get more out of each hour from someone engaged in what she is doing than someone who is watching a clock.

So, if engagement is what helps you get the most from a given amount of human capital, and larger social goals and missions – beyond money drive engagement, it means that technology consulting companies must compete by persuing worthwhile social goals that drive engagement.  At scale, it also means these goals have to be near universal virtues (i.e. transcending religion, politics, etc.).

In the next post in the series, I will explore other businesses where this model is imporant, as well as types of businesses where frankly, this model does not work, due to dependence on attracting capital.

In Consulting, Human Capital Matters More than Financial Capital, Part 2

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

Aaron Erickson, ThoughtWorker

Yes, it’s true – I finally made the jump.

Magenic (my employer through the end of May) was – and is – a great place to work.  Leaving my Magenic has been one of the hardest decisions I have ever made.  However, given the opportunity to not just do agile development – but do agile development side by side with the inventors of agile development, it was just not an opportunity I felt would be wise to pass up.

June 1, 2009, my journey with ThoughtWorks commences.  Stay tuned!

Aaron Erickson, ThoughtWorker

Got Risk? Waterfall Projects during a Downturn

In my book, The Nomadic Developer, I have a section of the book that defines various terms in a section called, appropriatley, Appendix B, A Consulting Lexicon.  One term I define is a new term I like to call “Faith Driven Development”:

Faith Driven-Development

A development practice also known as “code n’ pray” or “Waterfall”. It relies on an ever knowing business analyst write an Old Testament like book known called “The Requirements”; non-coding architect to write New Testament like book called “The Design”. Once those are done and cast in stone tablets, a developer (you) is called upon to code the system, with results in a situation that resembles the last chapter in the New Testament, called “Revelations”, in which the forces of good and evil fight on a giant battlefield, with massive bloodshed (a process known as “Testing or Quality Assurance”) after which there is a promise of a thousand years of utopia.

Sadly, it seldom ends this well.

Of course, as you might guess, when you run into the term “Waterfall”, you get redirected to “Faith Driven Development”.  I will admit up front that I am no fan of waterfall methods.   The largest reason why I am no fan of such methods has to do with what I believe is going on, in reality, when a waterfall project is sold:

confidence trick or confidence game (also known as a bunkoconflim flamgafflegrifthustlescamscheme, or swindle) is an attempt to defraud a person or group by gaining their confidence.

(from Wikipedia)

In software, this game is played when someone sells a certainty of outcome when such certainty of outcome far less likely than he or she perports it to be.  The history of waterfall projects – especially waterfall projects with durations longer than a sprint or two – tells us that outcomes are highly variable as to when such a project will complete, if it is completed successfully at all (see Standish Chaos report, among other sources).  This is nothing new, of course.  The reason companies today ask us to underwrite fixed bid projects is to use it as a risk sharing mechanism to presumably reduce the chances that they will be conned, by having a company underbid the project, and then the project’s momentum to continue billing indefinitley.

There is, in effect, a race to the bottom effect in this business that means a consultancy can go out of business – or at least lose a lot of bids, because, buyers, will rush to firms that will tell them what they want to hear.  For the same reason that I might be tempted to try a snake oil that made it such that I could lose weight without effort, because there is demand for custom software with certainty of cost outcome, there will always be companies trying to sell into that market.  The toughest part of selling agile is being an honest broker in a world that accepts selling snake oil as viable business practice.

Which gets to my main point.  It is bad enough trying to be honest when many in the business world want desperatley to believe “the big lie of waterfall certainty”.  When the downturn comes though, the race to the bottom intensifies, resulting in some of the worst, riskiest projects known to man.  These projects are the waterfall projects sold during the downturn.

So what happens in a downturn that makes this risky?  First of all, competition intensifies.  You don’t just have two players telling the buyer what they want to hear, you have four or five.  Second, downturns cause short term to come into high focus.  If you are an account executive, and you are way short of quota, you might quote something at 50% of it’s true cost just to get  the deal and buy yourself some job hunting time.  If you are running an office and have a bench, you might even assume that you can cover any mistakes by throwing your bench at the problem – despite that such a move probably turns your net margin on the deal negative – even based on your most ideal assumptions.

In other words, the things that make waterfall a bad idea for consulting – the need to make promises based on hubris rather than observable facts, become even worse when consulting during a downturn.  During a downturn, the promises tend to be bigger.  The idea of forcing developers to work unpaid overtime becomes not only possible, but probable.  Quality not only goes down, it flat out gets cut from the budget (i.e. we all have seen QA become the first to go in such scenarios).

I know we all want certainty.  Nobody wants to just keep throwing money at a problem – or even at a solution, without some basis for finding out what the return on investment is going to be.  The problem, however, is waterfall is simply bad risk management.  It spends all the time mitigating change and process controls, while saying very little about how people actually work.  Waterfall and more old school PMBOK approaches don’t deal with:

  • The fact that velocity picks up during a project – if you have the same team, based on the team growing in understanding of the domain
  • Changes occur late in cycle even if the business didn’t change – based on increasing understanding

In fact, if you are doing steady “earned value management” type approaches with a presumed fixed set of deliverables, because average velocity starts low and picks up, you essentially start the project from behind.  Because you start from behind, you demoralize the team – and create the initial tendency to hide information about status that goes up the chain (remember – bad news tends to get hidden).

Waterfall assumes that people don’t learn anything valuable by doing.  It assumes that change is to be controlled, not harnessed.  It lies to it’s sponsor about team dynamics – creating the basis for “cover your butt” project management that stands behind dysfunctional teams and negative suprises.  In an upturn, at least when the project fails, you can get another job.  In a downturn, for you, and the sponsor, it is a far riskier problem.

When I conceived of this post, my first thought was to say “maybe you should do a risk matrix” to be transparent about the risks… but the more I thought, the more my instinct is to “just say no”.  I think I will go with that for now.

Got Risk? Waterfall Projects during a Downturn

Fear… and Consulting during a Downturn

Lets face it, when times are good in consulting, when recruiters are constantly complaining that “there just are not enough people”, it is easy to feel secure in your job so long as you are not gratuitously unqualified.

When things are going the other way, however – when business declines – my god how things turn.  Every day, I hear from people who are afraid… very afraid, of what might happen when they hit “the bench”.

I understand this fear.  For the record, I have it as much as anyone.  When times are hard, and you know that even good companies are not going to keep you on a bench much beyond a couple months, it is easy to start to assume the worst – and plan your life as though the worst will happen.  You assume your client will kill your gig for “budget cuts”, you will hit the bench, nothing will happen in two months, you will be laid off, you will burn through your savings, your wife will leave you, your kids will hate you, you will live in a park nearby your house, and your wife and kids will be walking your dog with “the new daddy” – who got the gig you didn’t – and your old dog will pee on you while you are waking up after sleeping that night in that park where your old family decided to take a walk.  And that is all before you contract Swine Flu and die a horrible death, alone.  You laugh – but this is not that unusual of a thought process that someone hitting the bench might have in their head during bad times.

Whatever you do, you have to get past this.  Things were not as good as you thought during the good times, and things are not as bad as you probably think now.

I am not saying bad things can’t happen.  Indeed – they can.  But chances are – just like it is unlikely that you will get a coin flip right more than a few times in a row, chances are, all the bad things will not happen in a row.  My guess is that most consultants wont end up with their former dogs peeing on them.  And if that does occur, at least misery has company.

My theory – and I have at least some reason to believe it is true, is that many tech consultants, when presented with layoff, will get creative.  Some will go independent – taking shorter term gigs until a longer term opportunity comes along (and who knows, perhaps finding they like the indy life and staying there).  Some will form startups (note, if I find myself unemployed, I am going full bore developing Twixcel!)  Others might even change careers.  And that is for the – in the worst case – 20% or so in this business that end up getting laid off.

I could be wrong.  Maybe Armageddon is here.  But even if it is, if things are that bad, I might as well live with it, since there is nothing I can do about it.

So… what can you do about it?  Well – how to survive is another post.  But in the short term, dealing with the fear is the most important thing.  In the short term, my best advice is to focus on your client now.  The client you have now, even if they are not perfect in every aspect, is golden – do everything in your power to get extended.

Now, assuming that does not happen, what to do next?  Stay positive.  Show up to the consulting company office every day (if you can) – and volunteer to work on anything and everything you can – especially anything related to helping in the sales cycle.  But don’t overdo it by trying to work 60+ hours per week.  Keep your sanity – work out – and pay attention to your family and hobbies.  You need your support system intact if anything bad does happen.

Lastly – do not let fear paralyze you or demoralize you.  If, for no other reason – you gain an advantage in the market, either within your consulting company – or external to it, by being that “positive, high energy person”.  Remember, you can adjust your sail, but not the wind.

This is, of course, very easy to say, harder to do!  Those who know me know that I often do more than my own share of “worst case scenario assumption” when I do planning.  Half the reason I wrote this post is to remind me what I need to do to deal with this :)

Fear… and Consulting during a Downturn

Death to the “Trivia Interview” or What is the Meaning of Irony?

As friends of mine who became victims of the recent US economic crisis start to look for jobs, I am often getting, usually over (a few) beers, very scary stories about what it is like interviewing today.  Sadly, it is reminding me that not much has changed since last time I interviewed during hard economic times, back in the early 2000s.

Lets face it, technical people are mostly horrible at technical screening.  We choose questions from lists, like a famous one Scott Hanselman put on his blog a few years back.  And then if someone knows a sufficiently high number of trivia questions, we assume they will be a good developer, and the next phase starts, which usually involves making sure they shower, shave, etc. – and are not a total psychopath.

The real issue here, of course, is that forming good technical interview questions extremely difficult.  Ideally, most companies would hire for aptitude, since we all know that good developers learn things very quickly – that is part of what being a good developer means.  Sadly, many still do not.

Let me illustrate through a story.  Lets say that, for sake of example, someone was hiring a developer to build something useful, like the i4o indexed Linq framework that I wrote a couple years ago – and continue to maintain to this day.  My guess is that if someone else were trying to build such a framework in 2007, given that in 2007 I had zero Linq experience – other than a vague idea of what it was for, I would have never been even granted an interview, much less passed it.

I, like most developers, learn things when I need to learn them, rather than just studying trivia just for fun.  Thus, I learned Linq – because I wanted to write an indexing framework.  On a Friday night.  During which time I wrote 500 lines of code.  By the end of that architectural spike, I had the essence of i4o working.  I then spent the next Saturday – another 8 hours or so, cleaning things up and handling some corner cases.  No experience to working software that – now – actual software companies like Component ONE are copying and selling for money (see LiveLinq).

The point isn’t that I was, or am, some sort of genius.  Actually, I am a rather ordinary software developer.  The thing is though that despite all the world’s APIs, I understand computer science.  In college, we had classes for:

  • Algorithms and learning the meaning of computational complexity (i.e. why a hashtable is faster than a linked list – and why the former takes up far more space)
  • Software Design – where you learn about the general value of reducing coupling and limiting scope of variables (the “fewer moving parts” bit of software engineering)
  • Compilers – so you understand what happens when you, well, compile from the language into native code
  • Language Paradigms – Procedural, OOP, Functional (F#, Haskell, etc.), Logic, and yes, God’s Language, Lisp
  • Operating Systems – so you understand the environment of most things you will write, what processes and threads are, etc.
  • Databases – so you understand how things generally get persisted, normal forms, and so forth

Frankly, everything important I know about software architecture is in one of these, or a small number of other more fundamental areas.  When I operate in a programmer role, I only decide to understand what I need to understand when I need to.  Lets put it this way, if I had to design a multi-threaded system in Java in 3 days, I probably could.  Not to take anything away from Java gurus, but given I know that Java is a language that generally runs on a JVM, that it probably has a thread system, that there are probably some libraries people use to manage that and not have to operate on thread primitives most of the time, I could be reasonably competent in not very much time.

But this is really the symptom of the larger problem.  The real issue is that some companies, when they hire software developers, hire them like contractors.  I understand testing for how well someone knows a given part of an API if all you are going to do is bring them as an expert in that API for a month.  In consulting, we run into that interview all the time, and expect it.

The problem is when companies who are hiring for long term – who should care about very different things, start with questions like “what are 4 methods supported by all delegates in .NET? (know 3… not good enough… gimme 4 you idiot!)”.  I am convinced that people who do this kind of interviewing really don’t care that much.  They want an easy screen that is easy to administer, makes them feel smart (because it is their own favorite API), and gives them plausible deniability if a hire fails (well, he passed the “hardest test we had”, not my fault he came in and messed up the group).

Real interviewing is hard.  I don’t know all the answers, but a a good starting place is Joel’s “Guerrilla Guide to Interviewing“.  And for the candidate, frankly, I would tell you, strongly consider whether you would want to work for an organization that relied on quiz show, trivia question interview techniques.  While not reliable, there is a pretty good unscientific correlation between “cultures of asshole” and places that use quiz show interviews.

Death to the “Trivia Interview” or What is the Meaning of Irony?