You.next()

Red-faced and Righteous

2009-06-24T12:58:00.000-07:00

When you are leading a team, you gain strong insight into the capability of each person. Software development teams are no exception; in fact the disproportionate contributions of different developers actually let you zoom-in on individual capabilities more sharply than in other functions.

That was the scene when I was leading a group in Europe a few years ago. I hired each person and oversaw their ramp-up on my company’s products. We had an impressive set of skills and we were not shy about taking on big challenges to make up for faltering business back in the U.S.

After a few months, though, I got some bad news. A key team member had been commuting by car nearly 90 minutes each way. Even though he loved his job, he just could not keep it up. He’d taken a job much closer to home and I would soon have a gaping hole in my project plans.

I knew his value to the company and the damage that would be done by his departure so I went in to overdrive. I tried offering several different incentives but the only thing he wanted was more time to spend at home with his young family. If I wanted to keep him, telecommuting would be the only option. He was responsible and often worked solo on parts of deliverables so I agreed immediately. I crossed my fingers and set off to discuss the situation with the general manager of the business.

At a leadership meeting the next day, I re-told the story and stated my decision. There were three other people in the meeting, all of them young managers like me. To my great surprise, they all rejected the idea of allowing anyone to work remotely. The room was polarized, three against one. Their arguments only served to strengthen my resolve. For example, they argued that one person could not be so important. Then they argued that someone working remotely would be unaccountable and irresponsible. Finally, the argument was that if one person received the work-from-home benefit, everyone else would want it too.

I wish I could say I kept my cool but instead, I got angry. In fact, several of us got red-faced as we each dug-in to our positions. I knew we should retain the guy who wanted to leave, and that telecommuting would work for him. I also knew software development and personnel management better than the people arguing against me. The meeting ended in a stale-mate with the general manager essentially shutting me down and tentatively ruling against me.

I had set myself up to fail. The development team had been running so smoothly that other leaders had no idea how it worked or why one person could be so important. They also commoditized the people (thinking they would all want to work from home) because they had not become engaged enough to know them as individuals.

I should have provided details like how I would structure the telecommuting plan formally – things like official HR policies, access to development tools, and management tracking. I had to play catch-up and do all of that work in the wake of the leadership meeting. But none of that would have made a difference if I had not forced the issue by becoming obviously passionate about my point of view. Without that little outburst, the decision would have been "for the good of the business" without the need for my "technical input."

The general manager ultimately approved the idea and the developer became a very successful telecommuter for years afterward. The experience taught me to think about how an idea is presented to a mixed audience. But more importantly, it taught me to engage argumentation, debate and even vocal jousting (appropriately and professionally) if the alternative is failure.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

Learn once, run anywhere

2009-05-15T18:07:00.000-07:00

I went to visit a new outsourcing partner overseas a few years ago. We were in a ramp-up situation where literally dozens of jobs needed to be filled. I had recruited in Europe, the US and Australia by then so I was curious about how my skills would translate in the outsourcing climate.

Before I get a lot further with this piece, we need to be clear about something: Companies exist to make money. Not to help you fulfill you dreams of creating order in the software universe or to sponsor you through all of the MCSE steps. Granted, those things are ancillary benefits that can come along for the ride, as long as they don’t get in the way of the business.

That’s how I looked at it when my company wanted to consider outsourcing. I saw it as a natural avenue to explore; a way of reducing costs. I certainly would have wanted the company to reduce costs in other areas so it would have been lop-sided to ask that they spare software development from consideration for saving some green. There are really smart (I mean scary smart) people all over the world so there’s no reason to expect outsourcing to fail categorically. So I figured that either I could make it work, or my competitors would do it, then take over my market by offering products at a lower cost.

So I’m back to my story. I had interviews lined up from morning to evening in 30 minute intervals. I don’t normally take notes during an interview (that’s for immediately afterward) but I made an exception because the names were so unfamiliar and there were so many people. Just as I had hoped, once the interviews started, I was in familiar territory. I won’t write about all of the interviews but a few of them stand out, and with the power of hindsight we can trace the outcome of each decision.

