>
... when you're trying to meet business goals, speed of execution trumps quality of implementation every day of the week.This is a topic I've been mulling over in my head for quite a while, contemplating writing about it and/or trying to give talks/presentations on it (I just have no idea where that would possibly be welcomed/appropriate within the developer community).
I'm curious about where and how you work that you find this to so consistently be the case?
---
Over the years, I've worked with multiple kinds of businesses on custom, from-scratch software. I'm not talking websites; I mean software on which they depend for actual daily business/employee operations. Perhaps I've been extraordinarily lucky in the last 8 years, perhaps I filter out the rubbish, but I have yet to work with a single client that values speed of execution over quality of implementation. In fact, the longer I do this, and the more I get to intimately know my clients and their businesses, the easier I find they happily pay more for quality of implementation. I rarely find myself facing earning less to provide speed of execution. They consistently pay a premium for quality implementation.
I don't negotiate on speed vs quality. Want speed? Cut features, not quality. Need a lower budget? Cut features, not quality.
I spend more time getting to deeply understand my clients, their businesses, and their goals than many other developers I personally know closely. I begin this on Day One, Meeting One--the first time I'm invited to discuss a project with a potential client.
I ask questions that get a client talking deeply about their business--what weaknesses/inefficiencies they're trying to solve with custom software, what goals they're trying to meet, what they've tried in the past, even what other developers/companies/options they've talked to or considered before me, and what has been offered/promised by my competitors. I drive the conversation to what kinds of business/operational features they're looking to automate/enhance with software, what benefits they're hoping to experience, what value they think software will bring their business.
I always take copious notes. I try to keep the client doing most of the talking. I probe and dig when necessary to really understand what they're trying to accomplish. Within a single meeting, I work to establish a base-level of trust by way of focusing the entire conversation on making sure my client knows they are heard and their needs/goals are understood. When I do take the floor and speak at length, it's to echo back what I've heard, what notes I'm taking, how I understand their needs, how I think we can solve those needs.
The first meeting is usually a long one. I never watch the time. I don't wear a watch. I don't glance at my phone. I get the client talking and keep them talking. I remain mindful of who is quiet in the room, and try to actively engage them in the conversation. I want the whole room in on the discussion, and I want them all feeling like they're part of this thing.
I say we a lot. By the end of an initial meeting, I've usually established an impression and expectation that I'm invested. And it's not bullshit. For me, at least, it's really damn genuine. I want the client to know that we can solve X, Y, and Z in a way that's going to bring great value to the company, and it's going to be of the utmost quality.
I never talk about speed. I rarely even discuss rates in the first meeting. I'm also rarely asked about them by the end of the meeting.
I usually close out these initial meetings with a brief outline of the process we will follow moving forward creating software to improve the business. I explain how I'm going to be doing the heavy lifting of distilling all of our conversation and my notes into a document that highlights and maps out all we've discussed as a complete guide to everything we think is important to helping the company.
Clients don't typically think in terms of features. They think about efficiencies, cost savings, goals, plans, ideas, and above all, value. I never ask them to give me a list of features to build. That's my job to provide them, based on understanding their business and its needs completely. If I can't take the time to do that properly, we're never even going to be worried about speed of execution vs quality of implementation. The project's going to be a disaster from the start.
We get back together some days later, after I've mapped out everything from our discussion into a semi-technical feature spec & roadmap. Everything is broken down into constituent parts. I include explanations that educate them on the process of building their software. I go to great lengths to make sure they understand technical limitations/expectations. I don't ever bullshit them or myself. I've taken to ranking things with a loose grading of technical difficulty and time required for different components of the software. I am always priming them for the price tag without ever talking about it.
When we get to the part of talking about the price, it's never awkward. They've been primed. I've earned their trust by being completely open and honest, and by listening and paying attention to their real needs. They see me as an extension of the company. We're in this together and $X is what it's going to take to get the value the company needs out of the software. When the price is too high, I walk them through prioritizing the features/components into a list of things they want to have now until it fits into their budget for "this phase". I never offer a choice of speed over quality.
> They want to know that they don't have to keep an expensive pain-in-the-ass "rockstar" developer around just to maintain and build on it.
My clients typically want to know they can keep me around forever to maintain and build on whatever I do for them.
From where I sit, it's all about earning trust. Maybe I'm just lucky. Maybe I work with a completely different set of clients. I just can't imagine having to deal with a client who seriously stresses speed over quality.
> I suspect the only way we're going to get to make software the way we want to make it is, if we also run the business using the software.
Or, if we build up enough trust that a client views us as an equal, invested in the business using the software. My clients practically treat me as if I was a partner in their business.
At the very least, there's really no luck involved here. There are better clients out there. Maybe it's time to start rejecting shitty clients.