[scarface74]

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

And that’s why developers don’t get ahead....

There are basically “three levers of power” in an organization - relationship, expert, and role in that order.

The developer who knows how to build relationships is the one that doesn’t get his silly bug put on blast by the QA and gets an unofficial Skype message and doesn’t get official very visible tickets when something blows up in production and gets a quick Slack message so that he can be prepared to explain it.

It’s also the different between a developer who has to submit a ticket to netops and wait three days for a VM and one that can send an email, get it set up within 30 minutes and then create the ticket as a formality.

[FLUX-YOU]

That's just silly, you can build relationships in other ways.

If you want to be the go-to guy/gal that gets constantly interrupted with this sort of stuff, your time won't be respected.

Plus, you're teaching them to go research things on their own. Why is that a bad thing?

[scarface74]

Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentors, spends way too much time in meetings and just greases the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly. I have my office days where I expect to get interrupted and my work from home days where I don’t.

No one gets promoted by constantly telling coworkers and management to RTFM.

[FLUX-YOU]

>Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentor, spend way too much time in meetings and just grease the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly.

Great. That's exactly what I said in my original post -- hire someone specifically to do that. Problem solved. Now your junior/mids don't have to explain that. But that's not the career trajectory of every developer, let's be honest.

If someone's going to deny me a promotion for linking a wikipedia page that answers a basic question and completely ignore my technical contributions, I absolutely do not trust that place has the best interests of its developers in mind and is likely driven more by politics than anything else.

[scarface74]

If someone's going to deny me a promotion for linking a wikipedia page that answers a basic question and completely ignore my technical contributions, I absolutely do not trust that place has the best interests of its developers in mind and is likely driven more by politics than anything else.

No place has the "best interest of its developers in mind". That's true for any industry. It's a lot easier to replace the on the floor factory worker (i.e. the developer) than the foreman (the architect) and they get paid accordingly.

Don't get caught up on the title, role power is the least effective type of power in an organization. If you leverage relationships and can be seen as the expert, you can easily punch above your weight.

[FLUX-YOU]

Why do I need to punch above my weight? So I can finally tell people 'no' when they try to take my time away with stuff that they can fix themselves?

I think it's clear we have two very different motivating factors in careers. You want to climb the corporate ladder and get power and influence, and I'm content building things.

[scarface74]

That's just the point I've been making "climbing the corporate ladder" is about gaining role power. Role power is the least effective method of getting things done in an organization.

I wanted to "build things" my entire career and was stymied by management and team leads who I couldn't convince to see my "vision", net ops and dev ops who made me go through mounds of red tape to get anything done and coworkers who had their own agendas and wanted to get noticed and get the prime projects just as much as I did. It led to a lot of frustration.

The best way to be able to "build things" the way you want is to have the influence to do so by getting people on your side through relationship building and getting people to trust your expertise.

I like to "build things" too and have no desire for management. But, the way to stand out and make more money than the average, heads down developer is to have soft skills.