How to Work with Engineers on a Web Development Project
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How to work with engineers
Every successful site is a collaborative effort, requiring people from different disciplines—design, engineering, marketing—to work side-by-side. But they think differently, work differently, and speak very different languages. For a product to succeed, you have to learn to bridge the gap.
If you're a non-technical manager working on a software project, it helps to understand the lay of the land. These 17 tried and true tips will help you navigate the world of software development and understand the engineers who rule the roost.
Bring them in early. This applies to all collaborative projects, and holds true here: You should consult engineers early in the process, when the product is still being defined. If you don't, you risk both charting an impossible course and alienating your engineer.
Present a specific problem to be solved. Engineers are natural-born problem-solvers. They usually produce their best work when presented with a problem to solve (rather than a solution to implement).
Collaborate, don't dictate. It takes at least two minds to create a web application. You may understand the user problem you're solving, but the engineer understands the technical problem. You need each other. In order to produce a successful site, you must find a way to work collaboratively.
Be clear about what you need. You must have a clear, mutual understanding of what a requested feature has to do and what it doesn't have to do. So don't ask for vague or ill-defined features. Go over every aspect of the product in painstaking detail, in order to avoid misunderstanding. "The key thing to do is to sit down with the engineer and go through all the details," says Noah Mercer, former director of software development for The New York Times and The Washington Post. "Define everything in as much detail as you possibly can. And then write it down."
Be decisive. Think through needs and priorities before development starts. Nothing causes engineers more pain than "flip-flop" project managers who can't make up their minds, says Jim Morris, former Director of Software Engineering for Fogdog Sports. A change in plans usually means you've wasted their time and energy. "Every feature change feels like a stab of a knife to an engineer."
Prioritize. Every new feature added to the list pulls resources. Don't request a new feature without explaining where it falls in the priority list. Be explicit about what's most important, and what should be completed first.
Set clear goals for the project. The better you articulate the goals, the more effective your engineers can be. "If it's ingrained in them—what the goals of the project are—then they have a measure by which to make some of the micro-decisions, even when you're not around," says Greg Dotson, Chief Information Officer of Guru.com. "Then they don't have to involve you in every micro-decision, and they feel empowered."
Think in versions. The first released version of your application will not be the last. Web software development involves constant iteration, so you have to get out of the mindset of producing a grand, perfectly executed product all at once.
Ask questions. As producer or designer, you need not understand the intricacies of the site's system architecture or object model, but you do need to understand what's going on.
Learn the language. As intrepid travelers always learn: It helps to speak the language. Or at least understand a few words. Brush up on the terms you hear engineers throw around. (You can look up any word on Google and have a definition in seconds.) But don't just throw buzzwords around—make sure you understand words before using them yourself.
Ask about implications. It's hard for non-engineers to know whether a given task is easy or difficult. So it's important to ask: "How much time will this take? Will it jeopardize other projects?" Cate Corcoran, former Director of Online Communications for PeoplePC, says, "One thing I would do is just admit that I didn't understand the magnitude of certain requests. It's almost like a two-step request process. First I'd ask, 'If I requested this, what would it mean?' Then I'd say, 'OK, I'm requesting it.' Or, 'OK, I'm not requesting it.'"
Show some interest. Many engineers hold their projects near and dear to their hearts. So showing a sincere and informed interest in their work can go a long way toward building trust. "Engineers are in love with their invention," says Indi Young, a partner with consulting firm Adaptive Path. "There's a real part of them in there. They know how it was born. They know why they brought it to life. They know the little jokes they put in it. They know where it's going to go next. They have goals for this thing. This is just like a child, really. So if you're interested in it, and you ask smart questions about it, then they're going to want to talk to you. They'll be more likely to trust you."
Convince them it was their idea. "There's a lot of judo involved in working with engineers," said Jeffrey Veen, author of The Art & Science of Web Design. "You know, you use the force of your attacker against them. Last week, I spent, literally, an hour going in this huge circle with an engineer until he decided to do the thing I wanted to do in the first place... That's the judo you use with engineers. Let them decide to do the right thing, by directing them toward it."
Find a good mentor. It's hard to find an engineer who can patiently explain technical concepts in non-technical terms. When you find such a person, don't let them go! Get them on your team whenever possible. And even if they aren't working on the same project (or in the same company), hold on to them! Ask them questions; take them to meetings with you; remember their birthdays; buy them coffee. They are very, very important to your success.
Don't forget to say thank you. "It's really important to give people positive feedback, and to thank them for the things they do," says Cate Corcoran. "A lot of times, engineers will act like they don't need your praise. When you thank them profusely for working all weekend, they'll act like you're a dork. But I wouldn't believe that message."
Smile and nod. There's nothing wrong with faking it every once in a while. As designer Jeffrey Zeldman writes in his book, Taking Your Talent to the Web, " You might hear [developers] talk about Perl, Java, ASP, PHP, SSI, XML, ColdFusion, and other technologies. Just smile and nod as if you get it."
If all else fails, quote Star Trek.
"You have to ask questions," says Lance McDaniel, VP of Creative for consulting firm SBI and Company. "Non-technical people get thrown off in technical conversations by acronyms and jargon. But once you get caught up on the terms, the conversation is not unreasonable to follow."
"Of course, designers are just as bad," he laughs. "They're both equally stubborn."