Red-faced and Righteous

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.