As a creative director (who also happens to oversee the Web development projects) for a direct-marketing company, I am well aware that I am always the most technically challenged person on the project team. High school math and a journalism degree only get you so far. But, like the ancient Egyptians who relied upon big logs, sand, and clever ramps to create pyramids the size of office buildings, I’ve learned to make the most of my skill set. I’m also in charge, so people pretend not to notice my shortcomings.
Surprisingly, after nearly a decade in this role, I’ve acquired some expertise on how business people and developers can work together better—drawing on each other’s strengths and understanding each other’s weaknesses. Following are three truths I live by:
1. Developers will complicate everything if you let them.
Techies can be too smart for their own good. Yeah, that’s you: Always a dozen lines of code away from pure genius. There’s an algorithm to solve every problem. Rien n’est impossible! But why buy a turbo-charged power blower to clean up leaves in your front yard when a $20 rake will do? Sometimes old-school simple is better. We non-technical types are here to keep the brainiacs grounded in reality. So trust your instincts and don’t be afraid to assert some common sense over a runaway process—and be particularly wary when anyone insists on talking over your head. If all else fails, remind everyone who is footing the bill.
2. IT people can write beautiful code, but don’t count on them to make things sensible (see 2a) or pretty (see 2b).
2a. Developers will relish tackling any problem you put in front of them—the trickier the better—and will likely do so in a literal way. The best developers are the ones who care as much about the business requirements and usability ramifications behind what you are asking for as they do about your specific request. Those of us unfamiliar with technology sometimes latch onto ideas that seem cool, or land on technology-related solutions to a problem, without fully thinking through the root issue. Developers often assume that we have fully vetted an idea, when in fact we haven’t. We think we’re brainstorming and, meanwhile, the developer is writing project specs. The lesson here is to remember Truth #1, which ensures that what gets built solves a business problem you actually face (as opposed to solving a business problem that someone else faces, or one that nobody on Earth faces).
2b. Unless a creative type intervenes, the presentation layer will be ugly. People like me, who live and die by our ability to spec a proper typeface, align design elements on a grid, and piece together cute outfits even on our days off, forget that these skills are not universally shared. You’ll be happier with the result if you assign a visual person (e.g. graphic designer) to the project from the very start, which will relieve your technical team from having to think about whether your project is having a good hair day or a bad hair day.
3. Treat your development team like siblings.
We all got labeled as family members: The Smart One; The Wild One; The Whiner. Each of us has a role to play and none is necessarily better than the other. Bridge a partnership with developers who—like your brothers and sisters—you can trust with your humanness. Show them your stupidity and silliness and encourage them to show you theirs. Hold each other accountable for mistakes, but know that mistakes will happen. In the end, it’s the connections between us that give our lives and our IT projects meaning. You just have to believe that the bonds between us are more powerful than the ones that pull us apart.