How to demonstrate technical leadership skills in a situation where my inputs may not be welcome?

Question

I work at a large software enterprise. Multiple orgs, multiple teams, huge hierarchy of managers and managers of managers.

I am a fairly senior individual contributor with more than a decade of experience, and I think I am good, and have fairly deep knowledge in my area of expertise.

Recently during a one on one with my manager, i asked him what I could do to get promoted. My manager said that I am doing well in the team that I have been assigned to, even identifying and taking on problems that nobody thought about, coming up with new ideas, new solutions to improve things, cut costs etc. But, in order to get promoted faster, I should show cross organizational leadership and also get good recommendations from teams that I do not work with.

He pointed out to me that a team adjacent to ours is facing problems in what happens to be my area of expertise, and I should go talk to them and help them out.

So I go and talk to the members of the other team. Once I know about their problems, a couple of things become obvious to me:

1. They are doing it wrong. Now, I am not the world's foremost expert in the area of my expertise but I am fairly good. And, to check my biases, I described their problem and their approach, to my peers outside my organization and they agreed with me.

2. There is an easier way to fix their problems. I am fairly sure I can whip up a prototype over a week or two, and make it production ready over a 2 or 3 months, with a little co-operation from the other team. Again, to check my biases, I talked to my friends and peers outside the company and they seem to agree with me.

3. The other team members are far too deep into their way of thinking, and have invested close to two years in trying to make their approach work. They haven't made it work so far and given the way they are going, I have serious doubts they will, even if they take another six months or so.

4. They get super defensive when questioned about their tech choices, and become tense, curt and even passive aggressive. At this point they are far too invested into this solution and there is too much sunk cost. They will pursue their solution come what may, because they are also hoping for career progression based on their work in that area.

What do I do in this scenario? I don't think doing nothing is an option because my manager will count that against me and use that as a data point against promoting me.

I can spend some of my personal time, rapidly prototype the solution, and demonstrate that it works, but this can backfire against me in a couple of ways:

1. By doing so, I will have just demonstrated my individual contributor skills and nothing more. I don't need to demonstrate that, and I am already at a level where such skillset is expected of me. Best case scenario, they will give me one off some quarterly award that means nothing in the long term.

2. The other team will not like it one bit. They will try to poke holes in my solution and even if I am confident of defending my solution, it will be a long drawn out and will take too much of my time and will have little chance of succeeding and will eventually lead to nowhere.

How do I approach this situation? How do I demonstrate technical leadership and conflict resolution skills in a way that will help the other team and also make me look good and take me closer to a promotion?

Answer 1

Have a talk with your own manager.

• Explain what you've learned about their technical problem.
• Explain what solution they're currently pursuing.
• Explain what solution you have in mind.
• Tell him that the impression you get is that they're not open to different solutions than they're currently pursuing.

Now ask your manager how to proceed. His job as a manager was to see that another team had an issue, and he thought you could provide a solution. You could, but run into "meta" problems, and that's his ballpark.

He should help you decide whether this is just not going to work (the other team doesn't want to be helped), or whether it should be done anyway, at which point you can ask him for help softening the ground and smoothing ruffled feathers.

This could go either way and it's a management issue, therefore you need to get your manager's input.

Answer 2

First of all, make sure you are approaching them in a official capacity, not just as a colleague-met-next-to-watercooler person.

Couple of steps, when you are working as an adviser for a team which is not directly being managed by your superior:

• Ensue your manager and the manager of other team is aware of your involvement.
• Document everything, all conversation and suggestions.
• Ensure that you follow the rule: "Show, don't talk". Some people may not like the fact that someone from "outside" is coming and imposing their "expert opinion" on the team's internal tasks, thereby essentially questioning their team's capability - avoid that. So, point out the pros and cons of all the approaches / improvements you have to suggest, and let them make a choice for the solution.

Remember, you don't make the decision for them, provide them with the options, weigh the options from a third-person view (someone outside the team) and help them choose a better option. If they are resisting a good proposal because of their politics, it's their loss. You have your inputs documented and circulated - use that to show your involvement to your manager.

Answer 3

You need to earn their trust and respect as individuals (or at least the trust of one or two of the more senior members of the team).

You say that you're confident that their approach to the project is flawed. That doesn't matter as far as your short term goal is concerned.

Instead, try to offer your help to deal with immediate problems they're facing. They can't work out why a test is failing? "Hey, I can help you with that". They're having trouble understanding how some library works? "I've used that before, I can peer program with you for a while if you want".

You might feel that this is useless - the whole project strategy is flawed, so helping them is a waste of time! It's not. You're using your time to build their trust, and to teach them that you're a person they can rely on, you know your stuff, and that listening to you gets them good results.

This won't be quick to do (think months of consistent support), but once you've done it then that's probably good enough to meet the goal your manager set - they'll be happy with you and give positive feedback.

If you still want to go above and beyond and actually help their project, then you'll have the capital to do that now. Not as an outsider coming in, questioning their choices and trying to order them around without any authority, but rather as a trusted colleague who has a track record of fixing their problems, and who is having (another) useful conversation with them.

Answer 4

Part of technical leadership, or really any leadership, is the politicking that goes along with it. It helps to have a higher level understanding of what's going on.

You need buy in. You can tell them they're wrong, you can explain why they're wrong, but unless they agree they're wrong it doesn't matter. In their reality, you are interfering. In their reality, you are a problem.

Are you? Probably not. What you're saying sounds reasonable to an outsider. You don't have to convince outsiders.

I've often run into issues when I see some other department doing something that is a giant waste of time (and therefore money). Why spend $50 when you could waste 3 hours of 3 people's time (At least $400) instead?

It's simple really. From that team's point of view, spending a dollar to save a dime was perfectly reasonable, because it wasn't their dollar. That $400 is externalised and they saved $50. The real issue however, is that the manager already spent $600 they weren't allowed to, and spending $50 proved not only did they disobey orders, they didn't even get the results they needed.

From that managers point of view, he wasn't spending $50, he was admitting he wasted $600. Who wants to admit they wasted $600?

If I had to guess, someone is covering their rear in this case. Depending on how your company looks at the distinction between "progress" and "failure" it could mean they went down the wrong path, and are working towards a better solution once new information became available, or it could mean that they're incompetent. If they make you go away, they don't have to worry about it.

Sadly, this is very common. Most businesses measure how hard people work and not how much they get done. For many people, it's easier to "just do their job."

Your job as a leader is to cut through this and act in the best interest of the company. It's even possible your manager knows this is a problem and wants to see how you handle it. How you do that very much depends on the people themselves.

Answer 5

It is very hard to help someone who doesn't report to you and doesn't want your help. Maybe you can take a step back and focus on the teams, individuals and problems where your help is appreciated.

When stepping in a broader technical leadership role, you will more often have the situation where you don't have a clear mandate and your role is not defined. It is up to you to figure out where you can have the most impact. Generally you have a lot of impact where: - you are the right person for the job - business priorities are high - you have buy-in - you can act as a multiplier

In the scenario you describe you can check the first two boxes, but not the latter two. You could suggest a solution that isn't adopted or do it on your own, but either way your impact would be limited.

To get buy-in you not only need to find the right person to trust your abilities, but also needs to have the same interests. It sounds like you approached the engineers in the team directly and they either didn't trust your approach or what I think is as likely, didn't have any interest in changing their approach: It could look like they failed if they give up their approach and they are probably emotionally invested in what they came up for themselves. At the same time, the business goals very removed from the typical engineering team.

What I would suggest in your situation is to find the right people who want your help. These could be: 1. Someone else in the team that has an interest in pivoting 2. A stakeholder of the team that has some influence on how the team is working 3. Engineers in a different team, that have accepted that they can use help on another problem.

Let's get through the options:

1.) Another person in the team

