System administration is a cumulative work in large corporates
August 5, 2009 Leave a comment
There’s No “I” in a Great System Administration Team
A great team of system administrators can move mountains (of data). Here, learn how to form, norm, and storm with your colleagues.
–> <!–//<![CDATA[ var m3_u = (location.protocol==’https:’?’https://d1.openx.org/ajs.php’:’http://d1.openx.org/ajs.php’); var m3_r = Math.floor(Math.random()*99999999999); if (!document.MAX_used) document.MAX_used = ‘,’; document.write (“”); //]]>–>
Everyone knows that working amid a disjoint or dsynfunctional team reduces productivity. Staff meetings resemble battlefields, there’s no give and take, and seniority exceeds its natural boundaries.
On the other hand, being on a great team can make work seem like fun. A team that clicks is tackles technical problems with ease and increased efficiency.
So how do you build a great, individual system administrator? How can each individual contribute to the team dynamic? The answers are the same whether you’re a manager or a team member. In this column, I’ll discuss strategies that have worked for me as a team member and as a leader, and I’ll give you some examples of what a team can do when it pulls together.
A great team of system administrators starts with proficiency. Notice that I didn’t say technical proficiency. Of course, technical skills are very important and serve as the basis for hiring, assignments, and promotion. However, not every member of a system administration team need be an expert in Linux, Solaris, or what have you.There is a enormous value in having team members who are subject matter experts in something only incidentally related to the pursuit of system administration.
For example, I once had a great team that included four very different personas: a Unix expert, a great intermediate system administrator with experience in varied environments, a guy who used to raid drug boats for the United States Coast Guard, and a former Apple Genius. The team worked because it “did things right” and drew on varied expertise in some pretty cool areas. The Unix expert served as an architect, while our all-purpose administrator would tackle any and every weird request thrown at him (and there were plenty) with great aplomb. The drug boat raider was able to work quickly and efficiently under absurd levels of pressure and whining from users, while our former Apple Genius wowed the users with amazing customer service.
Such a diverse team need not happen by accident. You can craft the team to suit. There are plenty of junior and intermediate system administrators out there with something other to offer than guru-like knowledge of Unix. Hire the whole package and you’ll often get an employee that is highly-motivated to learn and bolsters the capabilities and personality of your group. I am especially fond of candidates with considerable customer service experience.
The next most important property of a great team is cohesion, or what the military refers to as “unit cohesion.” Cohesion is lunching together and helping out in the middle of the night. Cohesion is helping out when you don’t have to or when you don’t want to.
For example, Joe is on call this week, the Christmas holiday. Bob is not, but Bob has more knowledge about the new CRM system the sales team had to have up and running before the New Year. When the CRM mail gateway fails, no one wants Joe stuck in the data center until 3 a.m. on Christmas morning, working on a recovery. Thus, Bob and the team head to the data center to help Joe. Working together, the system is spitting out mail before Santa leaves Eastern Standard Time.
To build cohesion, eliminate process silos. When a sole team member is responsible for a product or final deliverable, there are few opportunities for cross training and collaborative work — less cohesion. Engaging more team members in a final deliverable means gives each individual a stake in the group’s success. When more people have a stake in the collective success, everyone is more likely to cooperate to achieve a successful outcome.
For example, one way to avoid the holiday debacle of the failed CRM mail gateway is to give parts of that build out to each team member. Each completes his section of the build (usually working from a standard checklist or document called a Method of Procedure) and passes the ticket to the next team member. Now, if your team is small and organized into “areas of responsibility” this approach may not be the best for you. Helpdesk guy and network guy may not have much to contribute to server builds, but these days it’s a good idea to have as much flexibility in small teams as possible. This is where gaps in understanding become opportunities for overlap, resulting in cross-training and team building. Cohesion tends to increase the more team members learn from each other.
Discipline is another very important element of a great team. Now, when I say “discipline,” I don’t mean a single, strong, clearly-focused leader barking out orders to the team (although strong leadership is always present in any great team). Instead, I mean the contrary: With system administration teams, as with other unique organizations, leadership roles are most effective when shared. There is a natural order in individual leadership and accountability throughout the group. his isn’t to say there isn’t one manager to which all team members report, (that is primarily an administrative function, but rather that the manager lets the team member whose task or deliverable is currently being performed call the operational shots.
For example, if you’re doing a network reorganization on a late night in your local network closet, a good team leader or manager will have the member of his team responsible for the network configuration delegate all the tasks to be completed by the team and let that team member work the procedure. In the case, the team leader/manager only steps in and retakes the helm if something terrible happens.
Incidentally, if letting your employees call some of the shots gives you the willies, you probably need to consider another line of work. System administration is no place for harboring.
Discipline must also improve performance. A great team improves performance directly by assessing work products to identify flaws, opportunites, and optimizations. Obviously, the idea is to limit the flaws and encourage the optimizations, but the point is that the review is performed by the team. Team introspection goes hand in hand with the concept of spreading a final deliverable out over various team members. Evaluating progress at the roundtable encourages open-ended discussion and active problem-solving. Team meetings are transformed from weekly rehashes of what’s “happened/happening/will happen” to active sessions where team members challenge each other and offer valuable input and feedback on the proposed actions of the coming week.
Speaking of performance, metrics of success should reflect the basic operating assumptions of the group. If the group changes, the metrics must change, too, or you risk an ineffective or even counterproductive measurement system. I mention this because as system administrators, not a day goes by where what we do isn’t measured in some totally crazy way, usually by some relic milestones system from the 1990s mean to measure sales goals or assembler code development. As you contribute to your team’s performance, make an effort to contribute to the continued development of the performance measurement system as well.
The last important element of great teams is culture. A team culture allows the team to develop a proud and distinct identity, which fosters pride in the group’s work. Building culture is fun, but it also takes work. Here are four suggestions.
- Eat lunch together, even if it’s once per month. Lunch is typically the only time when everyone can stop working and talk about work or talk about things totally unrelated to work. Get out of the office. Go across town. Become regulars at some place where no other team from work goes.
- Establish an identity. Get t-shirts made with your team’s unique name on them. If your team supports some special function like say, cleaning out cubes when people get canned, integrate that into the design of the t-shirt.
- Set aside team time. Team time ranges from longer lunches with presentations by team members, to road trips to Ohio Linux Fest. Take your team off campus, get away, and build relationships.
- Establish your own language. In the past, the teams I’ve led or been a part of have done this by using code names or epithets for team members and customers outside the team. Keep it respectful and be as vague as possible.
Follow these four recommendations and you’re well on your way. However, there is a catch. The trick is avoiding what I called “culture spillover.” Culture spillover is when your culture gets too big for the group and your team members start acting like some self-righteous goth punk kids with an attitude about technology. In a March, 2001, Harvard Business Review article, Paul Levy called this “The Nut Island Effect,” named after the team that operated the Nut Island sewage treatment plant in Qunicy, Massachusetts. The quick version describes the possible eventualuty ike this:
- Team gets identity
- Management ignores team
- Team gets cocky
- Team forgets it’s mission.
- No one knows what is going on.
- Bad stuff happens.
To avoid the Nut Island Effect, communicate well and often, and keep the mission of the organiziation in mind. Remember who your customers are. Don’t get cocky and everything will work out fine.
Proficiency. Cohesion. Discipline. Culture. All four are the keys to building an awesome team of system administrators. Learn from each other as much as possible, and strive to meet the objectives of your organization according to the business model given to you by senior management.