Tuesday, January 11, 2005

Drinking From The Well of Our Incompetence

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.

3 comments:

Joshua Allen said...

Exactly; people are biased to place great value on the knowledge, skills, or experience that they hold exclusively. This becomes a well-known HR problem at a place like Microsoft, where we routinely promote technical people to management positions. If the technical expert cannot make the transition out of his comfort zone, then the whole team suffers. The number one cause of employee morale problems and churn at Microsoft is lack of predictability to schedules, budgets, and feature sets -- the most boring of project management skills seem to be unattainable by many of the technical wizards.

Of course, the blame for systemic problems always rests with management in the end, because it is management's resposibility to determine who manages. And it is management's responsibility to devise the systems by which sales interfaces with engineering in a non-randomizing manner. And it is management's responsibility to cull the herd of engineers (or sales folks) who just don't get it. And so on...

It is certainly possible that engineers with analytical capabilities can point out organizational tweaks which could help make a better company. But in my experience, engineer-types tend to tinker to the point of being counterproductive. Refactoring your code constantly doesn't really hurt, but reorging too much leads to serious attrition. And most of the organizational advice that engineers tend to have is only attractive because it has never been tested in the crucible of real-life experience. Good company management relies on far more than analytical abilities; and there is a reason that the market for CEOs is much smaller and more competitive than the market for engineers.

Mike said...

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.

len said...

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.

Comment Policy

If you don't sign it, I won't post it. To quote an ancient source: "All your private property is target for your enemy. And your enemy is me."