A colleague is working in a small software development company (twenty employees). He's a part of a team of five developers who work on the leading product of the company.
For a few years, the founder was unhappy about the technical skills of the employees, and he recently hired a senior developer for the double role of technical lead and project manager. He was the only one doing an interview, and the only one deciding to hire this person.
This senior developer has an impressive CV listing a career of twenty-five years in IT, with a lot of successful projects accomplished for companies ranging from tiny ones to multinational corporations.
The team, however, became much less appreciative of his profile over two months. I had an opportunity to talk with three of five members of this team, and they all highlighted three issues:
According to them, the guy is a jerk, and has no respect towards the other members of the team. One recent quote of him talking to a junior programmer in front of the team is very illustrative: “I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a******.”
One should note that I had a few meetings with this person, and he seemed very nice and polite. I wouldn't believe that this was the same person who was constantly insulting his team mates, if I didn't have the testimony of three team members.
In the past, decisions were taken by all team members. When members wouldn't agree, they would discuss it all together and come to an agreement, or at least explain the reasoning to the ones who won't agree.
Now, all important decisions are taken exclusively by the lead developer. Those decisions cannot be questioned or discussed, even if all five team members find that a decision makes no sense.
The senior developer's skills and practices seem a bit... obsolete. A few examples:
He hates IDEs, auto-completion, and features which are intended to help programmers write code faster, and claims that the team should use Notepad++ to be productive. While it makes sense in different circumstances, it's difficult to imagine C# developers suddenly abandoning Visual Studio for Notepad++.
He doesn't refactor the code, and doesn't care about style (which is inconsistent across his own code), the reason being that “he only cares about things that actually matter”. As a side note, style was previously checked by a nightly build, which started to fail since the arrival of the new lead.
He rejects the idea of a nightly build, as well as automated tests. According to him, “any professional developer tests his code anyway by hand, so there is no reason to waste time writing automated tests”. The nightly build is also a waste of time, according to him.
He thinks that version control is mostly useless, and seem to misunderstand how to use one. This leads to the situations where he develops a feature alone for three to five days, and when he finally commits his changes, he does “take mine” for all conflicts. If other team members complain that their code was erased, he invites them to rewrite it. On several occasions, other members did the same, erasing the code of the lead developer. He looked surprised (it seems that he doesn't know how to use svn log or diffs), and did his changes again, complaining that “they were mysteriously lost” and blaming SVN for screwing up.
He overstates the importance of code optimization. His approach is correct, i.e. he runs a profiler, determines a bottleneck and fixes it; the problem is that there are no non-functional requirements of performance, and no elements indicating that the users may consider the application as being slow (and hosted on low grade development VMs, the app feels very responsive). He, on the other hand, spends practically half of the time optimizing the code.
He writes all SQL by hand, and rejects the idea of an ORM. One should note that the current product is based on Microsoft's ORM Entity Framework, and two of the five developers never used SQL before.
He rejects frameworks and third-party libraries, considering that it's much easier to write stuff from scratch. He decided to abandon all JavaScript libraries and frameworks except jQuery, claiming that when he started programming in JavaScript fifteen years ago, there were no frameworks, and the life was much easier.
He thinks that mobile devices (including tablets) are just a hype, so there is no reason to waste precious time to ensure the compatibility of the site with those devices and to make responsive design. The product is a public web application which is not expected to be used a lot from mobile devices. Responsive design, however, could be very interesting to have for this app, since even on desktops, it will be displayed on both 19-inch monitors as well as large high-res ones.
He asks the team to stop using internet (especially StackOverflow) and rely on their brains, the offline documentation (I didn't even know Microsoft still sells MSDN CDs!) and the books.
Team members complained to the founder of the company about their new lead about those three issues. The founder responded that they are overreacting, and that he has an absolute trust in the skills of the new lead, based on his CV and the interview, which is exactly why he assigned to this person the role of a lead developer in the first place.
What should the team do to:
Either throw the lead out of the team or the company,
Or force him to change his attitude towards the team?
A lot of questions were asked in the comments, so here is some additional information.
What's the company structure above him? Who is his superior?
Given the tiny size of the company, the structure is quite flat. At the very top, there is the founder of the company. And then there are employees, which report directly to the founder. Legally, the new lead is at the same level as the remaining five team members. For instance, he has no power to fire a team member or even move him to a different team.
Some of what you say in the bullets as points against him are actually points for him. I mean he is right in at least half of them
Indeed, this is the way I tried to present the subject. Personally, I find that some of those nine points make sense, but not in the context of the current team. For instance, my primary development environment is vi, but I won't force a C# developer to go use vi instead of Visual Studio, nor would I use vi myself when developing C# apps for Windows.
I really don't understand why this guy is wasting his time at your little company. He could probably make a lot more money working somewhere else as "the guy who still knows how to maintain our 25-year-old, undocumented, business critical legacy system, written in a programming language that only 3 people in the universe still understand."
Indeed, it is not very clear for me either. Should I mention that he knows COBOL?...
I do not believe this is an actual question. In my opinion this is a post intended for trolling. You basically took all possible bad habits combined them together and asked what to do.
My role of a IT productivity consultant means that I'm called when companies experience difficulties with their teams of developers. More than half of the cases are about inexperienced and often demotivated programmers who are forced to work on crappy code of a boring software product. The other part, however, deals with situations of conflict, strong politics, mutual misunderstanding and general mess. Therefore, I'm indeed facing TheDailyWTF-style situations much more often than ordinary developers, since it's actually my job to be where WTF is happening.
This already happened before. I posted a question describing a WTF situation, and some people assumed (their comments being removed since then) that I'm trolling. I imagine that a lot of situations I faced would be considered the same way here, which is understandable. By the way, the situation I describe here is far from being among the worst ones I've seen.
Unfortunately, there is no way I can show that those situations are real. For instance, for obvious reasons, I can give neither the name of the company, nor the name of the developer diva in the current case, and even if I could, nobody here knows this company or this developer (unless some of you worked in France in financial sector maintaining legacy systems).
It sounds slightly odd that the perceived problem is with the new lead, and that there is no perceived issue with the people working under him (such as you). Was the founder correct to be unhappy about the current team? If not, why was he?
Note that I'm not a member of the team, but merely a consultant.
I think the founder is absolutely right to be unhappy about the current team. The four developers have little experience in programming in general, and C# in particular. The fifth is more experienced and he's the one who originally insisted at using version control, who set up the nightly build, etc. Still, the overall level of the team is not as high as one would need to build well a product they are building right now.
It was an excellent idea to decide to hire a technical lead. However, things would have happened much better if it was a person who would teach the current team instead of blaming them, and work with the current members, not against them.
Why would anyone oppose using Internet to get help on software issues?
I don't know the official reason, but I would suppose that the lead developer always did it this way and considers that StackOverflow's quality is inferior to official MSDN documentation.
Did it ever occour that the purpose of this guy is for the team to quit?
Interesting idea. Making team members quit would make a huge financial benefit for a small company which may not be able to afford firing them. Once those programmers leave, the company may hire more experienced developers and move the developer diva to another team.
So I don't know to what length your team members have complained to your boss about the lead dev. But have you had a good round the table conversation with them?
Indeed, there were individual complaints, but no round the table conversation. Good suggestion.