by Jared Goralnick
Last week I was lucky enough to see Chuck Geschke, a co-founder of Adobe Systems, speak at Loyola College in Maryland. Not only was he passionate and insightful, but he offered some lessons that I found particularly valuable. His main message was that if you treat your customers, vendors, and employees with respect and kindness then they won’t come back to bite you when you need them. However, one of his specific analogies I found to be particularly helpful immediately afterwards. I’m likely going to butcher its explanation, but please don’t let it reflect poorly on him. He explained that
Engineers can often be classified as Arrow Shooters, Scouts, and Road Pavers
Arrow Shooters are the ones who see an idea in the distance as a worthy target. They’re the visionaries who recognize a possibility for a new product but aren’t necessarily the best suited to determine how to get there or whether there will be financial rewards in the end.
Scouts are the people capable of surveying the market, considering what resources need to be assembled, and determining if there’s a viable path to the target. They wouldn’t know where to look if it weren’t for the arrow shooters, and they’re not necessarily the folks who can dig in and make the product happen.
Road Pavers are those who get their hands dirty with the real development. With a little bit of the overall vision and some general landscape of the situation, they’ll get you from point A to the target. And if they’re a great road paver they’ll be able to step one foot in front of another until they get things done, on schedule and on budget.
Mr. Geschke used this analogy to explain one of the ways that Adobe balances the types of engineers they hire. It’s not enough to hire the best coders or the true visionaries–it’s about finding the right mix of people who can work together.
I found this idea to be intellectually stimulating, but initially not all that relevant for my small business. Then the next day I was faced with a hiring decision and a seemingly obvious existing employee for the job. My gut told me that it wasn’t a fit, even though it was essentially one software developer that could rise to fill a larger development role. Immediately it became clear that not only was it an issue of a road paver who wouldn’t make a good arrow shooter, but I also realized that the employee, once he understood the position, didn’t want to take on that role.
In other words, Geschke not only recognized that these different roles exist, but that someone who codes all day is just as important, and arguably as difficult to find, as the visionary who regularly recognizes brilliant ideas for new features or products. My existing employee knew what he wanted in his career and that he was quite good at that–so who cares if someone else might carry an arbitrarily fancier title?
Geschke’s theory here is really another great way of recognizing & rewarding strengths while avoiding the Peter Principle. If you have an opportunity to hear him speak and learn about how Adobe has grown & prospered, I encourage you to take the opportunity.
You should really subscribe to Technotheory via 
email or rss.
