Asking for help in IT in a senior position while keeping credibility

Question

I am working in a senior position in an IT department. Having learnt a new technology recently and being quite experienced, I rarely, if ever, get stuck on programming matters.

Lately, I have noticed a colleague who takes pride in his technical proficiency and acts as a de facto leader. I appreciate his competence and thought to ask him help on a very specific matter on which he worked a few months back.

Lo and behold, while he could help a bit, I overheard at the coffee break from a more junior colleague that he thought "that I was better than this; if I ask for help, it does not show much proficiency". Basically, me asking for help was seen by this junior as a sign of weakness.

I am strongly trying to ask for help even more because I believe, as a senior team member, I need to be able to be more vulnerable and simply ask when it is needed.

The perverse effect it does seem to have is to make me look weak, seemingly. I am fighting against this because this is a misconception, but in a competitive environment, you never know. Especially in IT, where I do work, where promotions are few and far between, some are more "cutthroat" than others.

How would you ask for help, given the situation at hand, without losing credibility?

Answer 1

Asking for help when you don't know something isn't weak - no one person can know all the details of each technology they will encounter. And assuming that it's not happening with every aspect of the job, but instead on specific things where you know a colleague has specific knowledge that will help, then it's actually the sensible and efficient thing to do.

The junior staff member is the one in the wrong here. I've seen it time and again - a junior/inexperienced person can sometimes get locked into that weird mentality where they feel that to ever admit they don't know something or need help will forever mark them as incompetent. It's ridiculous, of course, but it happens all the same and it's the bane of good team work.

Unfortunately, you can't control someone else's perception. All you can do is control how you act. And the best thing to do with this sort of thing is simply not to feed the false perception. You need to own the fact that you don't let your ego get in the way of you getting the job done as best and as efficiently as you can.

Don't act like it's a shameful thing or be embarrassed about it because it's not and you don't need to be. Should this junior or anyone else comment about it directly or when you are otherwise in a position to respond, then you point out that, of course you do so, and you would expect any member of the department to do likewise because there is no point in spending hours or days figuring something out when the person in the next cubicle can give you the answer in five minutes.

Answer 2

This junior developer has a flawed understanding of what a senior developer is supposed to do.

