In practice, this starts with my availability. Since I don't work with estimations my gigs do not have an estimated end date, because what I only care is that what I am hired for finishes in its natural way.
In particular I don't tell my clients "I need to be done by time T", that would be putting a de facto deadline to the project and wouldn't be consistent with my view to focus on bringing the best value to what I am hired for.
So this is not a selling strategy, but it is just the natural way in which the conversation normally goes. Then, I explain why I work that way. Also, the corollary is that if that person or company hires me, I will be as focused on their problem and in the quality of work as I am being now with my current gig (the commitment that doesn't allow me to give a starting date.)
I have some public track record, so when someone hires me they know who are hiring. That, I am sure, also helps. Though I have to say when I started I didn't have so much exposure.
BTW, that for me includes Scrum sprints. No matter if you call it points, or whatever, you are estimating that something is going to take so much, and that by next week we could deliver A, B, and C. Is the same shit in the end.
Don't do that, talk about facts. Use past tense. Last week we DID A, B, and C. This project COSTED this much.
Some clients already work without that shit, pipeline and priorities. That's all.
Also, do not put yourself in a compromise by inertia. "I'll have it by tomorrow" and nobody asked. Try to avoid that kind of sentences. Then you absolutely have to do it by tomorrow no matter what, or else you need to excuse to fail the expectation. Be deliberately vague: "I'll have it soon", "I'll write back", "I'll prioritize this", often times that language is more than enough for communicating. But best of all: say nothing! Just work hard, let your work speak for you.
Working hard is key. Work hard and communicate often to have a close feedback loop. If you do that, in a few days your client already sees how it goes, it can feel the speed (as you do), it can feel the velocity, and that everyone is concentrated on what matters for quality. If you enter that flow, everything is so smooth and good for the success of the project.
I have been working non-stop that way for 5 years, and I truly believe it is the best way to deliver quality software.
While I completely agree with you, I don't see this happening anytime soon in big companies with multi-year projects easily worth 7+ figures.
Often enough the deadlines are set in stone within the contract and every milestone is defined ahead of time as well. I've worked with many such companies over the years and its always the exact same story. Some of them are even considered tech giants today.
It's also telling that I consider every single one of these project to be of mediocre quality at best from an engineering point of view. Thing is, our customers usually bleed so much money they barely notice it could be done any better.
People in charge of these projects usually don't know anything about software engineering and add more importance in pleasing investors in the short-term than producing value in the long-term.
Yes, in that case that's not your market. (Unless someone responsible for some of that budget hires you under those "local" conditions.)
But in general, as in any product or service, you have a market. Sometimes you may loose the lead, but it is important to say no to be true to yourself.
What I have found is that people and companies with which I get to work are clients of high quality themselves.
I recognize your way of working in how my girlfriend works. She is very successful working this way. Within a couple of days in a new job people see her working hard and delivering results. She earns a lot of trust from colleagues, clients and managers by working this way. What she does, she does it very well. It looks easy enough, but it is not. Working this way is actually difficult.
In particular I don't tell my clients "I need to be done by time T", that would be putting a de facto deadline to the project and wouldn't be consistent with my view to focus on bringing the best value to what I am hired for.
So this is not a selling strategy, but it is just the natural way in which the conversation normally goes. Then, I explain why I work that way. Also, the corollary is that if that person or company hires me, I will be as focused on their problem and in the quality of work as I am being now with my current gig (the commitment that doesn't allow me to give a starting date.)
I have some public track record, so when someone hires me they know who are hiring. That, I am sure, also helps. Though I have to say when I started I didn't have so much exposure.
BTW, that for me includes Scrum sprints. No matter if you call it points, or whatever, you are estimating that something is going to take so much, and that by next week we could deliver A, B, and C. Is the same shit in the end.
Don't do that, talk about facts. Use past tense. Last week we DID A, B, and C. This project COSTED this much.
Some clients already work without that shit, pipeline and priorities. That's all.
Also, do not put yourself in a compromise by inertia. "I'll have it by tomorrow" and nobody asked. Try to avoid that kind of sentences. Then you absolutely have to do it by tomorrow no matter what, or else you need to excuse to fail the expectation. Be deliberately vague: "I'll have it soon", "I'll write back", "I'll prioritize this", often times that language is more than enough for communicating. But best of all: say nothing! Just work hard, let your work speak for you.
Working hard is key. Work hard and communicate often to have a close feedback loop. If you do that, in a few days your client already sees how it goes, it can feel the speed (as you do), it can feel the velocity, and that everyone is concentrated on what matters for quality. If you enter that flow, everything is so smooth and good for the success of the project.
I have been working non-stop that way for 5 years, and I truly believe it is the best way to deliver quality software.