Candidate number one opened the conversation with “I am an expert on …” and he named a few technologies. I don’t have an issue with arrogance but this guy could not back it up with examples or facts. I voted thumbs down but let myself be overruled in a recap "round table" discussion afterward; he was no expert but he could be a decent coder since he had passed a written test up-front.

Candidate two was a rock star. Short on experience but spot-on with every behavioral question – like how to give constructive feedback to a peer, how to change your approach after a failure and even how to re-organize a project plan that’s in trouble. I said YES and stuck to my guns when other interviewers wanted to bounce him because he wanted too much money.

Candidate three was a tester, not a developer. I have a few case scenarios that I use in QA interviews – questions like “How would you like for the CEO to think of the QA function?” or “Would you ride in a plane that’s never been flown?” I use those mostly to establish whether the candidate understands that QA adds value (vs. just being a process stage or a cost center). This guy did not get it. He could not see the big picture – I knew he would never be accountable for the quality of software. But he had tons of experience, including previous projects that the other interviewers knew in detail, so I let him on the team.

Candidate four was an understated quiet kid. It was hard to get him to talk about himself or his projects. His resume was not even clear so I took out his written test. Unbelievable… I had only seen it done better once before. I loved the way he defined words like “semaphore” because it showed how deep of an understanding he had. I also liked his ER diagram – simple but he even used some standardization in the field names for the simple test example. Once I got him talking, I was sorry I only had 20 minutes. Of course I wanted to hire him but the other interviewers tried to tell me he would not work well on a team. When there was one opening left, I got him in.

Fast forward through projects and deadlines… Candidate One (Mr. “I am an expert…”) was the first to go. He was a charlatan from the start; one of those people who takes away from the productivity of everyone else by negativity. I wasted my time and the company’s money when I let him be hired. Candidate two proved his rock star qualities over and over again, eventually moving to the States to work at our headquarters. He was worth every penny of his higher-than-usual pay level, and he was easy to manage as well.

Candidate three, the QA analyst, mostly just took up space on the payroll until I could put the microscope on him during a third-party certification of the software. He was classic in his ISO-certified diligence preparing documentation and paperwork but useless in the lab actually doing testing. I knew there was a problem because we never saw the defect levels rise and then fall as we went through the transition from code freeze to release. I leveraged the crisis to move him out of the team. Candidate four, the quiet kid, never ceased amazing me. My favorite thing about him was how he learned a ton about the product – not just enough to write his piece of the code according to the functional spec… this guy had ownership!

I’d love to say I had a 100% record for that hiring trip to the out-sourcer but the truth is that we could have flipped a coin and gotten the same result – about half the decisions were good, half were poor. If I had stuck to my guns instead of doubting myself, I would have had that 100% kick off that I was after. I was right about the fact that great people are everywhere, and I would also have been right to assume that my instincts applied just the same to people everywhere, too.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

Own it for the long haul

2009-04-12T15:53:00.000-07:00

Its been almost 10 years since Y2K so I guess a lot of people reading this were not yet in the workforce at that time. It was an interesting node for the software development role: a combination of incredibly boring work that was incredibly well paid for a short period of time.

Y2K was really nothing unusual for me because at the time I was at the dead end of a product line, holding up the fort while the company developed a replacement. Maintenance was my mainstay so checking and re-checking for unintended rollover effects fit right in with the plan.

Two things about my Y2K experience are worth explaining so I’ll pack ‘em both into one episode and spare you the cliffhanger.

The first of the two was something we called project Gauze. Back then we were constantly thrashing over the support call logs trying to figure out ways to reduce costs (thereby increasing profit margins) on the help desk. It is frustrating to fix defects that late in a product lifecycle because clients don’t want to incur the cost (pain) of rolling out updates, especially when they can call the helpdesk at no additional charge. Y2K updates, however, were widely anticipated to touch every installation. Governance auditors and other paperwork leeches created a fin-de-siècle culture of fear and charged big bucks to ensure compliance. If we could inject some support call fixes into the Y2K patch, it would make the whole thing have a positive impact on our customer’s experience, and our costs.

