John Elam - Home | twitter:@elamje | my coding flow playlist: spotify | coding music: List | me now
consult vs create
June 19, 2021

Anyone who has ever done software consulting is aware that your incentives are at odds with your client. Bill by hour, take your time. Bill by project, take shortcuts whenever possible. In both cases, it is rare for the consultant to be completely bought into your project, product, and business. They have no stake in the game. They won't be around for the upside, and they can bounce at the first sign of downside.

If the options are hourly billing or project/fixed rate billing, it would appear that the first option would lead to higher quality work and lower delivery speed, while the second option would lead to lower quality work, but higher delivery speed. The variables that make the difference in this circumstance end up being the developer(s) skill and productivity, e.g. low skill, low productivity devs will be bad on either type of billing structure, whereas high skill, high productivity devs could be great in either billing structure.

Don't forget, all things equal, both billing structures are likely inferior to having a team in house with "buy in". "Buy In" can be driven by incentive schemes, culture, or individual enthusiasm, but ultimately, you want Buy In. The issue with traditional consulting, as outlined above, is that the project stakeholders rarely aim to inspire consultants. They are just a means to an end.

Which brings us to the other side of the isle - creating. Building software from scratch, with a wonderful team, on a wonderful timeline is oft a pinnacle of a software career. When the team is internal, the incentives have been made perfect via cash, bonus, & equity, and the work is highly engaging, the project will sail.

Align software consultants with your mission - your project, product, or business. You brought them in, so you control the billing structure. You set the vision, you can bring the enthusiasm to make them Buy In.


back. | home.