Tuesday, February 22, 2011

Musings on Meetings 2, Electric Boogaloo: Using a meeting to actually help (not hinder) you and other people

I just has a mad morning of scheduling meetings. I could hear the disappointed sighs from co-workers in nearby cubes, while others immediately responded to the meeting requests with what seems to be...joy. Meetings are a necessary evil in the managing business, and are often abused to the point where the meeting itself seems evil. This is not to say that there are not some inherently evil meetings--entities that have taken on their own lives and must be stopped--but this entry isn't about those. It's about using meetings as a tool to be effective.

I once managed an external vendor. They didn't do well with dates unless those dates were punctuated with meetings. Meetings were where they knew I would call them and politely pester them until I get what I want (my promised deliverables). I was rarely harsh--don't threaten to fire someone, for example, unless you're not planning on ever using them again. But I was essentially the height of politeness. This is because you can hang up on an angry person. However, most people are wired to be nice to someone who is nice to them, so when I called they were stuck--they either had to explain to me why they didn't have what I asked for and they said they'd give, or have it at that time to avoid the guilt/disappointment I would express to them, in kind and assuring tones.

We can talk more in later blog posts about using people's natural emotions to get them what they want--and in turn get you what you want--but this post is about using meetings as a tool. My example above uses the meetings to box in time frames and help my external vendor meet dates.

This method doesn't work for all occasions.

Your immediate co-workers, boxed in the same position, will get grumpy, wondering if you don't believe them when they tell you when they'll have something to you. So, instead of a specific meeting with a specific person, you want to set up checkpoint meetings with the whole team; that way people don't feel singled out, but do feel a little peer pressure to deliver. In Agile/Scrum, these are daily meetings, 15 minutes or less. I don't recommend that status meetings ever go over a half hour. If you want status & to discuss some issues, do status in the first half hour, and then let people go who don't care about the issues that they want to discuss in the second half hour. People will LOVE you for this.

Allow me to reiterate: status meeting should be their own beast, with their own rules, to be truly effective. There are always people who will happily drone on and on and on about their project. When they are done 25 minutes later, the person following them may say five words, and considered himself done. Neither is a useful type of status; eg: "...and then I had green beans, and then a Diet Coke, and then compiled the code, and we were done!" Um, Thank you. Next? "Everything is totally fine." Riiiigghttt...

My recommended rules for status meetings:

1) Set an Agenda before anyone comes to the room. This is a status meeting ONLY. Set up a separate meeting for further definition of issues.

2) Set a time limit. For example, the meeting is only 20 minutes, so each of you will have 60 seconds + around 60 seconds of questions (if that time is needed).

3) Answer only the following questions: 1) Status of your project is red/green/yellow, 2) why, 3) is there anything on which you require help/are blocked (if so, what)? You can certainly add in your own or switch out questions, but never more than three in a status meeting to keep it short.

4) For folks that need help, we'll schedule appropriate follow up meetings. Don't feel you need to work it out in status unless its gonna take under 15 seconds.

5) Reward people for ending on time or early; eg: everything from "you get some time back!" to "if we can get this done in under 20 minutes, I'm taking you all to lunch." I've offered board games, door prizes, etc. It helps set the norm for the team that being on time and finishing on time is the way things are done. It also saves a LOT of drama.

In Agile/Scrum, the questions are slightly different and the meeting is typically 15 minutes or less. I could do our daily stand up in 10 at one company, even though I had 14 people reporting. Mind you, we were attempting to go for our best record, which is how we got it down to 10 minutes. Note, we still didn't lose any productivity from doing it this way. Which was AWESOME. Some people, however, find that your lead Quality Assurance tester holding a stop watch a little distracting while they're trying to report.

Hand off reminder meetings are also quite useful internally; they let people know when data they are interested about is coming in. Just be sure when setting up the meeting to set the time for the participants as "Free" and then they'll get a pop up that both has the data they've been waiting for and which doesn't mean they have to actually go anywhere! A big win all around.