Sometimes not all the members of the team see a need to change their approach. I have often seen team members working on a solution that took a lot of time, because they didn't feel a pressure to deliver quickly. If a team is working on a project without results for 2 years and they still get good reviews for the code they wrote, they might not have an incentive to change. The team lead of or product owner in that team might be in a different situation and more aware of the importance of finishing the job. Usually those two roles are the ones who has to justify missed deadlines and exceeded estimations. If you can convince one or both of them that their current approach has a risk to drag on for a long time, they then can influence the rest of their team and change their incentives.

2.) Stakeholders of the team

In some organisations it is possible that the whole team is doing fine with a flawed approach. If the managers of the team can convince upper management that delays and faults are expected and non-avoidable even the product owners and team leads might not have an incentive to change. As long as that is the case you will have a hard time to convince the team to change their approach. In that case you can look outside of the team and see who has an interest in the project to be done soon. There might be another team that is blocked by the delayed project, the manager of the product owner, that is eager to release etc. You can suggest your approach as "Plan B" or as an intermediate solution to "temporarily" solve some of the problems until the original project is finished. You will be looking for the person that has a strong interest in your solution and influence to either fund your approach (or proof-of-concept) independently, or to make the original teams change their approach.

3.) A different team with different challenges

This feels a little bit like giving up, but you don't want to waste your time with a team that rejects you. If there another team working on a high impact project and is open to your help, you can have much more impact with less effort. If your manager doesn't have a concrete expectation that you help with team A, but just suggested it as the most obvious solution, it probably doesn't matter to them if you suggest instead: "Team A seems pretty set on their solution, that I don't think I am the right person to help with. But I think I can help team B with their problem instead, which is an important thing to solves as well." Write down your proposal for solving Team A's problem, and keep it in the drawer when the time is right.

Don't waste your time trying to convince people who have no interested in adopting your solution. Find the person who has the right influence and who is open to your suggestion.

Answer 6

TL;DR;

I would recommend you stay away from that as it will ultimately be counter productive. You were told to

get good recommendations from teams that I do not work with

you instead are on the path of making an enemy of another team.

---

Just to provide a different point of view, all the other answers actually assume your evaluation is spot on, to me, this sounds like you're being overconfident and you should exercise caution.

I'll rephrase what you just explained to try to clarify:

I've had a series of conversations with them and I think I can do in 3 months but my self what their whole team hasn't managed to do in 2 years

First off, yes, no wonder they get defensive.

Secondly, you should reevaluate your appreciation of the work done and, more importantly, consider there's just way too much information in a 2 year project to be able to grasp all the intricacies and complexities in a couple of conversations.

I'm sorry but, unless the other team is completely incompetent and you do know for a fact they are, it's just far more likely that you are underestimating the scope of their project. Technology choices and architectural approaches can hinder a project timeline significantly, but not to reduce it from, let's say, 5 or 6 man years to 3 man months, that's simply very rare.

I can spend some of my personal time, rapidly prototype the solution,

There's a huge leap between the prototype and the final solution. Mostly the fact that the prototype does not have to concern itself with all the side cases, edge cases, sad paths, unexpected cases, performance concerns, security concerns, etc

This is likely to be taken with resistance and with good reason. You're not offering to help, you're offering to remake their solution based on a couple of conversations. If this was my team I would honestly be pissed off... not because of the offer of help itself, but because of the surrounding implications attached and, honestly, the arrogance that comes with it. Even if you're right and the arrogance is justified, the end result will be the same, another team that is pissed at you, which would NOT help on your promotion.