Take out any of those and you get either nothing or a disaster. But if all come together, you will have someone on your team who doesn't just recognize that missed opportunity the other excellent other engineers already realized, but actively go against the plans of at least one level of management in order to do what's right for the company.
They tend to create a lot of friction, but can often save a project. I personally love working with these kinds of people as I was formerly one of them — and they can and often do make the best managers later on (funnily enough, I've heard similar stories in the bio of almost any technology leader I respect).
Having made the mistake more than one time of accidentally enabling people who didn't have the loyalty / optimism or technical excellence parts though, I get why these kinds of people are usually held in place in large organizations. The resulting friction, bickering and havoc can as well break teams and companies.
You are absolutely right. I'd like to point out, that as one person, I've been both depending on the role.
If I'm in a new space with new tech, I need to learn before I have the technical excellence. If I don't feel safe, I won't have courage to challenge leadership. If don't have hope, I won't have optimism in the future.
I say confrontational systems, because the only way to actually spark change in a system that has been systematically extinguishing sparks of change is actually confrontation. And the very fact that confrontation as such is now associated with negative emotion (same with conflict actually) goes hand in hand with the top level comment on this issue. Confrontation/conflict is bad, optimism is good.
Confrontration is how you bring attention to a problem. Conflict is what happens when that dominant idea is challenged by another idea.
Confrontration is how you bring attention to a problem. Conflict is what happens when that dominant idea is challenged by another idea.
what i mean to say is, confrontation/conflict is a normal part of debugging reality, and is healthy as long as there is an open/healthy system to enable it
That is great for the one individual with that reach, but does not solve the problem from an organisation perspective.
If we took that advice to heart, then the CEO would have a line outside his door of all the engineers in the company, doing what they feel is best for the company. He would then say, Jeez, I think I need to have some managers to group these people together like in a hierarchy.
Plus the guy(s) you know, everyone else, including their managers, knew they had the boss' ear. And in my experience that person just becomes another manager, 'cos everyone reaches out to them to get their project unstuck.
There is absolutely no reason an engineer could not influence the decision making process of a manager. The manager is the one taking the responsibility for a decision, but it is a poor manager that fails to listen to their top experts and leverage their knowhow.
That's what it means to be a great engineer that gets the manager ear. It's not the engineer's job to manage, but is his job to be part of the team, and do what feels right for the team, including to tell their opinion on the matters they are a subject expert.
Processes are just scaffolding and general guidelines on top of a functional engineering organization.
An engineering organization is not a car factory.
No matter how brilliant, or well intentioned, no CEO can listen to all views from all experts - at a certain scale this goes from 'has other work to do' and flips into 'physically impossible'.
So, yes there is a reason "an engineer could not influence the decision making process of a manager. "
At some scales it is impossible. And if you mean why cant he influence the manager above him - yes thats fine. But that manager has f all chance of reaching the CEO as well. At certain points companies stop acting like autonomus agents and become, some kind of lava like process - predictable and impossible to stop.
maybe large firms are the problem overall
The tricky part is figuring out how much guidance you must give to achieve an overall goal, and then step the hell away from micromanaging.
Read Never Split the Difference by Chris Voss, or watch his Masterclass, which isn't really so much a masterclass in negotiation, although that was its intent on the surface. It's more a masterclass on empathy and understanding other peoples needs and how to leverage helping them succeed for your own benefit.
[Statement of my understanding of the situation]
"Well, from my perspective of understanding our mission statement and raison d'etre, our company's strategy for success is [describe the strategy from your perspective]. Is that accurate?"
[Await validation]
"Yes, that's pretty accurate."
[Empathize with their needs = instant connection]
"It's gotta be pretty frustrating for you to see these things that are happening down the food chain every day that are not only hindering that strategy, but actively competing against it. How do you deal with that?"
[Now just listen to them talk and ask questions and clarify to make sure they feel like you're not only understanding their pain, but understand their core basic needs.]
[Statement of your ability to help solve their problems. Why am I different than the other 200 people outside your door?]
"Well, I've been in the software game since I was 8, 37 years; and I've learned a lot of stuff over my years when it comes to high performance R&D. I've been on a bunch of successful high performance teams, including working with X, Y and Z, the team that did Y that was all over the news last year. Having been with this team a few months now, I've been observing what is going on and thinking about how the current tactics of the department are actively hindering us from completing our corporate strategy.
I would like to help align R&D with corporate objectives and not only reduce the friction that's preventing us from achieving them, but actively increase our productivity, output and responsiveness to our customer base to move us forward faster, making the product more desirable and more saleable, increasing profitability over current projections, reducing payroll by and significantly shortening our delivery cadence."
[Now you've piqued their interest, you've hit every pain point in a CEOs target list except for fund raising. Let the conversation go from here.]
The minute you start talking about increasing profits over projections, reducing friction, increasing productivity, reducing payroll costs, decreasing team churn and increasing employee satisfaction, you've basically just become a CEO's wet dream. That's everything a successful engineering team is made of... double if you've already done it before and can prove you can do it again.
So it doesn't matter how long the line up is at the CEO's door. It's no more difficult to bypass it and step up to the front of the line than it is to bypass the chain of management between you and their office.
Everyone's gotta eat. Everyone has a social life. Outside of the office, everyone is equal. How do you get the ear of a new friend or a potential girl or boyfriend. How do you catch their attention? Figure out who they are, what they do, what's important to them and what you can do to help them achieve their dreams. Make a plan. Execute. That's the secret sauce.
Bad sales reps push for every sale no matter what without listening. The GREAT ones focus heavily on discovery and understanding up front and then map what they're selling to (some of) your needs and tell you what they can't help with.
This is indicative of political savvy and the ability to influence.
Rewarding influence indicates a lack of leadership. Humans being social animals, we're already prone to being influenced by those who are good at influencing.
If management magnifies this tendency, they'll end up turning the workplace into something like social media with paychecks.
Building trust and understanding among colleagues is ALWAYS good.
That is exactly what happens, but not because your management isn't listening. The sacrifice of good ideas is done in the name of predictability or viability.
I've been witness to and driven a few of these sorts of moves and what has struck me is that successful "by-pass of management" rebellion costs time, effort and most importantly is a test of active leadership skills.
There was a system which I was working on which absolutely sucked (for me personally, because I worked on performance and it couldn't be improved without changing the architecture). There was a way to rewrite about 25% of the system under different assumptions which would fix the performance issues, but the system that was in production already had several other issues which needed to be prioritized over performance.
For a manager in front of a customer, of course, we're absolutely committed to fixing whatever is broken. That goes back into engineering, where the rewrite wouldn't have half the bugs we have, but it looks like Dunkirk when it fails. The manager has no way to actually approve the rewrite, when they're trying to hire immediately to just do the work that's already on the plan.
Anyway, long story short, there was an intern for the summer who did the rewrite and get it working to the point where the next generation system was almost entirely built out by a single uninterrupted intern over two months (& his code is still in prod today).
The methods needed to break rules and succeed are often just the same qualities needed to "just succeed", except the breaking of rules is necessary to prevent the regression to mean.
And if you don't succeed, being disavowed like this means worse results than following orders. There's something to be said about the motivation of a team after burning their boats.
I'm gearing up to do one of those off-the-books project right now. And the tolerance for risk is clearly something I'm having less of each year. That said, surviving failure does more for your confidence than clutch, but definitely would like less red in the ledger.