The Bi-Lingual Advantage in IT

Stephen R Balzac & Marilyn Edelson

Imagine a typical software solutions problem. The company needs to improve bottom line revenue, the customers are complaining and want their problem solved yesterday. At best, the engineer sees a technical challenge involving algorithms and code; at worst, he sees an annoying interruption to solving interesting technical challenges. The engineer’s goal is to build a robust, elegant solution to a problem. The manager, on the other hand, sees something very different: his focus is not on the technology but the process of assembling and coordinating a team. Who has the right skills? What skills are needed? What will this cost? How quickly can it be done? The manager’s goal is to give the customer what they really want, even if that is not the most elegant solution.

Dilbert highlights, to great effect, the gap between management and engineering. Frequently, the two groups seem to live in different worlds; more significantly, they often appear to work for completely separate companies with totally contradictory agendas. Sadly, there is some truth to this: as Ed Schein, professor emeritus of business psychology at MIT Sloan, points out, managers and engineers form two distinct, separate organizational subcultures. Each group has very specific goals, which may not always be in alignment. Unfortunately, since both groups are working for the same company, and apparently speaking the same language, they tend to assume that they have the same image in mind. As many managers and engineers have discovered, this can lead to more than a little friction.

It is, therefore, helpful to be bilingual, speaking both “Manager” and “Engineer.” Just understanding the concerns of the other group is not enough; being able to express them in terms the other group can understand is critical. In this way, each group becomes better able to appreciate the unique strengths and contributions the other brings to the business.

So how does one go about becoming bilingual? While having experience in both engineering and management might seem the obvious answer, sadly, it does not necessarily work that way. There is an old joke that an engineer’s idea of social interaction is getting the decimal point in the right place. Many software engineers are not the most socially adept. As managers, therefore, they often become little more than engineers who sign timecards. Frequently, engineers “promoted” into management are still trying to be technical experts. Unable to see any solutions other than their own, they end up fighting with the rest of the team over the “right” way to implement a solution. A manager, on the other hand, needs to focus on the team as a system. That requires a degree of social awareness and skill that many engineers have never learned, may not be capable of or even really interested in, just as many managers working in software organizations may not be trained in, capable of, or interested in software development.

What then is a good way of becoming bilingual? Daniel Shapiro and Robert Fisher of the Harvard Negotiation Project provide a number of negotiating suggestions in their book, “Beyond Reason.” Their techniques can, with very little effort, be adapted to the IT world.

• Start by appreciating the skills and expertise that the other party brings to the table. Engineers are highly trained, highly skilled experts in their domain. Genuinely acknowledge that. Treating people like interchangeable components devalues their skills, and makes them feel unappreciated. On the other side of the coin, engineers need to appreciate management’s contribution: running the business, providing the funds that make the engineering work possible, etc.

• Build upon affiliation. You’re already in the same company. What else do you have in common? Do you all have the same vision? Take some time to work on the image of the future and make sure you all agree. If not, or if what each group considers important is contradictory, then instead of building affiliation, you build separate, warring camps.

• No one likes to be told how to do their job. The more expert they believe themselves to be, the more this is true. Give people as much autonomy as possible. Recognize that an obvious question to you may be very difficult for the person asking it; that’s why they are asking! Tomorrow, you might be the one asking the “dumb” question. Inform without denigrating. Ask good questions. As David Rock, author of “Quiet Leadership; Six Steps to Transforming Performance at Work” suggests, “become passionate about improving not what people think about but the way they think.”

• There is often a struggle for status between managers and engineers. Managers are frequently viewed as the bosses, while engineers are employees. Engineers, however, see themselves as knowledgeable experts, without whom the project couldn’t be built. Recognize the status of each party.

• Acknowledge the importance of the roles played by managers and engineers. Both, and a variety of others, are critical to the success of the company. No one role is more important than the rest.

The key to building a successful business is not just assembling teams, but teams of teams. All parts of the business need to work together for the whole to succeed.

Good luck!

Stephen Balzac is president of 7 Steps Ahead, LLC (www.7stepsahead.com), a consulting firm focused on increasing client revenue and customer base. Contact him at 978-298-5189 or steve@7stepsahead.com.

Marilyn Edelson is president of OnTrack Coaching & Consulting (www.ontrackcoaching.com) as well as co-founder and Principal of IT Decisions Coaching LLC (www.itdecisionscoaching.com). She can be reached at 617-964-3202 or m.edelson@itdecisionscoaching.com.