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!
I have to admit that I hate the word “feedback”. To me, it’s basically like saying, “I’m about to tell you just how much you suck, but I’m going to put it in business terms so that you can’t get pissed off or cry about it.” (I may be exaggerating slightly.)
Nonetheless, no matter how I feel, I sometimes have to give negative feedback. Here are the guidelines that I’ve figured out (mostly by doing things the wrong way):
- ALWAYS always always get their side of the story. I can’t tell you the number of times someone reported something “bad” about a geek that looked very different once I had both sides of the story.
- Keep your emotions out of it. If possible, make sure you’re no longer pissed off before giving the feedback. Sleep on it, drink on it, kvetch to your spouse about it – whatever you need to do to make sure that you’re not seething when you give the feedback, because, you need to…
- Make sure it doesn’t get personal. There’s a big difference between saying, “That came across as harsh,” and, “You’re harsh.” This isn’t about who they ARE, this is about what they did or how they behaved in the situation.
- Be constructive. It’s not useful to tell them what they do wrong without telling them what they should have done instead. You want to help them learn? Guide them. For example, one of my geeks once ended up on the floor of his office with a back spasm. I happened to notice it when I realized all my other geeks were gathered around and making fun of him. My feedback to them went something like this:
Remember when so-and-so was in his office on the floor with back pain and you were pointing and laughing? Yeah. So, in the future, please first tell HR, then tell me, THEN point and laugh. Got it?
- Make sure they hear you. Especially if you’ve forgotten to leave your emotions at home, it’s easy to say things that wound your geeks and cause them to tune you out or emotionally shut down. Make sure they’re responding to you normally, but if they’re not…
- Let them go process it and then get back to you. You don’t NEED them to learn their lessons right away (or feel sorry or whatnot). You need them, instead, to truly internalize what you’ve said in order for them to do things more correctly in the future. Especially if you’re managing introverts (which many geeks are), you need to give them feedback, tell them how you would have preferred things to go, and then let them go process it so that they can internalize it. Always leave the conversation open so that they can come back to you with questions or arguments in the future.
This post is getting long, so I’ll leave examples to a future post. However, what have I missed? What lessons have you learned about giving or receiving feedback?
If you’ve ever managed people and (like me) are somewhat empathic, you’ve had this experience: you walk into the office, and you can feel the waves of disgruntlement radiating from your staff. You’re not sure why or what happened, but they’re grumpy. If it were just one or two of them, you could easily brush it off. But instead it seems that the cranky fairy visited your department and liberally sprinkled his gift around.
So you pull someone (in my case, usually one of my managers or senior folks) into your office and ask. Maybe said someone just glowers and says “nothing,” or maybe the conversation goes something like this:
Me: So what’s up around here?
Someone: I don’t think people are happy.
Me: Do you know why?
Someone: They’re not happy about <something you probably did, said, or asked them to do>.
The first time I had one of these conversations, I was honestly bewildered. I had no idea why it seemed like my staff suddenly hated me. Sure, there were some times that I did things to which a grumpy response was inevitable, but what I’m talking about here was boss-hating out of left field. I’ve developed some theories as to why this happens:
- You (the boss) represent the establishment. If your firm or company is doing something that they don’t particularly like, you are sometimes perceived as the immediate representative of The Man. I find this is more common with new direct reports or folks who don’t know you well enough to know your motivations yet.
- The “heart” of your department feels hurt. This doesn’t happen with every team, but there are often one or two employees who are the “heart” of the team (think Kaylee Frye on Firefly). However this person feels is how the rest of the team will feel. And something happened to make this person unhappy.
- You did something wrong. Or at least you did something that made them grumpy and you didn’t realize it at the time you did it.
So how do you deal with these situations?
- It’s tough to be part of “the establishment,” but you can’t get away from that to some extent, since you are your team’s main point of contact for the Powers That Be. If you realize this is going on, reassure your team that you’ll fight for their best interests, and work on building relationships with them so that they realize that you’re not The Man.
- It’s pretty easy to deal with your team’s “heart” if you get along well with him or her. You can take him out for a cup of coffee, find out what’s going on, and address the issue. If you don’t get along with him, however (and I’ve had both situations when I’ve been a manager), you’ll have to slog through more emotional muck before you can get down to addressing the issue. It won’t be quick or easy, though, and you might have to just wait for the current situation to blow over before working on building your relationship with him. I’ll bet you didn’t realize that you’d become part shrink when you became a manager, eh?
- I have a very simple formula that I follow when I’ve done something wrong or sub-optimal: own up to it, apologize for it, and take steps to make sure it doesn’t happen again. Trying to shift blame or defend your actions to your already pissed-off team will only exacerbate the crankiness and undermine their trust for you. Find out what you did wrong, take responsibility, apologize, and fix it.
I realize that I’ve only scratched the surface here; what situations have I missed? How do you handle it when your team seems to suddenly hate you?
Some of you have read this blog for a while might already know that I have some experience with technology disasters. Specifically, two back-to-back disasters involving many gallons of water and a server room, thereby earning me the nickname “Waterfall Girl” a few years back. (Which didn’t really stick, luckily.)
Here are some lessons I’ve learned:
- Geeks surprise you. You never know what they’ll do in high-stress situations.
- Communication is key. No change? Tell people that. During stressful situations, people just want INFORMATION (dammit!), and sometimes telling them that there’s been no change and you’re still working on it still actually helps them.
- Apologies help. Folks know the disaster isn’t your fault, but apologizing anyhow somehow helps them. I’m going to guess that it’s because it addresses how they feel and demonstrates that you realize the crisis has caused them no small inconvenience.
- You can’t please everyone. Did you make an announcement via the PA system? Well, some people would really rather have email. Did you send email? Well, prepare for responses vilifying you for not walking the floors or making an announcement Did you and your team walk the floors? Well, they’re not doing it fast enough. All you can do is your best.
- You can’t do everything right. Maybe you didn’t communicate fast enough. Maybe you didn’t figure out the problem in time to prevent a cascade event (or maybe the cascading events were inevitable). Maybe you estimated that things would be back in two hours but it took two days. You’re not infallible, and you will probably make even more mistakes in crisis situations. Forgive yourself, pick up the pieces, apologize, and move on.
- Acknowledge emotion. If you’ve already worked 70 hours by Thursday, you will be a bit, uh, grumpier than usual. Once when I took a post-disaster phone call, I said something to the effect of, “I realize that I haven’t slept and that you’re very stressed as well because of the disaster. My goal is to get through this conversation without either of us getting too testy or angry.” The caller laughed (as people will when you do or say something unexpected), and we got through a 12-minute conversation without excess grumpiness. Realize that your geeks will feel stress and get upset easily as well.
I’m sure there are more things to add. What have your experiences been?
Photo courtesy of Maciej Szczepaniak