Of course there were arguments against this idea. The main one was the catch-22 scenario whereby we could poison the Y2K upgrade by introducing new insurmountable problems in the release. We fought that one off by making the whole thing modular, meaning we could pick-and-choose what to roll out. The other argument was that we needed to tell clients what we were doing, and they would say “no” to the risk. That one, like much other speculation about client responses, turned out to be unfounded. Most any client will provide a reasonable answer to a request if the person asking is trusted and empowered to do the job right.

Gauze made a huge difference. We dropped the call volumes by about 40% on a product that pretty much everyone had thought abandoned. The added stability extended the life of the product, resulting in a few more years of lucrative maintenance fees and headaches for our competitors who predicted the product’s demise prematurely. The lesson? A new idea can take hold even when hundreds of people with established processes across many departments in a big business have to be convinced. Its not easy and the idea has to pass a lot of scrutiny but stick to it and make it happen.

The second Y2K notable was fast by comparison. The CEO called for everyone to join in and sit a shift or two on the help desk as midnight rolled around the world. So much for my 1999 new year’s eve. I had taken support calls during the early days of the product but ever since it got big and was pushed into thousands of sites, the help desk operation was a complicated machine that I knew nothing about. December 31of 1999 was an eye-opening experience for me. The tools and utilities that I had written years earlier to diagnose and fix problems were still being used, bugs and all. The knowledge that I had shared with the first few people we hired full-time onto the help desk had been immortalized in a sort of repository that was consulted and interpreted quasi-religiously. Procedures that I had conceived quickly and never optimized were being repeated thousands of times with exacting detail.

It was frustrating to me that people managing the help desk would not build their own tools and improve their troubleshooting processes. But then it dawned on me that the mistake was mine. The help desk is an operation that exists to scale and implement processes with a guaranteed service level and profit margin to the business; they are not responsible for re-designing the product. Arguably they could have invested in some development but would the company have allowed it? I don’t think so because anyone doing good development would be re-assigned to work on products.

The lesson here is that you have to build in care-and-feeding tools for the runtime-operation of a product. You can’t go overboard but you have to do something and stay on top of updates for the tools as the product matures. Otherwise, you face the mounting costs of hordes of people trying to fix problems that you (or your team) caused. When you emerge into a leadership situation, this is the kind of tough message that you have to enforce; it won't be popular with inexperienced people from any department but it will help you build a solid career of long-term successes.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

Thank you Sir, may I have another?

2009-03-03T19:27:00.000-08:00

Layoffs are all over the news lately. Just when you thought you had dodged (or survived!) outsourcing, along comes a recession. It seems like nothing is sacred.

I have been through boom and bust cycles a few times already, and I'm only 39. Its part of the way our economy works; there's some sort of Hakuna Matata comfort in this "circle of economy". But that's cold comfort when uncontrollable forces seem to be having their way with your life.

During the last big one, a cycle known as The Internet Bubble, I was managing a group of over 150 people. Our products were mature and profitable; our people were experienced and expensive. Our customers were satisfied and stable. But the advent of a new wave of web technology froze all software markets, just like the credit crunch we're in now has frozen purchases in general.

IT managers the world over demanded mature web-based solutions even though that was a contradiction in terms. Overnight we had to transform ourselves from a confident market leader into a lean, nimble startup. We could not afford all of our people. We had to maintain old solutions and invest in new ones even as budgets shrunk under the crushing silence of nobody buying anything.

It was no fun to be a software development manager then but it was a powerful time to galvanize leadership skills. I would not trade that experience for anything. It made me realize that when push came to shove, I could clearly distinguish between the contributions of any two given people if I dug in deep enough. That's what you have to do when the difference is that one stays employed and the other does not. I could also get leaders working for me to make that distinction, and I could work through the process with them to the point that I believed we were making objective decisions.