A senior developer is senior, not because his technical knowledge overlaps everything a junior can do (it can, but doesn't have to), but because he can do things that a junior doesn't even understand. The senior developer can (should?) understand broad implications of decisions, keep the big picture in mind, can delegate tasks, understands the importance of trusting your reports, and is able to build a team.

Deferring to another member's expertise is a learned skill, and is part of the "big picture" mentality, which this junior obviously does not have, and that's why you're the senior and he's not.

You have to realize that the task you're asking for "help" is not something you are unable to do, but it is something you are delegating and trusting the junior to do. If he gets stuck, you don't go "Oh, too bad. I'll fire you now." Instead, you will be able to assist, point to the right resources, brainstorm new ideas, investigate new leads on potential solutions, consult your own contacts, ask for help in different channels, etc.

With the specific thing you overheard, first, you need to make 100% sure you are not offended. This is up to you and needs to be processed without involving the junior.

Once this is done, and you are 100% sure that no offense is taken, then recognize this is something the junior MUST learn to grow into a senior developer. Anyone senior who thinks asking for help is a "weakness" will naturally create a very toxic environment.

Try to be honest and just ask him, in a non-confrontational manner, something like "Well, I overheard you saying (what he said). Why do you think that?" Make sure it is not defensive, and try to probe him on why he thinks the way he does.

If you look at the broader picture, does a CEO do everything his reports can do? Of course not. That's why there is a team of C-level executives, which then have their own senior reports, then they themselves have junior reports. You also can have managers who have no technical expertise themselves, but they can successfully manage senior developers.

Answer 3

Weakness is undermining a teammate who asks for help.

When I was starting out and there was no www, all help was in the form of manuals and advice from overworked colleagues, it was expected that you were supposed to know just about everything.

The world has changed. There is so much out there that no person can possibly even begin to know everything. If this were true Stack Overflow would not exist.

If you were working with or for me, I would be RELIEVED that you were asking for help. It would INCREASE my confidence in you because I know that you wouldn't be the one to go off and do something half-cocked, screw things up, and then try to blame someone else.

I once worked for a newspaper where when I interviewed a candidate and deliberately asked him obscure questions that he could not have known the answer to because I wanted to see him say "I don't know". He did, and we hired him. Why? Because we'd rather have someone say "I don't know what I'm doing here and I need help" than see a mistake make it into the newspaper and embarrass the company.

It is not a sign of weakness of incompetence to know your limits and seek help when you need it. It is a sign of professionalism and self-awareness and a trait I would LOVE to have in a colleague or in someone who worked for me.

The gossip is the weak one, and if I were your manager, he and I would have a conversation behind closed doors over this one.

Do not let this get to you, if he continues talk to him directly and then to your boss. He is undermining teamwork and slowing employee growth.

Answer 4

If it makes you feel better, I helped a couple of senior techs when I was an intern. Not because I was better than them or even smarter (I am not), it was because I happened to know the answer because I had done what they wanted to do before.

Asking for help is not a weakness. This junior doesn't know what he is talking about (probably why he is a junior). A good senior tech knows what he knows, but more importantly, he knows what he doesn't know.

What good would it do if you pretended to know something and couldn't do work because you were too proud? Keep working like you always have, and try to forget that this happened. Your credibility should not be harmed in any way (unless you keep asking the same question over and over again and never learn).

Answer 5

The way I see this is that your junior colleague already has a negative look on asking for help.

I think the right answer here is showing him that asking questions is not bad and in this case it is even smarter since your other colleague already has experience in the matter you need help with

Answer 6

You have the problem the wrong way around.

You have a junior developer that thinks there is something wrong with asking for help. That is bad both for them personally, and for their employer.

If there is anyone working in a specific mentor role to them, have a word with that mentor about that problem.

Meanwhile, not only should you continue to ask for help when you need it, but if they complain about that, call them out on it. Otherwise they'll never learn any better.

Answer 7

Team working is all about that, TEAM!

Everyone (including the misguided junior) has something to offer, and it's the job of the seniors in the team to organise the efforts of the team to be most effective.

It's not a "mine's bigger than your's" situation; far more a "every day's a school day" theme!

Changing the culture and outlook of your team is a real challenge, but one which will reap massive rewards/productivity/promotion/pay raises/etc/etc

That's what leaders are really about (whilst generating the code to finish the project, of course)

To directly answer your question: Openly and publicly (in a team meeting, perhaps) elicit the help of the "whiz kid", invite the junior to attend if appropriate.

Be comfortable saying "I don't know, show me". The whole team will work better as a result.

Answer 8

TL;DR

• if this is about promotion, consider monitoring yourself to find if your worry is justified or not. Compare with others who might be your rivals for the job. (now with EDIT section after @Cantalope's comment)

• if this is about reputation, weigh you asking others for help and them asking you, to see if you should be worried

• make sure it's not about your must-have skills getting rusted, this is the only case where junior will lose their respect for their senior somewhat deservedly, I've seen this happen

• if it's just about that junior, see other answers, I fully endorse them. Especially nice ideas: @Jon Hanna (whisper to junior's mentor), @SaggingRufus (junior may sometimes help seniors) @motosubatsu (why did this junior think so)...

Full answer

Junior guy aside (other answers cover it extensively), the question is:

How would you ask for help, given the situation at hand, without losing credibility?

1. What's the situation at hand?
2. Losing credibility... in whose eyes?

Let's start with a simple question:

Is this about promotion?

You mentioned cut-throat promotions right after this passage:

I am strongly trying to ask for help even more [...] The perverse effect it does seem to have is to make me look weak, seemingly. I am fighting against this because this is a misconception[...]

So, assuming it's (perhaps!) not just that junior who has this misconception; assuming your fears are about your promotion (will my boss think like this junior? will my other colleague fighting with me over promotion will tell the boss that I keep needing help in my tasks?); assuming you still want to ask for help (for reasons you do it now)...

How would you ask for help, given the situation at hand, without losing credibility?

1. I would monitor HOW OFTEN I do this. Just in case. Per person whom you ask (this sometimes matters). You may want to also take a look at how often you do this compared to others. And - if there's a significant difference - why.
2. I would first search/research/try my own ideas for 20 minutes (or a bit more if the problem is larger).
3. I would phrase my question appropriately, so others would know I've done my due.
4. I would ask on SO sometimes, rather than in the office.
5. I would try to come with simple rules for myself: when to (NOT) ask.

I ask

• when time is of the essence,
• if I can gain considerably more time compared to how much the other guy loses (answering and switching context),
• when I spent too much time on this without effect. How much is too much time for me depends on problem size/weight.

If my friend is doing demanding work, I may not ask, despite him most likely having the answer, unless circumstances are really favourable.

Bosses look for people who get the job done. If they get others help it's OK, as long as lower priority task doesn't pull folks who work on higher priorities. So... don't pull others to help if they do work more crucial and don't BE pulled to help while your task has priority... unless circumstances really show this is how it should be.

Competition in IT

EDITed after @Cantalope's comment:

I do worry about promotion, I will freely admit, since there are many cooks in there, and feeling "out of my main expertise" can be frustrating. I do have that feeling that in IT, competition is strong

1. If you wish for the top, either be the pioneer or be the last guy on this tech - both give excellent money and stability (to an extent).
2. Competition is somewhat strong. Still, you can easily measure company quality by the fact how often skills trample politics and vice versa. We are all human, so relying on "how pleasant other human seems to be" to judge them is wired in our nature, but it's getting work done that's worthwhile in many IT companies. An expert like you'll thrive in those that value skills - that's where you want to be. Of course... YOUR skills.
3. So, consider your main area of expertise. Is it aligned with what is needed for your boss? Cause he will promote what he needs usually. Doesn't matter (usually!) how terrific you are with C# if you guys are in dire need of Java folks for new Most Important Project Of Them All.
4. Feeling of being outside of your comfort zone gets to everybody, I think, you are not alone. Think positively, technologies are similar and getting more gets easier with time. This will never end, that's the job specifics, as I'm sure you know. Trust in yourself.

So promotion bottom-line:

1. Don't worry. Trust in your skills. If your company values politics and self-selling more than skills, consider moving. Unless there are people you like working with, that's usually a good reason to hang around for a bit longer.
2. Enrich them if that's what you want or need (perhaps a new language or framework to get that promotion or move to that other promising company?)
3. Evaluate your boss on whom he promoted in the past. Self-sellers? Smooth-talkers? Boot-lickers? Hard-workers? Tech wizards? X technology gurus? Then re-evaluate your chances.

Is the team ready to admit "I don't know"?

Now, the other part of your comment:

but I expressly want to make myself more open, no matter the comments.I accept not knowing. I am not sure if my team does.

1. Let's verify if they do then
2. If they do NOT, do you want to change that or do you want to move?
3. If you want to change that, I'd recommend changing their perception (thanks @BrianD for idea).

Verification on the surface may actually suffice - that is, you may have your answer after round of brief conversations in the kitchen or during company after-party. Informal setting, simple question, done.

"do you think folks like X or Y would admit they have a problem or they don't know the answer? I was wondering lately how we as a team stand on not knowing."

"I think X dislikes admitting to not knowing for he believes that makes him look weak. Would you agree?" Later just distinguish if he agreed with "he has this problem" or "it makes one look weak".

Changing their perception needs to start from putting "asking for help" and "getting their input" on same level. First has ramification of you being weaker (to some!), second (usually!) implies THEM BEING GOOD ENOUGH to be asked. I usually use both, so the message is clear for everybody around me, that I consider them same. After a while, if I ask somebody for help in X, everybody knows the guy is good with X.

Feel free to also employ pre-reviews, especially if you guys do code reviews. Get one technically sound person to pre-review your code and ask what can be done better. Follow on his advice. Then get him to review that code. Guaranteed approve, most of the time.

Changing their perception is about showing them the power coming from being liberated and not having to pretend to know it all. Focusing on real job, getting shit done, using THEIR knowledge for it without care if this makes you look weak. Freely admit that team makes you stronger. Thank for good idea here or (jokingly) for "being of use there with this nifty test trick".

Is this about reputation?

How often you ask? How often you are asked? How much time you spent on "your due" before asking? How much they do? If you ask series of questions without doing basic research, your reputation may take a hit among your peers (not to mention folks lower in hierarchy).

If I'm unsure how difficult problem I'm facing, I sometimes do a round and ask (in passing, marking I'm after quick-and-incomplete-on-the-fly-answers). If most of my peers seem to have no inkling about the issue or all are pointing to local expert, I know it's not just me. If some had, I can see if I need to improve here. Which leads to...

Have you ruled out rusted (while basic) skills? Perhaps it was an easy question?

Recently a very mature junior (older guy, changed careers, very deep learner) told me about seniors in his new workplace. Despite Java 9 coming out and Java 8 being out there for years, they never bothered looking at it and they keep saying how difficult it is. When he coded few things with Java 8, three of them rushed to his screen to look. He slowed down, coded this again so they would see how he did this, proposed he could show something about it if they wanted and generally never made a fuss, but he told me that it was a somewhat bitter-sweet feeling. So, while from your story it doesn't seem to be the case... double-check it. Perhaps your question is generally perceived as easy material? I had a few times asked for things that were easy to find and few moments with Google would've answered me equally well as my unfortunate co-worker who had to spent several minutes with me. I was quite embarrassed later when I found how easy was to find this in Google. Happens to the best among us, I think.

Don't get me wrong here. Nobody knows everything. Having rusted skills is a natural thing. But so is being perceived weak - especially by those, who see those skills as a must-have.

If in your job, coding is perceived as primary skill, and your coding has rusted (cause you are an architect for instance and are rushed from meeting to meeting), this will change how you are perceived. Deservedly so - strictly on coding-meter you are weaker than you were. Now couple this with bussiness-as-usual and you're too busy to spot this and too busy to fix this. So you ask for help more, because you know others may help much faster than it will take you to re-discover how this or that worked...

Similar loss of credibility follows if you deemed an out-of-comfort-zone question too time-consuming while it wasn't (not doing your due before asking).

Summary

1. Monitor yourself. Set simple rules when you would ask, when you won't.
2. Keep priorities of the job in mind when asking or asked for help.
3. Weigh in how often you ask / are asked, how much time you / others spend on helping. Compare it to your rivals if you're worried about them overtaking you.
4. Do your due for problems before you ask for solutions / help.
5. Phrase your questions so other know it.
6. Double-check that it's not an easy question, perhaps test how much your peers would take to solve it.
7. Don't mind the junior, his comment may come from simple excitement, that this mighty senior, whom he has enshrined, has things he doesn't know and perhaps can be reached in time.

Very lengthy answer, sorry about that.

Answer 9

I am not an IT manager but have run projects in different areas. One way to deal with this is to change the way you view this situation. Your job is not to show vulnerability but to be a good judge of efficiency.

Tasks should not assigned by who can do the specific job the most quickly but by whose time is best spent on the task. You as the senior have other, important jobs to do and should have better judgement on how to divide the work to efficiently accomplish the project goals. Use your judgment and exercise your authority without apology and learn to be comfortable in doing that. Transform the feeling of needing to show "vulnerability" into being open to ideas from team members, being willing to change your planing for good reason, and being liberal in passing around the credit for the work.

Answer 10

I have found that the best way to maintain credibility when you ask for help is to offer help in return on other occasions. In my pair programming opportunities with less experienced colleagues I don't have as good a memory for details, but I usually have a better insight into what will make a cleaner design or where a bug is most likely to be.

I think that's because, for example, the details of the syntax and standard libraries of the language we're programming in get mixed up with the dozens I've used over the years, where a younger programmer has only used one or two. But that breadth and depth of experience helps me form insights that are harder to intuit otherwise.

And when those flashes of intuition hit, your pair programmer will fully appreciate what value you bring to the table, even if they know all the trivia you have to google.