“How hard would it be to make a button…”

I can’t tell you the number of times I’ve heard sentences start with those exact works from clients. Early in my career, usually after the initial delivery of a beta, I’d get that question. I’d listen to the whole thing, put my head down, maybe ask a couple of questions about the details, think for a moment, and then come up with an estimate. Since I’m a pessimist, unlike most programmers, that number would often dissuade the client from proceeding.

After a few rounds of this, they’d complain that we weren’t as responsive as we were in the initial engagement. At first, that puzzled me. Our response time was usually just as fast, and in fact sometimes I was giving the estimate live in the meeting. They’d respond we weren’t as “flexible,” which I took to mean they were getting sticker shock and wanted the rate of feature delivery they got in the main site development even though they didn’t have a fraction of the budget.

Listening past the question

Over time I realized that’s not really what they meant. What they really meant is that we weren’t engaging with the same level of problem-solving we were in the initial engagement. In some ways, that wasn’t fair: in the initial site build, we often had strategic goals, long discussions about what they wanted, what their workflow was like, and how we could adapt the technology to meet their needs and stay within the budget. We were in contact several times a week and got updates on changes at their organization quickly.

Once the main site was done, that level of awareness was gone, so when they’d come out of the blue with a request, my automatic customer-service response was simply to answer the question as asked. Once I figured out they were frustrated with several rounds of that, I learned to listen past the question and instead of asking details, follow up with, “What’s the problem you’re having now that this would solve?”

Overcoming literalism

Unfortunately that’s not an insight that comes easily. Not only does it take experience, it takes a certain mindset. Junior people haven’t learned it yet, people from a sales background want to get an answer back quickly above all, and programmers are notoriously literal-minded and don’t often think about the meaning behind what is being said.

On the organization’s side, it’s also easy to get caught up in “feature fever,” especially as you start to understand the possibilities of web applications and how they can make your life easier. It’s incredibly tempting to envision a magic easy button that solves your problem. The only hangup is that while it looks like the flying magic unicorn pony simply drops elements on a page and they are easy to use and work perfectly, it actually takes a great deal of user experience and engineering skill to make a site function naturally and intuitively.

So the best defense against a good relationship going sour is a good offense: ask your web developer or agency to propose solutions to your problems. Explain to them the way you are doing things now, whether online or offline, let them know where the pain comes in, and ask them if there are any ways they can think of to simplify that. Often even the most inexperienced, literal developer will brighten up and say, “Oh! Yeah, we could just…” and suggest not only something that solves the problem, but solves with the least cost to implement, because good programmers are lazy.

While not up to the level of this hoary fun fact, you can take the title of this piece in multiple ways. Here, I mean two of them.

Work with developers

There are a lot of people who are “consultants” or “strategists” who’ve never built a working website, beyond possibly a simple HTML site in the 90s or configuring a blog in the last decade. That doesn’t mean these people have nothing to contribute; if they’re smart, they’ve observed what’s worked and what hasn’t, have good insights, and can relate to your organization’s problems in a way that helps bridge the gap. However, it’s rare that they have as intuitive a sense of how a potential solution will look in software, what level of effort it will require, or what alternatives might solve the problem as well.

Nothing’s more frustrating than talking through a problem, imagining a solution, and then being told three days later that it isn’t within your budget or, worse, being told at the end of the process that it’s going to require several more development cycles to complete when you’re already out of budget. A strategist or consultant who has built lots of websites similar to the one you’re considering will have that sense and be able to steer you to solutions or at least identify that more research is needed.

None of this, of course, means that just any developer will do. You will want someone who is good at bridging that gap between engineers and people who need their services. If they don’t have experience or expertise in your sector, then be prepared to educate them on the wherefores and whys of what you do and the special challenges you face that other organizations don’t. This, by the way, is a good role for those non-technical strategists or consultants: if they have expertise or experience in your sector, they can help bridge that gap to a developer who doesn’t but is good at working with customers.

Fortunately, most successful web development firms are founded by and staffed with technical types who are filling other roles but who started out as engineers. Likewise most successful independent developers are successful because they’re good at working with people to identify solutions that fit within their budget. This may not be true for agencies who “also” do web development, so if it isn’t obvious, look for technical experience in the resume of anyone proposed as your strategist and ask them about that experience before hiring them.

Work with developers

Planning a site isn’t something that happens only before the site is built. In fact, some argue that writing software basically is writing a design document in detail. [PDF] Once you’re working with someone who has stayed up late sweating out lots of different web development problems, you have someone who can work with you to figure out a way to address your problem that fits your budget, rather than simply taking orders and coming back to you late and over budget.

Additionally, software projects are notorious for having requirements change or receiving feedback that changes your initial assumptions—which then changes the requirements. So when you’re working collaboratively with the developer instead of handing them a specification, you have someone who can help you think through alternatives when those inevitable changes occur.

It takes a team

None of this is to say that web developers are the only people who should be involved in building your site or application: rare is the developer who also understands strategy, design, and user experience equally well as they understand code. But the stereotype of the socially inept engineer who can’t talk with anyone has left technical people out of the planning, and planning a site never stops. So make sure they’re in the room, have a voice, and are working with you to balance your needs, your budget, and their technology.