I was lucky enough to track down Mary Lavine, Managing Director, IT, Schwab Development. Even though most of her teams are focused on application development, some need to provide support for those applications in production environments.
One team in her department that was shouldering a heavy support burden was the Content Management System. She brought in an experienced senior manager, Mei Wan, who was familiar with the area and knew she was walking into a difficult situation. Her team was responsible for development, tools, systems administration, technical and business support. They barely had time to breathe, getting calls at all hours.
|Smart IT Columns|
How to Sell Product Purchases Internally
Is Everyone Replaceable?
Managing Vendor Demonstrations
Understanding Your 'Idiot' Manager
I asked if Wan had a particular example of a team member coming to her with complaints. There were so many times I couldnt keep track!, said Wan. No one was happy and no one was being successful.
Multiple team members came to her with the same message: We are doing way too many jobs, working around the clock nights and weekends, to keep going at this pace. There are things I have to offer the company way beyond what Im doing today. The not so subtle message was that management had to make changes or start losing team members.
After hearing this, I told Mary that I needed six months to make significant progress on this problem said Wan. They both agreed these developers were hanging on by a thread and they would start to lose them if the environment didnt improve. I agreed to give her team air cover, said Lavine. If the business side complained we werent delivering enough for them, I would ensure we were making progress and point to incremental improvements to buy us time.
And they both knew that each developer owned a large chunk of systems knowledge that would be almost impossible to replace. We felt if we lost any one of them we effectively lost the system because they each owned a key core competency, said Lavine. It was an easy decision to support these changes because we could qualify what the business would NOT be able to do for multiple months while we tried to hire, then train a replacement. Not to mention that during this time the others on the team would be even more stretched to cover the loss of expertise.
Wan started to collect feedback on improving the support situation, spending time listening to each of her developers. These were smart people that were just being told what to do. I simply leveraged their ideas to start building a better support process, said Wan. By listening to their ideas and finding small wins, she built up trust with them and that bought her more time to fix the problems.
Next page: Offloading Duties