Tuesday, September 27, 2011

Breathing Underwater

As noted in my previous blogs regarding screw ups in the workplace, sometimes what we do can make it harder to do our jobs. Sometimes, however, we are dumped into the deep end of the pool and have to keep everyone's head above the water, including our own, in a situation that we did not make for ourselves.

The first thing to do is to determine if you are actually underwater. By being underwater, I mean that your tasks and their scheduled complete date are sufficiently in jeopardy that if you had to choose between green status (all good), yellow status (likely ok, but problems) and red status (dear god), you'd put yourself in red status.

An example from my own life involved taking on a project for my company with a bank. The project had been scoped and approved and then paid for by the IS department of a specific group...then, during the time before the planning phase started, the company reorganized and a different group ended up with the contract. These folks did not want an external development company; their leader wanted full control over the project. He did what he could to get me and my team to literally move to Boston where he could supervise us. That was not in the contract, so we had several meetings, put together a plan and a schedule, and started moving forward.

Unbeknownst to my company and myself, he began hiring contractors. He already had one, but added two more. He gave them direct orders, often counter to what he agreed on in meetings with me and what they agreed upon in meetings with the entire team. Meetings we had DAILY to prevent this type of cross communication.

Once I caught on that, effectively, the other team had gone rogue at the customers request, I spoke with my boss and then the company president. Looking at my daily numbers, we were not only not moving forward on the schedule, in many cases we were moving backwards as my team had to fix things that had gotten broken, or throw away code that would no longer be used due to a change in direction that happened in a time zone three hours ahead of ours.

Armed with my daily numbers regarding checkins, bug fixes, feature progress, emails from all developers involved, I approached my boss and his boss and made the recommendation to simply end the project. If the project was being, effectively, sabatoged daily, then we needed to get out with our reputation intact and no additional monetary losses.

For reasons that made sense only to upper management, my request was not approved. I had to schedule more regular meetings with the client, meetings where the president of the company was present. Meetings were I got dressed down, nearly every day, for things that had been discussed the previous day. But I persevered. I've talked about the value of documentation before, and this is the project that brought that home for me. For every allegation, I had a document on why it had been done and who had approved it.

Eventually we achieved a rhythm; my team would come in and spend the first hour or two of the day undoing checkins from the Boston team. Then they'd fix the code the Boston team had made plug it back in, make sure the build wasn't breaking and the tests were now running, and then they'd start their work. Where you normally assume a person isn't productive eight straight hours a day, and I typically assumed six hours of productive time, I modified my schedule to include this maintenance and dropped them down to three hours of productive time per day and stopped counting the Boston team's work at all.

Suddenly, the client was getting what he/she wanted (in a really convoluted, frustrating way). I was able to alter the schedule and scope. I brought in Starbucks cards and toys and books for my team--every time they had to undo a tangle created by the Boston team, they got a prize.

In return, on the day when they finally got the build automation and test automation to work perfectly--greens all across the board--they took a picture of themselves doing the "Vanna White" thing with the monitor holding the good news and sent it to me (I was home sick that day). The whole team, grinning ear to ear made it clear I'd gotten their heads above water, and that, maybe, I had developed some gills. We did end up delivering on time and on budget, with the new schedule and scope.

Not all projects are that bad. But I think of that whenever a project I'm working on looks dire. At least, I think, its not that project all over again.

So basically, the steps to managing an underwater project break down as:

