It’s easier than you may think to ‘kill’ your managers. I’m personally not the greatest middle manager in the world, but I’m grateful for my time as one, since it … Continue reading Are you killing your managers?
I was recently reading an article about why Agile implementations are failing (yes, I’m a total geek), and it got me thinking about safety. I haven’t thought much about safety explicitly (beyond being an Amazon Safety Czar for my floor, which is different from emotional safety – I have a bright orange vest :)), but now I realize how important it is for your team to feel emotionally safe at work.
If your staff doesn’t feel safe, things might get pretty rough.
- They won’t trust you or your company. Everything you ask them or tell them goes under a skeptical magnifying glass and is hyper-analyzed. They may become hyper-critical
- They’ll probably start looking to leave. Honestly, the moment I stop trusting my company, I brush up my LinkedIn profile and start checking TheLadders for likely postings.
- They’ll stop telling you things that have gone wrong. They’ll be scared of your reaction and will delay telling you any bad news for as long as possible. For me, this is a nightmare situation, because I sincerely value the opportunity to work through issues WITH my team.
I’ve been thinking of ways to identify when folks don’t feel safe, and I’ve come up with the following:
- Defensiveness. A few years ago, I found myself getting weirdly defensive whenever I received any feedback. I thought I’d gotten beyond a lot of defensiveness in college, but it was back with a vengeance. In retrospect, I firmly believe it was because I had stopped feeling safe with my boss. Because I expected to be attacked, I responded defensively to everything.
- Lack of communication. Sure, sometimes folks are just quiet, but if you start not finding out about things that go wrong until MUCH LATER than they knew, guess what’s probably happening?
- Work ethic nosedive. Heaven knows, I have no issue with Facebook use at work, but if a geek stops producing and never seems to be looking at work stuff, you probably have a problem. It’s most concerning to me when I see a shift and can’t come up with a reason for it (e.g., burnout or home “stuff”), since it could be a safety issue.
- Crankiness. Do you have a geek who just seems to be a sourpuss? Okay, so they might just have dealt with a cranky user, but ongoing crankiness may be a sign of a safety issue.
I haven’t been thinking about this issue for long, so I’m sure I’ve missed things. What other safety warning signs are there?
A few years back, I realized I was killing my staff.
I thought I had found the ultimate in productivity. In order to manage my completely ridiculous inbox, I found a system. Each night, I’d leave the office late and go wait for the bus. While I was waiting, I would use my trusty Blackberry to clear out my inbox. I would merrily send emails as follow-ups, delete things, and set myself up for a pretty darn productive next day. Hey – I’ve always loved the concept of Inbox Zero (even though practicing it in Outlook is pretty much impossible). This made me, well, happy.
I’d go home, make (well, order) dinner, and relax, knowing that I was prepared for the next day.
And then something really annoying would start happening – my Blackberry would start going off. My team, fresh from their own dinners, would start replying to my email. Being a rather Type A personality, I’d then feel the need to read the email, which kind-of messed with my evening, but I got enough email from others that it didn’t mess it up that much. I’d ignore the email until the next day (except for urgent ones), and go to bed.
The next morning, I’d walk into the office, perfectly chipper because I knew what my day entailed. On my way to my office, I’d do my usual check-ins with my team (my office was at the end of the hall, so I did morning drive-bys).
Oddly, I found exhausted people who would immediately ask me if their response was OK, or expect me to have responded to their responses.
Sometimes I can be a bit slow, but after a few weeks (months?), I realized that my team was stressed and becoming less productive. I eventually even realized it was my fault. When I was replying to email after hours, they assumed I expected them to do the same. Sadly, they were already working enough, and I wasn’t expecting it. But I was the manager, and that’s what I was doing.
So I stopped. It was downright painful to have to come in each morning with a full inbox and deal with things I could have dealt with the night before, but the change in my staff was worth it. Their stress levels went down, they eased into their mornings, and they became more productive because they stopped working stupidly.
Here’s the thing with being a manager – YOU are the mold. You are what your team attempts to replicate. If you work stupidly, they work stupidly. If you work late, they work late. If you answer email at all hours, they answer email at all hours.If you manage stupidly, you’ll eventually kill them with stress. Or at least lose them to your competitors.
It’s easy to manage stupidly. Are you managing stupidly without realizing it?
I have a confession to make: I’ve been working stupidly. For a while now, I’ve been working all hours. Sometimes I start at 5am and end at 7pm. Sometimes I put in 60 hours and then work another 10 on the weekend. Sometimes I get up in the middle of the night and check my email.
Quite frankly, this is DUMB. I realized how dumb when I started at 9am and left at 6pm a couple of days last week and then did NOT work more at home. You know what happened when I did that? I was more productive. Yup. I got more work done at a higher quality when I cut time OFF my day. I spent last week producing a kick-butt set of graphs and various other analyses that are going to make up a foundational document for my role.
At the same time, however, I felt horrendously guilty. There I was, waltzing out of the office at 6 to go home, read a book, and recharge, and there my co-workers were, still in the office. Still toiling away at their desks. Even knowing that I’m a better asset when I restrict my hours, I felt awful leaving.
I know that restricting my hours makes sense. When I restrict my hours, all sorts of things happen:
- I am able to work crazy hours and get crazy things done during emergencies, because my tank isn’t empty.
- I am a much smarter person! My insights are brilliant, my documents beautifully written, and my analyses are razor-sharp. (Well, smarter, better, and sharper, anyhow.)
- I am easier to get along with. I don’t snap at folks as often.
- I understand what my co-workers are saying much faster.
- I have a better attention span.
- I have time to geek out reading all the new leadership books and resources.
I’m hoping that, by writing this post, I can stop being dumb. I can stop buying into the cult of overwork and be more valuable to my company, my co-workers, and my spouse. I also secretly (well, not secretly any more) hope that my co-workers read this and start leaving the office at sane hours, but I need to realize that I am responsible for my own actions. Therefore, I need to leave the office at a reasonable hour, limit working from home, and STOP BEING STUPID.
Is your staff frustrated? Do you feel like they’re all inefficient? Is there a line every night out your office door and a long queue of email from your team awaiting your reply? If so, I have news for you – the problem probably isn’t your geeks. The problem is mostly likely you.
You have become a bottleneck.
You probably meant well. Or maybe your team is new. Or maybe you suck at documentation (heck, I sure do). You probably have great reasons for it, but it’s still an issue – geeks get incredibly frustrated when their boss becomes a bottleneck.
Honestly, it’s going to take significant effort to stop being a bottleneck. However, it’s entirely worth it – your team will be happier, your stress will be lower, and everyone will get a heck of a lot more done. Here’s what you need to work on:
- Trust. Look, you have to trust your geeks. You have to trust that they’ll do their jobs, and you have to communicate that trust to them. Yes, this means you have to accept that they might not do things exactly the same way you will, but if you don’t trust, well, get used to having to hire replacements.
- Communicate. Your geeks must be clear about your expectations, or they’ll constantly double-check things with you. Proactively communicate about what you expect to see from their work.
- Establish Patterns. If each project has a different reporting mechanism, you’ll get stuck telling everyone how to report on each new task. You’ll also get stuck double-checking their work, since they’ll never know what constitutes acceptable results and reporting.
- Teach. Giving someone step-by-step instructions differs from truly teaching someone. Spending extra time making sure your geeks understand why they’re doing what they’re doing, how you think about problems like the ones they’re trying to solve, and what success looks like means that they can pattern-match for subsequent tasks. And that means that they won’t queue outside your office as much.
Investing this time will certainly help with frustration, stress, and constant questions. You should note, however, that you’ll still need a good way to keep tabs on projects and problems once your geeks no longer ask you about everything. The best advice I’ve ever read on how to do that is in The One Minute Manager Meets the Monkey. It’s a quick read, and totally worth it (even if it’s not on Kindle yet. Grrrrr.)!
Perhaps I’m a bit optimistic, but I am inherently convinced that anyone can be successful given the right attitude and circumstances.
I think I came to this conclusion in college. During my junior and senior years, I was a lab TA for the intro biology lab at MIT (7.02). This class had four major experiments (that I’ll call units), and the TAs would rotate between groups of students for each unit. During my junior year’s class, one group of students had a 3-person team (all others were 2) that was known as being a complete disaster. They had no idea what they were doing, and the other TAs would be constantly frustrated by getting them to work successfully on their experiments.
I’ve always been a bit rebellious, so when I rotated to this group on the third rotation, I decided that I wasn’t going to let the other TAs’ frustrations influence me. I spent the first day of that rotation watching and listening to them. I discovered that they were struggling to take the protocols designed for two people and expand them to three without being confused. I started working with them to try to more effectively divide and conquer each day’s tasks (and I had the advantage of having the best teacher for this myself – my lab partner the previous year had been SO GOOD at strategizing in the lab that I had learned some amazing ways to do it). At the end of that unit, when it came time to grade them, I was able to grade each of them a full letter grade higher than anyone had been able to during the first two units.
My experience with the “disaster” team convinced me that setting up the right circumstances could help pretty much anyone be successful. It (along with my experiences later) taught me that, to make people successful, I needed to:
- Watch and learn. Had I not taken the time to watch the “disaster” team to find out what was going wrong, I never would have been able to figure out how to fix it.
- Identify the real problem or challenge. And I don’t mean identify the problem that I thought existed before going into the situation . With the “disaster” team, we honestly just assumed they weren’t very good at biology lab. It turned out that their real problem was struggling with logistics.
- Communicate. Quite frankly, the “disaster” team knew that they were pretty disastrous. By talking to them about what I’d observed and the problems I’d identified, I got their buy-in to try to fix the problem together.
- Change the circumstances. Once we decided to try to fix the problem together , the “disaster” team and I talked every day about ways to solve it. As time went by, they felt more comfortable proposing their own solutions and asking me questions.
I’m not saying that my “disaster” team all pulled their grades up to As. But they definitely improved because we were working together to create successful circumstances for them.
In the business world, I’ve learned that successful circumstances don’t always include the current role for someone. The strategies I’ve used to address that (after I’ve exhausted the above) include giving negative feedback and, eventually, terminating the person. Luckily, however, I’ve found that more often I can (with the help of the person) create an environment that helps make him or her successful.
In my previous post, I talked about how to give negative feedback. In this post, I’ll describe the steps that I personally take when I have to give negative feedback to someone.
- Do my homework. First I have to make sure that I know what I’m talking about and why I need to give the feedback. This also gives me a chance to make sure my emotions aren’t leading the conversation. Especially with geeks, I’ve found that facts trump emotion every time, so making sure I have factual arguments rather than emotional ones is key.
- Speak privately. Unless I’m giving negative feedback to a group, I always make sure my conversation is private. If I have a regular 1:1 and the feedback can wait until then, great. Otherwise, I have to find a way to speak privately without interruption. This also means that I’m careful not to blindside my geek on the way to somewhere or in the middle of something – I have to make sure I have her attention as well. Ideally, I also have Kleenex on hand just in case (although I don’t remember often making my geeks cry).
- Say, “I wanted to talk about situation x. Can you tell me what happened?” I never start with my side of the story. I’m a huge believer in the idea that there’s my side of the story, her side of the story, and then the truth. So I need to get the geek’s side of the story in order to even remotely approach the truth (this is especially true when I have to give negative feedback about a situation that I heard about second-hand). Letting the geek go first helps me do the following:
- Understand how she saw the situation.
- Understand the reason behind why she took the actions she did.
- Understand whether she already feels bad about it – does she understand why the situation didn’t go well, or does she think everything is fine? I approach the rest of the conversation VERY differently depending on her current perspective.
- Find out whether she has already taken steps to fix the situation.
- Find out whether she knows what she should have done instead.
- Base my response on where she is. If she doesn’t understand what went wrong, I talk about that so that she understands what was wrong about the situation. If she already knows and is sorry, I talk about how to fix it or move on.
- Bring up what she did RIGHT in the situation. Rarely is an event all bad – it’s vital that my geek knows what she did correctly so that she can repeat it!
- Make sure she knows how to handle this type of situation in the future. Quite frankly, giving negative feedback is completely useless if there’s no way to draw something positive out of the situation. And the most positive thing is to make sure that it won’t happen the same way next time.
- Have a pleasant ending OR come up with action steps. Depending on how my geek assimilates the information, we’ll need to agree on what to do next. Either we move on and talk about pleasant things or we need to come up with next steps (e.g., regular check-ins or how to fix the situation if anything is fixable).
Honestly, I’ve had this blow up in my face once or twice, but trial and error have led me to this overall methodology. I’d love to hear about what other methods work for you!