Forums

So here's my story:

I've recently taken over as manager of a team of engineers (actually the team was broken up since it had grown too big, and I now manage half of the people on the team).  Although I've been the technical lead on several projects in the past, this is the first time I've done the resource management thing, written end of year reviews, etc.  The team is "matrixed", in that we are divided up into 4 "sub" teams, each one working on a different product.  We've experienced some turnover recently, and after a few long talks with the people who left, and some more talks with the people who are still on the team, I've managed to acquire some good information.  Now I need to figure out how to best act on the information, which is what I'm looking for help with.

The major issue is that cliques are present along the lines of the individual sub/product teams.  Each product we work on has a different set of requirements, required procedures, etc and therefore, getting from the beginning to the end of the program is very different depending on which program/product you are supporting.  I always emphasize the "one team" ideology, and encourage cross polination between sub-teams, but many times when people from one team attempt to give ideas to another, it is not received well.  Many times, it is because there is a certian amount of "pride" on each team, and the "ideas" tend to come out as follows: "Our way is better, so do it our way". or "How could a competant person even think of doing it that way?" (and other more personal insults).  This is usually the result of people who make suggestions without knowing more about the other product.  They give an answer that seems obvious to them, but in the context of the program, doesn't even make sense.  This is understandable, since we just do not have enough time to educate every engineer on the team to that level of detail of every product we support.  So the end result is people constantly trying to get people on their side of an argument.  Because of this dynamic, there never is one true "winner", rather just a bunch of people who are mad at each other.  Sometimes, it is so bad that people are cast aside, or thrown "outside of the circle".. After that, it doesn't matter what they do, nobody will ever take them seriously. 

After some thought, I believe the root cause may be a lack of technical leadership across sub-teams, which results in people jockying for the position of the undisputed technical leader.  Unlike my team, most of the other teams in our department have at least one person on their team who has 25+ years of experience.  This person isn't assigned to any single program in particular, rather they act as an intermediary, and usually have the final say.  This eliminates the need for people to strive to become the technical "king" of the team.  The way our teams are structured, my role as manager is to mentor and develop employees.  While I am engaged in the technical side of the work, and am involved with the major decisions and much of the day to day activities, I can't be involved with every little issue that comes up every single day, nor would I be suited for that role, since I'm new to the team myself and am still learning what we do at a technical level.  I definately do not have enough insight into the subject matter to justify being worthy of having the final say on these issues.

There also seems to be lots of negativity coming from some of the more senior people on the team when new people or less experienced engineers have a hard time coming up to speed and ask for help, or have a hard time catching on.  This happens despite the fact I've been pushing our senior people to help people out when they are having trouble, and I've even worked it into their goals for the year.

Based on this, can anyone offer some advice?

Thanks,
John

 

tiomikel's picture
Licensee BadgeTraining Badge

I'll keep this short as I am skeptical that I can provide you relevant advice but in the spirit of contributing, I'll give it a shot. I have worked only in secondary schools for the past 18 years. I have been a teacher, assistant principal, principal and now a director of professional development consulting with schools around the country.

I have much experience with schools including some of my own, that have had sub teams: (a) a middle school vs. high school in one building, (b) a early orientation program for 9th graders but then a different "explorations" phase for upperclassmen, or (c) lower vs. upper school configurations.  In my experience the structure of different programs is what drove identity and therefore us vs. them groups. No amount of "we are one team" on my part ever overcame this. My professional development was diluted as I was addressing different needs and each group argued for what they needed and did not collaborate with the other group. My solution in situation (b) was to eliminate having two programs. I made the school a single program with a single approach and the issues disappeared, targeted professional development was more effective and there was no us vs. them.

I don't know if it's possible, but can the structural distinctions be eliminated? Have every team contribute something to every product or have a single, unifed team working on one product at a time. Here is where my lack of experience with your field is telling. My suggestions may really be missing the reality of what you have to deal with. Hope there's something helpful in there.

Michael

NickA's picture

Michael has a really good point, you're fighting an uphill battle here.  But if you can find rewards that your engineers will consider meaningful, then intermittently dish out those rewards for 'one team' behaviours when you get the opportunity to do it.  Be careful - engineers are a cynical bunch.

 

Mark's picture
Admin Role Badge

Do One on Ones to build relationships.

Then give feedback.  Take your time getting to negative feedback.  When you do, you'll have built enough credibility for it to stick.

Mark

DHumble's picture

There's a group of 4 casts om rolling out the trinity.  They're in the basics feed = www.manager-tools.com/manager-tools-basics = I'd start with that and the others in that feed first. 

new_manager's picture

Thanks Mark.  I do one on ones with all of my directs.  The problem is that most (if not all) of this behavior is present when I am not around.  Most of what I know has come from discussions with others on the team.  While I have an idea of who the "king pins" are, I'm not sure I would feel right giving out negative feedback unless I see the behavior myself.  Of course, everyone is on their best behavior when the boss is around :)

mmann's picture
Licensee Badge

John,

I'm seeing this through the eyes of "The Greatest Management Principle in the World" by LeBoeuf which essentially says you're going to get more of whatever behavior you reward.  This is the sentence in your post that stood out for me:

" I always emphasize the "one team" ideology, and encourage cross polination between sub-teams, but many times when people from one team attempt to give ideas to another, it is not received well."

I'm going to go out on a limb and say that you need to establish a clear reward for using ideas from other teams.  Ask your directs to report on ideas they've borrowed from other teams and how they've modified them for their specific use.

Try to find ways to reward the use of an idea from another team.  You might even consider requiring annual goals that speak to using ideas from other teams.  Finally, consider modelling the behavior by sharing with your team how you've taken ideas from other teams in the organization.

--Michael