Okay, so the blog has been suffering a little. Sorry folks. I’ve just been burnt out. My primary job has been hectic lately, as management reorganized quite a large chunk of the system administration and “base technologist” jobs a month ago. I’m not complaining at all, actually, even though the last two weeks have been 70 hour weeks. I know I’m not going to get any sympathy when I say that I really try to keep to 40 hours a week (hey, work smarter not harder). Sometimes a reorg can be a good thing, if you are able to get some things fixed in the process.
One thing that is really getting fixed are some of the operating system teams. We’re not a one vendor shop. We run IBM AIX, Sun Solaris, Red Hat Enterprise Linux, Microsoft Windows, Apple Mac OS X, and an IBM z/OS mainframe. There is a team tasked to the care and feeding of each OS. The problem is that some teams were in pretty good shape, but some really sucked.
I read “The Trouble With Open Source” and while Stephen Marshall is talking about software development, he puts his finger on something system administrators absolutely need to succeed: a singular vision and clear design concept.
How can a system administrator have a vision when they work on machines for so many projects? A clear design concept? Heck yeah. An admin with a vision won’t have the vision at the application level (unless they’re implementing it). They’ll have it at the OS level, with standardization and forethought being big symptoms of vision. Your admins will be thinking ahead to what their customers might need, and what would make their users, and their own, lives easier.
How can you tell when there’s a lack of vision, and a lack of a clear design concept? Instead of a guiding voice there is infighting. Instead of leaving a meeting knowing what needs to be done they leave a meeting griping about their manager making a decision they didn’t like. Instead of welcoming help from others when they’re busy they resist any involvement by others in their projects. It’s my project. Those are my machines. Look how many machines I have compared to the other admins! I want a raise. No, I’m sorry, we can’t install that Perl module for you because it needs a newer version of Perl than the one that shipped with Solaris 8. No, we don’t install newer versions of Perl. Why? Because I said so.
Fixing this is really easy. Every team needs a leader. Not to take over the job of management, but to make technical decisions, provide guidance, and to drive the ruthless standardization every team should have. The leader is a technical leader who provides feedback and advice to management as to what should be worked on by the team, but doesn’t make personnel decisions or work assignments. If there’s a disagreement about how something technical should happen the team discusses it, the technical lead makes a decision, and management agrees. They’re a technical leader, not a team manager.
So, when I say that a reorganization can be good if things get fixed, I’m thinking about the restructuring of our OS teams. Each team has a leader now, backed by management, and charged with making some sense of the mess the old setup left. In the last three weeks infighting is down to negligble levels and the teams are starting to get things done that should have been done months ago. There’s even a technical lead above all of the team technical leaders, charged with standardizing common cross-platform tasks so customers will have the same experience regardless of whether they ask the Linux team or the Solaris team.
Time will tell if this works or not, but the initial signs, as a Magic 8 Ball would say, “point to yes.”
Nice!