From the author of

From the author of

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.

"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."

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."

"Of course, designers are just as bad," he laughs.
"They're both equally stubborn."

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."