Communicating With Engineers

Have you ever seen the above cartoon? More to the point, have you ever lived it? And if you have, you’ve probably lost a few years of life trying to understand how something seemingly so simple could… not be so simple!

From my standpoint as an engineer, it boils down to things not being communicated. If the customer fails to mention an important business rule then it’s possible that while creating the project a solution to a problem for the engineer would actually break the system as far the customer’s needs go.

It’s understandable that people forget things…we are all human right? Would it be better to mega-train the engineers so that no business rules could be missed? Should the customer be involved in every decision during the application’s design and implementation? I’ve been on teams where we’ve gone with one of those choices and neither really worked out, there should exist some middle ground where customers and engineers are communicating on a regular basis about the project. Have the engineers explain to the customers what they are doing for that piece of the application and why if it conflicts with something they expected.

Somewhere there’s an ideal frequency of interaction which will result in a product that has the correct amount of compromises without a ridiculous investment of time or money on the customer’s part.

There could also be room to give the engineer more flexibility when it comes to business rules or ways that the application could work. A good engineer will have up-to-date knowledge of current technologies and can often do things the customer may have not thought of, or even known was possible. Giving the engineer room to make decisions that are best for the website and then adapting your business rules to the new system could be very beneficial. Customers and Business/Sales teams win when they invest the engineer in the outcomes of the project. Getting the engineer invested accomplishes to things: 1) it makes them more important in the process and not just a tool to be leveraged and 2) engineers want to solve problems not just write code. You make money from us when you let us do some thinking and solve the problem. I’ve automated tasks for customers in the past that they had no idea we could automate, but the project started out with “This process has to be manual” until I showed them it could be done, and they ended up changing the rule since the application could do it faster. 90% of the time you won’t get the answer you want immediately, but if you’re patient, you’ll get a better result because we’ll stay up all night working on it until we’ve solved it, and solved it right!

I know it doesn’t sound like communicating more with the cave dwellers would help but it does (not just about the specific technical requirements!), and it’ll be less frustrating for everyone, so get out there and call your engineers!