There were some key moments like when I was asked to choose between providing raises as the company had promised, or keeping everyone employed. It was clear for me then and now: the company had to get into a healthy, sustainable position which meant that we had to have motivated, well compensated people even if it meant having fewer of them. That would be the most rational decision for the most people.

I also learned that it hurts a lot more to tell someone they are laid off than to tell them they are fired. Either way, the relationship is over but when you fire someone, the net effect on the team is always an improvement. When you lay someone off, you feel like its your own fault and the team takes a big hit. Later on, nothing made me think as seriously about job offers and recruiting as the memory of those layoffs. I never wanted to hire someone that I would ever have to lay off again. So far, so good.

Many developers considering leadership are probably glad they are not making the move right now. There's no doubt that existing software managers are facing tough decisions that they never anticipated. But if you are an objective leader with no hidden agenda, now is when people need you the most. There may not be big product launches or new VP promotions but you can figure out what you're capable of achieving under the current miserable economy faster than you will ever be able to later when the music starts playing again.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

Size Does Matter

2009-02-09T20:47:00.000-08:00

There are plenty of jokes I will spare you about size and how it matters in situations where the specifics are left to the imagination. But there is a reason for the headline here, and it is concretely applicable to office, desk and ego sizes.

You have to realize first of all that am I firm believer in differentiating great people by providing them with disproportionate rewards. It helps motivate and retain effective talent, and it encourages people who are not as successful as they want to be to find a different career. When it comes to offices, anyone can get stoked about having superior digs to work from; a nice desk and a big office makes a promotion feel “real” and it’s usually fairly cheap to provide that reward.

But big desks and corner offices are not good rewards for supervisory managers. Nothing says “I am superior to you” better than being in a separate place, behind a door, with an enthroning desk configuration. It makes even simple questions seem like an income tax audit – you have to prepare, disturb someone who must be doing far more important things, secure a judgment and desperately try not to ever bring up the same point again for clarification.

Yes, of course, some managers have that kind of job – people in sensitive financial roles, or human resources, or sales. Those are functional offices – they provide privacy and security. Some technical people need to work in quiet, dark solitude; they too get my thumbs-up on the office upgrade if it means they provide great performance in return.

But when it comes to a great manager over technical operations that truly serves the team he or she leads, my suggestion is that that person should be in the middle of the fray. That’s where information can be shared at a moment’s notice, casually overheard comments can be leveraged for project optimization, the pulse of progress is immediately evident, and, most of all, people will feel rewarded because of the manager’s presence.

That last statement cannot be read too lightly. If people are willing followers of their leader, taking that leader away will make them feel worse. It will immediately reduce the value of the leader and increase the intangible cost of the inexpensive reward that was intended for him or her.

I have had several experiences that concretely agree with all of this rhetoric. The best hardware engineering manager I know has always elected to work in the center of the action. A capable senior manager who replaced me in a role I once held moved himself to a corner office as soon as he could and immediately lost control of his team, and his job. My own favorite desk ever (because my team liked it) was when I moved into the receptionist desk in the middle of the floor of people I was leading. Two of the most effective “take over a mess and fix it” leaders that I know do so by immediately converting offices into meeting rooms.

I know a few people reading this will be doing so from corner offices. I am not judging your performance. There are exceptions to every rule. But next time your team faces a crisis, consider making a move back to your roots.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

Be bold and Learn from Mistakes that Follow

2009-01-20T19:58:00.000-08:00

Bold leadership is a sure-fire way to build loyal, willing followers. That’s certainly true in life-or-death situations, but it happens in every day office living too. People are drawn to individuals who take risks in order to challenge injustices or cut through red tape. It’s a power trip that is hard to come down from, when it works.

