Sometimes things go so badly for a manager that you just have to put some time between yourself and “that moment” before you can even think about it rationally. These are the sort of occasions when the horror of the situation seems almost impossibly comical in retrospect. Like the case of the disappearing employee.
I was in a new leadership role – the first time I had directly managed an all-right-brain function (not a technical department!) so I was a fish out of water. To make matters worse, we were filling a critical skill gap in the team and I needed someone who would provide some functional leadership over that area. We recruited hard and turned down many – until we found the “just right” person who seemed to make it worth the wait. Qualifications, attitude, team chemistry – it was all good. For about a week.
You see, this perfect person started picking fights with other departments right away, and by the end of the second week, I was in conference with the leader of another group, spending political capital to buy time for my new person to “adjust.” I explained all the problems away to a misunderstanding of whose-job-ends-where and a lack of training on our company procedures. These are not problems you face in technical jobs, I thought to myself.
Another week went by and the adjustments never came. Inter-departmental complaints got worse to the point where HR was involved, with two people threatening legal action against the company due to my employee’s arrogant bully behavior. At about that time, the other people on my team made it clear that the new person had none of the claimed job skills, so we not only had a rebel but an incompetent one.
What a mess! How could this happen to me, performance manager extraordinaire for hundreds of people in roles leading up to this one? Certainly there was some deception involved in the interview process but I would have spotted that in the first 90 seconds of interviewing someone for a technical role. But this was not a technical role. I had made my first big hiring decision in the new job, and it was wrong.
That’s when we got the rebel’s post-it note. It was stuck to a co-worker’s monitor, scribbled with something illegible except for the signature. Ever the diligent manager, I tried to call the employee’s cell but got no answer. Two more days, then the weekend, and no word or sign; – poof - gone.
If you’ve ever fired a really poor performer in a technical role, you have probably experienced the feeling of elation that comes over the team during the following days. Everyone is happy because “that” person is not around. Meetings go better because “that” person is not gumming up the works. The mood in the office lightens, and more work gets done. It’s an unmistakable signal telling you that you did the right thing. Well, five weeks into the new employee’s tenure, after two days absent with no word, I felt that elation in my small department.
Again, I was shocked. How could I have missed the fact that the whole team was working under so much tension and dread? How could I have noticed that people from other departments were avoiding us, but now they had decided to come back around again? Like Sinatra said, I picked myself up and got back in the race. I was bound to resolve the situation definitively and learn from it.
With some help from HR, we were able to come to the amicable conclusion of our employment relationship with the rebellious newcomer. That makes it sound too easy; the truth is that there was a lot of good work managing the emotions and egos involved. My team agreed unanimously to get the job done without putting anyone in the now-vacant role, which made me feel really stupid but very glad it was over.
So what were my cliff notes from this management use case? First, learn the actual job function of the department before you decide to hire anybody – regardless of what the prior manager or anyone else tells you. Second, no job is beyond testing; whatever people are going to be doing every day can be condensed into two hours and they can be asked to do it right in front of you before you make a hiring decision. Third, a take-charge attitude may be appealing in an interview but it’s only useful when the actual job requires it. Like Cesar Milan says about dog packs, misplaced alpha behavior is the root of a lot of unhappiness.
Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.
Wednesday, December 31, 2008
Sunday, December 7, 2008
Processing, please wait.
Any development manager is bound to have a love-hate relationship with software process. On one hand, some things can’t get done without a solid process – especially for larger projects, global efforts, etc. But on the other hand, software processes can make projects bloat-out for apparently no good reason. That happens when, for example, a big process is applied to a small effort.
Let’s start analyzing this situation by realizing that some form of process is always necessary. I can win this argument by defining process to be whatever I want… it can be as simple as “keep a copy of anything you send out to a customer so you can test it later” or it can be much, much more than that. The concept of process was something hard for me to understand right out of school. I knew how to write code to solve problems. Sure, it made sense to make backups occasionally and I also liked the idea of code reviews from the start, but what else could you possibly need on top of that? Left to my own reconnaissance, I would have never conceived that those and a hundred other details could be the foundation of a framework for creating professional software.
I had a job right out of school with a company that had been writing software for decades. They started my indoctrination by giving me the two-inch-thick process binder on my first day. It was Greek to me. The thing had its own vernacular of TLA’s that you had to learn before you could even understand the table of contents. I set it aside and started coding. About 60 days later, we had a training class on the monster manual, so I dutifully inserted the six or seven updates that I received into their correct pages in my growing process definition binder, and went off to class. After that, I went back to coding. Two more months went by and I threw the thing out. In the round file. Landfill ledger. It had taken up space in my cube for too long and it was useless to me.
Not three days later my manager dropped by with a couple of updates for my process binder. Evidently there was a squirrel cage somewhere full of people whose role it was to crank out cryptic updates to this thing. The manager asked me where I kept it so he could put the updates with it – must have been something really important.
So, I told him “I tossed it.” He turned white as all the blood ran out of his face. He just stared at me, repeating my words “You tossed it” even as his eyes grew wider while he contemplated the impossibility of this situation. I had to say something more or else start CPR so I said “Yeah, I could not use it for anything useful and I understand what I have to do every day without it.” He walked away like a robot, wondering what planet I had come from and probably also wondering if I had carelessly found a way to make life more interesting and rewarding. Eventually I left and the company went into deep financial trouble so I’m sure they reformed, eventually.
I was wrong to toss out the process manual and that company was wrong to have a rigid, incomprehensible process pushed down on legions of people. As with most management situations, it’s not black and white; my situation arose after thousands of well-intended decisions created a process that justified its own existence without regard to practicality. Just exactly where it went wrong is impossible to say, but I am certain that nobody had tried to re-engineer the process in recent years; instead, they just patched it up with more inserts for the binder.
In the years and leadership roles I’ve held since then, I’ve gone through several process re-engineering efforts and I found each of them valid and each of them useful to improve on their predecessor. When the company grew, processes needed to change. When the company went global, processes needed to change. When technology went from Windows to Web, processes needed to change. In all cases the outcome was (a) a huge amount of change management that had to be done internally and externally and (b) net benefits that came much later and were never as great as expected because the downside of process changes was underestimated.
That said, I process definition efforts always surprise me because of how eager people are to participate. Every developer, QA and manager wants to have a say in the new process. In fact, most of them are downright dogmatic about it, having read about a style or technique that they think is the missing link that will allow the software engineering machine to suddenly work frictionlessly. Usually, groupthink sets in and defines something impossibly different from current processes (and process automation technology, which is rapidly growing in influence) so a smaller team has to sort out a reasonable plan.
I was asked to deliver a lecture on software process to an undergraduate computer engineering course about 10 years ago, but I screwed up. They caught me on a bad day. At the time, I had several team leads that were punch-drunk on process changes that they wanted to make. They were trying to tell me that they could not succeed because of the processes that were in place, with certain success predicted by changing 8 things at once.
My message to the class was to be wary of processes; following process does not guarantee success. Instead, bring ingenuity to the table and use your ability to create high quality as a means to avoid being told not just what to do but how to do it. It’s a message that resonated well with really smart, inexperienced left-brain people and I left the lecture happy. But I know I did the wrong thing. I know I should have made sure they understood how uniform processes guarantee quality even when you don’t have the best people working on every single feature. I should have told them how processes would save their butts when they were working too hard to remember all the minor steps that had been learned through years of mistakes. I should have guaranteed that they would never consider the job done until it was code-reviewed, tested and checked-in.
Now that I’m not as smart as I used to be, I know that the process manual is something to keep and respect, but only if you can change it when it’s wrong. Whoever is in charge of the process definition had better have an open-door policy and technology that makes it easy to follow (and monitor compliance!). Anyone who must submit to a process should have the right to influence it. I can actually get fired up when I read about a process that I know intuitively will make people productive and happy without controlling them. I see processes as something of a design pattern for project management.
Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.
Let’s start analyzing this situation by realizing that some form of process is always necessary. I can win this argument by defining process to be whatever I want… it can be as simple as “keep a copy of anything you send out to a customer so you can test it later” or it can be much, much more than that. The concept of process was something hard for me to understand right out of school. I knew how to write code to solve problems. Sure, it made sense to make backups occasionally and I also liked the idea of code reviews from the start, but what else could you possibly need on top of that? Left to my own reconnaissance, I would have never conceived that those and a hundred other details could be the foundation of a framework for creating professional software.
I had a job right out of school with a company that had been writing software for decades. They started my indoctrination by giving me the two-inch-thick process binder on my first day. It was Greek to me. The thing had its own vernacular of TLA’s that you had to learn before you could even understand the table of contents. I set it aside and started coding. About 60 days later, we had a training class on the monster manual, so I dutifully inserted the six or seven updates that I received into their correct pages in my growing process definition binder, and went off to class. After that, I went back to coding. Two more months went by and I threw the thing out. In the round file. Landfill ledger. It had taken up space in my cube for too long and it was useless to me.
Not three days later my manager dropped by with a couple of updates for my process binder. Evidently there was a squirrel cage somewhere full of people whose role it was to crank out cryptic updates to this thing. The manager asked me where I kept it so he could put the updates with it – must have been something really important.
So, I told him “I tossed it.” He turned white as all the blood ran out of his face. He just stared at me, repeating my words “You tossed it” even as his eyes grew wider while he contemplated the impossibility of this situation. I had to say something more or else start CPR so I said “Yeah, I could not use it for anything useful and I understand what I have to do every day without it.” He walked away like a robot, wondering what planet I had come from and probably also wondering if I had carelessly found a way to make life more interesting and rewarding. Eventually I left and the company went into deep financial trouble so I’m sure they reformed, eventually.
I was wrong to toss out the process manual and that company was wrong to have a rigid, incomprehensible process pushed down on legions of people. As with most management situations, it’s not black and white; my situation arose after thousands of well-intended decisions created a process that justified its own existence without regard to practicality. Just exactly where it went wrong is impossible to say, but I am certain that nobody had tried to re-engineer the process in recent years; instead, they just patched it up with more inserts for the binder.
In the years and leadership roles I’ve held since then, I’ve gone through several process re-engineering efforts and I found each of them valid and each of them useful to improve on their predecessor. When the company grew, processes needed to change. When the company went global, processes needed to change. When technology went from Windows to Web, processes needed to change. In all cases the outcome was (a) a huge amount of change management that had to be done internally and externally and (b) net benefits that came much later and were never as great as expected because the downside of process changes was underestimated.
That said, I process definition efforts always surprise me because of how eager people are to participate. Every developer, QA and manager wants to have a say in the new process. In fact, most of them are downright dogmatic about it, having read about a style or technique that they think is the missing link that will allow the software engineering machine to suddenly work frictionlessly. Usually, groupthink sets in and defines something impossibly different from current processes (and process automation technology, which is rapidly growing in influence) so a smaller team has to sort out a reasonable plan.
I was asked to deliver a lecture on software process to an undergraduate computer engineering course about 10 years ago, but I screwed up. They caught me on a bad day. At the time, I had several team leads that were punch-drunk on process changes that they wanted to make. They were trying to tell me that they could not succeed because of the processes that were in place, with certain success predicted by changing 8 things at once.
My message to the class was to be wary of processes; following process does not guarantee success. Instead, bring ingenuity to the table and use your ability to create high quality as a means to avoid being told not just what to do but how to do it. It’s a message that resonated well with really smart, inexperienced left-brain people and I left the lecture happy. But I know I did the wrong thing. I know I should have made sure they understood how uniform processes guarantee quality even when you don’t have the best people working on every single feature. I should have told them how processes would save their butts when they were working too hard to remember all the minor steps that had been learned through years of mistakes. I should have guaranteed that they would never consider the job done until it was code-reviewed, tested and checked-in.
Now that I’m not as smart as I used to be, I know that the process manual is something to keep and respect, but only if you can change it when it’s wrong. Whoever is in charge of the process definition had better have an open-door policy and technology that makes it easy to follow (and monitor compliance!). Anyone who must submit to a process should have the right to influence it. I can actually get fired up when I read about a process that I know intuitively will make people productive and happy without controlling them. I see processes as something of a design pattern for project management.
Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.
Subscribe to:
Posts (Atom)