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.

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 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.

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.