I had been managing for about two years when I got in full-swing enfant-terrible mode. I seemed to get more responsibility at every turn, which gave me more clout to right wrongs and kiss babies – cementing even more warriors for my loyal ranks. And I was getting good results, too, compared with my predecessors who came from various external sources, but did not know our company or products.

People would go to great lengths for me, and I would do that for them too. Once, an irate customer challenged a QA leader on my team to fly out and install our software upgrades in person so he could feel the full brunt of the pain of notoriously unstable products. I knew we had to accept this challenge but the QA leader started backpedaling, concerned that he would be ambushed at the client location, in person. So I chimed-in, saying that not only would the QA leader be there, but so would I. The customer was skeptical but when we showed up and delivered, everything was smooth and the whole client relationship regained a lot of trust and partnership. High fives all around.

My reaction was completely predictable at the time when someone on my team lost company benefits because he missed a renewal paperwork submission deadline. I expected to have a 15 second chat with someone from the appropriate group and say “My guy was working 40 hours straight because I asked him to. As a result, you and I can get paid with the money he earned for the company. Fix his paperwork problem now. Sorry about the trouble.” But it did not quite work like that. I mean, I said my part. But I was turned down. The date had passed, the benefits were lost, thanks for playing.

I was in shock. I simply could not understand (a) how someone could challenge me and (b) why they would not want to fix this problem because this employee really did deserve the benefits in question. I took it up a couple of notches but no joy – it seems the company was getting very serious about having a formal benefits process, and there were too many large financial risks with violating a policy.

My shock turned to tantrum. I resigned, saying I’d rather not be at a company that could not respect its people. What a stupid thing to do… Suddenly, what had started as late paperwork turned in to a big political problem with senior level attention.

The benefits issue was fixed immediately, my resignation was declined, and I was counseled along with other leaders to do a better job communicating. So in theory, I got what I was asking for even though I looked like a little kid having a fit in the process. It was not until afterward that I realized just how badly I had disrespected people outside of my organization. That was the real damage done in this use case. One-track Focused on the needs of someone on my team, I completely disregarded the needs of others at my company. Those relationships never recovered.

My approach was too extreme. Who works on my team, who does not. Who makes the products go, who does not. I either like everything and I stay or I quit and take my ball home when one thing goes wrong. I had absolutely no finesse or sophistication. Unfortunately, it would take a few more of those cases before the lessons set in.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.

And -Poof- Goes the Weasel

2008-12-31T09:01:00.000-08:00

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.

Processing, please wait.

2008-12-07T06:02:00.000-08:00

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.

The Bozo Bit

2008-11-27T17:45:00.000-08:00

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.

A tale of Two LCD’s

2008-11-22T20:01:00.000-08:00

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 can’t hear you. There’s a banana in my ear!

2008-11-12T20:16:00.000-08:00

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.

Office Politics

2008-11-04T18:59:00.000-08:00

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.

How to be perfect (hint: just re-define 'perfect')

2008-10-27T20:41:00.000-07:00

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.

What Not to Do with a Video Cable

2008-10-19T18:22:00.000-07:00

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.

Typical

2008-10-19T18:19:00.001-07:00

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:

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.

It is important to distinguish the types of management and make sure the one you are seeking is the one you really want. If you are given a new challenge, determine which role is actually given to you and whether that is a stopping place, a dead end, or the right track:

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

2008-10-19T18:17:00.000-07:00

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

2008-10-19T18:16:00.001-07:00

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.

Cach and Cachet

2008-10-19T18:14:00.001-07:00

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.

The Box

2008-10-19T18:12:00.001-07:00

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.

Leadership is a complex problem

2008-10-19T18:10:00.000-07:00

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:

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.

Cut yourself off from your code

2008-10-19T18:08:00.000-07:00

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.

Getting there

2008-10-19T18:07:00.000-07:00

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.

Software Development Leadership

2008-10-19T18:05:00.000-07:00

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.

Management Use Cases

2008-09-07T14:12:00.000-07:00

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!