I’ve mentioned before that my first computer programming job was at a small company that provided software support, maintaining COBOL processing software, for small banks in western Colorado and eastern Utah. My first day on the job, Earl took me to a meeting at a bank a few hours’ drive from the office.
Earl’s instructions to me as we entered the bank were “Just sit there and listen. Don’t say anything unless you’re asked a direct question.” I’d been in similar situations before, so I had no particular difficulty following those instructions. Other than introductions at the beginning of the meeting and some brief informal chat at the end, I sat there silently taking notes.
On the two-hour drive back to the office, Earl asked me what I thought of the meeting. The first thing I said was, “I guess since bankers won’t ever learn to speak computer, I’ll have to learn how to speak bank.” Earl agreed and we spent the rest of the drive back to the office with me asking questions from my notes and Earl explaining the basics of what I needed to know about bank accounting.
I was fortunate to learn that lesson at the very beginning of my career, and I’ve made it a point to remember that every time I start a new job. Almost every job I’ve ever had in the 40+ years I’ve been in the business of software development involved me interacting with clients who know a lot about their business and essentially nothing about computers or software development. The onus was always on me to obtain the domain knowledge required so that I could meet customer’s needs.
It goes a little further than that, though. Not only must I understand the client’s business, but I have to explain computer-related issues to them in terms that they understand. When they ask me to solve a business problem, I have to understand exactly what they want, often asking them multiple questions to ferret out all of the details. And when they ask for something that’s impossible, or balk at the cost of implementing their favorite wish list item, I have to provide a clear explanation that doesn’t involve a discussion of gigahertz and terabytes, and provide lower-cost alternatives along with clear identification of the potential benefits and drawbacks. All in language that they understand. And, again, it’s on me to be sure that they do understand it.
It’s harder than being a school teacher in one respect: if the student fails, I’ve failed. I can’t say, “but he didn’t pay attention in class or do the homework.” If what I deliver is not what the client wanted (not to be confused with what the client asked for), then I failed in my duty and am at risk of losing my job.
As difficult as it is sometimes to acquire domain knowledge in a new field, believe me when I tell you that it’s a whole lot easier than trying to educate your clients about the field of software development. Sure, they’ll pick up a few bits and pieces along the way, but much of their understanding will be shallow or incorrect, and they’ll try to generalize from isolated incidents. Your only path to sanity is to take on the role of eager student, immerse yourself in the client’s business process, treat your client like an esteemed professor, ask probing questions, and take copious notes.
Learn your client’s language and learn to provide explanations in their terms. That’s the only approach that’s ever worked for me.