31

As a leader, on a few occasions, I had team members wondering why I was not remaining technical or why I was not paying attention to the most technical aspects of their jobs. On the other hand, I never had to justify myself with my management, they feel that I am technical enough for the role I am filling.

Being technically sharp is extremely hard and requires continuous learning as well as practice.

As a leader, I see my role as protecting my teams from destructive forces, making sure we contribute to the organization by delivering what is expected of us, helping maintain a good work/life balance and helping staff members grow and flourish.

I have explained this to my teams on occasions but still I am sometimes confronted by individuals who feel that because my work is not as technical as theirs, I don't bring value and I should participate more in the technical aspect of our work.

So, as a manager, how can I demonstrate to my team that, while non-technical, my work is useful to the organization?

13
  • 3
    Related: workplace.stackexchange.com/q/2381/869
    – yoozer8
    Nov 29, 2012 at 14:12
  • 3
    @DavidSegonds Can you say more about two words you've used: "confront" and "demonstrate" -- what is the context for the people on your team "confronting" you about not bringing value? Is it at deadline times? When they're frustrated with their own work? When they're just wondering out loud? Similarly, if you're doing all the things you say in paragraph 3 (which is all correct, imho!), are people on the team not thinking you do that such that you have to more visibly "demonstrate" it?
    – jcmeloni
    Nov 29, 2012 at 14:22
  • 1
    @DavidSegonds: are you sure they doubt your value, instead of your choice? Some people just can't see why you'd give up coding for a non-technical position.
    – jmoreno
    Nov 30, 2012 at 21:29
  • 1
    @jmoreno This is an excellent point and I think this is true in at least one instance. Very perceptive on your part. Dec 1, 2012 at 7:47
  • 1
    The best managers I have worked for are the ones that you never saw what they were doing but things just seemed to run smoothly. It wasn't until another manager would take over and everything would fall apart that you realized how much the previous manager was doing. So, the question you need to answer would be is everything running smoothly or is there one fire after another going on in your team. If everything is running smoothly then you will just have to be satisfied in your knowledge that you are doing a good job. However, if you are constantly putting out fires then your team is right.
    – Dunk
    Dec 12, 2012 at 0:10

9 Answers 9

42

Wow, I think you already summed it really well. I'm not sure I could - on a big picture level - describe it better than you did in the question.

So perhaps the strategy should be to go to specifics that your people can relate to. My examples are often things like (said to people on my teams):

  • I have to keep track of all the work, not just the details of your work. I can't research everyone's area, I have to trust that you have the in depth knowledge covered, and that I can understand you when you find something after you take the time I don't have and really dig into the information.

  • Team members are a multiplier - I meet with everyone on this team at least once every two weeks, but also anyone and everyone walks in daily to share info and get direction. If you and I are communicating for 3 hours a week, and everyone else does the same (and they do), then I spend 3 X 5 simply keeping up to speed with everyone and their needs.

  • I'm the person who goes to the meetings so you don't have to. I have X, Y, Z meetings about our project's funding, corporate policies, resource management, etc, etc. I'm pretty sure you don't want any part of these meetings (right?), but someone has to go to represent our team. That's me.

  • Add this all up and I have maybe 4 hours a week to keep up to speed on something technical - I think we can all agree that being truly technical takes more than 4 hours a week, especially when the other 36+ hours are not spent solving technical problems.

I've had talks with points like the ones above and most of my smart team members have agreed that the meetings of a manager are NO FUN, and it's a useful trade for them to have their manager be technically competent but not an expert, so long as they can trust me to understand what they are talking about and know that I'll respresent them intelligently at outside meetings.

2
  • Thank you. I like the specific examples. This will help me next time around. Nov 29, 2012 at 14:24
  • 8
    I've heard one of the key roles of the line manager as being "protecting the team from organisational rain", which I've found a nice turn of phrase when explaining things to the team.
    – GuyM
    Nov 29, 2012 at 19:26
11

You describe a difficult situation that I have been in fairly recently. I'm not going to claim that I handled it brilliantly, but I am going to tell you what I would do, if I found myself in the same position again.

Turn it around, ask them what you're not doing that they'd like you to be doing. If it is a technical job then ask them if they'd like you to free up the time for them to do it themselves. If it's things like code-reviews, that they don't feel qualified for, then offer to teach them.

More likely they won't have a clue what they want you to do. They just know that they have no idea what you're actually doing. If that's the case, you're doing your job well, and you should explain that to them. They shouldn't see ANY of the politics you have to deal with day-to-day. It's depressing and they don't need it.

Also remind them that you have a boss and it's up to them to judge your performance as a team lead. They do know what you're doing all day and if they don't then that's their failing, not yours.

