I'm in a team of fifteen people and the team is in transition after a few changes of management. The current line of management is pushing for an agile approach to developing software but without providing any lead. The team suffers from a big communication problem both inside and with other departments in the company who are our customers.

Management has recently created a sub-team composed by the technical specialists. They have great knowledge of the code base but have been in the company for up to ten years and are not so open to change. There goal is to provide technical direction.

I've joined the team in the last six months. I have a good six years experience developing different software but don't have the same knowledge of the code base as others. I have good communication and organisation skills and can relate to the customers easily.

The company's focus is to deliver innovative new products, but based on my observations we break down in project organisation (we seem to lose focus of the customer, get buried in the code base and misinterpret requirements).

I think I can provide direction in delivering projects with a good focus on the customer, however I don't hold the same technical expertise as the technical specialist team. I also think I'm the only one with previous agile experience in the team.

I've got two questions:

Is there room in a dev team for technical specialists and those that are good at delivering and making the customer happy, i.e the two working in tandem with each other?

You post that the seniors "are not so open to change". This seems to imply to me that you want to change some things and they won't let you. If the seniors are actually any good as developers, their reluctance is actually experience, and you'd do well to listen to it. In my experience (also over 10 years) the "new guys" often want to change things that they think are broken, and all too often if you let them, the 'fix' is no better than any real or imagined original problem.
–
Joris TimmermansAug 31 '11 at 9:11

Not really. The team is moving into uncharted territory and for me it's more about do I put my hand up and offer a different point of view. I've also got five years non dev work experience, roles more customer focused.
–
John ShaftAug 31 '11 at 9:21

@MadKeithV: As I read the question, the "change" in question is a move to agile processes, which the OP presumably supports, but it appears that this move is being driven by management, not by the OP himself.
–
Dave SherohmanAug 31 '11 at 9:21

@Dave - Correct. Initiated by management but management expecting the senior devs to provide the lead. I've been hired as a senior dev.
–
John ShaftAug 31 '11 at 9:28

2

I have yet, in six years of software, to have ever seen a reluctance to change that was actual "experience". Usually it's outright technical ignorance ("I've never heard of/used that before"), unwillingness to do things right ("We've always written all the logic in code-behind files, why change?"), or flat out sabotage ("Management thinks I'm a god, I can't let them see I don't know anything current").
–
Wayne MAug 31 '11 at 15:03

5 Answers
5

A team is a set of people where each one may have his own purpose based on his own strong points and competencies. There is nothing wrong in a team where technical specialists and people who are oriented more to communication than to technical aspects work side by side.

Of course, it requires a good organization and a mutual respect. There is a risk that people with large technical background and a good knowledge of the codebase will use their codebase knowledge and their technical skills to consider themselves superior, smarter or whatsoever, and try to force everyone to agree with their decisions.

Some situations can make this risk higher. Examples:

having one "guru" in a small team and constantly treating him as the best of the best. For example if a developer has an opinion, and the guru has another opinion, the wrong thing for the management (project manager, director, etc.) is to say: "he's a guru, so do what he says and shut up" (or, in a more polite form: "He has enough experience and he knows the codebase well, so trust him").

having a separate team of technical specialists (is it actually the case in your company?), for the same reason: if you isolate a group of people and consider them publicly as the best of the best, they may start to neglect the opinions of people who are not part of the team.

As for your second question, you need to have enough background to lead a team of developers. Otherwise, not only you will fail to understand what are they doing, but they will also have a bad impression of being lead by an inexperienced person, and will avoid asking you for questions.

This being said, no, you don't have to be a technical specialist. It's a benefit, but if I have to choose between a person who has good communication skills but lacks some technical ones, and a guru who have no communication skills at all, I'll always choose the first one.

Point two. Yes, it is the case in our team.
–
John ShaftAug 31 '11 at 9:22

@MainMa: "I'll always choose [the person with good communication skills]" Following the articulate incompetent may lead to seriously wrong decisions; it's surely better to follow people with a history of good judgment, even if they are not as socially skillful.
–
kevin clineAug 31 '11 at 14:06

1

I spoke about a person who "lacks some technical [skills]", which is not the same as an incompetent. The reason is that a lack of some technical skills can be improved for most people, while communication skills are much harder to improve, especially for technical specialists who know that they are better than most of their colleagues.
–
MainMaAug 31 '11 at 16:10

1

Let the guru write as much code as possible and leave everything else to someone else.
–
JeffOSep 1 '11 at 2:03

the methodology looks quite wrong for it and chosen for its buzzword value,

the most knowledgeable ones have been practically removed from the team (instead of dispersed into balanced sub teams where they can contribute and lead) and sent on a magical quest on deep thinking island

Those three elements all lead to a single conclusion: your manager is acting at random.

