The Hunter and the Blacksmith
In my years as a consultant, I’ve worked across multiple industries and have worn many hats on the spectrum of development and management. Unfortunately, many environments suffer from a disconnect between the enterprise leadership and what is actually being coded. This often results in both sides being frustrated: the big bosses feel like their engineering team is incompetent whereas engineering thinks that the rest of the organisation has no idea what they want.
If you are reading this, you are most likely on the engineering side of things. I’ve been there for most of my professional time, so I know the pains: requirements changing all the time, unreasonable deadlines and impossible requests. Often, it felt like we were the only ones working hard and the rest of the team had no clue about anything. It especially felt frustrating when the sales department made impossible promises that engineering gets stuck with.
However, things are not that much better on the other side of the fence: your sales people are doing their best to generate revenue and keep the company afloat by trying to convince people to buy or invest in a solution that they cannot directly contribute to. Most of the time, you won’t see someone in the sales department buckling down and coding that one key feature that will secure a big client. They can feel absolutely powerless to do their job, especially when the engineering team does not share their urgency.
As engineers, we sometimes forget that the sales and product departments can provide key insights about the customer. Great sales people are attentive to their customers: they know their market, they know subtle things that make them happy or things that ultimately do not matter to them. They can provide the most valuable information of all: context.
Sometimes, it helps to think of a company as a tribe: the sales people are hunters and the engineers are blacksmiths, both trying to ensure the well being of the group.
A Little Story
Imagine you are a blacksmith for your very own tribe that lives by the sea. One of the tribe’s hunters comes up to you one day and asks:
Hey listen, I need a gun that works underwater. Could you make one for me?
Ridiculous! You barely have working firearms as is. You take a deep breath, but you keep your cool. You ask: why do we need that?
To hunt sea creatures: we noticed the water nearby is full of delicious fish and lobsters to feed the tribe.
Great! We’ve got context. Remember that your hunters are not idiots, they have their area of expertise (tracking, studying migration of prey, etc) and they have the best interest of the tribe at heart.
You can then propose a harpoon gun instead of a firearm that works underwater.
Yes! A harpoon, that’s what we need. Can we get it within the week?
Impossible! You cannot gather the resources and construct harpoons in a week. That’s another thing engineering is used to hearing. Don’t panic, and again ask for context. Why this week?
Well it’s the mating season of the tastyfish: a small, soft fleshed, slow moving nutritious fish that could feed our tribe. It’s the best time to catch them in the shallow waters.
Ah, perhaps we can find a compromise. Can another solution be built faster in 1–2 days to capitalize on this situation while you build harpoons for the long term? How about using a spear with an elastic?
This might seem like a random example, but when I was in Belize, we went hunting using fishing spears with elastic tubing which were incredibly effective, despite their simplicity.
Fantastic! We can start hunting for tastyfish this afternoon!
Key takeaways
Remember that you are on the same team: engineers and non-engineers bring to the table different skill sets and points of views that are ultimately beneficial if you take a step back and consider both sides.
Keep your ego at the door: you are not smarter than the sales guys (and they are not smarter than you). Be humble, and ask plenty of questions: it’s ok to not know subject matter lingo or to be missing a piece of the context.
Always be attentive to the product/sales needs: sometimes they will ask for a specific tool or solution, but try to get to the fundamental need at the core of the request. Sometimes a prototype or partial solution will go a long way.
Most of the time, listening attentively and asking plenty of questions while offering alternatives will yield a collaborative solution that is optimal for business. Trust your non-engineers: they have unique insights on your customers or they can put you in contact with subject matter experts that will help you build a better solution than you could develop in isolation.
