Category: teambuilding

On Communicating Expectations

I love the suggestions I’ve gotten thus far–keep them coming! However, inspiration struck in the middle of the night, so you’re getting this one instead.

On Tuesday, I returned to work from the ILTA conference to discover that I had misplaced my staff. Or rather, that they had misplaced themselves. I stuck my head into the Help Desk office, only to discover that it had become a storage room. I turned around and located the office, only to discover that it only had one desk (and the corresponding one human) in it. I walked past the spare office, only to discover that the door was now labeled for the other Help Desk person. As you might imagine, I was relieved to discover that my name was still attached to my office, and my key still worked! (Although there was a huge cardboard box on my desk. Lame compared to my last firm, where they toilet papered my office post-conference, but we’ll work on that…)

I was somewhat shocked. After all, the promotions that would give the respective Help Desk folks their new offices haven’t come through yet. The two people working the Help Desk are now in different offices, and I was unsure that would be as effective as sitting six feet from each other.

However, this was exactly the final configuration that I had specified. And the only configuration I had discussed with everyone. Last week was slower than expected, so they executed what they knew to be the plan.

I had to sit down and figure out why I was shocked that they had executed the plan I had communicated. I realized that, while I had communicated the final plan to them, I had failed to communicate that I had expected it to be phased in differently. And that I had expected them to tell me a little more detail about the moves they were making.

They were executing 100% of what they knew to be the plan, and they were doing it faster than we had thought it could be done–there was nothing wrong with that. What was wrong was that I had failed to communicate how I expected them to execute the plan.

Lesson learned: geeks can’t read my mind. Also? My staff executes plans quite efficiently, when motivated. Next step: better define expectations.

On Communication

Let’s face it: geeks can sometimes be poor communicators.

(It’s tempting to end the post there to prove my point…)

I’ve seen geeks forget to inform colleagues and bosses that they’ll be on vacation, geeks neglect to inform companies about scheduled downtime, geeks fail to ask essential questions, and everything in between. So how does one, as a leader of geeks, deal with this?

  1. Know yourself. Many geek leaders were once geeks themselves. Have you inadvertently created a culture of non-communication? Do you tell your geeks if you’re leaving the office to play golf or have lunch? Do you let them know about potential changes and plans?
  2. Know your geeks. Wander into offices and cubes and ask what’s going on. Ask “why?”. And actually listen.
  3. Communicate about communication. Let your geeks know what is and isn’t acceptable to keep quiet about. For example, I make it clear that my geeks can tell me as much or as little as they want about their lives outside of work, but if I ask what they’re working on for their jobs, I require answers.
  4. Leave your door open. Allow your geeks to come by when they feel like doing so. Won’t happen much, but some geeks are more comfortable chatting than emailing. No, really, I’ve seen it. Honest.
  5. Revisit things. Introverted geeks won’t ask all their questions and voice their concerns in an initial face-to-face meeting; they’ll need to mull it over. If you don’t give them space to bring up these thoughts, you may never hear them. And they’re probably good thoughts to hear.
  6. Consider written communication. Email can be useful for this, but I’m planning to set up a wiki for my department to track projects.
  7. Don’t play the blame game. There are definitely unacceptable levels of communication (see examples above), but before ranting and raving at your geek about how he or she was REQUIRED to tell you about the system change, go into inquiry mode. Find out why the geek forgot to do it. Make it clear that it can never happen again, and then, if necessary, examine ways to prevent it. You may need to make a template email that the geek can send out to the company for downtime, or you may simply need to accept an apology.

If you try, you can probably create an environment where your geeks will communicate more. They’ll never become The Great Communicator (thank goodness), but you should definitely see some improvement.

On New Brooms

So the classic perception is that the new boss can–and will–make sweeping changes to an organization and staffing.

I can’t say this is very wrong.

I happen to be fortunate that my new staff is excellent, but there aren’t enough of them. And the systems? Well, let’s just say that we need to tweak them a bit, but I have a great foundation on which to work.

But I was having a conversation this morning with my senior network engineer, and we made the observation that I have about 6 months until I won’t be able to easily make big changes. So I need to move fairly quickly.

I plan to take the following steps:

  1. Assess
  2. Propose
  3. Execute

I’m almost done with step 1 now, and I hope to do step 2 next week. One thing I plan to do a bit differently, however, is that I will first get feedback from my staff on the proposal. After all, they already know the systems and players.

On Flex Time: How to Fail

In my last post about making flex time successful, I talked about some best practices that I find make flex time a beautiful thing for everyone involved. Now I’ll chat about how to completely fail with flex time.

  1. Be grouchy about it. Your employees aren’t stupid, and they know when you’re unhappy about something. If you resent employees who have flex time, you’ll damage their morale, and give other employees good reason to be grumpy about their co-workers’ arrangements.
  2. Don’t listen to complaints. Let’s say you have an employee who works weekends and takes off Thursdays and Fridays to take care of the kids. This arrangement seems fine, and then you have a huge roll-out that is scheduled to go live on a Thursday. This employee, a vital engineer on the project, might not think that he needs to be there on that Thursday. People complain, and you just shrug. The roll-out is harder, morale suffers, and people start resenting the flex person. This is sub-optimal for teamwork, to say the least.
  3. Don’t plan for it. Make sure you remember that someone has a four-day week when you’re planning projects and schedules. You cannot always depend on that person to show up on every Friday to make up for your poor planning–wouldn’t that defeat the purpose of flex time?

