As IT professionals, we have to readily adapt to change. Technologies constantly change, our clients change, and each job is different. I pride myself on having a great degree of technical knowledge that I can transfer to almost any job. Most of the time, this works; sometimes, though, the knowledge I think I have from the past hinders my progress in the present. A recent experience drove this point home to me.
At the time, I worked with a system integrator on the east coast. Our client wanted a desktop rollout with the typical mixture of new and refreshed systems along with a new server infrastructure. The team met every Monday to talk over problems. It met again on Thursdays to build the work plans for the Saturday rollouts.
This particular week started out like most others. We had a plateful of problems from the Saturday rollouts to hand out. After divvying them up, one issue remained: a misbehaving mail server. No one at the table really wanted to take it on, so I did. At that point, I had almost 10 years of experience with mail servers. How bad could it be?
Monday, Tuesday, and Wednesday went by in a blur. Thursday rolled around and the server was still not up. I stumbled into my planning meeting unprepared for the weekend’s work. One of my juniors asked me point-blank what was wrong.
On Friday, during my weekly assessment, I finally had to face that question. What was wrong? Why was I so stuck on this one problem?
What was the problem?
Looking at the previous week, I could see that I had accomplished none of my weekly objectives or my architectural responsibilities. I set aside everything to work on that server. Why?
Like most senior architects, I made my reputation first as a whiz-bang server slinger. Then I moved on to building networks, designing systems, and recommending architectures. But in my heart of hearts I never gave up the idea that I was still that keyboard jockey capable of solving any technical problem.
Holding onto that pride led me to three classic management errors.
I took on a job that I was not qualified for
My experience with the mail package (in this case, sendmail) was out of date. I knew the general outline and the system architecture, but not how specific configuration options interacted in this newer version. When I got in over my head, I refused to back down or let go of the problem.
I allowed a minor problem to derail my leadership efforts
When I focused on a single technical problem, I ceded my leadership role. I should have spent my time working with the team on creative troubleshooting, solution development, professional development, and business/technology vision synergy. Instead, I burned that time on a server. This caused our communications, customer relations, and adaptive design efforts to lag behind our deployment.
I shifted my own focus from the macro level to the micro level
I started to question specific configuration choices, settings, and detailed micro-level decisions made by my team. This choice to make the details my concern undermined my team’s trust in my impartial analysis of the situation. Before, they’d believed that as long as the system operated within acceptable parameters, I wouldn’t ride them. This incident breached that trust. They stopped putting their best work forward and started trying to second-guess me. As a result, the system started to degrade.
Stabilizing the server ended up being personally embarrassing, but reasonably simple. I swallowed my pride. Then I reassigned the problem to one of our engineers. To free his time, I took on some of his communication-oriented tasks until the server stabilized. He restored stable operations in three days.
The off-track design efforts required a great deal more work on my part. Allowing our design efforts to fall behind, as well as dropping the threads of leadership, was frankly inexcusable. It took the team almost three weeks to catch back up to design goals. I worked a lot of unpaid overtime during those weeks to ensure we would hit our targets.
Restoring the team’s trust in me took even longer. They never said anything directly about it, but I could tell from the metrics that something bothered them. I focused my efforts on providing positive feedback, asking challenging questions, and fostering healthy communications. Three months later, the team finally hit their old productivity numbers.
A year or so later, I led another Monday meeting. An issue with a broken system management server came up. My first impulse was to take it.
Instead, I restrained myself and we spent 10 minutes brainstorming about what might or might not be wrong with the thing. During the conversation, I watched the team very carefully. One of the juniors was biting off comments. During a natural pause in the conversation, I made a point of asking him for his input.
Although he looked like we were about to flay him, he laid out a possible technical scenario that might explain the symptoms. The team talked back and forth about how to prove or disprove his hypothesis. With metrics and experiments established, the junior went to work. He solved the problem that day.
In the first case, I allowed my technical pride to pull me away from my responsibilities. In the second, I followed the leader’s path, using my experience to help guide someone with the detailed technical experience to the solution.