In the Winter 2007 issue of the Sloan Management Review, there is an interesting article titled, "Bridging the Gap Between Stewards and Creators," by Robert Austin and Richard Nolan. The stewards in question are managers of technical employees and the creators are the technical employees. The 
article addresses the inherent conflict between the two groups. It is based on research carried out by the two Harvard Business School professors with "60 people who were deeply involved in the origins of the Internet and modern computing (p. 31). Their insights can be applied to any organization, like mine, in which we have a mix of creative and highly skilled software developers and a smaller group of managers.
I especially liked the table that contrasts the two groups along several dimensions.
- Stewards view compromise as inevitable when delivering a practical business solution while creators do not want to consider compromise when trying to achieve a vision.
- Stewards focus on the business model (or business value) and creators focus on the "coolness" of the solution.
- Stewards try to identify the point of diminishing marginal returns, creators are not focused on diminishing returns.
They then lay out some guidelines for keeping the relationship between creators and stewards in balance, including:
- balance influence between creators and stewards.
- cultivate bridging personalities
- use peer review to provide more accurate evaluation
- structure the innovation process to regularly produce tangible artifacts (deliverables)
- realize that there will always be some conflict.
In our organization, bridging personalities play an important role. It is important that our stewards (project managers, business developers and senior managers) spend time improving their technical knowledge to better understand the issues identified by our creators (developers and consultants) and to communicate these issues to our customers and prospects. Similarly it is important that as our creators grow in their responsibilities they learn about project and product management as well as general business knowledge.
Moving forward, I think that peer review can play a more important role at KMA in helping us assess the strengths and weaknesses of our creators.
Overall, I found that the article had some good insights for managing a software development group, whether it is in a product or services organization or in and internal IT group.