But qualify that somewhat. They need to know that you're working in their interests. With backing from your boss, offer them a part of your role. Say that they can take responsibility for one project or task in particular, and you will back them up. Let them see a portion of the garbage you're protecting them from.

All that said, you do need to keep your hand in, technically speaking. You don't need to be as technical as they do, but you do have to be on top of the latest technologies and what they offer.

If we're honest, management is a role with peaks and troughs of effort. When you're needed, you're needed immediately, but there are times when you do stop. Use those times to solve technical problems that your team can never find the time to solve. Get into the CI server and see what you can do to improve it. Have a look at a framework that the team has been saying would be useful and see how hard it would be to migrate. That sort of thing.

But don't ever become a bottleneck. Never become the guy someone is relying on for a key delivery. Cause you can guarantee that you'll end up with a political situation to deal with at just the wrong moment.

Finally, and this is the biggest lesson I've learned, do not pander to one or two negative influences within the team. Never forget that you're their boss for a reason.

6
  • Thank you for your reply. Whenever I do anything remotely technical, I become the bottleneck because I don't have the time. I don't have to protect them for our boss because he is a great guy (and he may be reading this). :-) Nov 29, 2012 at 15:31
  • @DavidSegonds: No, I never had to protect my team from my boss either (Hi Richard!), but he couldn't protect everyone from all the outside forces. That was our jobs.
    – pdr
    Nov 29, 2012 at 15:34
  • I read the question and this answer, and it is unclear to me what the "outside forces", you are "protecting" team members from, are.
    – oxygen
    Nov 30, 2012 at 17:29
  • 1
    @Tiberiu-IonuțStan: Politics, generally. Unreasonable expectations. Conflicting priorities. Inconsistent messages from customers. Management decisions made for less-mature teams being enforced on more-mature teams. The reason the original question is so difficult to answer specifically is because every day can be solving a different problem.
    – pdr
    Nov 30, 2012 at 17:51
  • 3
    @Tiberiu-IonuțStan In short, everything that isn't coding for eight hours straight.
    – Tacroy
    Nov 30, 2012 at 19:49
10

Sounds like a classic example of the misperception regarding managerial roles in IT shops. A lot of people (most prominently developers, but often even managers themselves) believe that "IT manager" is a high tech job. The reality is - as explained in Peopleware -, your job is concerned with people, not technical equipment, even if some or all of said people are doing high tech work. So you need soft skills - communication, presentation, empathy, emotional intelligence - first and foremost, not technical skills.

Of course, it is useful for you to have enough technical background to understand on a high level what your team members are actually doing, but you don't need to (and can't) go down to the minute details with it. Your job is to remove any obstacles which prevents your team from doing their work - and then step out of their way.

This requires lots of communication - both within your team and with external parties -, doing paperwork, attending boring meetings etc. etc. For most developers, these are precisely the things they would never want to do themselves. And getting too technical would actually render you less capable of dealing with this sort of stuff, reducing your usefulness as the protective shield of your team.

2
  • 1
    And the reason of the downvote is ...? Nov 29, 2012 at 17:05
  • 1
    +1 for "get out of their way." If your people feel you're getting in their way, then they'll likely see you as doing more harm than good (even if you're doing more good than they see). If you're acting as a stumbling block due to lack of technical knowledge in a specific area, then that could be the cause of the complaints, and it would be worth your while to determine whether you need to know more about those parts, or just get out of the way.
    – Shauna
    Nov 29, 2012 at 19:41
3

If you're doing the non-technical part of your job as a team/project lead properly (managing people, being the buffer between your team and the stakeholders wondering why it wasn't done before they asked for it), the junior coder's never going to fully appreciate what you're doing for them, because by doing your job you've prevented them being exposed to the consequences of you not doing the job.

However, you said it yourself; staying at the top of the technical knowledge game is extremely difficult and requires a lot of time and effort. Make sure you communicate that understanding to your team members; you know they work hard just self-educating on the cutting edge trends, never mind the grunt programming work. But, you need to impress upon them how you're making their job easier, and how much effort that takes. You know what's implied in your job better than they do (better than we do, in your specific case).

3

We are all part of a team.

I went from technical to managerial two years ago in a small but fast growing firm. I just happened to be developer number one when there was one developer who did everything.

I became in charge of system administrators, developers/programmers, social media developers and content producers. One thing I've always tried to do was hire system admins who knew more than me, programmers who were better than me, social media people who knew it better than me (not hard!) and content producers who could write better and knew the subject material better than me. And I told them this from day one at the company - you were hired because you're better than me at what you do. But you're part of a team and my job is to make sure things get done right and on time. Your job is to make sure things get done right and on time. So we have the same goals.

As far as the technical side goes, I make sure I know what does what, and they know the how. Ultimately, it's my job to choose the right tools for a solution, but I need their input for that. So we keep communication very open and try to decide as a team.

