> 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.
> 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.
> I feel like going and redesigning parts of the system that are usually other peoples' area would result in some interpersonal problems
Assuming this is done during free time and you're presenting the solution in a respectful way, then that's their problem, not yours. If you perceive this is going to happen within your team then there is already something wrong. There isn't enough trust and cooperation in working towards a common goal. Every solution should be openly presentable and scrutinizable by every team member.
If you suggest an idea, completed or not, and someone is offended by that, it's not your fault. It is a consequence of your actions. And, I'd argue it's not your responsibility to care for others' feelings to such a degree.
Some people may disagree. I don't know how they can survive. They must feel they are constantly walking on eggshells, wondering how people will react to whatever they say.
>> To make products you need a diverse set of leaders who share authority in varying decisions, not a chain of people who wrongly think themselves to be universal experts.
Works fine in case of actual universal experts Steve Jobs's, Jonathan Ive's, Larry Wall's or Linus Torvald's of the world.
That argument begins to break down when you appoint the wrong people to that job. You now have to follow orders only because some one is giving them, not because they are right.
>The criticism of creative destruction in particular - sure
>it may have costs but is not doing so any better? Thinking
>that preserving the status quo at the cost of advancement is
>in itself a distortion arguably.
This creative destruction obviously only has to happen when something cannot be changed. Then there's the question: why can't it be changed? In stiff organizations this is well-known to be there virtually anywhere but of course in startups as well.
My far-fetched theory is that teamwork is still something very rarely found. So individual people always have their own space, be it a project, microservice or some module. It's their baby, they've designed it, deployed it, maintained it etc. If someone else needs to join the project, this person always needs to ask the creator for permission of everything until the creator's rules are followed 100%. Maybe I'm alone with this observation but this has happened to me far too often. I wish these projects would rather emerge of joint thought processes and also be evolved like that. Then there would be no need of people having to go through walls, exposing border-line anti-social behaviour...
>If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work.
So many reasons, but they usually boil down to simple self-importance.
Also, remember that it's harder to read code than to write it. Any non-trivial library or service is going to have a learning curve.
>Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ).
Everyone has their own opinion.
In a rigid structure, this perspective wouldn't work because your paycheck would be imperilled by it.
>The problem isn't people chose different tech stacks its they don't want to work together.
Sure, I agree. In a correctly organized structure, their incentives would change, and their behaviors would be more cooperative.
>If they did they would choose tech stacks and work practices that foster collaboration.
No, that's like saying if people wanted unity, they'd make choices everyone would agree on. Everyone wants unity. They just everyone to unite to their idea of what's important/right.
Management is all about crafting an environment and structure that causes people to work in a productive way. That could happen in this company, but it hasn't.
> I took his advice seriously, came up with a couple ideas, and then approached him a week or so later to pitch these projects. He got _angry_ at me
Isn't it an environment for creating ideas, rallying people around them and then leading them?
If you're new with fresh ideas then you can directly go and try to do that because formally there is no boss. You only have to fight the informal hierarchy.
> People who can manage and code (architect, etc.) are truly rare.
I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons... but every time I've promoted a reluctant leader it's been magical for that person and for their team. A lot of times the people that self-promote and like to be in charge should never, ever be given athority.
> I am very skeptical of new technologies
I used to think that way until I realized that in a lot of cases, we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now - let's rewrite all the things in Rust! Underneath it all, though, the payoff for using new, less capable tech, is that eventually it will pass up the old in a very meaningful way - and when it does, systems build on the old are washed away.
> 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.
> "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.
> Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”.
You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization.
Good organizations value good ideas, irrespective of who thought of them.
> Every new idea had to be approved by him before going into production.
I see this in so many places and it's distressing to watch. This is the fastest way to ensure you lose people who actually love the company. Either you lose them as in they leave the company or they just stop giving ideas. I went through this personally. There would be meetings where people would be encouraged to give ideas, and unless the 'idea' was a reassertion of the leaders original idea it would be shot down. Even independent ideas/research would eventually come under the umbrella of a single individual's control. Very quickly became frustrating. Further meetings finally became all of us nodding head and waiting for things to finish. I have entire notebooks of doodles from those days. It was horrible for me because I loved the company and had so many ideas to help us function more efficiently and transparently.
Of note, the single individuals in this case would be one of the founding C-level folk.
> And just like every profession there are idea people and people who think they are idea people.
This line makes your argument unfalsifiable, as if I bring any example of bad idea people, you could just state that they're not actually idea people but just people who think they are.
> Idea people are left to hitting a home run, succeeding and making a name for themselves. No one is going to hire a first timer into Chief Idea Officer.
Well yeah, I wouldn't hire a developer who hasn't developed anything either.
> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)?
Seems like a very unfair restatement of what the author said. I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal."
Or to phrase it another way: if the understanding of the product isn't clear across the whole team, it doesn't matter if any one individual has a bunch of brilliant ideas for/about the product, because you aren't all working towards the same goal.
>You are dismissing the reality that some people are actually smarter than others.
I never dismissed anything like that. If I did, please quote my dismissal. In fact, this sounds like an assumption you made before reading what I wrote. Change your assumption and try reading it again.
> There are some people who really do have a real vision of a 'best' solution.
This statement only works with quotes around "best" and phrased as "a best" instead of "the best." I do not question that it is possible for a single person to have a driving vision, but what happens when this person, instead of explaining their reasoning to their collaborators, uses aggression to dominate them and force them to accept his or her solutions? Do flaws get pointed out? Or are we under the assumption that "smarter" people do not make mistakes? If not, with everyone on a team looking up to a single person to make all the decisions, who will catch the mistakes?
The question here was never "collaborate vs. don't collaborate." We're talking about teams, where a degree of collaboration is necessary to move forward, and individuals who disrupt the collaborative process via aggression.
>But, the collaborative effort and resultant end product is always, by necessity, a non-ideal solution for at least a portion of the end-users.
How is this different than non-collaborative effort? What exactly are you saying here? That a single person can build a completely perfect product that meets the needs for all end users while a group cannot? What you have said above is true whether collaboration is involved or not -- everything has flaws.
>Keeping this in mind, it can be understood that "the best product doesn't win" -- rather, the most popular and most agreed upon solution or product is what wins.
In a working collaborative environment, these two can be the same thing. When one person makes all the decisions by fiat, the solution that wins is that person's favorite, not one that has been thoroughly vetted or necessarily correct. I would rather rely on a vetting process than on a single human's biases. This is what collaboration is for, diluting biases and natural cognitive flaws. No one is immune to all biases and flaws.
>Perhaps, if the collaborative environment was less collaborative and more constructive, I would participate more.
What do you see as the difference between "collaborative" and "constructive"?
> 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.
> Great products are created by great teams. It’s almost impossible to create anything of any meaningful scope, these days, without a team.
Yes, but also there are things that teams cannot do, and in fact make them worse.
To use an example from my org, there is a feature which was proposed to accomplish a specific objective. The feature grew in complexity to address much more than was originally planned. A large team was assembled to rapidly deliver as the original objective was important to business needs. The large team enabled the larger version of the feature.
This mostly happened without the knowledge of one of those smart but ostracized engineers. When they became aware of it, they had to step in and force changes to prevent the large feature from leading to serious technical debt and behavior that would not compose with other features well. More changes should have been done to return to a simpler design that would have focused on the original goal but it was too late.
>This means, generally, that every change reduces inconsistency and increases cohesion of the entire network
This is analog to growing the tree, the page talks about cutting it down.
One could give many examples but the good ones are unlikely to resonate with others.
To give a poor one. There was a time when I understood human decision making as a hierarchy of people in increasingly greater positions of power with access to better information and to people with greater skill. Then one day it struck me how they too are just going though the motions with their freedom for creativity limited to a single potentially career ending move. The machine happily grinds on without anyone behind the wheel.
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.
reply