1) Realize you are underwater. Accept. Do not panic
2) TELL SOMEONE. Specifically your boss and/or his boss. The sooner people know, the sooner they can help, but also the sooner they can adjust their expectations.
3) It's ok to recommend that you close or cancel a project that is under water. You can do this based on return on investment (the calculation that the project is costing the company more than they'd get for completing it). But only do this if that is absolutely the case, and you have clear measurements to prove it.
4) You might get help, you might not. At the end of the day, the project underwater is your project. You will have to use what you have available to get back to the surface (and hopefully beyond)
5) Things you have to help you: the ability to adjust schedule, the ability to adjust scope, the ability to adjust resources. As we discussed in the Iron Triangle post, these are three things that make up a project; adjusting any one of them affects the others. So to pull yourself out of being underwater schedule-wise, you can add resources and reduce scope. To meet an expanded scope, you can extend schedule and resources, and to deal with fewer resources you can extend schedule and reduce scope. In my example above, that's what I did: I assumed fewer resources (because my team was undoing the work of the other team) and shrank scope and expanded schedule accordingly.
6) Address morale. Even if you don't actively have a team working against your team, being on an underwater project reduces morale. Death marches are often a technique used to try and get back out from under water, and, for a short time, they work, but the damage to morale affects the long term effectiveness and usefulness of your resources. You need to keep morale up, even if it means breaking for lunch together despite the fact there's still work to do.
7) Be creative. These prescriptive steps don't cover it all; the fact my team was thinking of beating the hell out of one of the developers when he came over to learn more about our systems required me to make each time they had to undo someone else's mistake a rewarding experience, to reduce the overall frustration. AS a manager, donuts, coffee, toys and books are a small price to pay to avoid homicide and to get a project done. But whatever works for me might not work for you--so be creative.
8) Keep communicating. Daily if you have to. No one wants to be surprised when a project goes underwater and stays there and maybe fails to meet dates or scope requirements. Keep everyone in the loop on the blocking issues and what you're doing to resolve them. Not every project will work out. You will have failures. This documentation will protect you and provide information for a project post mortem (a common technique where people call a meeting to find out what happened during the project). Often post mortems for projects that did not succeed become blame games that are not useful. But the communication, summaries and reports you keep during the process can clearly identify what was what, and keep the unproductive blame game at bay.

Tuesday, September 20, 2011

The $10,000 Pen

When I was working for a start up in Silicon Valley, we went under. It was called the dot com bomb, or dot com crash. A brief side note--it's not a selling point that you're CEO has been hit by lightening twice, as ours had been. Once is understandable, but twice is basically either stupidity or egging on the fates (or both). Whichever it was, it totally caught up to us.

Miraculously, 13 of us from the company that closed its doors were purchased with our technology and brought to work for a wharehousing company that wanted to be able to provide e-commerce sites to their customers.

When hired, we were promised our original rate of pay. Some got bonuses. I got a typo. A very nice typo--I was make A LOT more money than I had been making, and I didn't correct them.

Three months later came the first pay cut. Everyone grumbled--it was 10%; I did ok, as I had the typo. I was making less, but still more than I had originally been making.

At six months, the managers took another pay reduction.

On our one year anniversary, we were all gathered into a room for a party--we celebrated and laughed and talked about how miraculous that we had made it after the previous .Com fell. Then we were thanked for our service.

Then they announced another 10% pay cut.

Finally, they handed us all a pen as a present for our one year of service. I carried it reverently--even with my typo, that pay took me $10K less than I had been making at the previous company. I thought about taking it out back and running over it, since running over the new management was not an available option.

Basically, the point of the story is that what you do and how you do it set the tone for how people feel about you and the company.

Take the first paycut: a solid, sympathetic meeting explaining that certain contracts had not come through (or any convenient lie) and a reach out by the HR team to talk about our feelings and make us at least settled with our cut would have made us feel like part of the team, doing our part (although reluctantly) in keeping the company that kept us afloat, afloat.

I was a lead, and not a manager. I imagine the manager cuts sucked, but they didn't say much about them, so I cannot speak to how they could have been done better.

I can imagine the last round of paycuts could heartily have been managed better. Step 1) Meeting about pay cuts. Address concerns, fears, and thankfulness the company decided to reduce pay rather than lay anyone off. 2) Separate party thanking us for stayinng with them for the last year, despite the difficult times, and being told we were appreciated. Finally, acknowledging a pen is not equal to a paycut, but that they wanted to show us, in some way, that they appreciate us, even if they could not do it with the monetary recompense they would like.

Tada! It still sucks, but then everyone's still on the same side.

