Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> If you have a hierarchy where engineers are at the very top and the people who are interfacing with the outside world are a couple rungs below that, you really miss something when those people don’t have an equal voice at the table.

As an engineer, I've always found that I'm quite far from the top rung, and that my voice is frequently not the loudest at the table.

What may give the illusion that my voice is strong is that I only support ideas that I know I can build or are practical.

I find that the people who make complaints like that are usually the people who don't realize that their voices are just as equal as mine at the table. They just need to work on their credibility in order to make their voice stronger.

Edit: Credibility often comes from knowing what ideas to support, and when to stop pushing an idea. The term "idea person" comes to mind here.



sort by: page size:

> The idea was supposedly that everyones ideas were valid and hierarchy didn't matter and that everyone should challenge anything no matter who they were in the organisation.

On the engineering side, ideally this is how things are done anyway.

I've never had a problem digging into the ideas presented by engineers more senior than me, and I've always encouraged junior engineers to question any ideas I present.

Everyone, independent of seniority, is blind to giant gaping flaws in their own ideas. People also don't know what they don't know. If I have a gap in my knowledge, any plans I come up with are not going to take what I don't know into consideration if I don't know that I don't know something.


> This board itself is flooded with engineers with great ideas being dismissed because of “realities of the business” or “changing priorities”, much less “political realities” etc

Your argument would be rock solid if those great ideas were only applicable/useful in huge bureaucratic organizations (which is the type of environment where bullshit ideas are given more attention than truly innovative and impactful ideas). We've all probably been there before, and I get your point 100%.

However, the next step would be to go where your ideas can be heard. And if the idea is good enough, people will listen. Shouting into an org chart 10 miles deep to narcissistic C level executives has always seemed like a waste of time. So I don't disagree with you, but if you aren't being heard, speak to someone who will listen.


>Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans.

Does that really work ?

Usually these guys read the sales pitch from some credible source. Then you need to show them that the argument is X works really well for scenario Y but your scenario Z is not really similar to Y so reasons why X is good for Y don't really apply. To do this you usually rely on experience so you need to expand even further.

And the other side is usually attached to their proposal and starts pushing back and because you're the guy arguing against something and need a deep discussion to prove your point chances are people give up and you end up looking hostile. Even if you win you don't really look good - you just shut someone down and spent a lot of time arguing, unless the rest of the team was already against the idea you'll just look bad.

I just don't bother - if I'm in a situation where someone gives these kind of people decision power they deserve what they get - I get paid either way. And if I have the decision making power I just shut it down without much discussion - I just invoke some version of 'I know this approach works and that's good enough for me'.


> Do they have the best ideas or did they master the politics necessary to push their ideas up the stack and everybody else doesn't care enough?

Exactly: I had a very similar experience in my previous work.

A single guy was super-effective at pushing the technology he was strong in, and preventing anything else from reaching even development environment.

He was effectively a 10x because no other colleague was given an actual chance of shining.


> The idea was supposedly that everyones ideas were valid and hierarchy didn't matter and that everyone should challenge anything no matter who they were in the organisation.

Treating all ideas as valid is fine if that means all ideas get evaluated. For hierarchy you need somebody who can be the decision maker when a consensus cannot be reached otherwise the most stubborn opinionated people become the de facto decision makers. I experienced that situation before and resulted in some very bad implementations and massive tech debt and the people who stuck us with those bad decisions got to avoid responsibility and leave other people cleaning up the mess they created.


> Shit no, because the whole rest of the time I'm not coming up with those handful of new ideas, I'm less-smart.

For better or worse, I am such a person: good at generating ideas and product vision, merely competent at technical execution. Put another way, my verbal iq and empathy (if that can be measured) are much stronger than my analytical iq, as confirmed by essentially every standardized test I’ve ever taken. As a result, I function and process information differently than a lot of my engineer peers. Some things are obviously harder for me, which can be painful and embarrassing, but as a rule I’m involved in lots of interesting discussions and design sessions and tend to be a de facto product manager. It’s just different, a trade off in mental styles.


"As a really senior engineer in the company, of course I have strong opinions and I absolutely have a technical agenda. But If I interact with engineers by just trying to dispense ideas, it’s really hard for any of us to be successful. It’s a lot harder to get invested in an idea that you don’t own. So, when I work with teams, I’ve kind of taken the strategy that my best ideas are the ones that other people have instead of me. I consciously spend a lot more time trying to develop problems, and to do a really good job of articulating them, rather than trying to pitch solutions. There are often multiple ways to solve a problem, and picking the right one is letting someone own the solution."

"I learned that to really be successful in my own role, I needed to focus on articulating the problems and not the solutions, and to find ways to support strong engineering teams in really owning those solutions."

I love this. Reminds me of the Ikea effect to an extent. Based on this, to get someone to be enthusiastic about what they do, you have to encourage ownership. And a great way is to have it be 'their idea'.