I am also a big fan of the explanatory meeting (which is never held in a status meeting, but might happen after). Basically, you receive a doc or a set of instructions (or you provide one). A follow up meeting allows you to focus only on the participants who need to know, and allow you to go over the materials. Its important for explanatory meetings to ask people to read the material ahead of time, and it's important for your blood pressure to know that only about 20% of them ever will. Plan time into the meeting for them to read and review the document. Sometimes explanatory meetings are the ONLY way you can be sure someone will read the document. Use them judiciously, and, as noted, make them very targeted. I also recommend they never last more than an hour--if you need to schedule another, you totally can. But human beings burn out on docs after an hour or so.

That is it for the wisdom of today. I know you are shocked, but now I have a meeting to go to.

Tuesday, February 15, 2011

Serving Too Many Masters

Your boss's boss (BB) and your direct boss (DB) both have ideas about the project your team is running. More input is often good in these situations...except when it's not. BB and DB are amicable, good people who have completely different opinions on the exact same subject.

Which ideas do you implement? Since agreement is pretty much impossible, how do you know how to move forward?

Ok, now swap that example to a dotted line boss (DLB) and a Supervisor (S) and let's throw in the VP of your department (you're boss's boss's boss).

What's a person who wants to be both happy, productive and keep their job to do?

I had contemplated naming this particular article "Wonder Woman's Bracelets" or "Jedi Lightsaber 101." Both get the point across: you deflect.

The issues that arise because people in high positions cannot agree often fall on people further down the slope, as it were; and because that person further down the slope is charged with implementing the whatever-it-is, they take heat from people who do not see their specific concepts, ideas, and requests included. However, if you are getting conflicting requests from multiple locations, you really aren't to blame if they don't see what they want to see. And you will quickly end up under water (to really mix my metaphors here) if you don't put the kabosh on all this and manage your boundaries.

Basically, in the case with two people giving conflicting information you do the same thing as if you were getting conflicting information from five people; you deflect them onto each other. It works the same if the people are at your level, below your level, or above you. Find out whose decision it is for the whatchamacallit and firmly deflect the varying opinions to THAT person.

For my first example, DB and BB. BB outranks DB, so in theory his ideas should go first. But, DB manages your reviews and pay increases, making you a strong supporter of making DB happy. To solve the issue, you tell DB that you are confused and you are only going to do what DB says. Summarize that message in an email and send it to DB. When next BB emails you or asks for something, deflect BB to DB. If there is confusion among DB and BB, or BB is not happy, call a meeting of yourself, DB and BB and sort it out; assuming that your boss's are rational (assuming be dangerous in and of itself, but assuming rationality is also quite dangerous), they will either go with your solution--for BB to get his wishes to you through DB--or they will come up with another to take you out of limbo when you get conflicting direction. Like most people, they'll revert. In those cases, summarize an email or forward the one you got, and summarize the agreement while including DB and BB in the thread.

In this way you establish process and boundaries, and you stand by them.

Now, there will always be insane workplaces where doing something sane like this produces scary and unpredictable results. Feel free to reply to my post with situations that you'd like some insight on in regards to those types of things (or anything, really, related to management) and I will be happy to give your plight (hypothetical or no) some thought.

What about the situation with more than two guys? As difficult as it sounds, the same plan will work; start with your direct supervisor/boss and tell them the problem. Then round up all the conflicting responders and get agreement about who will manage your information flow. Then, deflect all future requests to your hero, the person who is making the final decisions for you.

What now, brown cow, if that person is you? In Agile/Scrum we call that person a product owner--their job is to collect business requirements and put them in order so that a project manager and a team can know what needs to be built and when, but don't have to sort through all the varying thoughts and ideas that people sometimes get when a new shiny project is being put together.

