I Know What You're Thinking

Back in grad school, I had a professor who told me about an interdisciplinary summer retreat he had been invited to years ago.  There were economists, political scientists (like him), sociologists, educational theorists, philosophers, and many other smart people.  Though they talked about a wide range of topics, he found it most interesting that, by the end, he could predict the kinds of questions people were going to ask before they asked them.

Economists would wonder about incentives, transaction costs, and barriers to entry.  Sociologists re-framed things in terms of demographics and norms.  Educational theorists were concerned about developmental impact.  Philosophers and English professors would bring the conversation back to 'the text.'  Political scientists would analyze power relationships and procedural constraints.  And so on.

This story has stuck with me for years, especially as I experienced the same thing myself in a similar summer seminar.  On the one hand, it's no surprise that professionalization teaches you a conceptual system with a specialized vocabulary, and it shows the value of doing so.  On the other hand, it's all a bit depressing, as if what we study and do for a living bends us to the wheel of a necessarily partial worldview.

Since leaving the ivory tower and returning to software full-time, I've noticed the exact same phenomenon.  In a technology firm, people from each team will have a perspective that's hard to shake.  Developers and architects will be concerned with system coherence and stability.  Testers live in a world of exceptional cases, where everyone is trying to divide by zero and servers are falling like flies.  Product analysts think in terms of costs, revenue, and rates of return.  Accountants want to know how they can report on it.  Support teams are concerned with how much manual intervention is required.  And project managers want to know how many person days it will all take.  And so on.

(This is all very rough, but you get the idea.  It takes a lot of work to truly appreciate any of these perspectives.)

It's important to recognize these points of view when working with other teams.  If you give a technical reason why it will take a long time to develop something, non-developers will only hear white noise.  They'll probably just think you don't want to do it.  But if you can talk about it using a set of terms they understand, such as existing products and features or past time estimates, you're much more likely to have a productive conversation.

This may seem like common sense, but I think it's one of the central challenges of getting things done in a complex organization: you have to be an expert in one knowledge domain while simultaneously being able to communicate with other experts in other knowledge domains.  All projects involve some give and take.  The less agile your process, the more important it is to make sure you have good communication from the start.  I've seen many projects fail because no one really understood what anyone else wanted.