Senior engineers - how do you go about building soft power, and establishing credibility?
Posted by ecethrowaway01@reddit | ExperiencedDevs | View on Reddit | 172 comments
For a bit more context - I've worked with a variety of senior engineers (L6-L7), and a lot of them are good, and a lot of them suck.
The most common thing between good leads / >senior engineers is that they're very good at establishing "soft power". People trust their opinions, people want to work with them, (generally) what they say, goes.
I've seen lots of more senior engineers not succeed at this. There's some common patterns that I see that hurt trust, like:
- Lying to people, or even just frequently being wrong about claims
- Stressing people out by having meltdowns or just generally being very negative
- Spending time picking fights or trying to come down on someone
But I've also seen engineers not do these and not establish a ton of soft power. For those who've succeeded at this, how do you accomplish it?
Vast-Statement9572@reddit
Competence, pure and simple. Does help some if you genuinely believe in the enterprise in which you are engaging.
Capable_Hamster_4597@reddit
Build some impressive shit and stand in front of your team when the business side is coming down on them. That's what I respect about my seniors, with anyone else I just play the game.
OutsideAd6229@reddit
Find the tree closest to the office and pee on it
Orca-@reddit
Being right, a lot. Solving problems no one else could solve. Being good to work with. Helping other people solve their problems.
Being visible doing all of these things.
Forward thinking and obstacle avoidance here is for your own benefit, being seen to put out the foreseeable fires is unfortunately typically better rewarded.
Yes, it is extremely dumb.
dfltr@reddit
BEING VISIBLE DOING ALL OF THESE THINGS in case anyone missed the incredibly important but somehow constantly overlooked part.
Doing great work is step one. Getting credit for great work is steps two through five.
Dearest-Sunflower@reddit
How do you learn to be visible doing good work? I'm currently feeling overlooked and under-credited for my work on a group project.
For context, I'm currently a college senior but I get to take grad-level courses because of my performance. This is for a group project, and I do most of the code implementation and contribute to ideas but I'm not taken seriously because I'm younger than everyone else. I think it's because of my communication skills (lack of assertiveness or being too wordy).
I know I'm very very early in my career but I think visibility would be an issue if I don't work on it now.
maholeycow@reddit
Totally agree. It’s a bit of a drag, I don’t like to talk about myself or explain how what I did was really great, but once I got over it, my raises and day to day have improved so much. There is a way to be tactful about it and it really does help if you can elevate others around you when calling out your accomplishments because then others do the same for you.
GlueSniffingEnabler@reddit
Yes this is my struggle. Looked deep into my soul to try and figure it out and was eventually diagnosed with a social anxiety disorder 😂 no wonder I struggled! So working on that side of things the most for now instead of actual work work.
miredalto@reddit
I wouldn't say that's necessarily a goal for soft power. Being visible to management may get you hard power, but people who chase visibility can be resented by their peers if they overdo it. Soft power comes much more through individual interactions.
riplikash@reddit
Kind of depends on the KIND of visibility you're chasing.
If your focus is on getting visibility for other devs, those under you, and other people you work with it builds soft power quickly. You still get the benefits of visible management, but also the good will of others appreciating your support and help.
TheMrBoot@reddit
On that same token, especially if you're in a lead role, take the opportunities you get to highlight the work of the folks on your team. Encourage them to get out there, highlight and credit them where you can, etc. It helps them in their careers, and also helps you get more experience and visibility as someone who can help their teammates be successful.
auburnradish@reddit
That’s what I do. And often the skip level boss would think I was not pulling my weight.
zippysausage@reddit
Also, owning a mistake and making it public in a positive way.
For example:
I temporarily broke the server because I left an errant space in the yaml. I've fixed it now and mitigated it happening again by using a linter in my local dev environment, but also in the pipeline to prevent bad config shipping in future; and updated our documentation, here's a link. Feedback welcome.
This demonstrates humility, honesty and builds integrity. No one gets here without making mistakes, it's part of the job and we can make good of the bad.
Difficult-Battle-330@reddit
Was going to say this if no one else had.
Be right, a lot, and immediately honest when you’re wrong.
Healthy_Razzmatazz38@reddit
This is it, theres a whole lot of things people tell you about how to succeed. The truth is if you're kind and right virtually everything else is marginal.
Just the other day someone asked me what the most surprising thing about being a staff engineer was and my answer was just how important it is you're virtually always right. If you're wrong even like 5-10% of the time, everyone under you will notice and not trust you.
Zambeezi@reddit
I would push back here and say that it’s about being right most of the time, but gracefully wrong occasionally.
As long as you’re right more often than others, and gracefully accept to learn when you’re wrong, in the end, it won’t matter if you make mistakes. Because, honestly, who doesn’t ?
seattlecyclone@reddit
I'd say being right when you claim to know what you're talking about is what's important. Just as important is the ability to realize when you're out of your depth, saying so, and deferring to the opinion of a teammate whose expertise you trust in that area. Boldly saying "I don't know" when that's the case can give your opinion more weight when you do offer one.
compute_fail_24@reddit
Knowing who knows the answer and asking for their opinion often builds your own credibility too. If you’re smart enough to know when somebody else has the better answer, you become more credible for anything.
boricacidfuckup@reddit
So if I am still junior/mid-level, asking specific people that I know have the knowledge I need for help builds my credibility? How?
Delicious-Fruit-2953@reddit
Part of my being able to trust someone with a problem is trusting them to ask for help when they need it instead of bulling their way through. Recognizing what you don’t know is as critical a skill as any other in tech. If you’re unwilling to ask, or unable to know when you should ask, you are way more likely to waste time on a sub optimal solution
Demonox01@reddit
If you're still junior / mid level you're likely still honing the skills you need to effectively plan and ship projects. You gain credibility by communicating clearly, taking opportunities when presented, and asking for help.
This kind of soft power talk is when you're in a senior+ position and starting to cap out on your individual ability to contribute more. At that point your ability to improve the speed and quality of others' work is more important than your ability to do work. This can be mentorship and supporting others, but the path forward at that point is going to involve supporting other teams and getting other people to support your decisions and go your way.
TheMrBoot@reddit
Not the person you replied to, but I'll take a stab at answering. Soft skills are important, and part of that is building up your professional network. Being someone who people can come to with their problems and you can either route them to the appropriate people or, even better, get those people working together and moving forward, is an important skill.
You could probably distill it down to being a good facilitator in some ways; knowing the right subject matter expert to pull in for a given topic can be just as helpful in some ways as having the answer yourself. You'd be amazed at how much people will reach out to and rely on you if you're known for being able to herd the cats.
im-a-guy-like-me@reddit
I've heard people refer to it as a "force multiplier" which fits pretty well.
HugeRichard11@reddit
It could be said that pointing someone in another direction is a correct answer in itself. Additionally you need to understand the question itself and the correct person to know who to point to. Both of those don’t come easy.
If you didn’t understand the question or pointed them in the wrong direction that could likely lose credibility for you too.
Healthy_Razzmatazz38@reddit
thats the polite way to look at it, but at a high functioning org i promise you will get fired as a staff engineer if you're wrong over 5-10% of the time.
its totally fine to not know provided you can figure it out and circle back, but being actually wrong is not okay. For junior/senior maybe is fine, but at that level its just not.
compute_fail_24@reddit
You got downvoted but I pretty much agree. If you don’t know the answer you need to have a good idea that’s the case and either figure out the answer or understand how to get it.
DarkFusionPresent@reddit
Agree. At that level, if you mess up, it's a lot of money down the drain. If there's uncertainty, it should be explicitly called out and addressed as well.
Zambeezi@reddit
That’s also a very fair point. In this case we can maybe term it as “gracefully ignorant”?
tcpWalker@reddit
I think it depends what we mean by wrong, too. I figure I'm wrong most of the time, meaning that most of the time I do non-optimal things. I am much more likely to be close to right or occasionally even optimal in areas I know better. But it's still a journey.
That being said, there's a much more extreme version of wrong where you just say things that don't make sense even without much context or don't know what you're talking about. And where you don't show any signs of learning. That's not even ok in a junior IMHO; but I've definitely seen it in seniors and even principals from time to time.
Orca-@reddit
Yeah, being right but an asshole can work, but only if you're right all the time and not so much of an asshole you're a net drain.
You get much more leeway by being graceful about the whole thing.
rgbhfg@reddit
Eh agree and disagree. Taking risk, and being right about 1/3 of the bets is a great batting average. It’s about knowing when to take the risk, and when not to.
coworker@reddit
Staff engineers are paid well not to take risks since losing those bets they waste other people's time.
KoreanThrowaway111@reddit
Being right about unpredictable things like “how will this perform at scale” is sometimes hard
BrobdingnagLilliput@reddit
...and honest. Which is easy to do.
c0nsumer@reddit
Being right, being sure others know what you did in a non-braggy way, and being nice about it.
It's kinda silly sounding, but I highly recommend the (old) book How To Win Friends and Influence People.
On it's face the book is about sales, but it's really about how to get along with people and have them want to work with you. (Because, after all, sales is about being friendly and working with people so they buy stuff from you. But all of this also applies to coworkers who want to "buy" your work.)
VettedBot@reddit
Hi, I’m Vetted AI Bot! I researched the Dale Carnegie How to Win Friends Influence People Book and I thought you might find the following analysis helpful.
Users liked: * Life-Changing Advice (backed by 4 comments) * Practical and Applicable Principles (backed by 4 comments) * Excellent for Personal and Professional Growth (backed by 5 comments)
Users disliked: * Outdated Examples and Anecdotes (backed by 5 comments) * Repetitive and Lengthy Content (backed by 3 comments) * Poor Book Quality (backed by 1 comment)
This message was generated by a bot. If you found it helpful, let us know with an upvote and a “good bot!” reply and please feel free to provide feedback on how it can be improved.
Find out more at vetted.ai or check out our suggested alternatives
RailRoadRao@reddit
Exactly, I can attest to all. Have been doing it and it's being really appreciated by my team.
Fluffy-Bus4822@reddit
Interesting to read this. Because I've done all this, to a pretty extreme extent. But it didn't actually work well for me.
I was employed at the company for very long (6 years), so that might a success in itself. But I never figured out how to have my opinions taken more seriously. It was actually a relief when I got laid off eventually. Didn't have to deal with that frustration any more.
I think sometimes you can do everything right and still fail. Good to keep that in mind. Sometimes you fail because of things outside of your control.
me_gusta_beer@reddit
My company has a robust internal blogging culture. Every successful project I’ve lead or been a part of, I create a blog where I lay out what we did, how we did it, and the benefits we unlocked. I also make sure everyone on the project LOOKS GOOD.
schmidtssss@reddit
I’ve also found that throwing credit to your teams when (within reason) folks know it was your play also builds a lot of clout on both ends of the spectrum
ravigehlot@reddit
You summed up decades of experience perfectly.
Exotic-Draft8802@reddit
This.
I guess there are different styles. My core trait is reliability: if I say I'll do something, I'll do it. If I say something will be done until X, it is done then.
Being friendly and clear in communication. Help people solve problems and have an eye on a lot of different topics to tell people upfront what to watch out for.
Learn the strengths and weaknesses of the team members. If they don't like a certain type of task, try to avoid that they have to do it. For example, I have a super skilled fellow backend dev who hates to document stuff. When I can, I write a draft and let him review it. No issue for me and he gets rid of having to think about the overall structure / where to put it. He just needs to iron out some details.
Or finding balance: strict reviews are mostly good, but at some point it becomes annoying. Then I switch to "does it provide value" and "would it cause issues" instead of making it perfect. Or I tell them that I could take over and iron out some remaining issues.
Xcalipurr@reddit
Amazon LP hitting outta nowhere
Agifem@reddit
That sounds like a lot of work. Do you have a simpler plan, something like "top 3 things soft power engineers don't want you to know" ?
daguito81@reddit
Even the first point is a bit optional compared to others IMHO.
I’m a guy that has some soft power (as OP called it ). But I’m not any kinda of super genius or savant or anything like that. I just like helping out people and I’m very social.
Sometimes I even get on a call see the problem and I’m like “Well I have absolutely no fucking clue, but let’s see if I can help “
Sometimes being the ignorant person in the call helps because you bring fresh eyes and could ask the right questions that helps someone have that “A HA!!” Moment . Sometimes I’m just a human rubber duck for debugging.
And that shit spreads. People hear that “you helped X” And “you helped Y” then their bosses keep hearing things. Your boss hear things as well. I also have to tell them that I spent some time helping X from Y fix something and that delayed me. But they’re cool with it because they like that we are seen as a group that likes to help other people. And we buy that with a bit of inefficiency and we’re cool with it.
You start getting some reputation and then it goes from there
So the must-haves for me would be. Willingness to help people when they need it (not when it’s convenient for you) . Be nice to work with (a crisis is always easier to manage with a bunch of jokes in the middle). Be visible (this can be easier said than done. But it’s fundamental.
A nice to have would be being a super expert, and extremely knowledgeable
Constant-Listen834@reddit
This is all great advice. People also need to keep in mind it takes 2-3 years of this to really build a good rep.
Fidodo@reddit
The best way to be right all the time is to change your mind. I'm opinionated, until I hear a better idea, then I'll flip my position on the spot.
janyk@reddit
I must be misinterpreting you here, because this sounds really fucking great. I'd love to be able to do quality work that puts out the foreseeable fires and be rewarded for it rather than have to work fast and cause regressions that we'll all have to fix during a crunch time later.
Jhohok@reddit
They are saying being the firefighter is more rewarded than preventing the fire.
Orca-@reddit
Ding ding ding ding ding
I prevented a massive forest fire by being forward looking.
No fire, I was quietly patted on the back and got my at-level bonus.
A coworker got well above target bonus thanks to putting out a bevy of fires of his own making.
Firefighters are visible, fire preventers are not.
auburnradish@reddit
Indeed. Often the higher ups don’t have enough context, time or interest to understand how much waste was avoided by forwarding thinking or just by asking a critical question at the right time. It’s frustrating.
janyk@reddit
Oh! I can see it now, but it seems like the phrasing is backwards. It sounds like he's talking about putting out the fires before they happen as a bad thing. I'd phrase it "Being seen to put out the fires which could have been foreseen..." to make it unambiguous.
Jhohok@reddit
It's a bit of a run on, but it's still pretty straightforward imo
Preventing the fire is only for intrinsic benefit (i.e. you don't need to fight a fire since you prevented it) without any extrinsic reward.
Visibly putting out the fire is extrinsically rewarded
Ace2Face@reddit
It makes sense. We don't have the mental capacity to reward people with foresight. However I can also attest that as a former lead, I was frustrated how one developer was putting out lots of fires, but a lot of those fires originated from the code that he's responsible for. I don't like fires happening, if your manager understands your role and your work well, purpusefully creating shit code or cutting corners won't pay off in the long run.
dfltr@reddit
Ain’t no heroic statues of building code inspectors.
Bohred_Physicist@reddit
Is this jargon from the rainforest company?
revrenlove@reddit
Which is further galvanized when one maintains humility.
I've worked with a couple of "rock stars" that had respect from the higher ups due to deliverables and getting shit done, but they weren't very respected by team members because they had an ego.
kingmotley@reddit
Making other people look good to their bosses by helping them hit their goals on time.
Orca-@reddit
Hah, yeah, that's a much more succinct way of putting it.
excadedecadedecada@reddit
I think you're supposed to just find the highest ranking engineer and kick his ass?
justUseAnSvm@reddit
In my last three roles, all senior, I've been able to become tech lead using soft power skills. I attribute this to a little bit of luck, and a lot a bit of prep. If I had to reduce it to a list of things to do, it'd be this:
First, Identify and take ownership of problems that would risk delivery. Not just any old problem, but going out, finding things that really hurt the team, and taking it upon yourself to take this risk away. Along with this, is that when you get something done, it's actually done, and others are able to use this. Like you don't get involved without making things meaningfully better.
Next, would be the art of being "less wrong". Think carefully when you speak, and only say things when you are sure. You will be wrong, but it really helps if people can trust your opinion.
Know the priorities, and shape the direction of the team to align to these priorities, focusing effort on things which get the priorities done, and deferring on everything else. When you understand the entire project and exactly what you are trying to do, you can make incredibly compelling arguments, since you always relate things back to the goals everyone decided on.
Finally, and maybe the most important, is to take a positive tone, be enthusiastic about doing the things you like, and hold your tongue when you have criticism. Along with this, is that you need to be the type of person who people want to work with, and that means sometimes making sacrifices in order for them to shine.
The silent factor here, is technical depth and experience in various research and engineering environments. If we are using a database, or shipping a web app, or building a product for people using ML, I have a set of experiences that I can fall back on to identify risk or offer guidance.
mayreds19@reddit
Thanks for the details. I like this answer a lot
kbbqallday@reddit
For the being less wrong point, I’d say it’s more important to accurately describe your level of confidence in a statement.
When you give high confidence in things you know and mid-low in areas of uncertainty that you’re trying to drive alignment on, you’ll end up looking better in both situations.
justUseAnSvm@reddit
Definitely. Sometimes you you just sort of spitballing.
The other thing I do is to put your feedback in the form of a question. "Is this going to handle concern X?", if I'm not highly confident. Just straight up platonic method will be annoying.
pocky277@reddit
Thanks for this! Can you give some concrete examples from your experience of the first point? The one about problems/risks? I’m having trouble visualizing what this means.
justUseAnSvm@reddit
I joined a project after the initial architecture was “decided”, and could come in and say stuff like: “this X won’t work, here’s how Y would solve that problem”.
Concretely, it’s stuff like looking at a streaming abstraction and realizing that won’t work without mini batching, and that our system didn’t fit a streaming abstraction. I didn’t actually propose the solution, but I outlined the problem and brought in help from the org Sr Staff folks.
Another example involved modifying source code. The team wanted to use a regex, but that will never work. I found a code modification tool, showed how it would work using a parser approach, et cetera.
Another example is designing DB schema. Given our access patterns, the schema would have been slow for one very frequent operation. I basically just pointed that one out, and after a quick load test the original PR author realized it was a problem too.
As much as I do this, I’m also pretty quick to defer to others when they say: “yes, I thought of that but we are good”. You gotta approach it like you bring a problem, get validation, and then if the other person doesn’t or can’t solve it, you do it.
BigLoveForNoodles@reddit
One-Willingnes@reddit
This is super important.
If you guess or give non concrete answers it is a big issue, a lot bigger than most think.
slyiscoming@reddit
chance909@reddit
Accurate time estimates of work.
If you can accurately estimate your work effort, and then deliver on time (because you have an accurate estimate), everyone will trust you and your comments on the next project.
Kavinci@reddit
I've always seen office politics as very Machiavellian. I recommend reading "The Prince" by Machiavelli. This book addresses the issue of gaining and keeping power. Take it with a grain of salt though, not everything will apply and the thoughts expressed should be taken abstractly and not literally.
joshsamuelson@reddit
I learned a ton about this from getting trained as a community organizer. If you ever have a chance to go through that training, I'd highly recommend it.
The rough process is something like this:
Have authentic 1-1 relational meetings and conversations where you just get to know people and understand what matters to them. This should be a mutual thing, not an interview, so they'll get to know you and what matters most to you. These people are known as your "base"
Spend some time thinking about where your mutual self-interest lies and look for a self contained issue or problem that most of your base will care about. You can also do this in conversation with your base. This is called "cutting an issue"
Come up with a project, task, activity to address the issue in some way. This activity is called an "action" in organizing. It doesn't have to be something everyone in your base will care about, but preferably something that will have a meaningful impact on the most people. Talk to your base and confirm that they think it's worth doing. This also helps in situations where you'll need management approval for the project. Build consensus before you present the idea.
Do the action. In the case of presenting an ideal for management approval, that's a self-contained action, then the actual implementation would go through the cycle again. In the case of an approved project, it's just implementing it, preferably as a collaboration.
Check in with your base about how it went. Did it actually address the issue? Are there more steps needed? If it didn't work out, what went wrong? Who else has shared mutual self-interest around this issue who might help? Is this the right issue, or should we refocus? etc. Identify future leaders who might own future iterations of the process.
Celebrate the progress, regroup for the next cycle, gather ideas for the next step, and repeat the process.
The concept of mutual self-interest is really key for making this work. It can't just be what you want, or what you think your coworkers want, or what you think the CEO wants, it's got to be in the self-interest of the actual people doing the work. But most people are highly motivated to work hard when it's in their own self-interest.
PragmaticBoredom@reddit
This is very good advice. I’ll double emphasize the importance of having authenticity throughout this process. It’s becoming more and more common to find people in the workplace who take steps like this and turn it into performative paint-by-numbers relationship building.
At one job I had a half dozen weekly 1:1 meetings scheduled from managers, leads, and ladder climbers who wanted to talk about personal lives, our childhoods, and everything else under the sun except for work for 30 minutes of the 1-hour time slot because someone high up at the company set the precedent that you need to build personal relationships to move up. I’d spend literally hours every week going through highly transactional “relationship building” as the work piled up. Nobody liked it and it obviously did not achieve the intended goal.
psyflame@reddit
This comment is gold. Thank you.
joshsamuelson@reddit
Thanks, I'm glad you got something from it.
I think part of what I like about this approach is that it takes the mystery out of the process of building consensus and "soft power" as OP put it. It nice to have a systematic approach rather than just "be really smart" or whatever.
My background is mostly in DevOps/SRE roles and I've found the organizing cycle works well for finding and removing pain points. e.g. in the release process. Because you're doing the work to figure out what people actually want and need it means that the project you end up doing will have a much bigger impact.
It also pairs well with ideas from Goldratt's "The Goal" too: https://www.amazon.com/Goal-Business-Graphic-Novel/dp/0815385137
SpiderHack@reddit
Fix lots of small problems, and appear to be solving the problems that others are having.
I go around and have 1:1s with every stakeholder, and ask them what pain points are they are having and tell them I'm just doing this on my own to try and get an idea of how I can maybe short term, but if not, then long term try to reduce everyone's pain points.
This sounds like it is simple, and almost cringe, but it works and builds so much good will with people that you can't help but build soft power.
The other thing I can recommend is solving the lowest hanging fruit first. Improving throughput of PRs by working on automation/CICD, etc. (so often this is always a place where improvements van be had).
Also, work on people making more numerous smaller PRs and not bigger ones that then get hung up for weeks due to nit picking in PR review. If any person complains about PR review that is almost always the answer (to most questions), cause even if the nits are the same #, they can get the smaller PR in faster, which means that changes from that PR can cascade into future PRs and make it so that they have less nit exposure area. Etc.
madprgmr@reddit
It's quite possible that someone having a meltdown isn't doing so by choice, especially given how many people on the autism spectrum end up in the software industry, but rather have been pushed well beyond the stress levels they can handle.
frontAND-more@reddit
I'm glad you picked up on that. Everyone else seems to think about sharing their advice but no one stops to ask what led to people having outburst in the first place.
yojimbo_beta@reddit
The fact OP has been given feedback that s/he's raising the team stress level is a big worry here
Flag_Red@reddit
I don't think OP was implying that.
Just that it's not good for your career.
madprgmr@reddit
Fair, maybe I am just coming at it from a manager point of view where viewing such things as them needing help rather than as something that harms trust, like OP said.
ecethrowaway01@reddit (OP)
Ah, I didn't mean to imply it's deliberate. As someone who's also got feedback on stressing people out, I know it's tricky expressing concern while not raising the temperature in the room, so to speak.
This might sound harsh - I think an expectation of a good leader is that they don't stress people out unnecessarily. If you're a team or org lead and always stressing people out, they aren't going to want to work with you.
yojimbo_beta@reddit
If you are getting feedback that you are raising stress, that implies multiple people have spoken to your manager about it. In that case I would make my number 1 priority to fix that perception before trying to coach engineers to "just handle it better"
Rynxt@reddit
Good leads reduce stress, they act as a shield for those under them. Stressed developers solve problems slower and the solutions they do get tend to not be as good.
madprgmr@reddit
Ah, I see. I appreciate the clarification.
frontAND-more@reddit
I really like this question because I'm baffled at my lead's ability to wield his "soft power" almost like Jedi mind tricks.
He actually outplayed me to a point where I was pushed out of the team because to me this type of power wielding came across as manipulative and it got to a point where he actually ended up stepping on my toes so much that I said f*** it. I'm out!
The secret sauce is to know when you have it and not abuse it or people will feel sidelined and to really mean it when you say you value people's opinion otherwise people like me will jump ship.
What I've learned from studying my lead is that he's only effective because he definitely gets things done and delivers, but he also gets his way and I tried figuring out how he does it.
Unfortunately so far I can only say: either you got it or you don't lol.
As the other comments state, for a large part it is about technical know-how too, that's for sure, but personality plays such a huge role that I can't see how this degree of practice can get you to this level of influence, but again please be careful about how you use it when you have it or you'll suck the oxygen right out of the room :)
nathism@reddit
I'm a senior engineer and learned mostly on the job after starting from a wildly different path.
Eventually you end up being the guy in the room that everyone else looks to to answer questions and you think to yourself "how did I get here?"
~Cue the talking heads...
hell_razer18@reddit
I call this social capital. Like others mention, did a right thing most of the time, take responsibility a lot of the time that nobody doesnt want to and in general dont be a dick. If you made a mistake, admit it. If you did well with someone else, praise them. Try to be the light house of your team/dept/org as best as you coupd be. Regardless of that, there will always somebody that compete and against with you so mind that as well, it is okay for agree to disagree
daototpyrc@reddit
Huh, just do other peoples work while they are busy arguing.
Nothing shuts people up, senior or not as fast as: "Oh this ticket that has 20 hours assigned to it, sorry I just implemented it while you two were arguing about if it should be 20 or 18 hours".
Shadow_Mite@reddit
I’m basically google for most everyone around and I can see problems wayyyyyyyy before they happen. The other thing I’ve always done is provide examples for claims beyond just saying “that won’t work”. Also encouraging people to try things as long as it won’t eat up too much time and not being a code nazi in PRs helps a lot.
ezaquarii_com@reddit
Bread, meat and potatoes:
1. care about others
2, being right
3. solve problems
matthedev@reddit
If you've ever played any of the computer games from the Sid Meier's Civilization series, you will know there are many types of victory.
Akin to a science victory would be introducing outside expertise to an organization. You can productionize cutting-edge research and theory or introduce technologies that are new to the organization. Your depth or breadth of knowledge makes you someone people turn to for advice and assistance.
A culture victory would be adding a positive energy to the organization that makes people happy to stick around and to refer their friends. Maybe it's mentoring the less experienced developers on the team or planning hackathons. You may bring innovations to process to make the work feel less like a chore. You introduce practices around documentation to ease onboarding of new hires and automate routine tasks that no one else got around to doing.
A diplomatic victory relies on promises and reputation as currency. You've found a way to gain powerful others' backing for promotions in exchange for whatever it is they're looking for (favors returned after your promotion has been achieved, projects delivered, misalignment and tensions across teams or stakeholders defused).
But sometimes soft power just isn't enough. Your manager or your manager's manager may want to keep busy but boxed in doing uninteresting and career-irrelevant work. Maybe, ideologically, they subscribe to "founder mode," justifying to themselves their use of skilled engineers as just another pair of hands, a "fungible resource." Maybe IC-level coworkers subscribe to a corresponding "hardcore" ideology, locking everyone in to a competition of busyness and expenditure of great effort. The opportunity such an environment provides is a study in hard power; there may be little room to exercise softer forms of power mentioned above, and an individual contributor won't be vested with the traditional instruments of authority: direct control over assignments, budgets, promotions, hiring, and firing. You may have to actively break expectations and jam machines designed to keep you busy with your work pre-chewed, and your performance closely monitored through numerous metrics and daily status updates; but that stuff's garbage to be tossed aside. Making waves will undoubtedly make some people uncomfortable in the process. Ultimately, you will know you're making progress if managers stop and adjust themselves before addressing you instead of issuing orders and managers are starting to implement your ideas. The goal is to modify the flow of work so that your day is not spent working on an undifferentiated pile of tickets and emergencies.
billybobjobo@reddit
Be really good and kind.
lovelacedeconstruct@reddit
Yes , I am pretty sure my senior engineer could do my entire job in 5 minutes yet he spends 15 teaching me what to do , I dont think I can do that yet :)
Im2bored17@reddit
Your senior eng probably can do it in 5 mins, but there's only 1 of them, and more 5 minute tasks than they have time for. Teaching you means they have less on their plate, and if they can trust you to do it right they won't have to deal with that issue themselves again. It's kind of a pattern...
At some point, leadership becomes about how effectively you can train others to become experts. You are only 1 person, you can't scale infinitely. If you don't force multiply and build up other people, you'll hit your limit and won't keep going up the ladder.
UpperPhys@reddit
Lol, this was super insightful and accurate. I'm this new guy (have been throughout the year in this new job) and that's exactly what's happened.
exploradorobservador@reddit
When you teach you learn, its incredibly useful because its builds team skill and morale, and it gives you a break from your own problems when you need a break.
PM_ME_SOME_ANY_THING@reddit
Kind is a big one. It’s easy to be a d!ck. It’s tough to coach others without being judgmental.
UntestedMethod@reddit
Why do you say that? What kind of judgments are you making about people you're coaching?
I think that's a personality trait not everybody has.
Humble-Twist-9982@reddit
When you know something, like really know something, it's easy to forget how long it took you to learn it.
UntestedMethod@reddit
Sure but that doesn't mean you need to.jidge other people for not knowing it. Even if it's a basic thing.
Rynxt@reddit
SMEs sometimes judge others working on their projects as dumb or inferior because the SME knows more and can do whatever it is faster.
sonobanana33@reddit
Nah, focus on chat rather than doing.
exploradorobservador@reddit
Pretty much this. You have to be seen as a guy to ask for advice and also realize that its a team effort and treat everyone with respect. My favorite engineer from my previous job was when I was a junior, super nice guy, learned a lot from him
grobblebar@reddit
Knowing what the problem is/how stuff works/what to do, OR KNOWING WHO TO DIRECT PEOPLE TO.
Saying “no” to things that people should be able to figure out themselves. Don’t do other folks’ job, just the hard shit that other folks’ can’t do.
Being right most of the time, and being able to enunciate what you know in as few, concise sentences as possible.
If you don’t know, just say “fuck, I don’t know”. Be up front and open about it. There’s plenty of things you’ll never know, so be blunt and shameless about it.
MrEloi@reddit
From my experience of L7-equivalent at a non-Google high tech, I feel that at L7 above you don't need 'soft power' ... you already have demonstrated raw ability plus many other attributes just by reaching that level.
L7 staff aren't fools, and know how to get things down.
Also the job titles at these level give you gravitas, so they act as a form of 'soft power'.
If an L7 asks or hints that a more junior staff member does something then normally that would suffice.
No shouting needed.
To me 'soft power' is a term used by those WITHOUT real authority.
Amazon is full of self-help books (e.g Influence Without Authority) covering this.
I doubt that many L6 or L7 staff have ever needed - or are even aware of - such books.
It is likely that those who do buy such books are not really suited for senior management.
-------
Are you really sure that the problematic types were L6 or L7?
Sustained disruptive behaviors are unlikely at the L6 and L7 levels due to the accountability and performance expectations.
chicksOut@reddit
I just keep fixing stuff, and they keep just letting me... 🤷♂️
GoTheFuckToBed@reddit
There is a famous football coach and the chapter 1 in his binder ins: players have to know each other, before going on to the field.
People who are not social and no fun do not get invited.
Andriyo@reddit
Plenty of good advice here already. I'd just say that it's basically empathy that all of us should learn in early childhood.
The thing is that it's easy to do in in the team/company that consists of healthy/non-deviant individuals. But not all of us learned basic empathy in the kindergarten. Deviation from the norm is not a bad thing in itself but it could make it harder to apply usual strategies that one often hears about ("don't be a jerk", "golden rule", "how to win friends" set etc)
No one will give you exact information how to deal with various deviant behavior because “All happy families are alike; each unhappy family is unhappy in its own way”.
There are basic strategies for your work environment though. A very valid strategy is "do not engage or disengage" - basically avoid teams with (potentially) problematic individuals. Deviant behavior is not always easy to spot but in general younger people are more likely to be on the spectrum.
If you can't disengage, then it's important to compartmentalize. Basically, disassociate your behavior with problematic individuals with your sense of one self. Otherwise, destructive/negative behavior could be contagious.
There are maybe some other strategies, but in general it's on case by case basis, unfortunately.
Also not all deviant behavior is bad, nor people are bad because of that behavior. It might be circumstances are such that "normal" behavior is unacceptable. For example, if everyone on the team knows that one of them will be culled for performance than it creates different team dynamics that one can't just apply "normal" rules. But again, there is different levels of "knowing" and how individuals react to the facts of life.
My point is there are no strict set of rules that will get you "soft power", just because we're all way too different.
glurth@reddit
Ask questions. Many people think this shows lack of knowledge, and so hold back. But the RIGHT questions can show or even highlight your strengths!
The bonus side effect: if you always readily admit that you don't know everything, when you DO speak with authority, people will be more apt to listen.
enter360@reddit
I always try to be the dumbest person in the room. Which means I should listen more than speak. When I do have opportunity to talk do so with kindness and facts. Admit when you don’t know something and need to go check to get the answer. Biggest thing that helps people advance in the process is being good to work with. At 3AM when everyone has had 12 cups of coffee and you’re still working the problem and not letting anyone get the blame pinned on them. That shows people when it’s their fault you’ll still afford them the same grace. In private absolutely correct them and coach them up if you can. Peer coaching on how to do technical stuff is great.
Lying is a quick way to burn any and all good will you may accumulate in your career.
DargeBaVarder@reddit
Taking responsibility for fixing things that shouldn’t be my responsibility. Other team causing delays? I’m gonna go talk to them and ask if I can help unblock them. That along with over communicating means you’re known to people, and known as someone who is capable of getting things moving.
You can avoid those common patterns by communication - don’t lie, and don’t stress people. Communicate delays early and often, and assume best intent.
slimracing77@reddit
Empathy goes a long way. Yes, you may be right and yes, you may have the best solution in mind. But if you can't see what the other stakeholders value then you're not going to have the same impact than someone who can see their needs and present the solution in a way that highlights the benefits to them. This doesn't mean necessarily changing the solution, but finding a way to communicate why they should care. Then you come away from it being seen as "the one who helped them" and not "the one who did the thing". Building rapport like this across multiple teams and situations is an investment.
exploradorobservador@reddit
I often think of that quote from The Big Lebowski "You're not wrong, Walter. You're just an asshole"
caseyanthonyftw@reddit
Sure, but let's face it, a lot of developers are wrong and assholes too.
DeterminedQuokka@reddit
Totally and usually it’s not about being right it’s about finding the compromise. I commonly get pulled into random stuff that has nothing to do with me to resolve the fact that both sides disagree and no one can actually figure out how to have a conversation. I walk in and get a list from both sides, give them a compromise then jet out of the chaos.
xabrol@reddit
Im currently on a project where I know more about azure data factory than any developer on the project And I've only been using it for 3 weeks and have less experience with Azure data factory than any of the other developers.
That's why I get put on projects.
Anytime I confronted with the new technology that I need to know or use to do my job. I read up about it. And become knowledgeable about it, and master it. And I do this in weeks or faster.
It's gotten to the point now where projects fight to have me.. And I've had multiple bosses tell me they put me on projects that are going to shit because they know ill quickly ramp up on all the tech and fix it and become the expert.
I swear it's like some developers just don't put in any effort to understand anything new. They just try to get their task accomplished with as little effort as possible. And then it has problems during the deployment because they didn't properly test cuz they didn't properly understand how to do that.
jjanderson3or9@reddit
Peace through strength. Know more than anyone else and intellectually dominate anyone who attempts to derail progress by beating them down with facts and logic.
ivoryavoidance@reddit
Two things: 1. Solving problems for people. 2. Solving some of the hard problems. Hard doesn't always mean some convoluted distributed system, it can be taking up tasks that people are avoiding. Hard can also mean a solution that saves time/money/both
flavius-as@reddit
randomInterest92@reddit
Do the hard stuff that nobody else does. Recently I wrote a script that kills unused old containers and volumes from our testing environment. It was like 15 minutes of work but devs are happy that they don't get "running out of space/memory" errors anymore and management is happy that they don't have to scale the server anymore. In fact they could downscale it and save money.
Nobody else would have ever done this.
Another thing i recently did was updating our pipeline to automatically shard the test suite in order for it to be able to run in parallel. Pipeline time went down from 20 minutes to 4. Everybody is happy, not just devs, also management
Nobody else would have ever done this
Make sure to communicate this to everyone in the company to reap the benefits
dcowboy@reddit
I'm polite, I don't lie, and I don't try and make anyone's job harder through my actions/inactions. It's not rocket science, just common decency.
met0xff@reddit
First establish your competency. Once people know you're good and can do stuff yourself, start being humble, praise your team members and give them the chance to highlight their work.
I have had so many times that people thanked me for giving them the chance to show what they did, giving them visibility, representing them. Also they want to shove other teams under me who are more hidden inside the company so they have a "champion". I spent an astonishing number of hours over the last months presenting stuff to every single stakeholder (just recently was then also asked to show the same stuff 7 times to 50-100 people each). The downside is obviously that I now get pulled into every single meeting anywhere just to give my opinion, so many docs shared with me to add something etc.
I don't really like meetings, I like having stuff written down and being able to think about them. So I feel my biggest obstacle is typically that I am never the one who calls in a meeting to discuss X but I rather put up a document for brainstorming or similar. But this isn't too much of a problem because there are so many others who seem to love to talk about everything so I just get endless invites anyway.
But all that is easy,, praising is easy. What I am also really bad at is what you might call hard power - pushing for stuff, fighting for my opinion (I rather just think: "ok then do it as you think and we'll watch it fail and burn"). Typically people listen to my opinions but when they don't, I don't fight for them at all. Last time we presented our suggestions for the idk 20th time and it was just bla bla another older manager stepped in and said "ok they've been showing this so often now, now stop talking and just to it how they said". Then cut the meeting short and told them to finally get to work. I was impressed honestly even if it let some people stand there with open mouths ;). Lol
nath1as@reddit
presence is very important, so it's much harder to do working remote
timle8n1-@reddit
When you are 100% sure about something say so. When you aren’t 100% sure about something say so. Know the difference between these two.
Acknowledge other people’s good ideas and help elevate them while giving credit.
Be kind. I struggle with this one when faced with incompetence but I’m working on it.
RealFrux@reddit
I have over my career actually questioned my way of often adding things like “probably”, “might”, “most likely” when I speak of things that are around +95% likely. Nothing is for certain and adding probably, might etc kind of also removes responsibility and add uncertainty. Many times I feel it is more appreciated if I talk about things as more certain. Everyone knows nothing is certain but if someone says something with more certainty the receiver can sometimes let it go more easily as the person now also have “skin in the game” to fix things if they for some reason was wrong. If you are wrong 1/20 and right 19/20 then usually that is good enough for credibility. Especially if you as soon as you realize you are wrong you are transparent about it and say so. If you can’t fix it easily and fast yourself first that is.
But I think what you kind of was after was full (or at least very much) transparency and be fast to admit mistakes which is something I totally agree with. I just believe in general there is a golden balance in how you speak when speaking about things that are 95% probable.
YesIAmRightWing@reddit
As someone said being right
But imo more importantly when you are right, don't be a dick about it, be nice about it.
SpeakingSoftwareShow@reddit
Not being a dick.
A lot of Seniors spend their time picking fights, putting others down, and crippling the team culture with tantrums and my-way-or-the-highway attitude.
Best Seniors I've seen are patient, and kind. Software is a team sport, and they are fully onboard with bringing the level of the team up. They can come down like a hammer when the situation requires it, but they understand that's a special technique for a limited set of moments; and often as a very final resort.
Be the kind of person who people want to ask for help/advice, and you'll wield a huge amount of soft power.
progmakerlt@reddit
Being visible - communicating, raising questions, solving problems.
Abadabadon@reddit
Coming up with a plan that can be easily tracked and asking for help when I need it.
LittleLordFuckleroy1@reddit
Be there for a while, be engaged, work hard, learn stuff. If people see you being proactive and actually following up on stuff, being accountable, trust will build.
maria_la_guerta@reddit
Unless you are the top 5% of your niche (hint: you're not) you will rarely fall into the second bucket.
The expectation of a senior eng at most places is that you are cross craft, and have the soft skills to align on the appropriate trade offs.
peldenna@reddit
doing what you say you're gonna do as best you can and delivering what you say you're gonna deliver as best you can
owning up to your mistakes
listening to other people's ideas and problems
being helpful
not being a fucking walking hacker news comment (pedantic assholery)
spending your accumulated credibility capital sparingly
standing up for your ideas when it matters (not when it doesn't fucking matter)
PMMEBITCOINPLZ@reddit
One time at my startup a sink overflowed in the bathroom before an event and I saw my boss, a millionaire, get out a mop and clean it up. I was impressed by that. So I try to do servant leadership, help juniors and try to solve problems. I don’t know if it’s working great but people do seem to listen to you more of what you say and do is reliable and helpful.
b1e@reddit
I’m going to latch onto this comment and commend you on capturing it so well.
Someone that’s willing to get their hands dirty alongside the team is huge. And especially if they’re loyal and willing to get the team’s back if they fuck up. Putting the team first above the company.
That combination of camaraderie and loyalty build deep respect. It’s obvious when IC leaders do this and they build true power that cements itself through reputation. That’s earned not bought or given.
Now, as a director I try to get my hands dirty. Not micromanage but trade real war stories and actually get a real feel for what’s happening on the ground. It’s a win-win for everybody.
candyforlunch@reddit
be friendly with everyone and right most of the time
bahumutx13@reddit
I casually talk to a lot of the company about their respective departments. I do my best to learn the basics of what they do, what are the big projects/tickets on their plate, and what problems they are dealing with.
Then I just do my best to support them when I can. For some teams that's just giving them a quick tour of my work, providing some deeper technical insight that might be useful to them, or sometimes I'm just lending them an ear. After awhile, as I've built up credibility, I've found that sometimes I can actually unblock them. I can actually support them in project meetings, I can re-prioritize my own tasks to relieve a tiny bit of pressure for them. That is worth diamonds to most engineers.
That's it. I do this with no strings attached and no hard feelings if they don't do the same. For me, I already benefited from the beginning by gaining better perspective and understanding of the company so if that's it, no problem. I've done this at every company I've ever worked for my entire technical career. At this point even when I join a new company I can quickly repeat this process and get up to speed.
Basically it's just casually earning engineering karma and not taking myself too seriously. I don't need to be the dude that solves all of the companies problems, I want to be the dude that people go to help solve their everyday problems.
--
Small warning label at the bottom...soft power is a sharp double-edged sword. Once you've accumulated enough karma to go engineering super-saiyan expect to be pounded with complex people/process problems. From the outside it looks like I just glide my way through project after project. Reality is this fog of infinite workload where I've spent so much time/effort unfucking other people's problems that my own become more like side projects. You'll live in this weird engineering-limbo where you get 5's on every review despite never finishing your own tasks. It's satisfying in its own way, but definitely not for everyone.
jubjub7@reddit
Why would you want soft power? It's all the work, none of the reward.
globalaf@reddit
There’s no one archetype for that. There’s not even a well defined route for getting there. You need to try hard, do good work, and toot your trumpet where appropriate.
careonomine@reddit
Being willing and able to drop what you’re doing to dive into a hard problem with a teammate that they’ve been banging their head on goes a long way.
Being kind and teaching them as much as you can along the way goes even farther.
I may not have the answer right away, but if someone on my team knows if they come to me with an issue that I’ll dig into it with them until we find the answer.
Or, I may have the answer because it’s obvious they fell into some trap of the language/framework, are completely missing some arcane detail, or are otherwise just plain doing something REALLY wrong.
In those cases, the odds are pretty good that the only reason it’s so obvious to me is that I’ve already done the same boneheaded thing once (at least…) in my career. Being able to laugh at myself and and say I did the same thing removes any shame they may have, keeps my own ego in check, and helps them feel safe coming to me if they feel stupid for being stuck.
devoutsalsa@reddit
Saying no to stupid projects.
dockemphasis@reddit
Logic bombs
Hot-Problem2436@reddit
Being the one that comes up with most of the good ideas, the one that helps others when their stuck, and the one that is kind when others are struggling.
Just understanding that they're humans and not robots and treating them like a friend is enough to earn their trust, and it's easier too. Then, being the one to solve their problems when they're stuck without micromanaging them is good. Trust that they can do their job once their barriers are removed and they usually can.
roger_ducky@reddit
Always let the best ideas win. Yes. That means, if it’s someone else with a better idea, go with that instead, and credit them for it.
If you HAVE to make a pronouncement when something is an absolute bad idea, but you can’t convince others, make sure you’re 90% confident. Then, announce what will happen and why if the idea was done anyway. Time should prove you right and increase your credibility.
Many times, ideas will seemingly “tie.” At that point, let them do it the way they prefer. If they do run into problems with it, help out or provide suggestions.
If people know you’re always receptive to good ideas and typically can be trusted with identifying them, your credibility will grow.
DeterminedQuokka@reddit
That moment when you are halfway through an extremely complicated data model and someone says “can we just add a json column to the table”. And you turn to them and say “yes we can, meeting over”
jeerabiscuit@reddit
Can we discuss engineering instead of hunger for power?
DeterminedQuokka@reddit
Not assuming that you are always right. There are totally times someone with very little context says something that’s way better than anything I thought of because they have more distance from the problem. Listening and realizing you are wrong buys you huge credibility. Also admitting when you are wrong. No one is dumb enough to believe you are always right, admit mistakes and learn from them.
Creating a plan that includes proving your premise. I don’t attempt to sell 2 years of work then we will find out if it’s a good idea. I say here is a 2 year project and here are the first 3 monthly checkins and what analytics will tell us if we should abandon the project.
Being nice to people. People aren’t being jerks on purpose. Never assume malice where ignorance is sufficient (I append this with, unless ignorance makes them look so bad malice is preferable for their career).
Don’t make it about you. My job isn’t to do the thing. It’s to teach other people to do the thing. The more things I call my precious on and hoard the more it looks like I’m not competent enough to explain something to another human. The more stuff I can hand off the more impressive stuff I can do.
Be able to talk to someone who isn’t a dev. If I can help a podcast manager or a marketer do their job I look fantastic. Especially if I can explain to them why tech techs.
Actually get estimates right. Being 2 months late makes you look either lazy or stupid. So if you say something will take you ______. Learn to get that number right.
shozzlez@reddit
Just freaking do your job. It’ll come. Worrying about all this other nonsense of a waste of mental energy imo.
BusinessDiscount2616@reddit
Provide your ideas but don’t force your architecture or design. engineers that do this almost always lead to problems. You learn from trying new designs and being open to the intern’s idea, and letting them develop a sense of ownership creates a really strong team.
The senior engineers usually don’t nitpick PRs with 50 comments and log off at 5pm, the 1% developers are usually coding their hobbies and work late on ideas. They focus on the parts of the system that matter to the business and let the juniors push what they want, delegating their responsibilities appropriately.
NormalUserThirty@reddit
projects im on are successful. projects im uninvolved with stall out and fail. the comparison matters. its impossible to build soft power if everyone around is better than me. why would anyone trust me if they have better options?
EnoughLawfulness3163@reddit
This is some anime shit
EuphoricImage4769@reddit
Kindness, generosity, respect, openness. People don’t remember what you say they remember how you make them feel.
dom_optimus_maximus@reddit
Find out what everyone's problems are, and solve them. Don't care who gets the credit. This includes other engineers, PMs, Scrum masters, Directors etc. Work on designs, solutions, ideas, etc on your own and give them to people. I can't tell you how many miro boards with routing tables, domain design specifications, architecture diagrams etc, I have handed off to people who eagerly jumped in and got moving with the nudge.
Have notes on everyone you work with and keep track of how competent they have demonstrated themselves to be. Invest heavily in the people who are very competent, and be kind and encouraging but measured in investment to those who score lower.
ToThePillory@reddit
A few things:
1) Admit when you don't know something, but always follow up with "I'll find out", and actually *do* find out, and email your findings.
2) Listen to people, take on their opinions, and be willing to say they are right and you are wrong. If you freely admit when someone has a better idea than you, you'll be believed more when you stick to your guns.
3) Give people a victory if they need it, back up your team, say "Exactly" if a junior says something good.
4) Again, back up your team, show no ego, be willing to delegate, be willing to admit you're wrong and your junior is right.
Really it's about having no ego, follow up on things you say you'll do, don't participate in any kind of rivalry, be honest if you don't know something, but always follow through on finding out.
The worse thing a developer can do is say "I don't know" and just leave it like that, because everybody is thinking "Well, isn't it your fucking job to find out?".
diptim01@reddit
Cooking
ucrengineer88@reddit
ownership of the project and complete honesty
SafeDrive4825@reddit
Credibility matters. You gain and lose ‘street cred’ through interactions with people. Everything matters.
AdamBGraham@reddit
Deliver.
Also communicate well and competently.
Xaxathylox@reddit
Those without credibility will dispise you for winning. Every time they wallow in their filth of incompetence will further their rage. Every time you solve in minutes what it takes them days to achieve will sink them deeper into their silent abyss.
Worry not about the opinion of fools.
robe_and_wizard_hat@reddit
One huge this is to have the courage to ask questions that you think you should know or that you might think people would consider you dumb for asking. Other people are wondering the same thing and will respect your courage and interest in seeking out the answers.
Related, share, frequently your own learnings as you research things. Take initiative to fix things that suck. Above all, be kind.
lab-gone-wrong@reddit
The biggest factor is having good relationships with everyone. This comes from trust, which comes from kindness and frequent interactions. Having one on ones with people, working on projects with them, helping them out when they ask for a favor and being an advocate for them as if they were your own teammate, are all highly respected actions that will build your relationships. This leads to trust which leads to people accepting your guidance, eventually yielding decisions to you entirely.
The second factor is expertise, which a lot of other posters have flagged. Know your area. Use that knowledge to drive successful projects and remove obstacles. People will come to you with problems and questions.
The third, and honestly least important factor, is seniority. Having a lofty title will help present a good first impression, which can kickstart your relationship with others. But that factor wears off quickly if you fail expertise and destroy trust with bad decisions and mistreatment of others.
Icecoldkilluh@reddit
Two types of engineers.
To use a sports analogy.
You’re either on the field. (Reliably delivering and leading feature delivery, putting out production fires, helping others)
Or your on the bench (Just do your tickets, moan about everything, avoid responsibility for anything of value or substance)
You gain capital being a team player, when you demonstrate you can be relied upon. There is no life hack/ cheat code/ shortcut.
Just hard work and applying yourself.
UntestedMethod@reddit
Well said
jimmyspinsggez@reddit
Give good code review, clearly explains pros and cons whenever doing review (suggesting code change) or design. Give tech talk on best practices within the team / cross team.
I have had lead/senior being very strong engineers, write good constructive code reviews and tech designs; I also have seen the other end of the world and can't help to think they sucked dick to climb to senior / lead. For context my current lead never gave me any comment on my code, my current senior is useless af and doesn't know any software engineering principle and design pattern.
eddielee394@reddit
Being a force multiplier for your teammates that makes each of them feel individually empowered. This allows you to build a rapport with people and establish trust amongst your peers. Knowing when you're wrong or aren't sure about something and being quick to admit it. I often tell my teammates that I may not know the answer to something, but I'll do everything I can to find the answer or find someone else that knows what it is.
bwainfweeze@reddit
Trust is the currency of the realm.
reboog711@reddit
Do you want to get leaders to trust you or other developers?
Some things I've done that have helped: * Present at Lunch and Learns or similar at your employer.
Contribute to the company blog if one exists. * Deliver! If you're known as someone who can meet business timelines consistently, it'll help your cred. * Mentor other devs. Sometimes this can be formal. Sometimes informal. But, helping them suceed will gain you a ton of cred. * Listen to understand.
When you're wrong admit it gracefully. * Give credit where credit is due. Credit the team when things go well. Take the blame when things go bad. This should be a manager creedo.
The last few are super generic platitudes, but I stand by them.
Obviously don't do things like lie or pick fights. My strongest personality quirk is being jaded and pessimistic. It's even come up in year end reviews. But, I've succeeded in spite of this.
Jmc_da_boss@reddit
By being right, often
And when wrong own it and rectify
BrobdingnagLilliput@reddit
Learn to make accurate estimates. NEVER say "I don't know" when asked how long something will take. At a bare minimum, learn to make order of magnitude estimates, e.g. 2 hours - 2 days, or 2 weeks - 2 months.
kittysempai-meowmeow@reddit
I am honest about what I don’t know or am not certain of so that when I am certain and confident people know I am not bullshitting them. I back up statements with evidence or I admit it is supposition.
fdeslandes@reddit
You can get away with being negative as long as you always provide solutions / alternatives with the negative comment, and that you can let it go when the stakeholders decide that the bad things are acceptable compared to the effort that would be required to fix them.
karl-tanner@reddit
Influence based on guidance. Almost instantly knowing the best path forward in a sea of ambiguity or complexity.