My experiences:
1) programmer in IT department of major newspaper: disregarded as IT geek. very small salary. the worst office spaces.
2) senior engineer in software startup: rockstar treatment, stock options, all the things you would expect as office culture
3) senior consultant at IT consulting company: must basically be a sales guy who writes good PowerPoints. Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.
Agree with these. I was a dev at a retailer that did catalog/phone sales and was starting to use web. Small salary, small PTO, no benefits. Pay increased when the business had an existential crisis and came to rely much more heavily on tech. Next was software consulting company churning out sites designed by marketing agencies, billed to the 15 min. Small salary, small PTO, some benefits. Then I went into SaaS (startup, then a public company). Nice salary + stock, great PTO, great benefits.
Aside from the comp/PTO/benefits, I learned that consulting isn't for me. The client interactions felt... adversarial, where they were trying to get more work for less money, while we were doing the opposite. I did not like that constant tension in conversations.
The point you made about consulting interactions resonates with why I also ended up not liking consulting. It feels like incentives are not aligned when doing software consulting a lot of the time.
I think it is flat fees which create the problem in the first place. There are six commonly recognised general project variables: cost, time, scope, quality, benefit, risk.
So suppose you've fixed cost, have you fixed the other five project variables too? If yes, you've just reinvented waterfall - which is fine if you have a very well defined task you repeat often, and there is little chance of much scope variation being desirable. It still might be adversarial in that you, as a consultant, might do the same process for every client, but it might be your first time working with a client, who expected more than the scope, or disagrees with your interpretation of the scoping document supplied.
Now suppose it is a much more bespoke task, where both sides need to discover some things about what works. You are likely to learn that part of the plan you originally had won't work to capture the benefits. Now the actual scope required is bigger; perhaps that is a risk you take. But perhaps one client realises some big scope requirement early, and deliberately takes advantage of the fact your scope is variable to conceal this from you when you set your fixed price; maybe you put some language in to try to reduce this risk. And perhaps your boss encourages you to use some of that language on an honest client who did genuinely try to communicate the scope, to make the client pay. Everything is once again back to being adversarial.
I think time and materials contracts are actually the best for aligning incentives - the consultant gives their best attempt at an accurate estimate of the work, and the client can freely change things as they go along - but carry the risk of cost changes. If the consultant is poor at estimation, doesn't give frank advice, or does low quality or slow work, the client ends the contract with the consultant and gets a better consultant, and since it is time and materials, it is clear what is payable and who owns what - so ultimately everything is well aligned.
as soon as you encounter an unexpected problem, your margin suffers. since unexpected problems can radically alter dev time, your margin can be obliterated.
If unexpected costs are shrinking your margin, you’re failing either:
1. …to negotiate the terms of your agreement correctly (what constitutes additional scope and therefore additional charges?). I will never take another client project without first agreeing on an SRS for this reason.
2. …to negotiate a fee with a margin proportional to the likelihood of unexpected situations arising. This is a function of the accuracy of requirements by simple/complicated/complex problem domains. I think this is what parent is suggesting.
If clients don’t like (2) they will work with you more on (1) by providing more accurate requirements, which lets you bucket some problems into more readily estimable domains.
What you’re saying is a much clearer answer. And what you’re saying is frankly pretty tough. But being a consultant is more than just asking someone to shut up and and pay you to code.
if you can maximize margin on all fixed price work while not pricing yourself out of the market you will dominate software dev and also make millions selling books. hint: it's not that easy.
handling fixed price software dev is like handling dynamite.
Curious to know every consultant flat fees and/or the metrics they use to determine it, since you will be charging for the “value” rather than the fixed hourly rate.
The consulting company gig paid alright. and all the guys who stayed got really rich due to IPO. I left the second my options vested. Literally when the transaction went through... no regrets because it SUCKED
> Maximize billable hours. What ever you do dont complete a project quickly or with minimum amount of code.
There's a real continuum of engagement budget here - at the other end of the scale you have the opposite problem where the fees are barely adequate, and your success is based on systemitizing shortcuts to crash out cookie cutter minimum viable products, and being able to get clients to actually cough up.
you can probably guess where I am now.