> whenever there is a bug nobody knows how to deal with, I'm the one they call.

Sounds like you already have some recognition and respect.

Why are you not the one evangelizing your ideas? It's not enough to have good ideas. You need to execute on them, you need people to understand why it's a good idea.

If one of these architects refutes or criticizes your idea, why don't you show case it? Why don't you build a prototype? You can then show that to everyone and make sure the origin of the idea is clear.

Also, talk about this to your manager. They should be able to help with making sure you get recognition for your ideas if it's important to you.


> E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined.

I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works?

It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol.

When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!


> Some ideas that look poorly thought out are in fact pretty good

The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above.

The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.


> What exactly are you pitching?

Some people have ideas to fix something within the society that they think can be better. Engineers also have some such ideas. I would like to get together engineers so that we can work together on some meaningful project with an aim to solve some social problems.

> The world has a ton of nonprofits

Can be a social enterprise?

> Most humans aren't very effective.

If that is the argument for any new idea/venture, then nothing will ever get done.


> I’d rather hear an analysis from someone embedded in the problem space than from someone whose ‘job’ is to squeeze profit off other people’s work

Everyone believes someone else is squeezing off their work. In tech, I've heard it from founders and sales about engineers; engineers about everyone else, including every other engineer; the person who keeps the shitshow of a culture hanging by a thread; the lawyers who keeps the company from being fined into oblivion; et cetera.

If there is a summary to draw from it, it's that the uselessness is probably concentrated in the person complaining and doing nothing about it (whether due to impulse or ability).


> "the experts" didn't understand what they were doing. So I had to lead them to come round to a perspective so they could think it was their own idea and hence be comfortable adopting it.

This also applies to industry. This is basically managing up 101 for engineers. If the boss thinks it's their idea, it'll get approved and supported. If they think it's someone else's idea, depending on environment, it'll get blocked or sabotaged.


> all the shy-introverted-yet-technically-good-developers get the short end of the stick and you are left with spin doctors who can promote themselves very well

Exactly, which is why more good technical speakers are needed: the guy who makes the best job at convincing why his idea is better than the one from the other guy is the one that will get his idea implemented.

And I'm not talking about people selling smoke: if I'm competing for one idea against another developer's proposal, and both seems reasonable enough, how will the boss know my idea is better if I keep it to myself? Even if I send him a paper explaining why my method is O(n log n), if my co-worker makes a 45 min presentation addressing my boss' concerns (which may not be only technical - "using this cloud provider it's reliable and will make us look as a forward-moving company" solves two of my boss' problems), he'll get the implementation.

When dealing with humans, emotions also play a role. Perhaps after the robot uprising we can solve our problems by forwarding benchmarks in CSV files, but until then it wouldn't hurt taking a course on two in how to get our ideas across our bosses' thick skulls.


> The immediate assumption is that people are tools/resources to build the product. That's talking like an engineer.

That's more management-speak than engineer, in my experience. I hate being referred to as a resource.


> I think that this is pretty status-quo (you're an engineer, not an idea guy/founder after all).

Er, no. A good leadership knows how to frame questions and let the engineers find the solutions. You don't come the engineering team with a solution already decided down to every last detail. It's what they're good at, after all, solving problems. Ideally you have someone who's leading the tech side who can call shots on the product AND work on the technical stuff.

Too many biz-dev types starting companies treat their engineers like code-monkey servants, to the detriment of the product and the company.


> You're thinking like an engineer. Engineers are poor at estimations, poor communicators and can't give me a damn budget.

And yet it is engineers who will be building this magical platform that you think is 'neat', that you think engineers generally somehow can't understand.

How is that going to work out?

Engineers are always greener on the other side of the fence.

Zapier, Tines, Workato (and doubtless some other gibberish names I haven't heard of) don't intend for a system like this to work, either. They won't bend over backwards.


> People solve the problem for you, but you have to watch and listen.

I love this. It reminds me of my favorite saying about design: “People don’t design ships. The ocean designs ships.”

At work I try always to say “human” rather than “user,” for just the reasons you state. Like you, I think I’ve done my best work when I’ve been able to remove myself from the equation. It’s one reason I like building software that I’ll never use myself — it keeps reminding me that I’m not my customer.


> and make a PPT telling a room full of engineers and developers how they should be building complex systems.

This is unfortunately not an experience I am unfamiliar with. I have to pretend to eat a big plate of humble pie on the first technical call with a lot of our clients.

Once you learn their first reaction is going to be to reject your proposal on arbitrary grounds (i.e. a new security theater show), you start to present simpler proposals purely for the sake of tripping their initial response. Once you get them to fire their objections across the way, it is really easy to review the impact and build the real proposal that meticulously deals with each point that was raised.

next

Legal | privacy