The way they handled it, however, made it very "us" v. "company." Our lead dev started doing 80% of his work, because that was what he was being paid. We lost two people almost immediately after their talks with management were not "Here's what is happening and why we had to lower your pay" but "No, there's no possibility of an increase, you should be happy you have a job."

The morale of the $10K pen story is that how you present things to people may not be the way they see them. When you are delivering news--especially ambiguous or bad news--you need to be honest with people AND appreciative of the work their doing in praise and words...not just a cheap pen.

As the manager, you typically have little control over random finance changes, like across the board paycuts. But much like a third grader may not be able to control a bully telling her she's ugly, she (and you) can control how she reacts to the unpleasantness and form a reaction of her own making. It is important to the third grader for her eventual maturity, and it's important to you as a manager if you want your team to continue to be happy, let alone stick around and work together.

Sometimes you can't stop the company from making itself the "bad guy" through policies and actions. But you, yourself, can be allied with the employees, per their perceptions, and make a much better work environment out of something, no matter how lousy it may get.

Tuesday, September 13, 2011

Be an Information Nexus

Dictionary.com defines a Nexus as:

1. a means of connection; tie; link.
2. a connected series or group.
3. the core or center, as of a matter or situation.
4. something to do with cell biology that doesn't match/isn't as applicable as the other definitions, so is being left out. Look, a monkey!

Basically, in the workplace, you don't want to know everything, you want to be the person who knows who knows everything. Other than being really hard to parse, that sentence incorporates the definitions 1-3 above by making you the center, a means of connection and part of being a connected group.

No one who is rational ever expects that you will know everything. But, for example, in interviews people will want to know what you will do when you run across something that you don't know what to do with. The proper answer is "find out what to do with that thing" and then provide examples of how you'd do that.

That seems very common sensical, but, as you know, common sense isn't (to continue with my theme of hard to parse sentences). Most employers would like a base amount of information in your brain when you start, just like your current employer wants you to know enough about your job to do it, but they also want to know that you are prepared to help yourself if you run into trouble.

What works for me, and makes me more valuable to the people that I work for, is that I retain the answer and who provided it each time I have to find an answer to a question; I keep it in email, in my brain, I make notes in my notebook...at one job, I actually kept a database of answers and who knew them. The gist is, you want to become informed beyond just being able to do your own work, but to be productive and useful to other members of your team and to be the go-to person for folks outside of your team, as well. Even if you don't know all the answers, most people don't differentiate between you being all knowing and you being the person who knows the people who know. It reflects well on you and your team, makes you a better candidate for job retention, and can be called upon for a yearly review with concrete examples to prove your value to the company.

As a manager, it makes you seem wise and mysterious. Ok, mostly just wise. Upon occasion your people will still come to you with questions where you cannot easily, on your own, go and find out the answer and those occasions can be opportunities instead of challenges, by mentoring the employee who wanted to know in the way of finding out...and then having the employee report back to you when they have the answer. You'll both be happy--he or she will have the answer they want and you'll have another fact in your arsenal for the next time someone needs to know something.

Tuesday, September 6, 2011

Getting Improvement Without Going Full HR on Their Butts

You have an employee who doesn't need to be scared out of their minds by a trip up to HR about their job performance. Instead, you need to do your thing, as a manager, to get them flying straight; HR is a last ditch attempt at fixing things, and, quite frankly, as a manager its' part of your job to prevent things from going that far if you can prevent it.

The first thing to think about is, when did the behavior you've noticed start? Has this always been a problem with this person and it's just becoming an issue now, or did it just start in the last few weeks?

If it's always been an issue and just got worse recently, or just started recently, there's probably a catalyst for the bad behavior that you can isolate; if it's about the time the server started going down like a five dollar whore, you can probably curb the behavior by talking to the person about it and getting a new server. If it's because your employee is getting a divorce or a loved one has passed, then you can treat them more gently and give them more benefit-of-the-doubt in resolving the issue; the thing that is causing or being exacerbated by the bad behavior is not going to last forever, but it will be a while and you need to be supportive. If there doesn't seem to be any precipitating cause, or worse, this is how they've always been, you have a harder road in front of you: moving people out of established bad habits is hard work, and usually considerably less successful in repairing. The longer someone does something the wrong way, typically the more resistant he or she will be to doing it the right way.