I’m sure there are many other creative ways to fail at flex time, but I’m hoping that these two entries will help you avoid them.

On Flex Time: Making it Successful

I blogged a bit about flex time in my post On Insomnia, but I’ve been thinking about what makes flex time successful (or not!), and I thought I’d post my thoughts here. This post is about what to do to help make flex time successful (my next will be on what might cause flex time to fail).

  1. Bilateral flexibility. Both the employer and the employee must be flexible. I had an employee once who worked a 4-day 32-hour work week, and did not work on Fridays (when daycare was closed). However, if I ever needed her to come in on a Friday for a large project or emergency, she put her son in back-up care or called on a relative and was there. Likewise, if she ever wanted to trade a Tuesday (or other day) for a Friday, I let her do so as long as the work allowed it. The bilateral flexibility made this arrangement a resounding success.
  2. Core hours. In order to facilitate teamwork (and I’m not sure there are many modern work environments that don’t need teamwork!), core hours are vital. Team members need to know when they can find each other for questions, brainstorming, etc. I held core hours for my last department to 9:30-4:00, which were hours when everyone’s work schedule overlapped. If I were working in a software company, I might set those hours to 11:00-3:00 in order to handle both my night owl programmers and the crazy early birds who need to pick their kids up from school.
  3. Don’t give flex time if the job isn’t flexible. While it’s admirable for all companies to want to grant flex time, sometimes it just isn’t happening. Nursing shifts have to start and end at specific times. Utility trucks have to all roll out at a certain hour. The help desk has to be covered from 8:00 AM-8:00 PM.
  4. Be honest during the recruiting process. If the job isn’t flexible, don’t tell a great candidate that he or she might be able to negotiate it later. Be up-front about expectations during the initial interview in order to recruit and keep great employees (this goes for much more than just flex time).
  5. Don’t only grant flex time to your favorites. If someone in a certain job has flex time, you have to be prepared for everyone else in the same role to ask for it. If you only granted it to one person due to special circumstances, be honest and communicate the circumstances (within reason–don’t disclose private HR issues) to that person’s co-workers.

Stay tuned for my next flex time post on mistakes I’ve seen (not just the flip side of the five best practices above–honest!). I figure it’ll come out next week…

On Maturity

Overall, I think that maturity is overrated. That is, if we define maturity as being boring, steady, and un-creative, which is how most “mature” people I’ve met in the business world define it. If we define maturity, however, as being well-balanced, able to have fun, able to be creative, and able to get the job done while enjoying it, then I think we should all be more mature.

I fell into the trap of assuming that I had to be mature (by my first definition) when I first became an IT Director. I stood up straight and suppressed some of the odder aspects of my personality. I probably wasn’t much fun to be around, and I guarantee I wasn’t having much fun–I lost a lot of weight from the stress.

Then I hired a computer training specialist. Who had many years of law firm experience and who had served in the Army Reserves for even more years. He was about 6 years older than I, and really knew how to be professional. He seemed well-adjusted, and the users loved him.

Then he brought in a wooden bear that, when you lifted its head, pooped M&Ms.

My wacky side loved it, but since it was right outside the HR Manager’s office, I held my breath and ignored it. One day, I sheepishly poked my head into her office, and she said she thought it was a hoot.

A hoot?

Turns out I didn’t really know the real meaning of maturity. A truly mature person knows how to have fun at work. Get the job done? Absolutely. But even more important is getting the job done while enjoying being there. You’re happier. Your team is happier. Staff stays longer at their jobs, and you only have one scotch at the end of the day (and that because you actually like scotch).

Okay; so making staffing decisions by allowing them to duel it out with flying monkeys at 10 paces might have been a bit much, but…

On Complementary Strengths

I’ve read and heard many places that most people hire people like themselves. (I mostly hear this in the context of why white men hire more white men, but I’m not touching that here.) I’ve also seen many studies that prove that diversity leads to stronger decision making and a better bottom line.

Anecdotally, I can tell you that the best team I’ve ever built started when I hired people very unlike me in strengths and habits.

Why? Because I have weaknesses. (I’ll give those of you who know me a moment to get up off the ground, since I’m sure you fell off your chairs at that public admission.) I’m very good at big-picture thinking and people management and team-building, but I’m weak at details and physical organization.

So you can imagine that if I built a team out of people just like me, no one would remember to book conference rooms for our meetings, and eventually our work space would be covered with piles of mixed-up papers. However, when I built a team out of people who were great at details but weak at the big picture and people who were physically organized but weaker at human interactions, mixed in a few people who were great at research, and so on, our strengths compensated for each other’s weaknesses.

Building a team out of people with complementary strengths leads to stronger work, but it can also be hilarious, as you find each other’s weaknesses amusing. Being able to laugh with (and occasionally at) each other also builds a better team.