If it's your job to mesh all the business requirements (also called functional specifications, recommendations...the list goes on) into an order that people can follow to complete a task (more technical or not), then you will also use deflection. You will make sure that all the stakeholders and people with input go to no one else but you; them telling your project manager what they want when it's your job to know that is counterproductive (though sometimes people will do that in an effort to do an end run around process in a helpless attempt to get something they find important done...they will also do this occasionally because they just don't know what to do).

Once everyone is coming to you, I recommend starting with individual meetings. Meet with one or two of the stakeholders at a time and write down what they want and don't want. Reference the list with other stakeholders as you make the rounds. Once you've got a complete list of all the items, call a meeting and go over the list with all the folks involved. The top agenda item of the meeting is to determine which one of them gets final say if there is a conflict. Then sit back and occasionally direct the conversation back until you have an answer. Once you have an answer, go over the items on the list, get it blessed by that person, and move forward with your project, repeating this process as needed moving forward. Basically, deflect people from randomly bugging the people doing the work, and then get agreement on the authority figures involved so that if someone is unhappy they didn't get A, B or C, they have another person (who is not you) to work it out with.

What if you are one of the masters? What if you have someone working for you that also must respond to someone else? Maybe you get half their time on a project and the rest goes to a different project, or maybe they are a product owner for a project where you and your boss are a stakeholder. How can you help them?

The first thing to do when dealing with someone who has many masters, is to sit down and talk with them. Ask them how they are doing and if they need anything. Ask them if they lack clarity on anything on which they are working. Check in regularly on them in this way. If they have more than one master, they will eventually lack clarity on things. At that point you can help them with their deflection manuever--call a meeting and find out under which circumstances which boss's requests go through first. Or, call a meeting and help them find out which stakeholder's data reigns most supreme. Then, and this is really important: even if you are not the person whose data reigns supreme, SUPPORT THEM. Frequently when dealing with multiple bosses, you just don't have a choice, and passive aggressive behavior from a sore second-place boss is not going to make them any more productive.

You want people to want to work for you as a manager. To do that, you need to try to make life easier so all they have to worry about is doing the best job they can on their work. Whether you're one or one of a million bosses to someone, you always are shooting to be the best one and the one they work hardest for.

Tuesday, February 8, 2011

Perception v. Reality: You May Be Doing Your Job, but It's Good Other People Think You're Doing It

My current vendor company boss and I were just talking about this, and he suggested I make it a post for my blog. So, here it is.

As a consultant working for my vendor company, I have been pretty lucky in landing my own gigs. Previously, when working for a consulting company in Redmond, I ended up taking whatever new gig they had landed and managing a team around that.

Did you know that I do not breathe every moment for an opportunity to work on website student loans? That, when I go to sleep at night, I don't dream of government fiscal policies and security procedures? I also don't create community websites with forums and blogging in my spare time for fun.

But those are all things I did for my job. And would do again. The thing is, you're not always going to get stuff you like to do. Further, you're not going to get stuff you like to do in the way you like to do it. Basically, the reason they pay you, as far as I can tell, is because they don't want to do whatever you're doing, themselves (also, in many cases, they can't, but that's another blog post).

And yet...customers are paying for the experience that you are giving your all to them 100% of the time. While they don't REALLY expect you to be thinking about loan rates when you're cuddling with your sweetie on the couch, they do expect it to be foremost in your mind while you're working on their project in the office.

Typically--consulting firms and non--also want to know that you are actually WORKING when you're at work. How do they know you are working? Through a whole host of activities, some of which are not actually working on your assigned work.

For many people, perception is as key to you doing a good job as you actually doing a good job; which is to say, they see you working, they hear you asking questions, they receive regular emails at the start or end of the day, they perceive you taking an interest in the team and your work, and they notice you have given the work some thought, probably outside work hours. These things are pretty easy to do--not a lot of extra work involved--but really improve your appearance to a client or manager.

1) Know your group's out of the office (OOF) policy; if you need permission before you work from home (or to leave early or arrive late), get it. This seems very sensible, but sometimes, especially for veterans in industry, this part gets skipped and people get annoyed.

2) Even when you can set your own in-office and out-of-office hours, tell people as much in advance as you can, and remind them often. It's courteous, but it also plays into later steps so that people know what you're doing and where you're doing and when you're doing it.

3) When I first get up in the morning, I frequently log into work email and answer the immediate items. Even though I typically arrive an hour after my boss does, if he asks me questions about my email when I walk in the door, I'm able to answer them/at least be familiar with the topics. Also, my initial morning emails bookmark my work start time; even if my boss doesn't see me until 9 am, he has emails from me starting at 7:30 and he knows I'm working even before he can physically see me doing it.

4) Make an effort to connect with the existing team; failing to do so may cause teammates/clients/managers to perceive that you have not become as invested in the team because you haven't spent the time doing so. Do so as much as possible, without detracting from your workload. I recommend taking a look on someone's desk and asking about what you see there: children, pets, etc. as a casual conversation starter before jumping directly into work. Try to keep track of those details for future conversations, and, when asked, provide similar details on your own. Yes, people, small talk actually counts. When in doubt, the weather is a fast and furious topic to get in and get out with.

5) Take some of your own time and look at your group/industry in relation to competitors and folks in similar markets. Be able to talk a little about the "wider view" of the work you do and how people do it elsewhere. Save these tidbits (don't spout them constantly), but sprinkle them in as needed to show you are paying attention and care about the work (even if you aren't and don't).

6) Use (5) as a jumping point to make suggestions that will improve work performance. Do not concentrate only on improving your own work performance, but work to be perceived as taking an interest in the team as a whole and improving overall process. To avoid being the person who is working "too hard" at this tactic, do not recommend new solutions anymore than twice a week (use your judgment).

7) Be responsive; if you do not already check your email every half hour, set up an Outlook reminder to do so. Respond immediately to emails as soon as you see them, even if you are responding with "I've seen this, investigating now." As weird as it sounds to be obssesive about email, quick turn around time (even if you don't have an answer) really makes people believe you are on the ball, even if you are really rocking in a dark corner recovering from a hangover.

8) Drop into people/teammates' offices a few times a week and ask a question/get some collaboration done in person (where possible). Talking to people outside of meetings is extremely good for creating a healthy team atmosphere. Face time is also very, very good if you want people to remember your name and your face...say if you're ever contemplating applying for a promotion.

9) Try to bookmark the end of the day with an email relevant to the work at hand. I might do a summary for my boss, or answer a group question as close to when I'm leaving as possible; it helps people know how late you were in the office. It also helps if you didn't have a really productive day, realize at home, log in, and send it. An early morning email (3) + a late day email received 3-4 times per week (as bookmarks for your daily productive schedule) helps establish a pattern of a regular, or sometimes even longer, work day. This works especially well for bosses with weird hours in relation to you.

10) Get in before your boss if you can, and leave after your boss if you can. If you have to choose between these items, always get in before your boss if you can. For some reason, bosses automatically assume that if you are getting in after them or leaving earlier than they are, you might not being doing a full work day, or working as hard as the person who is getting in before them or the other person who is leaving after them; it's a psychological affect, but one that hovers in their brain when you're not there to dispel it...such as when they are writing your first draft review.

11) Status, status, status! At least once a week submit a status report to the team and/or your boss letting them know what you did that week and how it maps to goals/targets for yourself and your team. Doesn't need to be anything more formal than a bulleted list; extra points for noting what you'll be working on next as well as the items you just completed.

To super-expand (11), for folks who are worried their bosses are worried they aren't putting in the time, a mini-status can be sent at the same time you answer email in the morning; shouldn't be any longer than three lines or maybe 5 bulleted points, and a second email, just before you go home, with how much you got done (equally short). Continue to triage with mini-status reports until a) you feel the danger is over b) your boss begs you to stop spamming them.

12) Attend team/company functions, even for just 10 minutes. Face time is important to your team, but its also important to people who are not on your team. Who knows which manager might remember your name and put you up for a new opportunity, or an HR person remembers you and doesn't put you on the cut list when they have the choice between someone they know and someone they don't know?

So there you have it: look busy. It helps to be busy, too.

My brother, when I was just entering college, offered me this advice: "If you don't have time to read the chapters, read a few pages at the front, a few pages in the middle, and a few pages at the end. Then answer questions in the discussion when they are about the pages you've read." That advice--like mine above--works great for the discussion period...but you will only do well on the final test if you actually do the work.

So, in addition to working on perception, be sure not to forget reality.

Tuesday, February 1, 2011

Another Animated Adventure: Managing Estimates



I am very verbose. You probably already knew that. By the 10th one of these I create, it'll be 2 hours and only my Dad will watch it because he's obligated to do so.

This one attempts to capture why having a manager is important. In this specific case, it's so upper management doesn't assume the "seemingly" possible impossible. There are a lot of additional side conversations that could have happened--where the manager argues for more specifics on the high priority project, or explains that what the upper manager thinks is quick dev work really never is--but in the interest of boring in you en masse only later, after I've gotten you to watch a few more, I skipped those.