A lot of times I’m talking about a solution with someone who doesn’t speak the same technology language that I do. Usually, this is during a sales meeting or a kick off meeting when the stakeholders and business owners are present. In our case the non technical people range from doctors, attorneys, artists or heads of marketing. For example, the head of a marketing department probably doesn’t care that we’re going to build a Web API in .Net 7 or the front end in React. But they are interested in what the application is going to deliver, what is the front end going to look like and how is this the solution to solve all their problems. We can deliver this information using detailed mock-ups and wire frames as well as tossing out the technology jargon in favor of more language anyone can understand.
Our clients are interested in the capabilities technologies bring to the table, like speed and a beautiful easy to use interface, not necessarily the technology specifics. They probably don’t care. What the company is hiring us for is to create a solution or solve a problem and generate revenue. As long as we are capable of delivering on what we agreed upon, we could write the solution in Classic ASP for that matter – actually don’t do that, that would result in costing your client more money down the road and therefore would be a bad business decision.
So, while it’s important to know the tech details of the project you should know your audience. If we are working side by side with a corporate IT group with developers, you can be sure we will be sharing many may of the technical specifics. Too many times I’ve been in meetings where the technology folks go way too much into detail about the product or solution. You can see the moment the client or stakeholders eyes glaze over and the point where you’ve lost them. This is an important thing to pay attention to during a meeting, if you catch it in time you can reel them back in before it’s too late. Another sign you might be going to techie is when people pull out their phones and start to answer email.
It’s a common phrase in the developer community to say “You’re not paid to write code, you are paid to solve a problem”. I couldn’t agree more. For example, when I go to the bakery, I don’t want the baker to tell me every single ingredient and every step of the baking process that was taken to create my donuts. But I do want to know that it was crafted using good ingredients, the staff was taken care of and I know that the final result is going to be exactly what I want. There’s a level of trust that is established between the client and producer where the client can trust you to create the thing they need and want.
Trusting the company that they align to my values and knowing they are going to deliver is important. When I go to the bakery and see the donuts I know that’s the what I’m going to get. No need to show me the flour and sugar. The same goes for software, show the clients what they want to see and speak their language. Our clients trust that we have their best interest in mind and are going to create the best possible product while keeping their best interest in mind.