[graypegg]

> It's for those who believe that skilled engineers are the true drivers of innovation and creators of meaningful products.

Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I do think developers have a major role to play, I don't think a company past a certain size would benefit from only devs making all decisions. A little specialization is OK when there is actually a useful task at hand.

There's innovation to be made on design or business side stuff as well. Maybe sort of lame to you, but it's helped me make stuff in the past.

Nothing to do with Agile btw, hopefully this doesn't sound like I'm pitching the tech world's private definition of capital A "Agile" with a different lens. Just a plea to appreciate that engineers aren't multitasking super gods.

[zelphirkalt]

I think we need to reverse the roles or how they play out in companies in day to day life. We need other people than engineers to _ask_ for certain changes or _make suggestions_. Not a product manager, who takes ideas from other departments as law and _makes demands_ out of that for the engineers, and then by the might of their management position push the changes through.

We could be better off with for example a designer talking directly to the engineers and asking them "Can you achieve XYZ?" then the engineers thinks for a bit and then reply "We can do XY, but Z would be way more effort and not worth it at this time.". Then they decide, whether to do XY even without Z. I don't see why designers or engineers should not be capable of sitting together to come to a decision, and I don't see, how there necessarily someone needs to be involved trying to force something down the throat of engineers.

Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.", instead of sales and marketing running off selling things that don't even exist yet. Then there needs to be acceptance and trust in the engineering team's competence. If that trust does not exist, we need to ask ourselves what the company is doing with such a team.

How I have come to loath the view, that engineers are like a band of little children, who will run off and go all crazy, if there is no manager ordering them around.

Some kind of overarching goals will need to be known or thought of. Those we can extract from having contact with the actual users, and from having great ideas, that we test out and get user feedback for.

In reality most engineers never have contact with the actual user in their daily job and as such, it is of course very far removed from being agile.

[danjl]

Just make the Designer the Product Manager, or get rid of the PM title entirely. After all, the process of navigating features and fixes to move the product forward is really a design job, not a management function. Also, the more the technical and design people understand the business side, including Marketing and Sales, the better. Ideally, technical and business sides work together, with design as the cartilage that holds them together.

[graypegg]

I think every good experience I've had as part of a team, was because the business people, the designers, and the engineers were all respectful of each other, and had no power over one another. So I totally agree! Nothing stops that.

People always imagine every team has to be some little internal war, and I think the whole methodology-mill industry is built around that belief. People CAN'T compromise or work together, or at least we can't bet on that, so here's some process. That rubs me the wrong way. It's pretty patronizing, you're right that it's like treating engineers like children.

> Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.",

This is a totally respectful conversation with understanding on both sides. I might want to just make sure that the engineer in this scenario would be open to:

    Marketer: "Feature XYZ is going to make a massive impact if we could get it with some clients this year before competitor X. Even feature XY without Z would beat their offering. What do you think?"


    Engineer: "Ah yeah, I can see how that would be a really good advantage to have. I think XY might still be a bit hard to hit for EoY with the quality requirements we have, do you know precisely what they're planning?"


    Marketer: "They are really only shipping feature X for the first month I think. No screenshots of Y in their announcement. Being the first mover would be good, even without Y."


    Engineer: "We can make X happen, easy."

That conversation is also very respectful and everyone is adding valuable knowledge. It feels more realistic to me as well. Sometimes "no" isn't a great answer when "could we try for something at least?" means we could solve a lot of problems/make a lot of money. That's sort of my ideal way of working now. I'll hold everyone to the expectation that they're good at what they do, and they respect that I'm good at what I do.

[bluGill]

That works when there is 1 engineer and one marketer. When there are hundreds of engineers and many marketers you risk the marketer unknowingly asks an engineer who isn't the right one and that person over promises not realized the full scope of the problem and how it will affect others who are also making their own promises.

[graypegg]

