Monday, August 13, 2007
Managers who play Architect
One pattern of conversation, I frequently hear from architects is the problem of handling manager-types who attempt to play the role of architects. It seems as if too many of them are getting it twisted and can't figure out the difference between controlling the process and making technical decisions...
Managers understand that the art of developing software is expensive and they are charged with ensuring that folks upstream get what they paid for. This causes them to think that they should be in charge of all important decisions, both technical and non-technical.
I wonder if folks who call themselves enterprise architects understand that it may be better to encourage those higher on the food chain to stop championing "process" and instead get those actually developing software to do so. What if the developer(s) became the hub of activity where all requests for changes went directly to them and weren't filtered? Sure, managers in any form, wouldn't be able to assert their abstract authority but could it bring more integrity to how decisions are made?
Having those not involved on a day-to-day basis making decisions is dangerous for an organization. The notion of a balanced score card, key process indicators and other metrics oriented thinking will ultimately lead to IT being highly aligned to the business at the expense of reduced efficiency and increased poor delivery of valuable working software.
Using metrics approaches also makes it difficult to tell whether people are the problem or the process is the problem as most enterprises don't have a good way to distinguishing either...
| | View blog reactionsManagers understand that the art of developing software is expensive and they are charged with ensuring that folks upstream get what they paid for. This causes them to think that they should be in charge of all important decisions, both technical and non-technical.
I wonder if folks who call themselves enterprise architects understand that it may be better to encourage those higher on the food chain to stop championing "process" and instead get those actually developing software to do so. What if the developer(s) became the hub of activity where all requests for changes went directly to them and weren't filtered? Sure, managers in any form, wouldn't be able to assert their abstract authority but could it bring more integrity to how decisions are made?
Having those not involved on a day-to-day basis making decisions is dangerous for an organization. The notion of a balanced score card, key process indicators and other metrics oriented thinking will ultimately lead to IT being highly aligned to the business at the expense of reduced efficiency and increased poor delivery of valuable working software.
Using metrics approaches also makes it difficult to tell whether people are the problem or the process is the problem as most enterprises don't have a good way to distinguishing either...
