I'm sure everyone has worked with engineers who might be 10x on their own but drag the team down being inflexible or insisting on solving the wrong problem.
I like the saying that "engineering is a team sport" and agree that the multiplier should be on the productivity of the entire team as mentioned in the article. The concept of whole being greater than the sum of its parts applies to both engineering systems and technical teams (which we'd probably say is a type of system on its own).
Not meaning to downplay the role of great engineers... I suppose the best scenario would be 10x engineers who can also help the rest of the team perform better.
This is fantastic to see - I've been thinking about the need for something like this for a while.
I think there are two markets for this and I feel like you are already addressing the homeowners. Have you reached out to utilities who are looking to shave peak loads with DER?
I recommend this essay often to people, especially in a start up. When someone describes their organization as being "flat", it's often a red flag because it means that there are unwritten power structure that newer employees will likely be excluded from.
That is a beige flag at worst. Every organisation has unwritten power structures that (often) exclude newcomers. Some organisations also have additional written power structures that (often) exclude newcomers.
While you're correct, my experience has been that the unwritten power structure is much stronger in places where there is no written power structure.
Where there is a written power structure you can usually appeal to it and eventually get something done. Where there exists no written power structure at all, you're out of luck unless you can quickly figure out what the power structure is.
A written power structure is a low resolution map. It's not perfect, but it gives you some idea of where to start making sense of things. A flat organization is never actually flat, but it also has no guideposts at all to show you even the rough outlines of the real hierarchies.
I worked in an organization with a low written structure. Creating unwritten structure is necessary consequence - each it happened as a reaction on serious dysfunction. And each time it improved things. And what you learned each time is that if you dont keep power, things will get very bad again.
Imo, that is argument for written structure. Written structure is easier to talk about openly talk about, reason about and fix. Unwritten structure is inferior consequence of its lack.
This is analogous to the 'unlimited' vacation policy. Now instead of following a codified and shared standard the employee has to negotiate every vacation day and consider how it impacts their standing in the organization.
It's an example that Zizek has often given. The startup boss is more insidious than the old school boss because he's "just your pal". The traditional boss you can rebel against, in the startup you can't because duh, you have no boss, so what are you complaining about? It's a way to disguise power.
Another thing is that it's also a way to dodge responsibility, as you see in tech. When a Japanese company fucks something up, you'll often see CEOs take salary cuts and sincerely apologize in front of the public. No need in startup land, nobody was responsible.
Indeed, flat or unstructured social organizations are going to lead to abuse if not coupled with some explicit philosophy that ensures that the group doesn't devolve into "might is right" or ingroup/outgroup thinking. Anarachists as in OP have one such philosophy and corresponding actionable processes to prevent abuse in unstructured groups.
So yes, the startups or orgs have to very explicitly lay down processes, otherwise the red flag is probably warranted.
Wow - that was painful to read because I can relate so much. Thanks for sharing. Another aspect of such dysfunction is the diffusion of responsibility that comes with it. The stubborn people who pushed for a particular solution rarely suffer ill consequence because the decision was technically made as a group.
I think a functional engineering decision process is more akin to a veto process. Someone, say Olivia in your example, would be tasked with selecting the language for the job and submitting the technical rationale for it and the relevant authorities (e.g. CTO or product owner) would sign off on the decision. They will normally have the power to approve or reject but not to impose certain solution. In a traditional hardware engineering, this is how it's done, where an engineer submits a design and it needs to be approved by relevant subject matter experts in various domains, such as material, thermal, structure, safety etc.
In Germany it just means it's a bad place to have a career in. Thankfully most HRs will happily advertise it in the job description making it easy to dodge.
I understand there is updates being made to the space export control rules (https://www.space.commerce.gov/new-space-export-control-rule...) regarding space/satellite components that were previously classified as ITAR. I've been curious to know if this will enable Canadians to apply to some space/aerospace technology companies in the US that were restricted to US citizens only?
We've done a lot of work for satellite and space weather companies and the feeling I've gotten from my clients is that these changes will open up jobs at space/aerospace technology companies for foreign nationals but right now, it's too early to tell.
Woah - this is strange. This was posted yesterday but I see that the timestamp has changed so it's only 4 hours old now. The timestamps for the comments seem to have changed also.
I think it’s a bug in how they merge threads. I saw this glitch in the Matrix a couple weeks ago. Went to respond in a thread and found I already had the day before. It was first thing in the morning in and telling me I posted four hours ago. Uh, no.
Fair enough. I feel like I've been seeing a lot of questions on Reddit along this line that comes off as very low effort to generate engagements so that's really the reason behind my comment but I see how my response also comes off as snarky.
I know what you're saying. It must work though — it engagad both of us for different reasons, rose to front page of HN. (Perhaps you would rather it did not though.)
Funny thing is, despite being an avid reader, I can't really say what my "best" book is. But I can easily describe the best meal I've ever had: we were on a tour in Chengdu, and they took us to a restaurant without any introduction. The meal was good but nothing special, until halfway through, when that nagging feeling that the flavor wasn't quite right made me realize that this is the Buddhist fake meat I'd heard about. And I only realized because I'd lived in China and eaten lots of meals so I knew what things were supposed to taste like. I have to say, the fish soup was incredible, the fish even flaked properly. To be so good that it took me halfway through a formal meal (which involves multiple courses) to recognize it speaks to how well it was done.
I never got to ask this as an interview question, but I always thought it would be interesting to ask - 'if you were wrong, would you want to know?' Not on any particular topic but in general. When I asked this in casual settings, I thought it was illuminating that no one gave a simple 'yes' as an answer.
That's so alien to me, because my answer to your question is an enthusiastic "Yes!!".
On further thought, I think the only humane objection is whether truth can ever really be separated from judgment. People don't like being judged and especially not judged unfairly, and true propositions can nevertheless connote judgment by contextual salience of the particular thing we tell someone that they're wrong about and why they're wrong, etc.
I would definitely think this would be very topic-dependent.
Perhaps the flip side to this is to consider when (if ever) lies or mistruths are allowable. After all, a lie, believed sincerely, makes the believer 'wrong' about something. I can certainly think of things told to me by people I care about, that if they turned out to be lies, I wouldn't gain any utility or value from their revelation.
Not an issue if one can do both but when there's a conflict, a great engineering firm will prioritize safety & quality over profit, whereas a business will prioritize profit & stock price over safety & quality.
Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
Scrum came from a world where product folks and developers never directly talked to each other. Everything was a formal written request with some requirements and there were SLAs for how long developers could look at it before providing questions and estimates back. After one (two if you're lucky) round(s) of questions a deadline is established, and work begins.
In that world, creating a single product owner that had the full complete say of this is what will happen that met with developers on a daily basis is a huge improvement of individuals and interactions. This is the single biggest win of Scrum, getting people to just talk to each other regularly, by having mandatory meetings all the time. If an organization has good communication or a product is too large for a single person to manage, Scrum ceases to be as useful option.
Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work.
Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.
Some software-related work, like regular changes to a website, or regular SRE work, is understandable and relatively repeatable.
Software development work usually isn't. Software development, by its nature, automates away everything repeatable and predictable, so unpredictable and never-before-seen stuff dominates.
Manifesto came out in 2001, you need to take into account the context of that time - the processes were often much more heavy-handed (esp. in big companies) than they are now. This manifesto item was never about not creating any processes.
Can confirm. I worked as Airbus' tier 1 supplier and they were even accompanying us to manage our own supplier, which in hind-sight, ensured that things like this didn't happen.
The way the project was structured, it was in the interest of everyone to succeed since everyone paid for their own development cost and only made money when the planes were sold. Not the easiest client to work for mind you - I've been told that many companies flat out refuse to work with them, but again, thinking back, I think that's what made the project a success, although extremely stressful.
Some customers you can't afford to have and some you can't afford to lose, especially not the ones that help you to perform at (or even above, by educating you) your potential.
Yep - certainly lessons learned through painful experiences.
Supply chain management is incredibly challenging and it's interesting to see one school of thought moving away to vertical integration as an alternative solution and another doing just as well with suppliers (Airbus, Apple, ASML, etc).
I like the saying that "engineering is a team sport" and agree that the multiplier should be on the productivity of the entire team as mentioned in the article. The concept of whole being greater than the sum of its parts applies to both engineering systems and technical teams (which we'd probably say is a type of system on its own).
Not meaning to downplay the role of great engineers... I suppose the best scenario would be 10x engineers who can also help the rest of the team perform better.