I'd rather have a (high!) chance of that happening as a mistake low down on the hierarchy tree, where it's just the marketer (or maybe a region's marketing team) and two engineering teams involved that have unfuck their situation, than high up at the top where the C-suite only talks about the roadmap with the marketers and the bad decisions just wash over the whole company.

Don't think there's any solution that fits all scales of head counts in all fields of work. Middle management exists because employing 1000 people to each do something specific is inherently a hard task. Are they doing the thing, are they stopping other people from doing their thing, have they signed this form, have they got their benefits for this, are they getting paid the right amount, etc.

You actually save a lot of hassle with hierarchy, in the people-wrangling group of tasks.

But I still think some inefficiency at the lower level between motivated product teams with a few mandates each, is a better long term bet than assuming the same reasoning for middle management to exist applies to other fields. Engineering/design/marketing isn't people-wrangling so we shouldn't assume the same solutions that work for wrangling more people work for shipping more products.

[alganet]

A company with hundreds of engineers and anyone of them can overpromise on some random feature?

Sounds like a widespread communication issue.

[bluGill]

That is why we have processes - so people know what promises they can make.

Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.

[alganet]

I've been there.

If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance.

If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process.

I've been on teams that transformed every little mistake into a lesson, burdening the whole team with cargo cult processes. Things we did because "once upon a time....". That's not healthy. I'm not implying that's your case, just showing another perspective.

[diob]

Absolutely, I love working with great designers / markets / etc.

[gspencley]

"The 5 Laws of Holistic Development" at the bottom reeks of being written by someone who is bitter and falling into the "us vs them" trap.

I get it, I used to get really upset when business "overruled" engineering advise and decided to adopt a subpar solution, such as reaching for a 3rd party vendor or telling me what library they want me to use.

Then I realized that the job of a really good senior engineer is to offer options, be able to discuss the tradeoffs of each and to empower the business to make informed decisions that take ALL of the context into account: budgets, timelines, market pressures, planned shelf-life of the application, what "quality" means to end users etc.

It is the business' role to do cost benefit analysis. Engineers tend to get into the mindset of "there is one, 'right', way to do something." The reality is that there are many possible solutions to a given problem, each with their own tradeoffs. The business hired you to be able to provide solutions that align with business goals, objectives and budgets.

If a manager is telling you that they like a particular tool and would like you to consider it, that's a sign that you have failed at communicating. You have not communicated the fact that you have already explored various options, you have not communicated the fact that you understand that there are tradeoffs to be found among various options, you have not communicated that there are options at all. Most likely you did what engineers are inclined to do: you told them what you think is the 'right' way to do it, and they don't like that because it is too expensive and you didn't give them a single "out" so they are looking for them themselves (even though that was your job).

"Synergy: Value genuine, purpose-driven communication over forced meetings and rigid processes."

That's no different than "people over processes" from the original Agile manifesto.

"Adaptability"

What do you think 'agile' means?

"Courage: Foster an environment where taking risks and learning from failures lead to breakthrough solutions."

Courage is a value that companies either hold or they don't. At my current employer we embody this as "Normal sucks" in our core values. This tends to be a culture problem when companies don't value courage. I don't object to this one, but it suggests that the author is bitter having worked at companies that don't value this and want to maintain status-quo.

"Mastery: Cultivate engineers who combine deep technical proficiency with a clear understanding of the product vision."

Here's the catch-22 when it comes to business:

You want to hire a team of super experienced and talented engineers who can develop your application to an incredibly high standard in a very fast time.

Your first problem is that the labour pool for software is already tiny. That's why wages are high. So you have a hard time just finding these engineers in the first place. Once you've invested weeks into trying to recruit them, some Fintech company with a bigger budget snatches them up from under you.

Now say you did manage to hire a few. These are middle-aged individuals with families who cost a small fortune and have very low tolerances for bullshit. They will not work weekends. They may be willing to work the occasional overtime but only if that's a rare occurrence, they participated in getting the team into the weeds and the overtime is guaranteed to get the team back on track.

This senior engineer isn't looking to get promoted, they are already earning enough comp that more money no longer motivates them. Some of them are approaching retirement while others are looking to move into leadership positions.

Whereas you have less difficulty hiring someone with 5 years experience. This is a young person in their mid-twenties who has something to prove. They want to get promoted so they want to impress you. They are not married with children and so they are way more willing to give up weekends and churn out mediocre pull requests like it's no ones' business.

What the younger engineer needs is guidance and mentorship. They need the people that you want writing the code teaching them how to write the code that you want.

That's another culture issue. But hiring is difficult especially if the person doing the hiring is not an expert in the domain they're hiring for. This will be the case for virtually ALL tech startups that aren't being co-founded by an engineer ... you need to trust that the top engineering talent you are hiring is competent to do the tech hiring for you.