Recently my girlfriend and I went to buy a car. After we made our decision, the negotiations began. The salesman showed us to a table, gave us both a bottle of water, and went into a windowless room to discuss terms with the dealership. He came back and gave us the dealership’s offer. After hearing our counter he went once more into the breach and back he came again with another offer only to listen to another counter from us. Back and forth he went for what must have seemed like forever for him until we came to an agreement all parties were happy with (well, happy enough).
This tension between parties is not unlike that of the tension between project manager and developer. As a longtime developer, now playing the role of project manager, I’m able to identify with both sides of the negotiation.
A capable project manager wants to deliver software on time and on budget. A strong developer wants to deliver software crafted with perfectly elegant code and written using the latest new technology. Both roles are essential, and if either had their way entirely, the client would suffer.
On time and on budget requires familiarity with approach. The first widget off of an assembly line costs a fortune to make while the second costs nearly nothing. An effective project manager needs to find ways to leverage existing knowledge to push projects along. This approach "reductio ad absurdum" can become dogma and lead to stasis. If a project manager focuses solely on meeting the next deadline they will invariably eschew time investment in innovative new technologies, unwittingly limiting their client’s options.
On the other hand, talented developers have a natural curiosity and understand as sure as the sun rises in the east that obsolescence snatches the idle. Investing time in the shiny and new is enticing — and essential. Shiny things can also be a distraction, and a constant embrace of the new can give a developer a shallow knowledge of a lot and a deep understanding of nothing. Fear of stagnation — healthy or not — is irrelevant to the client: they aren’t interested in paying to ensure employability tomorrow, they’re paying for software today.
Too often a shop promotes either the Project Manager's or Developer's ideal to the detriment of the other. They may be mutually exclusive, but ultimately it’s a false choice to embrace one of them or demand homogeny across roles. Listening to your own echo you may confuse the self-referential with the self-evident. It's important for a shop to set up an environment that takes suggestion and criticism.
The shop itself needs to foment an internecine warfare, or — less dramatically — play the role of my car salesman going back and forth in an endless negotiation. Both positions are about problem-solving, one focuses on the near-term and the other on the long-game. A healthy shop needs both to promote efficiency and a culture of learning; it’s the environment that has to negotiate the tension to stay both profitable and relevant. It isn’t one position or the other that makes a brilliant and useful piece of software for a client, it’s the balance.