211–220 of 265 posts
Earlier quoted context omitted.
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.
Flat fees. Problem solved.
as soon as you encounter an unexpected problem, your margin suffers. since unexpected problems can radically alter dev time, your margin can be obliterated.
Earlier quoted context omitted.
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.
Flat fees. Problem solved.
In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much. * Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software. * Is your company selling a software product (product com…
I chose to make a career out of #3, specifically logistics. I know how stuff gets from vendor to customer. This isn’t something you can buy out of a box. It’s usually heavily customized and made out of multiple systems were never design to work together. Every company does this differently. I enjoy this. I’m good at thinking through whole systems across a company’s many departments. This requires knowledge of interna…
As an aside, it seems that the $500K/year jobs have dried up - at least I don't see much of that on the "Who's hiring". Salary ranges seem to be more in the $100K - $200K range.
Earlier quoted context omitted.
flat fees fail for dev. as soon as you encounter an unexpected problem, your margin suffers. since unexpected problems can radically alter dev time, your margin can be obliterated.
Make bigger margins
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.
I don't understand our modern tech culture of saying maintenance is the last on the list; always getting chopped and cut; never getting a decent budget. In 20 years and several different companies I have always heard this but never agreed with it. Sure, the company wants new features to market, but the company also wants things to freaking work. During layoffs and hiring freezes I have seen SRE type orgs fair better…
Keeping the service running to a level that customers demand is a high priority for everyone. Nobody wants to cut SRE to the point outages cause customers to leave.
But I think SRE is closer to "operations" in a traditional company (i.e. unavoidable to provide the service), rather than maintenance (something often deferred as long as possible).
In this framing maintenance is things like tech debt reduction, improving internal tools, experiment iteration time, etc, which is often undervalued relative to product impact IMO.
Earlier quoted context omitted.
Make bigger margins
Not sure why you’re getting down-voted. 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…
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.
In addition to knowing which bucket your salary comes from, I think it is also useful to know how your organization values building software. Because this affects your career just as much. * Is your company selling software development hours (consulting)? I'm this car you'll be valued for client relations skills and the ability to bang out acceptable software. * Is your company selling a software product (product com…
To simplify, you always always always want to be working in bullet point 2, if at all possible. In the other two, you are a cost to be minimized or eliminated. Only if you are working on one of the companies core products are you an asset bringing revenue into the company.
Earlier quoted context omitted.
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.
Flat fees. Problem solved.
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.