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.
Thursday, November 27, 2008
The Bozo Bit
Even if you’ve never heard of it, you’ve probably had an experience with a person that caused you to flip ‘the bozo bit.’ Its an expression that means you have labeled another person as permanently incompetent. They just don’t “get it” and you have made a mental note to never let that person interfere with your success again. The bozo bit is a technical translation of the old saying “fool me once, shame on you; fool me twice, shame on me” (for not flipping the bozo bit sooner!).
The bozo bit can get in your way when you make a move into management. For one thing, you can’t afford to permanently downgrade someone on your team unless you are prepared to work with HR and other functions to remove that person permanently. And if you apply “the bit” to anyone else (peers in leadership, superiors) then you are making the assumption that you are superior to that person in every way and you will never need their support or assistance – an assumption that you are in no position to make. In fact, the usefulness of the cold, hard “on/off” bozo bit is really a reflection of your intense technical ability, where cold, hard boundaries exist between right and wrong. In many leadership situations, the line is not so clear.
I was working in a research institution in the 1980’s where my manager, a leading robotics researcher, was the first person who flipped the bozo bit on me. Sure, I struggled with the physics but he was OK with that. The bit flipping came because I betrayed his trust. I asked him if I could take a Friday off so long as I would work the following Monday, which was a holiday. He agreed, and I went out of town on a Thursday night to go see my girlfriend. Somehow when Sunday night came around, it did not seem fair that I had to go to go back to work. So I didn’t. I just skipped out on my end of the bargain, assuming no one would be the wiser because the lab would be empty for the holiday.
What I did not know is that my manager came to work on that holiday specifically to help me move my project forward. He forfeited precious visitation time (he was divorced) with his young daughter to come help me. Only I never showed up. Indeed I was deserving of the bozo bit and our relationship never recovered. I regret my stupidity to this day.
But before this turns in to an episode of “My name is Earl,” let me bring you back into the story. When you enter leadership, you have to realize that people make mistakes. Sometimes they are extremely stupid mistakes. If you manage long enough, you will come to believe that people can screw up in just about any way conceivable.
You are lucky if it’s only technical; for that, you can patch, teach and hopefully move on. If you think the problem is incorrigible, document the pattern and work the individual out of your organization. But do so in an unbiased, non-bozo-bit way. You can’t be fair to someone who you think is incompetent; they have to prove that for themselves, more than just once.
Another class of mistakes is behavioral. A whole subset of these are the domain of HR; in situations where one person’s actions impact other people’s rights, you will need to rely on good advice and leadership from them. Without too many details, some examples would be personal threats, inappropriate sexual conduct and the like. The best advice I have is to engage HR quickly and avoid discussing details with anyone, even your superiors unless directed by HR.
Some behavioral issues, like when I skipped work, are in your management scope. Other examples are expense policy violations, inappropriate use of company resources, violation of confidentiality agreements and so on. No mater how you perceive the mistake, keep your cool and leave the bozo bit off; you have to have an open mind to understand what happened and to treat the offender with dignity. You may choose to initiate harsh consequences but don’t lose control by clouding your perspective with quick, absolute decisions about complicated situations.
Be sure to get educated about your company’s official policies, and to communicate them to your team. People make enough mistakes when they are fully aware of the consequences; don’t give them the excuse of ignorance. As with most situations in life, though, there’s no substitute for judgment. The official policy won’t cover every case, and in some cases, the rules will be wrong.
A final point on this topic is that you can use simple mistakes to build loyalty. When someone does something wrong and you help them recover from it in a fair and dignified way, they will follow your leadership with intense respect. You may think you don't want their respect if the mistake is one you consider grievous but remember that your primarey role in leadership is to achieve through others. If you are unsupportive and biased, they will lose respect for you and lose productivity for the company.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
The bozo bit can get in your way when you make a move into management. For one thing, you can’t afford to permanently downgrade someone on your team unless you are prepared to work with HR and other functions to remove that person permanently. And if you apply “the bit” to anyone else (peers in leadership, superiors) then you are making the assumption that you are superior to that person in every way and you will never need their support or assistance – an assumption that you are in no position to make. In fact, the usefulness of the cold, hard “on/off” bozo bit is really a reflection of your intense technical ability, where cold, hard boundaries exist between right and wrong. In many leadership situations, the line is not so clear.
I was working in a research institution in the 1980’s where my manager, a leading robotics researcher, was the first person who flipped the bozo bit on me. Sure, I struggled with the physics but he was OK with that. The bit flipping came because I betrayed his trust. I asked him if I could take a Friday off so long as I would work the following Monday, which was a holiday. He agreed, and I went out of town on a Thursday night to go see my girlfriend. Somehow when Sunday night came around, it did not seem fair that I had to go to go back to work. So I didn’t. I just skipped out on my end of the bargain, assuming no one would be the wiser because the lab would be empty for the holiday.
What I did not know is that my manager came to work on that holiday specifically to help me move my project forward. He forfeited precious visitation time (he was divorced) with his young daughter to come help me. Only I never showed up. Indeed I was deserving of the bozo bit and our relationship never recovered. I regret my stupidity to this day.
But before this turns in to an episode of “My name is Earl,” let me bring you back into the story. When you enter leadership, you have to realize that people make mistakes. Sometimes they are extremely stupid mistakes. If you manage long enough, you will come to believe that people can screw up in just about any way conceivable.
You are lucky if it’s only technical; for that, you can patch, teach and hopefully move on. If you think the problem is incorrigible, document the pattern and work the individual out of your organization. But do so in an unbiased, non-bozo-bit way. You can’t be fair to someone who you think is incompetent; they have to prove that for themselves, more than just once.
Another class of mistakes is behavioral. A whole subset of these are the domain of HR; in situations where one person’s actions impact other people’s rights, you will need to rely on good advice and leadership from them. Without too many details, some examples would be personal threats, inappropriate sexual conduct and the like. The best advice I have is to engage HR quickly and avoid discussing details with anyone, even your superiors unless directed by HR.
Some behavioral issues, like when I skipped work, are in your management scope. Other examples are expense policy violations, inappropriate use of company resources, violation of confidentiality agreements and so on. No mater how you perceive the mistake, keep your cool and leave the bozo bit off; you have to have an open mind to understand what happened and to treat the offender with dignity. You may choose to initiate harsh consequences but don’t lose control by clouding your perspective with quick, absolute decisions about complicated situations.
Be sure to get educated about your company’s official policies, and to communicate them to your team. People make enough mistakes when they are fully aware of the consequences; don’t give them the excuse of ignorance. As with most situations in life, though, there’s no substitute for judgment. The official policy won’t cover every case, and in some cases, the rules will be wrong.
A final point on this topic is that you can use simple mistakes to build loyalty. When someone does something wrong and you help them recover from it in a fair and dignified way, they will follow your leadership with intense respect. You may think you don't want their respect if the mistake is one you consider grievous but remember that your primarey role in leadership is to achieve through others. If you are unsupportive and biased, they will lose respect for you and lose productivity for the company.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Saturday, November 22, 2008
A tale of Two LCD’s
I don’t have any evidence of this but I suspect that software developers were the first big market for the dual monitor configuration that became possible with Windows XP. Before I get a hundred emails about arcane OSs that supported two monitors already in 1972, let me acknowledge the few and brave who were around when those platforms were in vogue. You are acknowledged. And now I’ll move back to my story, which is when most of the rest of us were first exposed to the more-than-one-screen idea.
I was leading a small team, working at a vertical industry software/hardware supplier at the time. I only had three developers on my team so I requested three LCD’s from the IT department – one extra for each developer. This should have been a no-brainer; screens were cheap compared to just about any other upgrade. Everyone was psyched about the new monitors and for once it seemed I could afford something meaningful for every single person on the team.
Request denied. I could not have the monitors. There was no budget for monitors. The IT department had committed the hardware budget to our PC vendor so I could have new PC’s (even the ever-sought high-end laptops for me!) but not monitors. And if IT broke the rules for me, they would have to break the rules for everyone else, resulting in a huge budget problem. Read my lips: no new monitors.
But I did not need new PC’s. My team was fairly new and we had decent PC’s. I could not be bribed with a new laptop when the guys were expecting me to walk in like Santa Claus (fill in your gift-giving cultural fabrication of choice if you don’t believe in Santa) with a sack full of monitors. And anyway, I could not stand for spending more to get a lesser productivity impact. I needed monitors.
Escalating the situation only made things worse. It seems the IT manager had built up an impressive discount with the PC supplier by committing a higher and higher budget to them every year. And now he was unwilling to put that relationship on the table for some pesky developers. Losing even a tenth of a point of discount would mean tens of thousands of dollars. Case closed.
Sheer madness, I thought. How could they forget that the developers made the product that made the money that made the profits that made the budget happen to begin with? And weren’t the PC suppliers our vendor, to be toyed with just as our clients toyed with us? I went to the local superstore and walked out with 3 brand-spanking new monitors, for a total of about $500. The expense report was filed before lunchtime, which is about when the guys had their monitors in place, doubling their visual real estate and quadrupling productivity – or so I hoped.
It did not take long for IT to notice the new screens. Not a good scene. It seems the monitors would have to be removed because they were not official. They could not be insured because they lacked inventory stickers. They could not be supported because they were not from an authorized brand. They could not be properly depreciated because they were not purchased through the proper process. No problem I said… each of the developers got a small bonus and used it to buy a screen which is now his personal property. They each chose to keep their new screen to work. No depreciation, inventory, insurance or support would be needed. Thanks for asking.
Ultimately we did get to keep the monitors and I know I was right on this one, but there are subtleties to the story. This really was a special circumstance because few things will ever have the benefit provided by more screen space at such a low cost. And few things need as little support as a screen. The fact is that in a lot of cases, the IT guys would have been right. Most anything else that I would have wanted would have required them to configure and support new equipment, which means that my cavalier approach would have created real costs for someone else’s team.
What I regret the most however, is that I did not act more decisively. By dragging this out too long, I burnt some relationships with people who were just doing their jobs by telling me ‘no.’ I should have found a way to make them successful while making me successful rather than jousting with them like a toddler in a tantrum. After all, if getting the monitors was the right thing to do and it was that important to do it, I should have been able to get the company to make the right choice by making new rules, not breaking old ones.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
I was leading a small team, working at a vertical industry software/hardware supplier at the time. I only had three developers on my team so I requested three LCD’s from the IT department – one extra for each developer. This should have been a no-brainer; screens were cheap compared to just about any other upgrade. Everyone was psyched about the new monitors and for once it seemed I could afford something meaningful for every single person on the team.
Request denied. I could not have the monitors. There was no budget for monitors. The IT department had committed the hardware budget to our PC vendor so I could have new PC’s (even the ever-sought high-end laptops for me!) but not monitors. And if IT broke the rules for me, they would have to break the rules for everyone else, resulting in a huge budget problem. Read my lips: no new monitors.
But I did not need new PC’s. My team was fairly new and we had decent PC’s. I could not be bribed with a new laptop when the guys were expecting me to walk in like Santa Claus (fill in your gift-giving cultural fabrication of choice if you don’t believe in Santa) with a sack full of monitors. And anyway, I could not stand for spending more to get a lesser productivity impact. I needed monitors.
Escalating the situation only made things worse. It seems the IT manager had built up an impressive discount with the PC supplier by committing a higher and higher budget to them every year. And now he was unwilling to put that relationship on the table for some pesky developers. Losing even a tenth of a point of discount would mean tens of thousands of dollars. Case closed.
Sheer madness, I thought. How could they forget that the developers made the product that made the money that made the profits that made the budget happen to begin with? And weren’t the PC suppliers our vendor, to be toyed with just as our clients toyed with us? I went to the local superstore and walked out with 3 brand-spanking new monitors, for a total of about $500. The expense report was filed before lunchtime, which is about when the guys had their monitors in place, doubling their visual real estate and quadrupling productivity – or so I hoped.
It did not take long for IT to notice the new screens. Not a good scene. It seems the monitors would have to be removed because they were not official. They could not be insured because they lacked inventory stickers. They could not be supported because they were not from an authorized brand. They could not be properly depreciated because they were not purchased through the proper process. No problem I said… each of the developers got a small bonus and used it to buy a screen which is now his personal property. They each chose to keep their new screen to work. No depreciation, inventory, insurance or support would be needed. Thanks for asking.
Ultimately we did get to keep the monitors and I know I was right on this one, but there are subtleties to the story. This really was a special circumstance because few things will ever have the benefit provided by more screen space at such a low cost. And few things need as little support as a screen. The fact is that in a lot of cases, the IT guys would have been right. Most anything else that I would have wanted would have required them to configure and support new equipment, which means that my cavalier approach would have created real costs for someone else’s team.
What I regret the most however, is that I did not act more decisively. By dragging this out too long, I burnt some relationships with people who were just doing their jobs by telling me ‘no.’ I should have found a way to make them successful while making me successful rather than jousting with them like a toddler in a tantrum. After all, if getting the monitors was the right thing to do and it was that important to do it, I should have been able to get the company to make the right choice by making new rules, not breaking old ones.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Wednesday, November 12, 2008
I can’t hear you. There’s a banana in my ear!
I was working with a help desk leader who was struggling with the onslaught of tech support calls for a new product. Sure, the software was alpha-quality with plenty of nasty bugs but every single call was taking way too long to solve. Most of the problems were manifestations of the same core issue and could be fixed with a quick work-around. After I helped with a few of the call resolutions myself, I knew the problem was training. The help desk did not know the new product or any of the technology behind it. Never mind the methodology and process that could have prevented that; this was a startup. Of course we would eventually resolve many of the issues but sales were brisk and the next release was a few weeks away. The help desk needed to deal with the issues faster, even if only for a while.
I assembled a makeshift training course on the ints-and-outs (pun intended) of the new software and offered to train the help desk in a series of emergency sessions. We would give them a crash course in what-to-do-when and everything would be fine. With goodwill and a powerpoint deck, I met with my counterpart on the help desk leadership team.
The answer was “no”. More specifically, the help desk had no time for training because they were too busy. In fact they had just had to cancel training on the new benefits package because they were too busy with a lot of really long support calls that were coming in from the new product. If I wanted to help, I was told, I could come take some more support calls – or better yet, send the developers down to take support calls.
Remember ‘Sesame Street’? I distinctly remember an episode where either Bert or Ernie kept trying to talk on the phone and saying “I can’t hear you, there’s a Banana in my ear” while the other guy was at trying to tell him “take the banana out of your ear so I can talk to you.”
That’s what it feels like sometimes when you are trying to get people trained. They are too busy to get training on how to do their jobs more effectively. Too busy to learn products, too busy to learn tools. Too busy to be effective.
Of course my help desk counterpart did not intend to be stupid. She wanted to follow procedure, complete her role in an orderly fashion and do all the things that a help desk manager has to do when dealing with a deployed product. What she failed to realize is that we were not dealing with a mature piece of software; we were dealing with the shortcomings of a hasty release and we needed to bend the rules a little. What I failed to realize is just how important rules are in an environment like technical support or manufacturing (or shipping, I suppose, but I don’t have experience there yet) where the process is the job. I was basically telling this person to come learn some skills that would allow her people to perform work that was not really within their responsibilities.
The whole thing was out of whack. Years later I would understand that this was a violation of one of the parity principles of leadership. The help desk team was responsible for the success of the product in the field without having the authority to command resources that would make it successful. They could not stop the product from being deployed because they did not control QA. They were not trained on the product because it had not passed the right quality gate to require training the help desk (yes, even though it was being sold with clients fully aware of its quality level – thank you SOX). They could not demand that developers, who knew how the product worked, take the support calls.
If I had articulated it in this way to the help desk VP, the training I wanted to provide would have been initiated immediately. Instead, I got frustrated because the product my team had worked so hard to build was looking bad in the field. I actually accused the help desk manager of “not caring” and that’s when I realized that she had as much passion and pride of workmanship as I. Her challenge to me was to ask how it could be that we had created such poor software. We did not make poor software but we did release it half-baked because of pressure from above, and I knew it.
We muddled through the next few weeks, basically doing OJT by having developers suffer through support calls with technicians assisting at first, then flying solo. It is probably better that we did not do a quick training and wash our hands because the developers got to feel the pain of bugs in configuration apps that are too complex or quirky UI flags. We all pulled the bananas out of our ears and communicated until a patch smoothed things out. Then we went back to our functional silos and put them right back 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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
I assembled a makeshift training course on the ints-and-outs (pun intended) of the new software and offered to train the help desk in a series of emergency sessions. We would give them a crash course in what-to-do-when and everything would be fine. With goodwill and a powerpoint deck, I met with my counterpart on the help desk leadership team.
The answer was “no”. More specifically, the help desk had no time for training because they were too busy. In fact they had just had to cancel training on the new benefits package because they were too busy with a lot of really long support calls that were coming in from the new product. If I wanted to help, I was told, I could come take some more support calls – or better yet, send the developers down to take support calls.
Remember ‘Sesame Street’? I distinctly remember an episode where either Bert or Ernie kept trying to talk on the phone and saying “I can’t hear you, there’s a Banana in my ear” while the other guy was at trying to tell him “take the banana out of your ear so I can talk to you.”
That’s what it feels like sometimes when you are trying to get people trained. They are too busy to get training on how to do their jobs more effectively. Too busy to learn products, too busy to learn tools. Too busy to be effective.
Of course my help desk counterpart did not intend to be stupid. She wanted to follow procedure, complete her role in an orderly fashion and do all the things that a help desk manager has to do when dealing with a deployed product. What she failed to realize is that we were not dealing with a mature piece of software; we were dealing with the shortcomings of a hasty release and we needed to bend the rules a little. What I failed to realize is just how important rules are in an environment like technical support or manufacturing (or shipping, I suppose, but I don’t have experience there yet) where the process is the job. I was basically telling this person to come learn some skills that would allow her people to perform work that was not really within their responsibilities.
The whole thing was out of whack. Years later I would understand that this was a violation of one of the parity principles of leadership. The help desk team was responsible for the success of the product in the field without having the authority to command resources that would make it successful. They could not stop the product from being deployed because they did not control QA. They were not trained on the product because it had not passed the right quality gate to require training the help desk (yes, even though it was being sold with clients fully aware of its quality level – thank you SOX). They could not demand that developers, who knew how the product worked, take the support calls.
If I had articulated it in this way to the help desk VP, the training I wanted to provide would have been initiated immediately. Instead, I got frustrated because the product my team had worked so hard to build was looking bad in the field. I actually accused the help desk manager of “not caring” and that’s when I realized that she had as much passion and pride of workmanship as I. Her challenge to me was to ask how it could be that we had created such poor software. We did not make poor software but we did release it half-baked because of pressure from above, and I knew it.
We muddled through the next few weeks, basically doing OJT by having developers suffer through support calls with technicians assisting at first, then flying solo. It is probably better that we did not do a quick training and wash our hands because the developers got to feel the pain of bugs in configuration apps that are too complex or quirky UI flags. We all pulled the bananas out of our ears and communicated until a patch smoothed things out. Then we went back to our functional silos and put them right back 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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Tuesday, November 4, 2008
Office Politics
Office politics can be the source of a lot of angst for new managers, especially those who think about the world in an objective and technical way. For better or worse, real people in leadership roles have biases and alliances, differing agendas and even more divergent opinions. The result can often be what appears as nonsensical behavior, where the same circumstances result in different reactions on different days. What’s worse, the actions observed can appear to contradict corporate policies and objectives, undermining the hard work and sacrifice that leaders must ask of their teams.
Of course, sometimes these negative appearances are just as they seem – people behaving badly with motivation that is not transparent. Those people are always going to be difficult to work with and they will eventually get what they deserve. But more often than not, no one intends to do wrong or even to behave erratically. In these cases, perspective and priorities can make all the difference.
Consider a department that is struggling to meet a deadline on a lucrative contract. Leaders in that group will be directed to spare little expense in the mission to achieve the deadline. Overtime, bonuses, recruiting incentives, new equipment and minor extravagances will be tolerated. At the same time, the company as a whole may be underperforming and a different group could be under pressure to fire low performers, offer low raises and get by with old equipment. In both cases, the objective of the company is to improve its financial performance but the circumstances in different departments create different priorities for the leaders on the ground.
Two new leaders in these departments would each perceive the other negatively even though both of them were operating rationally toward the same overall company goals. Instructed to meet a deadline, the first manager will focus on the fact that his team must work very hard while other teams are not as focused. Denied equipment upgrades, the second manager will wonder what relationships and special contacts are needed.
Imagine a company memo that would go to each employee from the chairman explaining who is on an important project and who is on a maintenance project, who is performing better and who is performing worse, which segments of the economy support growth and which segments are going to be laggards, etc. This memo would provide each person with objective information and in that light, most of the decisions made for most of the departments would all fall into line and make sense to everyone. But many people would be insulted by such a communication because they would take offense at their ranking, the relevance of their role and their outlook for growth. The memo would be destructive to the company and could never be sent.
The manager’s role is critical in bridging the gap between cold, hard facts about how a business is run and the emotional psyche of the people who make the business function each day. Many of the challenges offered to managers are ambiguous balancing exercises that must be carried out over time rather than solved once and for good. In doing so, occasional disagreements with other leaders will necessarily come about. In fact, the tension of discord is sometimes referred to as a healthy pressure which ensures that leaders are working to their fullest abilities.
This political jousting is uncomfortable for new managers minted from the technical ranks because they are used to arguing on facts and logic instead of emotion and bravado. Nonetheless, capable leaders will learn to sort through these situations and use them to establish stronger relationships of trust and respect with other departments. In the early days, remember not to take any situation personally and not to dwell on what’s already done. Write down the lessons learned and move on.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Of course, sometimes these negative appearances are just as they seem – people behaving badly with motivation that is not transparent. Those people are always going to be difficult to work with and they will eventually get what they deserve. But more often than not, no one intends to do wrong or even to behave erratically. In these cases, perspective and priorities can make all the difference.
Consider a department that is struggling to meet a deadline on a lucrative contract. Leaders in that group will be directed to spare little expense in the mission to achieve the deadline. Overtime, bonuses, recruiting incentives, new equipment and minor extravagances will be tolerated. At the same time, the company as a whole may be underperforming and a different group could be under pressure to fire low performers, offer low raises and get by with old equipment. In both cases, the objective of the company is to improve its financial performance but the circumstances in different departments create different priorities for the leaders on the ground.
Two new leaders in these departments would each perceive the other negatively even though both of them were operating rationally toward the same overall company goals. Instructed to meet a deadline, the first manager will focus on the fact that his team must work very hard while other teams are not as focused. Denied equipment upgrades, the second manager will wonder what relationships and special contacts are needed.
Imagine a company memo that would go to each employee from the chairman explaining who is on an important project and who is on a maintenance project, who is performing better and who is performing worse, which segments of the economy support growth and which segments are going to be laggards, etc. This memo would provide each person with objective information and in that light, most of the decisions made for most of the departments would all fall into line and make sense to everyone. But many people would be insulted by such a communication because they would take offense at their ranking, the relevance of their role and their outlook for growth. The memo would be destructive to the company and could never be sent.
The manager’s role is critical in bridging the gap between cold, hard facts about how a business is run and the emotional psyche of the people who make the business function each day. Many of the challenges offered to managers are ambiguous balancing exercises that must be carried out over time rather than solved once and for good. In doing so, occasional disagreements with other leaders will necessarily come about. In fact, the tension of discord is sometimes referred to as a healthy pressure which ensures that leaders are working to their fullest abilities.
This political jousting is uncomfortable for new managers minted from the technical ranks because they are used to arguing on facts and logic instead of emotion and bravado. Nonetheless, capable leaders will learn to sort through these situations and use them to establish stronger relationships of trust and respect with other departments. In the early days, remember not to take any situation personally and not to dwell on what’s already done. Write down the lessons learned and move on.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Monday, October 27, 2008
How to be perfect (hint: just re-define 'perfect')
I was assigned to work closely with a very capable technical leader. I looked forward to my first meeting with him when I would have the chance to go through my usual on-boarding process. That normally consists of finding out what a new team member's goals and ambitions are, where they think they fit in to the organization and what they want from me as their manager. Sometimes these discussions are simple and sometimes they can be very complex, dragging out over a period of weeks. Regardless, they are always useful and productive.
This particular leader was clearly seen by others in the department and by the entire regional office as a respected expert. He had experience to match that respect; he knew our products and industry well. But in our ramp-up discussions, he raised the issue of emerging as a full-fledged personnel manager. He was tired of his limited technical role and wanted more. He was tired of never having the last word in broad meetings where technical issues were just part of the problem.
We discussed the ins-and-outs of the management role and my perception of what might limit his success. He pledged to work on those areas and our discussions continued. At first he continued to do a great job as a technical lead, exceeding my expectations for his ability to adapt toward better interpersonal communication and teamwork.
When we began to discuss his first management role, he embraced it enthusiastically. Everything seemed aligned so we formed a small team for him and kicked off a project. Nearly immediately, however, things started to unravel. Two people from his team approached me to escalate concerns about their assignments and the plan their new leader had set out for them. The new leader himself began working extreme hours and still could not keep up. He also began complaining about some parts of the management role which he felt were beneath his skills. He requested that a project manager be assigned to his team so he could delegate work to them.
My style is to be very direct with management issues but he was imploding faster than I could schedule feedback discussions. The situation was caustic as he blamed me for the issues and wanted more time, but I needed to take swift action in order to avert an employee and project disaster. He proposed a solution that brought the situation into perspective. Basically, he felt that his responsibility for non-technical issues was a bad use of his time, but that as technical leader, he had previously not had enough responsibility. So I should make him the leader over the entire department, with delegate resources to handle the areas where he fell short personally. In essence, if the role were perfect for him, he would be perfect for the role.
Faced with a tough technical problem, he would never have tried to re-define the constraints just to make his life easier. But that's exactly what he was doing in his first leadership role. It is meaningless to say that you perform well in a role so long as it is a role that you perform well. The whole point of the leader is to bring the team together, filling-in the gaps between them; that is not possible when the leader's role is stiffly defined in a hierarchical dominant fashion for others to align around.
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.
This particular leader was clearly seen by others in the department and by the entire regional office as a respected expert. He had experience to match that respect; he knew our products and industry well. But in our ramp-up discussions, he raised the issue of emerging as a full-fledged personnel manager. He was tired of his limited technical role and wanted more. He was tired of never having the last word in broad meetings where technical issues were just part of the problem.
We discussed the ins-and-outs of the management role and my perception of what might limit his success. He pledged to work on those areas and our discussions continued. At first he continued to do a great job as a technical lead, exceeding my expectations for his ability to adapt toward better interpersonal communication and teamwork.
When we began to discuss his first management role, he embraced it enthusiastically. Everything seemed aligned so we formed a small team for him and kicked off a project. Nearly immediately, however, things started to unravel. Two people from his team approached me to escalate concerns about their assignments and the plan their new leader had set out for them. The new leader himself began working extreme hours and still could not keep up. He also began complaining about some parts of the management role which he felt were beneath his skills. He requested that a project manager be assigned to his team so he could delegate work to them.
My style is to be very direct with management issues but he was imploding faster than I could schedule feedback discussions. The situation was caustic as he blamed me for the issues and wanted more time, but I needed to take swift action in order to avert an employee and project disaster. He proposed a solution that brought the situation into perspective. Basically, he felt that his responsibility for non-technical issues was a bad use of his time, but that as technical leader, he had previously not had enough responsibility. So I should make him the leader over the entire department, with delegate resources to handle the areas where he fell short personally. In essence, if the role were perfect for him, he would be perfect for the role.
Faced with a tough technical problem, he would never have tried to re-define the constraints just to make his life easier. But that's exactly what he was doing in his first leadership role. It is meaningless to say that you perform well in a role so long as it is a role that you perform well. The whole point of the leader is to bring the team together, filling-in the gaps between them; that is not possible when the leader's role is stiffly defined in a hierarchical dominant fashion for others to align around.
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, October 19, 2008
What Not to Do with a Video Cable
I had an employee once who was setting up a test system for an important project. This person was not a junior engineer; in fact, the person was recommended highly and transferred temporarily at great expense to my group because of reported effectiveness.
After a couple of days of setup, I looked in on the progress and found out that there had been a snag. Additional people would be needed and it could be resolved in a day or two. I approved and made the assignments so it could get done.
At the end of that first week, there was one specific issue still outstanding. Now keep in mind that all of this is in the setup for the project, not in the project itself. The one issue outstanding would require us to ship hardware across continents to fix. I recommended a few things to try while the hardware shipment was underway.
Another week went by and the emergency shipment of hardware arrived just in time for a progress review. Still no-go; the system was not working. At this point, nothing was beyond my suspicion and frankly, I was mad. I was having to report that we could not even start this project and all the resources I had applied were not helping.
So I visited the lab. I poked around the system and within 3 minutes (it was just that long -I wish I were exaggerating) I discovered that they had a video cable where a serial cable should be. It was a DB9 cable for those who care; the old-school monochrome CRT's had a DB9 connector and so did the second version of PC serial ports. The connectors were the same but the cables were not.
Another two minutes to find a decent serial cable and test it... everything worked. I went from mad to nuts... why had nobody realized it was the wrong cable? Why had nobody tried a different cable just for the hell of it while they waited a week for new hardware? Why had all of my resources yielded nothing? Why do I have to do everything myself?
I behaved badly. I was frustrated, and it showed. This would have been a great opportunity to teach people, regardless of seniority, about how to diagnose this kind of problem. How to separate hardware from software issues. How to troubleshoot a big system. All sorts of things could have been taught. But I taught them something different.
By getting angry, I taught them to avoid telling me what was really happening in their work. I taught them to avoid any opportunity for me to enter their workspace. I taught them to avoid getting on another project where I might judge their ability to do exactly what I would do instead of measuring their ability to show a balanced blend of many different skills including teamwork, client focus and camaraderie.
I should have been in the lab more - I might have even spotted the problem a full two weeks earlier. I should have talked more in-depth about the problem and asked the right leading questions to exhaust silly things like bad cables. I should have celebrated finding the solution rather than getting angry when the trouble was over.
The funny thing is that no mater who I blamed for the problem, it was my responsibility. I was entrusted with the people and the goals. If I managed well or poorly, made good or bad things happen, it was all mine. So I might tell myself that the people involved should have known better and that other people would not have failed me but the fact is I picked them and made the assignment. I gave them two weeks of rope and carte-blanche resources. In retrospect, I really had no idea what they were doing - which means that, as the manager, I had no idea what I was doing.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
After a couple of days of setup, I looked in on the progress and found out that there had been a snag. Additional people would be needed and it could be resolved in a day or two. I approved and made the assignments so it could get done.
At the end of that first week, there was one specific issue still outstanding. Now keep in mind that all of this is in the setup for the project, not in the project itself. The one issue outstanding would require us to ship hardware across continents to fix. I recommended a few things to try while the hardware shipment was underway.
Another week went by and the emergency shipment of hardware arrived just in time for a progress review. Still no-go; the system was not working. At this point, nothing was beyond my suspicion and frankly, I was mad. I was having to report that we could not even start this project and all the resources I had applied were not helping.
So I visited the lab. I poked around the system and within 3 minutes (it was just that long -I wish I were exaggerating) I discovered that they had a video cable where a serial cable should be. It was a DB9 cable for those who care; the old-school monochrome CRT's had a DB9 connector and so did the second version of PC serial ports. The connectors were the same but the cables were not.
Another two minutes to find a decent serial cable and test it... everything worked. I went from mad to nuts... why had nobody realized it was the wrong cable? Why had nobody tried a different cable just for the hell of it while they waited a week for new hardware? Why had all of my resources yielded nothing? Why do I have to do everything myself?
I behaved badly. I was frustrated, and it showed. This would have been a great opportunity to teach people, regardless of seniority, about how to diagnose this kind of problem. How to separate hardware from software issues. How to troubleshoot a big system. All sorts of things could have been taught. But I taught them something different.
By getting angry, I taught them to avoid telling me what was really happening in their work. I taught them to avoid any opportunity for me to enter their workspace. I taught them to avoid getting on another project where I might judge their ability to do exactly what I would do instead of measuring their ability to show a balanced blend of many different skills including teamwork, client focus and camaraderie.
I should have been in the lab more - I might have even spotted the problem a full two weeks earlier. I should have talked more in-depth about the problem and asked the right leading questions to exhaust silly things like bad cables. I should have celebrated finding the solution rather than getting angry when the trouble was over.
The funny thing is that no mater who I blamed for the problem, it was my responsibility. I was entrusted with the people and the goals. If I managed well or poorly, made good or bad things happen, it was all mine. So I might tell myself that the people involved should have known better and that other people would not have failed me but the fact is I picked them and made the assignment. I gave them two weeks of rope and carte-blanche resources. In retrospect, I really had no idea what they were doing - which means that, as the manager, I had no idea what I was doing.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Typical
Software, while wildly successful as a commercial product, is an incredibly young discipline. The tools of the trade are just barely starting to take shape when compared to many other disciplines in medicine, engineering, law, or government. Software has drawn mathematicians and engineers, tinkerers (with their own special name in software, hackers)—even artists. The work itself is a combination of these skills—art and engineering in software design and architecture; detective work, forensics and problem solving in debugging; modules assembled like so many bricks and sticks of a builder. Any one of these fields of work has a tradition of established hierarchy and career path, via fellowships or tenure in academics, apprenticeships in the trades or hierarchical promotion in engineering.
Here is a relatively standard perspective toward “management” from an evolving software professional:
Working Lead
· Performs the same function as everyone else on the team, with some time allotted to leadership functions
· Handles escalations from within the team and mentors team members
· Responsible for schedule commitments made by everyone on the team
Technical Lead
· Responsible for directing technical decisions for everyone on the team
· Go-to person during design and requirements crises
Manager
· People “report to” you for formal human resources issues (compensation, promotion, etc.)
· Review performance of team members
· Interview new team members
· Report to superiors on entire team’s performance against goals and budgets
The manager’s role is to serve the team by making sure that their needs are met, which includes providing a steady stream of well-formulated tasks, suitable to the skills and experience level of the recipient and prioritized by the business. The job is a continuous stream of decisions and communication that can be intensely exhausting at first, especially if done well. The business pressure comes in the form of large projects, which are often ambiguously defined. The manager’s role is to divide and conquer. How he or she chooses to do this will mean the difference between success and 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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Here is a relatively standard perspective toward “management” from an evolving software professional:
- Early career: I don’t know what is good or bad about my managers.
- Intermediate: I know what I like and what I don’t like, but I am not ready to try to do better than the professional managers around me.
- Midcareer: I could manage better if “they” would put me in charge.
- Every day after that: I should have tried to be in charge, but I’m too busy.
Working Lead
· Performs the same function as everyone else on the team, with some time allotted to leadership functions
· Handles escalations from within the team and mentors team members
· Responsible for schedule commitments made by everyone on the team
Technical Lead
· Responsible for directing technical decisions for everyone on the team
· Go-to person during design and requirements crises
Manager
· People “report to” you for formal human resources issues (compensation, promotion, etc.)
· Review performance of team members
· Interview new team members
· Report to superiors on entire team’s performance against goals and budgets
The manager’s role is to serve the team by making sure that their needs are met, which includes providing a steady stream of well-formulated tasks, suitable to the skills and experience level of the recipient and prioritized by the business. The job is a continuous stream of decisions and communication that can be intensely exhausting at first, especially if done well. The business pressure comes in the form of large projects, which are often ambiguously defined. The manager’s role is to divide and conquer. How he or she chooses to do this will mean the difference between success and 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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Leadership at a Startup
Every software start-up is truly a unique enterprise. Nowhere else can so many people create value with nothing but their own potential and a small amount of capital (generally, for pizza and computers). Of course, it’s also very easy to lose the value before it grows, as when you run out of pizza money before anyone likes what you’ve done. But the point of this is that start-up companies are usually a “non-management” environment. It’s not a matter of intense management or lax management; it’s loosely coordinated management anarchy:
- If there is still money, you work doing whatever you do that adds value.
- If there is no money, not a lot changes except that you have to decide if you’re willing to work for nothing for a while.
The idea is that if it all works out eventually, there will be money to create organizations and so on. Because you were there early, you’ll skip all the levels of bureaucracy at Dilbert®-style companies that already got old. Maybe…
Working at a software start-up is like concentrating time. You can focus on exactly what you are best at doing, which is how we experienced it. (Both authors went through it at different companies on different continents but the experience was the same!) Most software professionals have experienced some form of crunch time—the variable seems to be only how long it lasted. In a relatively short period of time, you get good with the tools at hand, translating school knowledge into tech magic. When the bag of tricks runs out but there’s still more intensity needed, you learn to research and expand yourself in real time. You find the state of the art for your specific task and immerse yourself in it. Feeling powerful and sharp, you take on bigger and bigger jobs, shunning the suggestion that someone else should be brought in to help, assuming that’s even possible. A few late nights and some weekends is all you need to stay on schedule. You are now a hero—irreplaceable, self-sacrificing, revered, and respected.
Before you even realize it, though, you are burning out. Skills are evolving, but technology is mutating right under your nose and you can’t change fast enough. There are no more hours in the day that you can work, and you are already as good as it gets with the tools at hand. The light at the end of the tunnel gets further away, and you need help! One answer, a very good one in fact, is for you to find a way to scale your abilities. Learn to achieve more through 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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Runaway Pattern
There’s a runaway pattern of holding strong software developers in key technical positions while befuddled managers do nearly everything else incorrectly. It’s not quite that bad, but Dilbert® cartoons would not be popular if something were not fundamentally wrong in the software development industry. You can be part of the solution, but you have to decide to make your move.
The capabilities of a software manager, broadly, are two. First is functional or technical leadership ability within a domain of knowledge related to the work that is being managed. The second is the will to lead people. These are complementary abilities—they support and build on each other as your abilities grow. Still, for most people, one or the other of these will be stronger, and that one will generally set the tone of your management career. The simplest way to see this is the ultimate evolution of these capabilities into the chief technology officer (functional leader over technology direction) and chief operations officer (usually responsible for most of the people who execute day-to-day business). Both of these chief roles require a strong capability to lead, but they arise as distinct abilities and strengths in a career.
As a manager, you can outperform many others who use the concept of evolving design incorrectly. They do not understand the technology well enough to evaluate the feasibility of a solution to an obstacle. Without the power of technical aptitude and experience, they direct their teams to get started, hoping everything will work out. These managers passionately direct their teams toward goals that will never be achieved, destroying confidence and value until the effort is abandoned. Technical competence, on the other hand, allows you to know what should be possible (and the caveats to express it properly), and what is impossible no matter how well things go.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
The capabilities of a software manager, broadly, are two. First is functional or technical leadership ability within a domain of knowledge related to the work that is being managed. The second is the will to lead people. These are complementary abilities—they support and build on each other as your abilities grow. Still, for most people, one or the other of these will be stronger, and that one will generally set the tone of your management career. The simplest way to see this is the ultimate evolution of these capabilities into the chief technology officer (functional leader over technology direction) and chief operations officer (usually responsible for most of the people who execute day-to-day business). Both of these chief roles require a strong capability to lead, but they arise as distinct abilities and strengths in a career.
As a manager, you can outperform many others who use the concept of evolving design incorrectly. They do not understand the technology well enough to evaluate the feasibility of a solution to an obstacle. Without the power of technical aptitude and experience, they direct their teams to get started, hoping everything will work out. These managers passionately direct their teams toward goals that will never be achieved, destroying confidence and value until the effort is abandoned. Technical competence, on the other hand, allows you to know what should be possible (and the caveats to express it properly), and what is impossible no matter how well things go.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Cach and Cachet
The highest paid people in most companies are in management. The rewards for managers arrive slowly, but they pile on for years. The work is very hard, complicated, and frustrating! The stakes are high: you will be rewarded not only by those above you, who appreciate your achievements and feel comfortable giving you bigger tasks, but also by your team, who feel they owe you much of their success because of the opportunities you created for them.
Even if your cash compensation is sufficient, you may feel unappreciated at work when your pay raises are lower than you believe they should be. For technical people, compensation clearly is linked to ability but also to market rates for the ability in question—when more people are available to do the work, companies can afford to pay less. The converse, of course, is also true. For management functions, the environment is more dynamic. Great managers are highly valued and paid with “retention” packages that are intended to keep their focus away from any new job opportunities. But the path from being a developer to a member of senior management is a long and uncertain one.
A second important factor related to cash is not only your ambition but that of your family and other dependents. Cash is the dominant term in the perceived rewards that you take home. You will feel disrespected and unappreciated if your role is unable to provide sufficient cash to meet their needs, which will ultimately challenge you to consider your role and even your choice of employers. If you are honest with yourself about these needs, then your career ambitions will align properly with the roles you seek and the kind of company where you are engaged.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
The Box
You can think of the entire product development process, from concept to final testing and documentation, as a black box. The box takes in requirements and produces, via engineering and scientific principles, a product. This box can operate more or less efficiently and more or less reliably. The black box can create a lot of adverse by-products (angry beta users, burnt-out development teams) or useful by-products (well-honed teams, beta customer references, mature processes, and reusable platforms). But these are secondary results and not the true purpose for which the box was put to work.
Every emerging manager works inside the box at first, handling specific tasks and paying little attention to anyone else’s work. But curiosity or ambition or sheer luck occasionally turns the budding manager’s focus to other parts of the environment where unusual things are happening.
Other individuals are doing their own work—not all at the same pace or with the same skill. Other teams are organized differently, and these differences appear to impact how people feel and how well they do their jobs. At first, these are simply mental notes or casual observations. The patterns that define the effectiveness of the box seem to be random and chaotic; as such, they are uninteresting phenomena because they cannot be controlled by technical efforts.
Still, something is following a pattern. Everyone who works for a certain manager seems to be happier than everyone else. Certain products don’t seem to have as many problems as others. People on some teams are well known in the company, while no one has even heard of other teams. Like with any system, more information is needed before the pattern can be discovered. Under tight deadlines and peer pressure to master new technology, the discovery of the management pattern remains a distant curiosity. For some, the need to master the pattern never matures into action. For others, there’s a shortcut: go outside the box.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Every emerging manager works inside the box at first, handling specific tasks and paying little attention to anyone else’s work. But curiosity or ambition or sheer luck occasionally turns the budding manager’s focus to other parts of the environment where unusual things are happening.
Other individuals are doing their own work—not all at the same pace or with the same skill. Other teams are organized differently, and these differences appear to impact how people feel and how well they do their jobs. At first, these are simply mental notes or casual observations. The patterns that define the effectiveness of the box seem to be random and chaotic; as such, they are uninteresting phenomena because they cannot be controlled by technical efforts.
Still, something is following a pattern. Everyone who works for a certain manager seems to be happier than everyone else. Certain products don’t seem to have as many problems as others. People on some teams are well known in the company, while no one has even heard of other teams. Like with any system, more information is needed before the pattern can be discovered. Under tight deadlines and peer pressure to master new technology, the discovery of the management pattern remains a distant curiosity. For some, the need to master the pattern never matures into action. For others, there’s a shortcut: go outside the box.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Leadership is a complex problem
Learn the business of your product. How does it fit into the operations of its ultimate users? Is it a productivity tool or a part of their sellable product? Does it automate a process between people or a protocol between equipment? These are important questions ultimately related to how your product can be priced and sold. In turn these core issues are contributors to how the product should evolve over time. When you understand what it does rather than how it works, you have taken a huge leap past many of your peers.
Business knowledge distinguishes the leader from others on the team. Understand how the product makes money. Understand how it is used. Know and communicate with customers when called upon. Have a good relationship with the representatives from every function that is required to release your product (QA, documentation, marketing, etc.). Think about what might have been missed in the project plan and mitigate risks proactively. Engage with other teams that you depend on to ensure that they are on track. Drive specification reviews between teams and customers. Learn the competition – what are the people like you at other companies thinking, and can you think smarter? Listen to everyone who has something at stake. It’s a long list, but if you are truly emerging as a manager, you will one day complete them all, and a hundred others, instinctively.
It is important for you to know the competition that works against your team or your company. Learn how your company profits from the product. Does it cut internal costs? Is it a big source of recurring maintenance revenue? Is it a loss leader that guarantees a long stream of customization revenue? If you are not selling a product but instead bill your time by the day or by the hour as a consultant to your clients, what is the core competency of your company that most interests those clients? All of these are important topics that will help you think differently about technical problems.
You have to solve the business of the problem, not just the technology of it. It may be necessary to do any of the following things even while in the process of doing what you have traditionally considered to be your job:
Business knowledge distinguishes the leader from others on the team. Understand how the product makes money. Understand how it is used. Know and communicate with customers when called upon. Have a good relationship with the representatives from every function that is required to release your product (QA, documentation, marketing, etc.). Think about what might have been missed in the project plan and mitigate risks proactively. Engage with other teams that you depend on to ensure that they are on track. Drive specification reviews between teams and customers. Learn the competition – what are the people like you at other companies thinking, and can you think smarter? Listen to everyone who has something at stake. It’s a long list, but if you are truly emerging as a manager, you will one day complete them all, and a hundred others, instinctively.
It is important for you to know the competition that works against your team or your company. Learn how your company profits from the product. Does it cut internal costs? Is it a big source of recurring maintenance revenue? Is it a loss leader that guarantees a long stream of customization revenue? If you are not selling a product but instead bill your time by the day or by the hour as a consultant to your clients, what is the core competency of your company that most interests those clients? All of these are important topics that will help you think differently about technical problems.
You have to solve the business of the problem, not just the technology of it. It may be necessary to do any of the following things even while in the process of doing what you have traditionally considered to be your job:
- Determine how to solve a whole category of problems similar to the ones currently on your plate. If you get good at it (“gain a competency” in commercial parlance) then your company can rely on a steady stream of profits.
- Determine how to lower the cost of solving the problem or deploying the solution. A cheaper solution that is just as good will always be more appealing. As a bonus, it is also generally true that simplicity is beneficial both for the cost and the elegance of your team’s work.
- Determine how to make solutions more predictable from the perspective of the users. Would you ride in an airplane that has never been tested? Neither would your customers; the cost of ensuring stability will more than pay off in increased value.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Cut yourself off from your code
A classic pitfall that traps many developers is a high level of ownership and dominion over source code modules. The code has a personal, essential quality for these developers, as if it were their own form of artistic expression. University training teaches this artistic level of elegance in algorithm design, and after all, many great developers have been writing programs since they were bringing home art projects for Mom and Dad. Occasionally, the three-way love affair (developer, source code, company) works well, even for a long time.
For the emerging manager, personal attachment to source code is a mistake. Thanks to Von Neumann, software is just that—soft. It has to change with requirements and time. Anyone’s code can be learned and continued by someone else. In fact, source code needs to be more readable by a person than by any machine. Sure, a compiler has to parse the code, but a person should be able to understand it. Every programming student hears that comments are good and style is important, but few are taught that their career depends on it.
Source code should be documented in a way that anyone coming along at any time could understand what it does and why. The brilliance of any great program lies in the mind of its creator; the software itself is just a reflection of that brilliance. Buried under the same evolving modules for years, it is natural for some developers to believe that their creation (source code) is a part of themselves. As such, suggestions for improvement are rejected and the very idea of a code review feels like a violation of personal rights. Unfortunately, their careers are as frozen in time as the code they worship.
You may be thinking that the idea of working to become independent of your code is contradictory to the notion of being a subject matter expert or functional leader. There is some overlap between knowledge of a specific code base and its business value or technical domain. But a true functional leader has knowledge and capabilities that are portable outside of the limited confines of the source code—possibly including but not limited to specific repositories of programs.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
For the emerging manager, personal attachment to source code is a mistake. Thanks to Von Neumann, software is just that—soft. It has to change with requirements and time. Anyone’s code can be learned and continued by someone else. In fact, source code needs to be more readable by a person than by any machine. Sure, a compiler has to parse the code, but a person should be able to understand it. Every programming student hears that comments are good and style is important, but few are taught that their career depends on it.
Source code should be documented in a way that anyone coming along at any time could understand what it does and why. The brilliance of any great program lies in the mind of its creator; the software itself is just a reflection of that brilliance. Buried under the same evolving modules for years, it is natural for some developers to believe that their creation (source code) is a part of themselves. As such, suggestions for improvement are rejected and the very idea of a code review feels like a violation of personal rights. Unfortunately, their careers are as frozen in time as the code they worship.
You may be thinking that the idea of working to become independent of your code is contradictory to the notion of being a subject matter expert or functional leader. There is some overlap between knowledge of a specific code base and its business value or technical domain. But a true functional leader has knowledge and capabilities that are portable outside of the limited confines of the source code—possibly including but not limited to specific repositories of programs.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Getting there
Have you ever read a leadership development book? It’s hard to categorize them all together because there are so many. But two categories do stand out. One group is oriented at people who need to learn to lead and motivate. They are all about getting groups fired-up and committed to goals. Another group is more like the "I'm good enough, I'm smart enough, and doggone it, people like me" of Stuart Smalley fame.
Neither of these categories works for engineers or software developers who need to learn leadership and management. We think in patterns and processes, not in rhetoric. The process of leading needs to be explained in terms that make it a technical function whenever possible. In fact, non-technical managers could use a dose of this approach to tighten-up their style, too. Of course there is a human element of the job that lacks a purely logical approach. That part may be the hardest to learn but it is not a reason to fail in a management career.
Few avenues support a natural evolution into a successful management career leading technologists. As with anything new, setbacks are unavoidable. Without a good coach or the confidence of conviction, potentially talented people can fall back into individual contributor roles bitterly confused, having failed for the first time in their successful technical careers. That is an unnecessary waste and it can easily be avoided with a management development approach that values and leverages a technical foundation. The win-win is that exploring leadership options will teach you a lot about yourself. No matter which way your career goes, you will be in the driver’s seat getting there.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Neither of these categories works for engineers or software developers who need to learn leadership and management. We think in patterns and processes, not in rhetoric. The process of leading needs to be explained in terms that make it a technical function whenever possible. In fact, non-technical managers could use a dose of this approach to tighten-up their style, too. Of course there is a human element of the job that lacks a purely logical approach. That part may be the hardest to learn but it is not a reason to fail in a management career.
Few avenues support a natural evolution into a successful management career leading technologists. As with anything new, setbacks are unavoidable. Without a good coach or the confidence of conviction, potentially talented people can fall back into individual contributor roles bitterly confused, having failed for the first time in their successful technical careers. That is an unnecessary waste and it can easily be avoided with a management development approach that values and leverages a technical foundation. The win-win is that exploring leadership options will teach you a lot about yourself. No matter which way your career goes, you will be in the driver’s seat getting there.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Software Development Leadership
How can Apple consistently beat much larger companies with hit products that nobody knew they wanted?
Why do startups thrive when technology is changing rapidly?
Why do corporations follow the whims of capital markets instead of listening to their own smart people?
Those are a few of a thousand questions that all get to the same issue. Scott Adams has asked all of them in his own cartoonist way by turning questions into satire. Plato understood it and has been quoted for 2500 years. Even Ed McMahon understood it too. Curious?
Millions of great engineers, software developers and other technical people are managed every day by managers who do not "get it." Regardless of how good the engineers are, the managers can easily destroy their work faster than it can be produced. Adams invented the pointy-haired manager to exemplify the DontGetian breed. Plato told us loud and clear: if good people are apathetic about leadership, evil people will be the leaders (maybe "evil" is a little strong here - I'm hoping someone will reply with a correction related to the ancient greek term). And as for Ed, he was actually ahead of everyone with the answer, though it was no doubt an anonymous writer’s line: you have to enter to win. Huh?
Too few of the technical best and brightest choose leadership as their career path. They don't even enter the race. They are apathetic about becoming leaders and managers of their peers. And why would they get excited about it, anyway? When management seems to be the path of the incompetent, and technical roles pay well? They would if they understood that many incredibly successful companies achieve that success when brilliant people lead brilliant people. They would if they felt confident in their ability to make a career change without becoming obsolete. They would if they understood what is needed and just how logical and concise good management can be.
But they won't enter the race; they won't even think of it. The state of the industry is to never pull of the greatest talent from the "do-er" ranks into management or leadership because, after all, that would cut back on productivity. It’s the same geniuses that don't realize that good management itself is a great way to boost productivity. Corporations select and foster engineering traits that are completely orthogonal to leadership abilities, and then they populate the leadership ranks with well-meaning but incompetent people. Another generation of software developers and engineers is disappointed with every decision that "management" makes. Scott Adams gets a few hundred more ideas. We all laugh nervously at Dilbert and wonder, just for one second, what it would be like to be in charge.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Why do startups thrive when technology is changing rapidly?
Why do corporations follow the whims of capital markets instead of listening to their own smart people?
Those are a few of a thousand questions that all get to the same issue. Scott Adams has asked all of them in his own cartoonist way by turning questions into satire. Plato understood it and has been quoted for 2500 years. Even Ed McMahon understood it too. Curious?
Millions of great engineers, software developers and other technical people are managed every day by managers who do not "get it." Regardless of how good the engineers are, the managers can easily destroy their work faster than it can be produced. Adams invented the pointy-haired manager to exemplify the DontGetian breed. Plato told us loud and clear: if good people are apathetic about leadership, evil people will be the leaders (maybe "evil" is a little strong here - I'm hoping someone will reply with a correction related to the ancient greek term). And as for Ed, he was actually ahead of everyone with the answer, though it was no doubt an anonymous writer’s line: you have to enter to win. Huh?
Too few of the technical best and brightest choose leadership as their career path. They don't even enter the race. They are apathetic about becoming leaders and managers of their peers. And why would they get excited about it, anyway? When management seems to be the path of the incompetent, and technical roles pay well? They would if they understood that many incredibly successful companies achieve that success when brilliant people lead brilliant people. They would if they felt confident in their ability to make a career change without becoming obsolete. They would if they understood what is needed and just how logical and concise good management can be.
But they won't enter the race; they won't even think of it. The state of the industry is to never pull of the greatest talent from the "do-er" ranks into management or leadership because, after all, that would cut back on productivity. It’s the same geniuses that don't realize that good management itself is a great way to boost productivity. Corporations select and foster engineering traits that are completely orthogonal to leadership abilities, and then they populate the leadership ranks with well-meaning but incompetent people. Another generation of software developers and engineers is disappointed with every decision that "management" makes. Scott Adams gets a few hundred more ideas. We all laugh nervously at Dilbert and wonder, just for one second, what it would be like to be in charge.
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 dozzens of other use cases for leadership. Please see more at www.youdotnext.com.
Sunday, September 7, 2008
Management Use Cases
Welcome to You.next()'s blog space for new and ever changing Management Use Cases.
You.next() is a new book that's all about the beginning of the leadership track in software development careers. And Management Use Cases, found throughout the book, are real world examples of things that happend while the authors were leading software development teams.
This blog will be updated occasionally with new Management Use Cases and the obligatory rant about how and why things turned out as they did.
Thanks for visiting, and stay tuned!
You.next() is a new book that's all about the beginning of the leadership track in software development careers. And Management Use Cases, found throughout the book, are real world examples of things that happend while the authors were leading software development teams.
This blog will be updated occasionally with new Management Use Cases and the obligatory rant about how and why things turned out as they did.
Thanks for visiting, and stay tuned!
Subscribe to:
Posts (Atom)