As has been mentioned, as managers our jobs is to make theirs easier. Our bosses watch us more than them, and we want nothing to get in their way of delivering an excellent product or solution.

1

While there are some great answers here on how you can make sure your team understand what your role is (and I agree you have an excellent handle on that already), having reflected on this a little bit I keep coming back to "first seek to understand, then be understood."

The two examples you give in your first paragraph are interesting in this context.

...team members wondering why I was not remaining technical...

...why I was not paying attention to the most technical aspects of their jobs..

The fact that your team raises these maybe highlighting their own concerns and/or needs.

The first issue is related to career choices, and how those impact ultimately on status and remuneration in your organisation; I'd suggest the team members asking this respected your technical skills, and are worried that the only path forward in their careers is to emulate your choices and leave the technical role behind.

The second issue also suggests to me that perhaps your team valued you (or the previous person in the role) as a technical mentor/guru, and are missing that role within the team. They may also be concerned about how you will be able to conduct performance reviews if you are not aware of how they have delivered on a technical basis.

I'm making some big jumps here - and there maybe other ways the team has expressed themselves - but what I'm really driving at is that as well as the excellent suggestions in the high-voted answers here, you might want to drill a little deeper in to the questions your team is asking and determine where there underlying concerns are.

One technique I have come across in this is the "5 Whys" - you respond to the question by asking "why do you ask that?", and use the same "why" questioning style to drill into their responses. It usually takes fewer than five iterations to draw out the underlying concern, which the team member may not have been able to easily express.

One of the hardest things I find with leading my team is that sometimes I have to listen very carefully to hear what my team is really trying to say.

1
  • While I don't believe this applies to my particular case today, +1 because I think this approach would have helped me a few years back. Dec 1, 2012 at 7:52
1

I would let them face the "outside" from time to time, without your protection. This might give a good hint about your contribution. I've been in this situation a lot of times, and allowing some technical people to be directly exposed to unpleasant, "non-tech" experiences (e.g. difficult discussions with customers) made me gain their trust.

2
  • Depending on the experience of the staff, how well the communicate with "the outside" and who "the outside" is, this could have disastrous repercussions for the team and possibly the company.
    – alroc
    Dec 6, 2012 at 18:14
  • I agree, it could. However, it might also be applicable. I applied it in the past, with good results... Dec 7, 2012 at 7:15
0

If you work in a construction industry and have never participated in constructing a wall ever in your life, what makes you think you will be able to connect to the problem your workers are trying to solve.

Knowledge about what your staff does is very important. You do need to be technical. Else don't make technical decisions. If you make technical decisions then you have to be technical. If you don't, then make it clear that you are there to reflect their technical decisions (good or bad) to the project management team. If you have your objectives mixed up, then you have a problem.

Another excellent way to bridge the gap will be to do a "Expectation Setting" exercise with your team and your boss together. In this meeting, share

  • Responsibilities
  • Expectations from team
  • Expectations from boss
  • Expectations from project

Now this is a very healthy exercise. If you are smart, you will be very open, calm, focused. Discuss this meeting with your boss, a very senior peer, someone who has managed OR who knows the team members. Also a team member (someone mature). I think your issue is "disconnect between your team and you on expectations". If you give them a chance to speak in front of your boss, they will be rational.

Give enough time for this meeting. Do it again to ensure that all have been captured. May be this is a team bonding exercise, more than a expectation.

-3

As people become more intelligent and learn to work together toward a goal they will ultimately become more independent. As they become more independent the only way to be valuable is to move from being a leader to being a lubricant and a catalyst to the parts that can produce and lead themselves. To show that you have value you have to do this and not be emotional. Remember if you are not one of the team members that is producing the service product, then you are an external force sent in to maximize production whether you are objective for the members or subjective to them. A member that wants this autonomy will remind you that you are not directly connected to the technical aspects of the work when you try to intervene. One more thing. The perfect team will produce so efficiently that any extra forces will not increase the profit to cost ratio much if any. Don't assume you are in charge thus you know better, and certainly don't make the mistake of getting in the way of an efficient team. They will eat you alive. If you want your job to be efficient then you need to be able to direct when needed and step back as well and you even need to be just as technical or more so. So of you choose to not be better be able to roll with the punches.

2
  • how does that answer the question? "As a leader, how can I communicate to my staff that I don't need to be as technical as they are?"
    – gnat
    Nov 30, 2012 at 18:42
  • @gnat The post ends with another question (which also has the post as context): "So, as a manager, how can I demonstrate to my team that, while non-technical, my work is useful to the organization?". This answer negates the possibility (this makes it a valid answer, which addresses the question).
    – oxygen
    Dec 1, 2012 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .