There was a discussion in my cube yesterday with an engineer that I thought interesting in the context of attempts to get better growth and performance from our company. The position of the engineer was lack of communication between development and management is a problem for many companies, but this is really the fault of management because they cannot understand engineering. If the manager takes the time to explain his or her techniques, tools and terminology, a programmer with their assumed mathematical skills will likely understand what the manager knows, but the reverse cannot be assumed. Programming is innately complex and mysterious and no matter how long and how well the programmer explains their techniques, tool, and terminology, the manager will never catch on. For this reason, the arguer went on, development decisions and design decisions must be left strictly to the engineering staff. Interference by product planners, line managers, upper management, and for God's sake, anyone from the sales staff is just interference and time wasted plus exposure to risk that the product will not perform.
Do you believe this?
My position is this: programming is not that complex although some applications are. Any discipline practiced widely enough suffers from from terminology legacy, that is, the language used is likely a polyglot with layers of overlapping terms accrued from many years of practice and reinvention. That which is assumed to be science by some is just common practice. Further, any terms acquired in a discussion or description that are not applied with some regularity become meatware clutter, that is, they can be pronounced but applying them well without experience is dubious. It becomes a case of "A little learning is a dangerous thing. Drink deep or taste not of the Pierian spring" as Willy the Shake wrote.
Truthfully, of those of you who sling code for a living, how many of you know how discounted cash flow (DCF) and earnings-based valuations work and can be reconciled? Do you know what the key performance variables are for forecasts (sales growth, profit margins, working capital turnover and long-term asset turnover) as well as financial leverage and cost of capital? Do you know how to get those values (from whom, who is credible, how do you vette the data, etc.)?
You might be able to write the code to calculate the values, but I suspect that given some reasonable practice, so can your manager. I also suspect your manager has a better grasp of when to use that software and when to trust their gut. All the counter examples exist on the other side of the knowledge chasm, of course, but I think the point is made.
Too often, we don't trust each other and that is really why so many of our businesses fail or have mediocre growth. We do have to trust each other to do their job. Otherwise, we are drinking from the well of our incompetence.
2 comments:
Nice post. I've gone back and forth across both sides of the engineering/management divide, and i've come to the conclusion that management's understanding of engineering is almost always superior to engineering's understanding of economics. And i'm not just talking about stuff that you'd learn in an MBA program; i'd also include basic engineering economics. For example, i'd guess that not 2 software engineers out of 10 have any experience with software cost models. Most could not explain factors involved in making decisions about engineering for reuse, or building vs. buying.
I've decided to be an engineer because i enjoy it more, but i no longer have any illusions that i'm doing something too special for the management to comprehend.
The tendancy of organizations to oscillate between vertical and horizontal structures is possibly due to clarity about finances (drives toward verticalization and hierarchical command and control) and the need for innovation (the environment or platform changes and the organizations have settled into non-optimal equilibria, essentially, pareto optimal locally, and a Nash equilibrium overall). If the communications between management and development (sans all other players) are noisy or non-existent, there is little chance that the chaotic orbit between those attractors can be modified into a productive schedule.
The local politic tends toward a homophily and while that makes for effective communications within a culture, it makes intercultural communications noisy inefficient. The price paid for fixing that is training, repetition, and negotiation. Certain nodes will become polylingual to a certain degree and they will become the bridges even if they aren't the managers. Often these are not formal positions; they are catalytic. Smart managers identify these individuals and don't interfere with them.
Technically, they are a third-order cybernetic relationship.
Post a Comment