The next thing to think about is what exactly don't you like about the behavior. If he/she is deleting the source tree daily, that's pretty damn clear (and probably grounds to fire or put into a mental institution before the rest of your team gets hold of that person). If, however, its more of a way of saying words, word choice, or overall attitude, you need to break it down into something as concrete as deleting the source tree so you can show them what you don't like; if you can't provide a clear example of the behavior you don't want to see, there's no way for them to know what to change.

Next, you want to look at what behavior you would like to see. If, for example, your problem employee is Mrs. Negative--the glass is not only half full, it's also full of acid--you probably want to see, at the very least, a cessation of the majority of the negativity which means that you might want Mrs. Negative to be more quiet in group meetings unless she has something productive to say. An additional behavior you'd like to see is that she does have something productive to say--dreaming up what could go wrong is not bad behavior if you are also working out possible solutions to what could go wrong. Harping on a problem without solving the problem, however, is bad manners.

Talk to this person casually the first time, unless things have progressed to "seriously disruptive." An employee should not be penalized for a manager not noticing their bad behavior or for other employees not letting them know they don't like the behavior. While we assume (remember my earlier posts on assumptions?) that certain behavior is accepted as the norm and that any person should understand that, we all know that's not the case; otherwise teams would agree completely and no additional management would be required. It would also be a spooky world where we all had the same daily clothing choices as Ronald McDonald--the same shirt, tie, etc. Freaky. Fortunately, the world is not like that, and, unfortunately, employees are not psychic (or fortunately--they probably wouldn't be working for you if they were psychic as they'd be on a beach somewhere). If they don't know that they are doing something wrong, they cannot fix it. So, no matter how annoying it is, you have an informal conversation (maybe during your regular 1:1) to discuss it.

In that meeting, you cover what behavior needs to change, and what you'd like to see instead, and then you leave it ALONE. Hounding people who may be self-conscious about what you've just told them is poor form and also likely to undermine the result you actually want to get.

Its likely this person will show immediate improvement...and then, over time, may slip back into the bad habit. As soon as you see the regression, talk to them again. Again this is an informal discussion, with appreciation and notice of the hard work they've already put into this, but with a reminder that you saw the undesired behavior return.

If they slip up again, or, as noted above, if the issue is immediately seriously disruptive, you'll need to prep a little before you meet with them again. You'll need to define the problem and the steps taken to date to resolve it (previous meetings and suggested behavior). Then you'll need to create a step-by-step plan of things this person needs to do in order to alter that behavior, and a check-in date (or dates) after the plan is implemented so they can tell what their progress is and you can measure it, too.

This will not be the final form of this plan--that needs to be worked out by you and the employee, together. Someone honestly struggling with a behavior wants to be part of the solution for that behavior so they a) are invested and b) don't feel bossed around. If everything is coming from you, its way too easy for them to believe that the problem is also with you, and not them.

Then, meet with them. Go over the timeline of the issue, define the issue again, define what's been done, so far, unsuccessfully to resolve the issue, and then ask the person to help you brainstorm how to resolve this issue to both of your satisfaction by the date you've selected (which should be out by at least a week or two, preferably a few months, and which gives time for check-ins and improvement from those checkins). While you don't want to be threatening them at this time, you will need to tell them that you need to see improvement along the schedule to which they've agreed or you will have to take the next steps, which neither of you want to do. Next steps will be getting HR involved.

Next, work the plan. Give the person every chance at success that you can, as long as you feel they are giving their best to you. You may need to involve HR to help them get classes or training they need. Or, they may not be able to accomplish the goals they set out with you, and it becomes an HR exercise from there that you must monitor. However it goes, though, you know you will have done your best by them before you had to get the human resources team involved. Further, you'll have it all documented for HR.