In many companies, the 'product' department exists to protect the owners from the leverage developers would have if they had access to the business context.
In my experience it is the opposite of that. Many ‘product’ groups exist because engineering teams kept complaining about meetings and just wanted to be told what the build. Collectively as a profession we have ceded away many of the things that made software development unique and powerful over the last 10 or so years.
This is true, but I've also seen "product leaders" in organizations not articulate a clear vision, requiring the engineering staff to do a Socratic-like process to pull tangible requirements out of said "product leader". It's a tedious process so I'm not surprised engineers throw their hands up and just have a PM do it.
I do think SV puts more trust in their engineering teams to produce polished software, whereas other companies will burn through tons of dev resources over nit-picking or implementing speculative edge-cases.
> requiring the engineering staff to do a Socratic-like process to pull tangible requirements out
If you've got good business analysts, this is what they're supposed to be doing.
I think if you have great product people, great business analysts, and great developers, the system of PO-Analyst-Developer can work. The problem is that BAs and product people aren't generally making a ton of money, so the great ones will move on to more lucrative positions, and great developers get bored quickly if they're just given a list of JIRA tickets. So pretty soon, one of the three things breaks down then all hell breaks loose. The product folks don't have a clear business vision. The analysts are soft technically and don't know what questions to ask. The developers are either building a space shuttle when they need a bike, or they don't know how to build the bike in the first place.
On the other hand, I can certainly imagine situations where the requirements aren't "hardcoded" but rather they are flexible and heavily driven by what's feasible and what's hard from the engineering perspective (so they can't be "pulled out" from the product leader), and determining that vision properly requires involvement of engineers and can't [technically can, but the outcomes suck] be prepared by someone else and just handed off to engineering.
Completely agree, same thing has led to massive growth of product mangers, product owners, and various other titles that do similar things.
The devs still tend to have to ask a lot of questions to get anywhere useful but in these situations the P* roles at least give them some traction to work from and get movement.
Frankly, since I've moved to the Netherlands, every project I worked in seemed to exist exclusively to justify a comfy, lazy job for incompetent Dutch POs, scrum masters,"customer journey experts", copywriters, designers. There is way too much money in this country and an incredible amount of bullshit jobs.
Sounds like a big company problem. In most startups anywhere in the world, I would think they would be pressed for cash to just hire software engineers.
Junior engineers and PMs need the software to have a skeletal structure on which they can hang their features. This skeletal structure has to be put together by the lead engineer and lead PM. Usually I see both PMs and engineers churning with bad design when such a clarifying structure is missing or ill-defined or has become broken due to hard pivots in pursuit of business/product-market fit.
I would tweak that just a bit that bad developers just want to be told what to build.
The best engineers I've ever worked with and for were constantly asking "why" and would get incredibly frustrated in this "Product Owner runs the backlog" type of organization.
Edit: details. Our devops allies itself with management and kept “business secrets” from developers. It was abbhorant to witness. I eventually introduced functionality into the devops tools and openned it to developers and got bullied (2nd edit: by my own team and management, i was soft bullied: silence treatments, secret meetings without me, lies, etc. i was junior. My own confession: i did the work without discussing it with the team after being told “fuck the devs” by a senior.) to quit.
My guess is that if developers understood the business, they would understand how simplistic a lot of the business models are, and how much of the profit is derived directly from their skilled labor and yet how much of the profit goes directly towards someone else, and developers would suddenly realize they have leverage because they are essentially the profit model.
Note that this is the case in most industries, not just software. And that's why the "patrons" "bosses" "chiefs" whatever they are named over time always fought to keep their employees silenced, non-organized... Maybe now is the time to consider cooperatives and getting rid of all or part of the hierarchies (some cooperatives work well with simpler hierarchies). They want disruption, we cut the ties.
Hmm, that is a weird conclusion to draw from the observations.
The article and the conversation here suggests that the Silicon Valley model is a good way to give developers more leverage and also to get more out of them.
That model is generally far from cooperatives and still has plenty of hierarchy.
Getting 'organised' and into cooperatives might still work, I don't know? I'm just saying that the available evidence here points to a very different direction.
(Cooperatives have been tried, and there are some software companies inside and outside of Silicon Valley that work along similar principles. But by-and-large they aren't the companies eating the world.)
Matt Levine's Money Stuff often harps on the theme of investment banks being run like workers' cooperatives in practice.
It asked why couldn't development firms be organized like how doctors or lawyers often organize themselves, as partnerships with the PMs, etc like nurses or paralegals.
On a more macro level, doctors and lawyers use regulation to keep the competition at bay.
In some jurisdictions, there are limits that make it harder for outsiders to employ doctors or lawyers and sell their services like you would employ programmers.
(In eg Germany, that even applies to pharmacists.)
Even if they use regulation to limit how many and who is a practitioner, this doesn't give a satisfying answer to why they organize themselves that way and we do not.
Just because anyone can be an engineer, it doesn't follow that we can't form partnerships. I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.
Another argument I heard was that partnerships are required in certain fields due to liability concerns so that risk can be contained to individual partners. But this only explains why they must, not why we can't.
> I could be wrong, but those doctors and lawyers who are in partnerships don't seem to be using that structure due to lack of employment opportunities under other structures.
A big part of the regulation of doctors and lawyers is the part that keeps the competition out. Google or your favourite startup can't just train up a few neural networks and start dispensing legal or medical advice; even if that advice was much better than what you'd get from your median human lawyer or doctor.
The organisation into partnerships might be more about who's excluded, than what the people in the club are allowed to do?
You are right about liability concerns playing a role, too. And then there's also tax issues.
As long as the engineers are replaceable by other engineers, that’s not really leverage. The leverage is the capital to pay the engineers’ salaries and the risk tolerance for the business model possibly failing.
Essentially, developers with substantial domain experience / familiarity with the problem space tend to do what they think is best, instead of following orders.
Accepting the value of that behavior requires a great deal of personal and organizational maturity, especially when you want to try something out quickly and your developers refuse.
Sample phrases include:
"Why did the customer ask for that - it sounds like our planned implementation won't satisfy their goals", or
"Won't this change mean we operate at a loss to subsidize your other company, which will affect staff bonuses".
Staff at company A have negotiated a profit share / performance bonus.
Boss directs company A to provide services “below cost” to company B. Company A now has no profit to share; it has been funnelled elsewhere to avoid paying the staff their bonus.
Thats an interesting take. But wouldn't product end up having the same leverage? Or is the goal to divide product and engineering work so that no one person has the complete view of the business?
The product department (of a sizeable software company) generally lacks the technical ability to actually construct a competing product with the business knowledge they have.
They understand the business' financials and interface directly with customers, but they don't understand how the product works. Any features or issues end up being proxied through these nontechnical resources.
This is why you will hear devs complain loudly about the parasitic product department (or equivalent layer above them) that always just seem to be
> getting in the way
However, because developers often don't actually want to interface with customers and just want to build cool tech, and charming socialites are very glad to act as that interface, this usually works. As a secondary effect they (non-intentionally) obfuscate the inner workings of the company from the devs who would otherwise (as the GP points out) realise how much they are being (ab)used and turn the screws on the upper management.
