As a designer, or designer-type-person, running a design shop without in-house technical capabilities, I’ve worked with a lot of different developers and technical type guys (usually guys) over the years. I’ve used different guys for different work. Some of them are better at front end stuff, and some of them are better at back end stuff. Some of them are better at smaller projects, and some of them are better at bigger projects. Some of them have been fun to work with, and some of them, well,…not so fun.
You get the idea, and you can probably relate. There are ups and downs when you outsource anything, when you have to find someone else to do the work you cannot do with your own two hands. There’s a level of trust involved that can be downright scary, especially when it’s your client. (It’s my client, dammit! Don’t screw this up!)
Here’s where I am going with this. Some of these guys have been good, and some of them have been bad. Good and bad, however, are absolutes in this case. They are not relative terms when it comes to picking a dev team.
Here are the things you should be able to take for granted. A good tech team has all the skills required to complete the project. They have the staff to complete the project on time. And they have the management skills to deliver it on budget. Hopefully, your team can do all that.
However, they can do all that and still not be a good dev team. Because only a good tech team can read requirements—business, user, and technical requirements—and deliver the site or application or whatever that you’ve asked for. (A better tech team will work with you to write those requirements. My tech team can do that, but that’s not where I’m going.)
Today, I am on a happy rant about my tech team and what makes them great. What makes them great is their ability to keep their fat mouths shut about our design work. It’s not because they don’t have an opinion. They definitely have an opinion, and they will share it if asked. But what makes them great is that they know what kind of feedback we find constructive. They know better than to say, “I don’t like that color.” They will speak up when technology can improve our designs: make them more flexible, interactive, fun, interesting, or easier to manage. They make these suggestions thoughtfully, not so they can get the client to pay them to learn some new technology or to add something flashy just for the heck of it. We are always open to the kinds of suggestions that make the user experience better and/or make the site management experience better.
What makes them the best is that we can trust them to build the site to pixel-perfection. They follow our design specifications—the pure look and feel specifications—without question, even when they’re unhappy about it. For instance, about 20 minutes ago, one of them (I don’t need to name names, he knows who he is; he is sitting behind me while I type) said, “People who put gradients in their headers are [expletive deleted]!” He was loud and proud about this proclamation (even though he said “header” when he meant “global navigation menu”).
My reply? I know you’re dying to know. Did I berate him, curse him, throw things at him? Nope. I laughed.
He said, “I mean, really [expletive deleted]? They put gradients in the header!”
I laughed harder, and said, “Of course they did.”
He sighed, turned back to his computer, and finished coding the gradients.
And that, to a designer, is the absolute definition of a good tech guy and a great tech team. They know when to challenge us. They know when to make suggestions. And they know when to shut the [expletive deleted] up about stupid [expletive deleted] like gradients in the header.
blackpepperinc.com 