...and you worry about the customer? I mean, the customer is the last of your concerns here, (and yes, it shouldn't come last, on that we probably agree) but what I see here is: (pardon my french)

a big fan,

a pile of manure slowly falling onto it,

and you in the middle, trying to toss your weight all the way into the fan.

Stay off the way of the old ones and their opinions, and take notes of how they and those opinions, affect your work, and the project, how, and when: heavy reorganization will come, and you'll want to have referentiable facts to support your position and role in the situation.

I can't upvote this answer enough! This describes my personal hell experience at my last company as well. Agile chosen for buzzword value, nobody knows what it means so it ends up turning into AGILEFALL because true Agile takes too much micro-managing power away from management. Ridiculously large team of mostly inept or apathetic people. The most knowledgeable ones being formed into a single group detached from active development. These kinds of dev organizations form when they have a BLOATED BUDGET and CAPTURED NICHE CUSTOMER BASE. Delivering quality to the customer comes second.
–
maple_shaft♦Aug 31 '11 at 11:29

+1000 if I could. I wish I could send a few less-knowledgeable people to a "magical, deep thinking island", preferably one filled with angry Murlocs.
–
Wayne MAug 31 '11 at 15:05

I don't see how Agile is wrong for a team of 15 ...if the mgmt is planning on this migration of methodology, then it probably should become a team of 3 sub-teams. I understand Agile works best with smaller groups ...but is there really a problem with the size of the team as long as communication improves (which would be a requisite in this case)?
–
IAbstractAug 31 '11 at 16:49

1

Yes, IAbstract, splitting the team in sub-teams can do. But if they did that splitting, they did it wrong: by putting all the knowledgeable people together and leaving the poor chaps that know jack about the codebase alone.
–
ZJRAug 31 '11 at 16:53

The responsibilities of leading a dev team can vary a lot, ranging from assigning tasks, approving code for production, designing the archictecture, deciding about planning figures or training requirements etc., up to more mundane tasks like granting vacation requests. While you can delegate some of the tasks to members of the team, you will have a hard time leading such a team if you lack expertise in more than some categories. Understanding what the team does and how it does it is important.

From your question I gathered your main concern is that the team lacks in communication skills, so coordination with other departments (or customers) and tracking requirements is a problem. It seems your team would benefit from adding a project manager or liaison manager to the team. That does not imply such a manager needs to be the overall team lead or a technical director. His work forcus is on building a bridge between the communication partners in distress and to translate between them, not necessarily to lead them.

This takes bits of some other answers, but it sounds like you have a development team that isn't as customer-focused as it should be, and a manager who hasn't realized this and hasn't forced focus into your workgroup. The inmates are running the asylum. Sounds like what you need is manager and customer contact. The manager makes the list of things the customer wants and the devs need to make that happen. In other words, you need to get into hamburger mode ("make me a cheeseburger, no I don't care about your mustard pattern, neither does the customer, just get the burger done so you can get started on the fries") until you get back on track. This doesn't mean the manager has to be rough, just that it sounds like you need strong real leadership (from someone outside the dev team).

In terms of your questions:

1: Yes, but the arrangement is work with the customer to find out what they want (frequently), and then tell the devs what to build. The person working with the customer helps the customer figure out what they want, the devs don't sit around wasting money building little pet projects that no one actually wants or will pay for. You don't want the devs in on this because 15 vs 1(or 2) is confusing for the customer, who are they really dealing with?

2: No, you don't have to be a specialist, but you have to know enough to detect the falsehoods or BS. I saw a dev team go forever (overbudget and late) because the "lead" was completely non-technical and had to rely on a developer on the team. Of course, he had his own agenda and was just following his flight and fancy. Poor "lead" didn't have a clue she was being BSed. Just smile and nod, smile and nod. Back to your question, sometimes a technical expert is a bad thing as the lead, because he or she will often go off and make (or remake) something big, over-architected, and excessively complicated. In a nutshell: A good lead has a sound technical backing, and an equally-sound or better understanding of how that team and project fit into the business objectives.

Don't sweat the agile thing, your manager heard the word somewhere. Just do what works and get the customer in there early and often, and demo early and often.

Sounds like you need to establish a customer advocate role. This is an agile team term for the person that represents the customers interests to the team. They sit in on all design meetings and make sure the engineers are building to the requirements the customer has laid out. Also ensure that you are there to help answer questions they may have about requirements. Offer to take questions to the customer if necessary as well.

One thing you can apply your customer skills for is to act in this role. Write up detailed requirements (in the form of user stories if you want to be agile about it) to detail what the customer wants. This is very important if you customer is vague in what they want. Nothing leads to over-bloated buggy systems more than vague requirements.

You should be as a team reviewing all the code done for a sprint (another agile term which is delivering buildable tested code every 1 to 2 weeks). If you need to sneak up on this idea what I did with my team was to just have the in process review meeting where we brought in management (it was a small company) and customer advocates and demoed all the new features from that week (or 2 weeks work). The developers need to all attend this meeting. They will hate it, complain it's a waste of time etc., but they will hear directly from the customer what they like and don't like about what they are doing.

Be forward about keeping things lean. If a feature starts to be discussed that is not in the requirements say so. If you can get authority from management, make developers test the hell out of each feature too. Nothing stops a lame unnecessary feature like having to spend 2 days writing tests from hell for it.