Dear Ms. Management:

I worked recently under a management structure that seemed not to care about wildly childish behavior on the part of one 'senior' developer (well, they gave him another, fancier title, but I'm not sure that's appropriate.) This 'senior' developer had been seen stomping around, huffing and puffing, waving his arms wildly when challenged with questions that he thinks should not be asked. The director of engineering was present at the time, and didn't even notice this little outburst, or if he did, he didn't react or do anything to intervene.

Immediately following this particular meeting, the 'senior' developer stomped directly to his cube, muttering invectives and saying "seven days to talk about it, fifteen minutes to write the code", and started hacking product code "to show them". I found this incident quite disturbing, and, sadly, I was paralyzed at the time, unable to figure out how to deal with this situation..

The overwhelming impression that I got from this experience and others like it is that the management and development teams were highly dysfunctional - something that I should have seen sooner, but sadly, I ignored the warning signs. Another strong sense was that this 'senior' developer was powerful within the company and not to be challenged, ever.

I ended up leaving the company shortly after these incidents. Upon reflection, it seems that there was quite a 'cult of personality' within that organization - the strong, adamant, bullying lead developer, and mostly meek, compliant developers who tended not to question the 'leader'.

My questions for Ms. Management:

• Can you recommend a way to deal with such a situation, should I (or your readers) encounter such an environment in the future?
• Can you suggest ways to detect and avoid such an environment *before* one joins the company, during the interview process, for example? Are there questions one can ask, or other subtle cues and clues one can look for?

Sincerely,

-- Baffled by Bad Behavior

Dear Baffled,

There could be a number of reasons for this organizational behavior. One, of course, is that the organization you stepped into is just hopelessly dysfunctional from top to bottom. It happens sometimes, and the best you can do is get out with as little collateral damage as possible.

More often, though, the problem is with the head of the department – in this case, the Director of Engineering. If you can get a handle on the underlying cause, you have a better chance of handling and changing the behavior effectively. The prima-donna is an issue, but the fact that the behavior is unchallenged is the real problem.

One key reason might be that the manager is non-technical (or minimally technical pretending to have a deeper understanding than he does), and is buying into everything your flamboyant senior developer tells him. If this is the case, you may be able to present a more rational approach to the manager (appropriately documented by you and backed up by written sources). In the case of software development, nearly every book ever written on the development process – even XP – advocates design and review over prima-donna hacking. You’ll do better if you can come up with a well-thought-through plan in conjunction with other members of the team – you want this to be a ‘for the good of the company’ group effort, otherwise it will seem like you’re in it for your ego (and let’s face it, your prima-donna has enough ego for the whole team). As part of your proposal, perhaps you can find a better place for your ‘senior developer’. This type of personality often can do a fabulous job as an evangelist or visionary – but keep him out of the product development environment. Let him make prototypes and present them to investors, keeping the money flowing and product maintainable.

Another reason might be that the manager considers the senior developer absolutely key to the business and irreplaceable – combined with the obvious volatility, the manager is afraid of crossing the developer and losing him. If the rest of the development team is strong, you can start facing the developer down in meetings and other forums – but the trick is to remain very calm, have your arguments in good order and on a technical (not personal) basis, and be willing to keep calmly pushing until you get an answer. On the other hand, of the rest of the development team is not strong you probably want to just cut your losses – if the senior developer leaves, there truly will be no one to pick up the slack and put things right.

If the manager is simply non-confrontational, facing the developer down in a public forum, as described above, will give the manager an out. He can agree with you without having had to initiate the confrontation, and you’ll give him an excellent starting point for changing the system.

Finally, the manager could be simply clueless – his mind is elsewhere, he’s dealing with investors or his boss or family troubles or whatever. In this case, you not only should advocate a more rational approach privately with the manager, but you should state your case for addressing the hostile work environment the manager has allowed to develop.

So, how do you ferret out this situation BEFORE you take the plunge? There are definitely some questions you should ask – and you should ask every person with whom you interview. Note differences in answers between staff and management, see if you get any evasions, and watch for eye contact:

1. How do key decisions (in this case, architecture and design) get made, reviewed, recorded, and validated? [If everything comes down to a key developer, there’s a problem. If management thinks things are sanely documented and reviewed and the team thinks one person dictates these decisions, there’s a problem. If no one really knows, there’s an even bigger problem.]
2. How does the team work, and who are the players? [Again, differences between management answers and team answers are key here. If the list of team players is different between the two groups or if the ordering of the team players is consistent within groups and different between groups, there may be an issue. If the team is led by one person and there’s no good explanation about how suggestions and decisions are made and vetted, you may have a problem as well. Expect to hear about a review process, not a distribution process.]
3. Follow this up with questions on existing roles within the team and the company, and how people move amongst the roles. Look for good movement within the team and an actual knowledge of what roles exist and how they’re filled.