When you are leading a team, you gain strong insight into the capability of each person. Software development teams are no exception; in fact the disproportionate contributions of different developers actually let you zoom-in on individual capabilities more sharply than in other functions.
That was the scene when I was leading a group in Europe a few years ago. I hired each person and oversaw their ramp-up on my company’s products. We had an impressive set of skills and we were not shy about taking on big challenges to make up for faltering business back in the U.S.
After a few months, though, I got some bad news. A key team member had been commuting by car nearly 90 minutes each way. Even though he loved his job, he just could not keep it up. He’d taken a job much closer to home and I would soon have a gaping hole in my project plans.
I knew his value to the company and the damage that would be done by his departure so I went in to overdrive. I tried offering several different incentives but the only thing he wanted was more time to spend at home with his young family. If I wanted to keep him, telecommuting would be the only option. He was responsible and often worked solo on parts of deliverables so I agreed immediately. I crossed my fingers and set off to discuss the situation with the general manager of the business.
At a leadership meeting the next day, I re-told the story and stated my decision. There were three other people in the meeting, all of them young managers like me. To my great surprise, they all rejected the idea of allowing anyone to work remotely. The room was polarized, three against one. Their arguments only served to strengthen my resolve. For example, they argued that one person could not be so important. Then they argued that someone working remotely would be unaccountable and irresponsible. Finally, the argument was that if one person received the work-from-home benefit, everyone else would want it too.
I wish I could say I kept my cool but instead, I got angry. In fact, several of us got red-faced as we each dug-in to our positions. I knew we should retain the guy who wanted to leave, and that telecommuting would work for him. I also knew software development and personnel management better than the people arguing against me. The meeting ended in a stale-mate with the general manager essentially shutting me down and tentatively ruling against me.
I had set myself up to fail. The development team had been running so smoothly that other leaders had no idea how it worked or why one person could be so important. They also commoditized the people (thinking they would all want to work from home) because they had not become engaged enough to know them as individuals.
I should have provided details like how I would structure the telecommuting plan formally – things like official HR policies, access to development tools, and management tracking. I had to play catch-up and do all of that work in the wake of the leadership meeting. But none of that would have made a difference if I had not forced the issue by becoming obviously passionate about my point of view. Without that little outburst, the decision would have been "for the good of the business" without the need for my "technical input."
The general manager ultimately approved the idea and the developer became a very successful telecommuter for years afterward. The experience taught me to think about how an idea is presented to a mixed audience. But more importantly, it taught me to engage argumentation, debate and even vocal jousting (appropriately and professionally) if the alternative is failure.
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, June 24, 2009
Friday, May 15, 2009
Learn once, run anywhere
I went to visit a new outsourcing partner overseas a few years ago. We were in a ramp-up situation where literally dozens of jobs needed to be filled. I had recruited in Europe, the US and Australia by then so I was curious about how my skills would translate in the outsourcing climate.
Before I get a lot further with this piece, we need to be clear about something: Companies exist to make money. Not to help you fulfill you dreams of creating order in the software universe or to sponsor you through all of the MCSE steps. Granted, those things are ancillary benefits that can come along for the ride, as long as they don’t get in the way of the business.
That’s how I looked at it when my company wanted to consider outsourcing. I saw it as a natural avenue to explore; a way of reducing costs. I certainly would have wanted the company to reduce costs in other areas so it would have been lop-sided to ask that they spare software development from consideration for saving some green. There are really smart (I mean scary smart) people all over the world so there’s no reason to expect outsourcing to fail categorically. So I figured that either I could make it work, or my competitors would do it, then take over my market by offering products at a lower cost.
So I’m back to my story. I had interviews lined up from morning to evening in 30 minute intervals. I don’t normally take notes during an interview (that’s for immediately afterward) but I made an exception because the names were so unfamiliar and there were so many people. Just as I had hoped, once the interviews started, I was in familiar territory. I won’t write about all of the interviews but a few of them stand out, and with the power of hindsight we can trace the outcome of each decision.
Candidate number one opened the conversation with “I am an expert on …” and he named a few technologies. I don’t have an issue with arrogance but this guy could not back it up with examples or facts. I voted thumbs down but let myself be overruled in a recap "round table" discussion afterward; he was no expert but he could be a decent coder since he had passed a written test up-front.
Candidate two was a rock star. Short on experience but spot-on with every behavioral question – like how to give constructive feedback to a peer, how to change your approach after a failure and even how to re-organize a project plan that’s in trouble. I said YES and stuck to my guns when other interviewers wanted to bounce him because he wanted too much money.
Candidate three was a tester, not a developer. I have a few case scenarios that I use in QA interviews – questions like “How would you like for the CEO to think of the QA function?” or “Would you ride in a plane that’s never been flown?” I use those mostly to establish whether the candidate understands that QA adds value (vs. just being a process stage or a cost center). This guy did not get it. He could not see the big picture – I knew he would never be accountable for the quality of software. But he had tons of experience, including previous projects that the other interviewers knew in detail, so I let him on the team.
Candidate four was an understated quiet kid. It was hard to get him to talk about himself or his projects. His resume was not even clear so I took out his written test. Unbelievable… I had only seen it done better once before. I loved the way he defined words like “semaphore” because it showed how deep of an understanding he had. I also liked his ER diagram – simple but he even used some standardization in the field names for the simple test example. Once I got him talking, I was sorry I only had 20 minutes. Of course I wanted to hire him but the other interviewers tried to tell me he would not work well on a team. When there was one opening left, I got him in.
Fast forward through projects and deadlines… Candidate One (Mr. “I am an expert…”) was the first to go. He was a charlatan from the start; one of those people who takes away from the productivity of everyone else by negativity. I wasted my time and the company’s money when I let him be hired. Candidate two proved his rock star qualities over and over again, eventually moving to the States to work at our headquarters. He was worth every penny of his higher-than-usual pay level, and he was easy to manage as well.
Candidate three, the QA analyst, mostly just took up space on the payroll until I could put the microscope on him during a third-party certification of the software. He was classic in his ISO-certified diligence preparing documentation and paperwork but useless in the lab actually doing testing. I knew there was a problem because we never saw the defect levels rise and then fall as we went through the transition from code freeze to release. I leveraged the crisis to move him out of the team. Candidate four, the quiet kid, never ceased amazing me. My favorite thing about him was how he learned a ton about the product – not just enough to write his piece of the code according to the functional spec… this guy had ownership!
I’d love to say I had a 100% record for that hiring trip to the out-sourcer but the truth is that we could have flipped a coin and gotten the same result – about half the decisions were good, half were poor. If I had stuck to my guns instead of doubting myself, I would have had that 100% kick off that I was after. I was right about the fact that great people are everywhere, and I would also have been right to assume that my instincts applied just the same to people everywhere, too.
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.
Before I get a lot further with this piece, we need to be clear about something: Companies exist to make money. Not to help you fulfill you dreams of creating order in the software universe or to sponsor you through all of the MCSE steps. Granted, those things are ancillary benefits that can come along for the ride, as long as they don’t get in the way of the business.
That’s how I looked at it when my company wanted to consider outsourcing. I saw it as a natural avenue to explore; a way of reducing costs. I certainly would have wanted the company to reduce costs in other areas so it would have been lop-sided to ask that they spare software development from consideration for saving some green. There are really smart (I mean scary smart) people all over the world so there’s no reason to expect outsourcing to fail categorically. So I figured that either I could make it work, or my competitors would do it, then take over my market by offering products at a lower cost.
So I’m back to my story. I had interviews lined up from morning to evening in 30 minute intervals. I don’t normally take notes during an interview (that’s for immediately afterward) but I made an exception because the names were so unfamiliar and there were so many people. Just as I had hoped, once the interviews started, I was in familiar territory. I won’t write about all of the interviews but a few of them stand out, and with the power of hindsight we can trace the outcome of each decision.
Candidate number one opened the conversation with “I am an expert on …” and he named a few technologies. I don’t have an issue with arrogance but this guy could not back it up with examples or facts. I voted thumbs down but let myself be overruled in a recap "round table" discussion afterward; he was no expert but he could be a decent coder since he had passed a written test up-front.
Candidate two was a rock star. Short on experience but spot-on with every behavioral question – like how to give constructive feedback to a peer, how to change your approach after a failure and even how to re-organize a project plan that’s in trouble. I said YES and stuck to my guns when other interviewers wanted to bounce him because he wanted too much money.
Candidate three was a tester, not a developer. I have a few case scenarios that I use in QA interviews – questions like “How would you like for the CEO to think of the QA function?” or “Would you ride in a plane that’s never been flown?” I use those mostly to establish whether the candidate understands that QA adds value (vs. just being a process stage or a cost center). This guy did not get it. He could not see the big picture – I knew he would never be accountable for the quality of software. But he had tons of experience, including previous projects that the other interviewers knew in detail, so I let him on the team.
Candidate four was an understated quiet kid. It was hard to get him to talk about himself or his projects. His resume was not even clear so I took out his written test. Unbelievable… I had only seen it done better once before. I loved the way he defined words like “semaphore” because it showed how deep of an understanding he had. I also liked his ER diagram – simple but he even used some standardization in the field names for the simple test example. Once I got him talking, I was sorry I only had 20 minutes. Of course I wanted to hire him but the other interviewers tried to tell me he would not work well on a team. When there was one opening left, I got him in.
Fast forward through projects and deadlines… Candidate One (Mr. “I am an expert…”) was the first to go. He was a charlatan from the start; one of those people who takes away from the productivity of everyone else by negativity. I wasted my time and the company’s money when I let him be hired. Candidate two proved his rock star qualities over and over again, eventually moving to the States to work at our headquarters. He was worth every penny of his higher-than-usual pay level, and he was easy to manage as well.
Candidate three, the QA analyst, mostly just took up space on the payroll until I could put the microscope on him during a third-party certification of the software. He was classic in his ISO-certified diligence preparing documentation and paperwork but useless in the lab actually doing testing. I knew there was a problem because we never saw the defect levels rise and then fall as we went through the transition from code freeze to release. I leveraged the crisis to move him out of the team. Candidate four, the quiet kid, never ceased amazing me. My favorite thing about him was how he learned a ton about the product – not just enough to write his piece of the code according to the functional spec… this guy had ownership!
I’d love to say I had a 100% record for that hiring trip to the out-sourcer but the truth is that we could have flipped a coin and gotten the same result – about half the decisions were good, half were poor. If I had stuck to my guns instead of doubting myself, I would have had that 100% kick off that I was after. I was right about the fact that great people are everywhere, and I would also have been right to assume that my instincts applied just the same to people everywhere, too.
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.
Sunday, April 12, 2009
Own it for the long haul
Its been almost 10 years since Y2K so I guess a lot of people reading this were not yet in the workforce at that time. It was an interesting node for the software development role: a combination of incredibly boring work that was incredibly well paid for a short period of time.
Y2K was really nothing unusual for me because at the time I was at the dead end of a product line, holding up the fort while the company developed a replacement. Maintenance was my mainstay so checking and re-checking for unintended rollover effects fit right in with the plan.
Two things about my Y2K experience are worth explaining so I’ll pack ‘em both into one episode and spare you the cliffhanger.
The first of the two was something we called project Gauze. Back then we were constantly thrashing over the support call logs trying to figure out ways to reduce costs (thereby increasing profit margins) on the help desk. It is frustrating to fix defects that late in a product lifecycle because clients don’t want to incur the cost (pain) of rolling out updates, especially when they can call the helpdesk at no additional charge. Y2K updates, however, were widely anticipated to touch every installation. Governance auditors and other paperwork leeches created a fin-de-siècle culture of fear and charged big bucks to ensure compliance. If we could inject some support call fixes into the Y2K patch, it would make the whole thing have a positive impact on our customer’s experience, and our costs.
Of course there were arguments against this idea. The main one was the catch-22 scenario whereby we could poison the Y2K upgrade by introducing new insurmountable problems in the release. We fought that one off by making the whole thing modular, meaning we could pick-and-choose what to roll out. The other argument was that we needed to tell clients what we were doing, and they would say “no” to the risk. That one, like much other speculation about client responses, turned out to be unfounded. Most any client will provide a reasonable answer to a request if the person asking is trusted and empowered to do the job right.
Gauze made a huge difference. We dropped the call volumes by about 40% on a product that pretty much everyone had thought abandoned. The added stability extended the life of the product, resulting in a few more years of lucrative maintenance fees and headaches for our competitors who predicted the product’s demise prematurely. The lesson? A new idea can take hold even when hundreds of people with established processes across many departments in a big business have to be convinced. Its not easy and the idea has to pass a lot of scrutiny but stick to it and make it happen.
The second Y2K notable was fast by comparison. The CEO called for everyone to join in and sit a shift or two on the help desk as midnight rolled around the world. So much for my 1999 new year’s eve. I had taken support calls during the early days of the product but ever since it got big and was pushed into thousands of sites, the help desk operation was a complicated machine that I knew nothing about. December 31of 1999 was an eye-opening experience for me. The tools and utilities that I had written years earlier to diagnose and fix problems were still being used, bugs and all. The knowledge that I had shared with the first few people we hired full-time onto the help desk had been immortalized in a sort of repository that was consulted and interpreted quasi-religiously. Procedures that I had conceived quickly and never optimized were being repeated thousands of times with exacting detail.
It was frustrating to me that people managing the help desk would not build their own tools and improve their troubleshooting processes. But then it dawned on me that the mistake was mine. The help desk is an operation that exists to scale and implement processes with a guaranteed service level and profit margin to the business; they are not responsible for re-designing the product. Arguably they could have invested in some development but would the company have allowed it? I don’t think so because anyone doing good development would be re-assigned to work on products.
The lesson here is that you have to build in care-and-feeding tools for the runtime-operation of a product. You can’t go overboard but you have to do something and stay on top of updates for the tools as the product matures. Otherwise, you face the mounting costs of hordes of people trying to fix problems that you (or your team) caused. When you emerge into a leadership situation, this is the kind of tough message that you have to enforce; it won't be popular with inexperienced people from any department but it will help you build a solid career of long-term successes.
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.
Y2K was really nothing unusual for me because at the time I was at the dead end of a product line, holding up the fort while the company developed a replacement. Maintenance was my mainstay so checking and re-checking for unintended rollover effects fit right in with the plan.
Two things about my Y2K experience are worth explaining so I’ll pack ‘em both into one episode and spare you the cliffhanger.
The first of the two was something we called project Gauze. Back then we were constantly thrashing over the support call logs trying to figure out ways to reduce costs (thereby increasing profit margins) on the help desk. It is frustrating to fix defects that late in a product lifecycle because clients don’t want to incur the cost (pain) of rolling out updates, especially when they can call the helpdesk at no additional charge. Y2K updates, however, were widely anticipated to touch every installation. Governance auditors and other paperwork leeches created a fin-de-siècle culture of fear and charged big bucks to ensure compliance. If we could inject some support call fixes into the Y2K patch, it would make the whole thing have a positive impact on our customer’s experience, and our costs.
Of course there were arguments against this idea. The main one was the catch-22 scenario whereby we could poison the Y2K upgrade by introducing new insurmountable problems in the release. We fought that one off by making the whole thing modular, meaning we could pick-and-choose what to roll out. The other argument was that we needed to tell clients what we were doing, and they would say “no” to the risk. That one, like much other speculation about client responses, turned out to be unfounded. Most any client will provide a reasonable answer to a request if the person asking is trusted and empowered to do the job right.
Gauze made a huge difference. We dropped the call volumes by about 40% on a product that pretty much everyone had thought abandoned. The added stability extended the life of the product, resulting in a few more years of lucrative maintenance fees and headaches for our competitors who predicted the product’s demise prematurely. The lesson? A new idea can take hold even when hundreds of people with established processes across many departments in a big business have to be convinced. Its not easy and the idea has to pass a lot of scrutiny but stick to it and make it happen.
The second Y2K notable was fast by comparison. The CEO called for everyone to join in and sit a shift or two on the help desk as midnight rolled around the world. So much for my 1999 new year’s eve. I had taken support calls during the early days of the product but ever since it got big and was pushed into thousands of sites, the help desk operation was a complicated machine that I knew nothing about. December 31of 1999 was an eye-opening experience for me. The tools and utilities that I had written years earlier to diagnose and fix problems were still being used, bugs and all. The knowledge that I had shared with the first few people we hired full-time onto the help desk had been immortalized in a sort of repository that was consulted and interpreted quasi-religiously. Procedures that I had conceived quickly and never optimized were being repeated thousands of times with exacting detail.
It was frustrating to me that people managing the help desk would not build their own tools and improve their troubleshooting processes. But then it dawned on me that the mistake was mine. The help desk is an operation that exists to scale and implement processes with a guaranteed service level and profit margin to the business; they are not responsible for re-designing the product. Arguably they could have invested in some development but would the company have allowed it? I don’t think so because anyone doing good development would be re-assigned to work on products.
The lesson here is that you have to build in care-and-feeding tools for the runtime-operation of a product. You can’t go overboard but you have to do something and stay on top of updates for the tools as the product matures. Otherwise, you face the mounting costs of hordes of people trying to fix problems that you (or your team) caused. When you emerge into a leadership situation, this is the kind of tough message that you have to enforce; it won't be popular with inexperienced people from any department but it will help you build a solid career of long-term successes.
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.
Tuesday, March 3, 2009
Thank you Sir, may I have another?
Layoffs are all over the news lately. Just when you thought you had dodged (or survived!) outsourcing, along comes a recession. It seems like nothing is sacred.
I have been through boom and bust cycles a few times already, and I'm only 39. Its part of the way our economy works; there's some sort of Hakuna Matata comfort in this "circle of economy". But that's cold comfort when uncontrollable forces seem to be having their way with your life.
During the last big one, a cycle known as The Internet Bubble, I was managing a group of over 150 people. Our products were mature and profitable; our people were experienced and expensive. Our customers were satisfied and stable. But the advent of a new wave of web technology froze all software markets, just like the credit crunch we're in now has frozen purchases in general.
IT managers the world over demanded mature web-based solutions even though that was a contradiction in terms. Overnight we had to transform ourselves from a confident market leader into a lean, nimble startup. We could not afford all of our people. We had to maintain old solutions and invest in new ones even as budgets shrunk under the crushing silence of nobody buying anything.
It was no fun to be a software development manager then but it was a powerful time to galvanize leadership skills. I would not trade that experience for anything. It made me realize that when push came to shove, I could clearly distinguish between the contributions of any two given people if I dug in deep enough. That's what you have to do when the difference is that one stays employed and the other does not. I could also get leaders working for me to make that distinction, and I could work through the process with them to the point that I believed we were making objective decisions.
There were some key moments like when I was asked to choose between providing raises as the company had promised, or keeping everyone employed. It was clear for me then and now: the company had to get into a healthy, sustainable position which meant that we had to have motivated, well compensated people even if it meant having fewer of them. That would be the most rational decision for the most people.
I also learned that it hurts a lot more to tell someone they are laid off than to tell them they are fired. Either way, the relationship is over but when you fire someone, the net effect on the team is always an improvement. When you lay someone off, you feel like its your own fault and the team takes a big hit. Later on, nothing made me think as seriously about job offers and recruiting as the memory of those layoffs. I never wanted to hire someone that I would ever have to lay off again. So far, so good.
Many developers considering leadership are probably glad they are not making the move right now. There's no doubt that existing software managers are facing tough decisions that they never anticipated. But if you are an objective leader with no hidden agenda, now is when people need you the most. There may not be big product launches or new VP promotions but you can figure out what you're capable of achieving under the current miserable economy faster than you will ever be able to later when the music starts playing again.
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.
I have been through boom and bust cycles a few times already, and I'm only 39. Its part of the way our economy works; there's some sort of Hakuna Matata comfort in this "circle of economy". But that's cold comfort when uncontrollable forces seem to be having their way with your life.
During the last big one, a cycle known as The Internet Bubble, I was managing a group of over 150 people. Our products were mature and profitable; our people were experienced and expensive. Our customers were satisfied and stable. But the advent of a new wave of web technology froze all software markets, just like the credit crunch we're in now has frozen purchases in general.
IT managers the world over demanded mature web-based solutions even though that was a contradiction in terms. Overnight we had to transform ourselves from a confident market leader into a lean, nimble startup. We could not afford all of our people. We had to maintain old solutions and invest in new ones even as budgets shrunk under the crushing silence of nobody buying anything.
It was no fun to be a software development manager then but it was a powerful time to galvanize leadership skills. I would not trade that experience for anything. It made me realize that when push came to shove, I could clearly distinguish between the contributions of any two given people if I dug in deep enough. That's what you have to do when the difference is that one stays employed and the other does not. I could also get leaders working for me to make that distinction, and I could work through the process with them to the point that I believed we were making objective decisions.
There were some key moments like when I was asked to choose between providing raises as the company had promised, or keeping everyone employed. It was clear for me then and now: the company had to get into a healthy, sustainable position which meant that we had to have motivated, well compensated people even if it meant having fewer of them. That would be the most rational decision for the most people.
I also learned that it hurts a lot more to tell someone they are laid off than to tell them they are fired. Either way, the relationship is over but when you fire someone, the net effect on the team is always an improvement. When you lay someone off, you feel like its your own fault and the team takes a big hit. Later on, nothing made me think as seriously about job offers and recruiting as the memory of those layoffs. I never wanted to hire someone that I would ever have to lay off again. So far, so good.
Many developers considering leadership are probably glad they are not making the move right now. There's no doubt that existing software managers are facing tough decisions that they never anticipated. But if you are an objective leader with no hidden agenda, now is when people need you the most. There may not be big product launches or new VP promotions but you can figure out what you're capable of achieving under the current miserable economy faster than you will ever be able to later when the music starts playing again.
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.
Monday, February 9, 2009
Size Does Matter
There are plenty of jokes I will spare you about size and how it matters in situations where the specifics are left to the imagination. But there is a reason for the headline here, and it is concretely applicable to office, desk and ego sizes.
You have to realize first of all that am I firm believer in differentiating great people by providing them with disproportionate rewards. It helps motivate and retain effective talent, and it encourages people who are not as successful as they want to be to find a different career. When it comes to offices, anyone can get stoked about having superior digs to work from; a nice desk and a big office makes a promotion feel “real” and it’s usually fairly cheap to provide that reward.
But big desks and corner offices are not good rewards for supervisory managers. Nothing says “I am superior to you” better than being in a separate place, behind a door, with an enthroning desk configuration. It makes even simple questions seem like an income tax audit – you have to prepare, disturb someone who must be doing far more important things, secure a judgment and desperately try not to ever bring up the same point again for clarification.
Yes, of course, some managers have that kind of job – people in sensitive financial roles, or human resources, or sales. Those are functional offices – they provide privacy and security. Some technical people need to work in quiet, dark solitude; they too get my thumbs-up on the office upgrade if it means they provide great performance in return.
But when it comes to a great manager over technical operations that truly serves the team he or she leads, my suggestion is that that person should be in the middle of the fray. That’s where information can be shared at a moment’s notice, casually overheard comments can be leveraged for project optimization, the pulse of progress is immediately evident, and, most of all, people will feel rewarded because of the manager’s presence.
That last statement cannot be read too lightly. If people are willing followers of their leader, taking that leader away will make them feel worse. It will immediately reduce the value of the leader and increase the intangible cost of the inexpensive reward that was intended for him or her.
I have had several experiences that concretely agree with all of this rhetoric. The best hardware engineering manager I know has always elected to work in the center of the action. A capable senior manager who replaced me in a role I once held moved himself to a corner office as soon as he could and immediately lost control of his team, and his job. My own favorite desk ever (because my team liked it) was when I moved into the receptionist desk in the middle of the floor of people I was leading. Two of the most effective “take over a mess and fix it” leaders that I know do so by immediately converting offices into meeting rooms.
I know a few people reading this will be doing so from corner offices. I am not judging your performance. There are exceptions to every rule. But next time your team faces a crisis, consider making a move back to your roots.
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.
You have to realize first of all that am I firm believer in differentiating great people by providing them with disproportionate rewards. It helps motivate and retain effective talent, and it encourages people who are not as successful as they want to be to find a different career. When it comes to offices, anyone can get stoked about having superior digs to work from; a nice desk and a big office makes a promotion feel “real” and it’s usually fairly cheap to provide that reward.
But big desks and corner offices are not good rewards for supervisory managers. Nothing says “I am superior to you” better than being in a separate place, behind a door, with an enthroning desk configuration. It makes even simple questions seem like an income tax audit – you have to prepare, disturb someone who must be doing far more important things, secure a judgment and desperately try not to ever bring up the same point again for clarification.
Yes, of course, some managers have that kind of job – people in sensitive financial roles, or human resources, or sales. Those are functional offices – they provide privacy and security. Some technical people need to work in quiet, dark solitude; they too get my thumbs-up on the office upgrade if it means they provide great performance in return.
But when it comes to a great manager over technical operations that truly serves the team he or she leads, my suggestion is that that person should be in the middle of the fray. That’s where information can be shared at a moment’s notice, casually overheard comments can be leveraged for project optimization, the pulse of progress is immediately evident, and, most of all, people will feel rewarded because of the manager’s presence.
That last statement cannot be read too lightly. If people are willing followers of their leader, taking that leader away will make them feel worse. It will immediately reduce the value of the leader and increase the intangible cost of the inexpensive reward that was intended for him or her.
I have had several experiences that concretely agree with all of this rhetoric. The best hardware engineering manager I know has always elected to work in the center of the action. A capable senior manager who replaced me in a role I once held moved himself to a corner office as soon as he could and immediately lost control of his team, and his job. My own favorite desk ever (because my team liked it) was when I moved into the receptionist desk in the middle of the floor of people I was leading. Two of the most effective “take over a mess and fix it” leaders that I know do so by immediately converting offices into meeting rooms.
I know a few people reading this will be doing so from corner offices. I am not judging your performance. There are exceptions to every rule. But next time your team faces a crisis, consider making a move back to your roots.
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.
Tuesday, January 20, 2009
Be bold and Learn from Mistakes that Follow
Bold leadership is a sure-fire way to build loyal, willing followers. That’s certainly true in life-or-death situations, but it happens in every day office living too. People are drawn to individuals who take risks in order to challenge injustices or cut through red tape. It’s a power trip that is hard to come down from, when it works.
I had been managing for about two years when I got in full-swing enfant-terrible mode. I seemed to get more responsibility at every turn, which gave me more clout to right wrongs and kiss babies – cementing even more warriors for my loyal ranks. And I was getting good results, too, compared with my predecessors who came from various external sources, but did not know our company or products.
People would go to great lengths for me, and I would do that for them too. Once, an irate customer challenged a QA leader on my team to fly out and install our software upgrades in person so he could feel the full brunt of the pain of notoriously unstable products. I knew we had to accept this challenge but the QA leader started backpedaling, concerned that he would be ambushed at the client location, in person. So I chimed-in, saying that not only would the QA leader be there, but so would I. The customer was skeptical but when we showed up and delivered, everything was smooth and the whole client relationship regained a lot of trust and partnership. High fives all around.
My reaction was completely predictable at the time when someone on my team lost company benefits because he missed a renewal paperwork submission deadline. I expected to have a 15 second chat with someone from the appropriate group and say “My guy was working 40 hours straight because I asked him to. As a result, you and I can get paid with the money he earned for the company. Fix his paperwork problem now. Sorry about the trouble.” But it did not quite work like that. I mean, I said my part. But I was turned down. The date had passed, the benefits were lost, thanks for playing.
I was in shock. I simply could not understand (a) how someone could challenge me and (b) why they would not want to fix this problem because this employee really did deserve the benefits in question. I took it up a couple of notches but no joy – it seems the company was getting very serious about having a formal benefits process, and there were too many large financial risks with violating a policy.
My shock turned to tantrum. I resigned, saying I’d rather not be at a company that could not respect its people. What a stupid thing to do… Suddenly, what had started as late paperwork turned in to a big political problem with senior level attention.
The benefits issue was fixed immediately, my resignation was declined, and I was counseled along with other leaders to do a better job communicating. So in theory, I got what I was asking for even though I looked like a little kid having a fit in the process. It was not until afterward that I realized just how badly I had disrespected people outside of my organization. That was the real damage done in this use case. One-track Focused on the needs of someone on my team, I completely disregarded the needs of others at my company. Those relationships never recovered.
My approach was too extreme. Who works on my team, who does not. Who makes the products go, who does not. I either like everything and I stay or I quit and take my ball home when one thing goes wrong. I had absolutely no finesse or sophistication. Unfortunately, it would take a few more of those cases before the lessons set in.
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.
I had been managing for about two years when I got in full-swing enfant-terrible mode. I seemed to get more responsibility at every turn, which gave me more clout to right wrongs and kiss babies – cementing even more warriors for my loyal ranks. And I was getting good results, too, compared with my predecessors who came from various external sources, but did not know our company or products.
People would go to great lengths for me, and I would do that for them too. Once, an irate customer challenged a QA leader on my team to fly out and install our software upgrades in person so he could feel the full brunt of the pain of notoriously unstable products. I knew we had to accept this challenge but the QA leader started backpedaling, concerned that he would be ambushed at the client location, in person. So I chimed-in, saying that not only would the QA leader be there, but so would I. The customer was skeptical but when we showed up and delivered, everything was smooth and the whole client relationship regained a lot of trust and partnership. High fives all around.
My reaction was completely predictable at the time when someone on my team lost company benefits because he missed a renewal paperwork submission deadline. I expected to have a 15 second chat with someone from the appropriate group and say “My guy was working 40 hours straight because I asked him to. As a result, you and I can get paid with the money he earned for the company. Fix his paperwork problem now. Sorry about the trouble.” But it did not quite work like that. I mean, I said my part. But I was turned down. The date had passed, the benefits were lost, thanks for playing.
I was in shock. I simply could not understand (a) how someone could challenge me and (b) why they would not want to fix this problem because this employee really did deserve the benefits in question. I took it up a couple of notches but no joy – it seems the company was getting very serious about having a formal benefits process, and there were too many large financial risks with violating a policy.
My shock turned to tantrum. I resigned, saying I’d rather not be at a company that could not respect its people. What a stupid thing to do… Suddenly, what had started as late paperwork turned in to a big political problem with senior level attention.
The benefits issue was fixed immediately, my resignation was declined, and I was counseled along with other leaders to do a better job communicating. So in theory, I got what I was asking for even though I looked like a little kid having a fit in the process. It was not until afterward that I realized just how badly I had disrespected people outside of my organization. That was the real damage done in this use case. One-track Focused on the needs of someone on my team, I completely disregarded the needs of others at my company. Those relationships never recovered.
My approach was too extreme. Who works on my team, who does not. Who makes the products go, who does not. I either like everything and I stay or I quit and take my ball home when one thing goes wrong. I had absolutely no finesse or sophistication. Unfortunately, it would take a few more of those cases before the lessons set in.
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
And -Poof- Goes the Weasel
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.
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.
Subscribe to:
Posts (Atom)