Friday, June 11, 2010
Culture, Style & Push backs
No, this is not a section best covered by one of those lifestyle magazines, but rather an area that is often neglected in books on IT management. Your leadership is all about imprinting a specific culture onto your team. Whether your team works with a spirit of openness or secrecy, confrontation or collaboration, urgency or relaxation, depends upon the behaviors you promote as a leader. In IT, more than in other profession, a well-motivated team is likely to deliver greater results than a team that is discombobulated and demoralized.
Once you have set-up the team structure and staffed it with the best resources you can garner, you should strive to do the best with what you have. Remember that driving a team is not unlike driving a car. You need to know what gear to use when turning or when going straight. Managers with a one-dimensional style fail to realize that a project is a living thing. Projects should be driven with precision and in line with the circumstances. This does not mean that you should relax the speed of delivery. “If you have everything under control, you are not going fast enough,” are the words of Mario Andretti. Not only should you expect to operate to the very limits of your control, but you should also accept that, if you have staffed your team with the right balance of skills and styles needed to achieve success, you should expect to deal with the negative consequences of personality issues, tensions, and frustrations.
And speaking of frustrations. . . Assuming that your transformation effort attempts to establish a corporate wide architecture, you are likely to find significant push-backs—especially in the area of architecture (tenets and standards, remember?)
Following are the top ten favorite push-backs I’ve heard:
1. We have a time to market issue. We need to deliver this in two weeks. When the architecture is in place, we will migrate to it.
2. I know you expect us to follow the new architecture standards, but I can’t afford to train people for it just now.
3. I know you have some of the architecture running, but it has never been tested. We certainly don’t want to be the first ones to use it!
4. I know you have the architecture running and it has been tested, but we’d feel more comfortable using our better-tested Excel macros.
5. We are 80% architecture compliant anyway, so what’s wrong with the use of a different programming language?
6. We like your architecture but it doesn’t really apply to our project.
7. I not aware of this new technology, so it mustn’t be ready for prime time yet.
8. I recently read in PC Week that protocol XYZ is better!
9. You mean you really want to deploy this stuff? I thought it was only meant as PR to impress our customers!
10. We really want to be compliant, we really do, but we think that sticking with Cobol right now is safer.
How do you handle these types of remarks? Well, tenets and standards are there to provide an overall framework to help align the enterprise as much as possible. But you do have to be flexible, particularly when the business drivers are such that, if you are not flexible, you could become road-kill. It’s best to accept that architecture exceptions are going to take place and codify an appropriate exception-process (even then, there will be exceptions to the exception-process, rest assured!). Bottom line, evaluate the argument against the exception criteria, which will hopefully include minimum remediation to ensure the architecture process can be brought back on track. Is there a need to sometimes develop a cheap-and-dirty tactical solution to solve an immediate business need? Okay, no problem! Just make sure to fund the on-going work and make certain that this tactical solution is eventually re-factored into architecture compliance; plus take into account the migration from tactical to compliance. I have discovered that sponsors of tactical solutions will rarely deny this very reasonable request. Other arguments may be easier to dispense with, but you should never, ever, close your mind to them. Perhaps protocol XYZ is better and cheaper than the one you have been considering! Give everyone a fair shake and allow them to justify their rationale. If the argument was “religiously” motivated, dogmatic, or driven by some other precious self-interest, justifying it will be difficult. Still, if there is reason for considering an alternative, then please do so.
In the end, I circle back to the point of Culture. As long as the team is committed to the success of the project, and the reasons for the negative issues are frank disagreements based upon well-meaning differences of opinion, you should be able to manage the situation to your advantage. Think about it for a moment. We all know that pressure creates diamonds and friction polishes them. In my experience many successes are brought to fruition under the heat of deadlines and in response to initial failures. If from the onset, you’ve seen to it to create a great team, you will get the results you want in the end. Just be sure to have plenty of coffee and donuts on hand to support the effort!