For example, in an area with strict financial/regulatory compliance laws, are you expecting every engineer to be an expert in those laws? And have contacts at the government agencies implementing those policies?
The developer teams, who else? You build it, you need to know what you are building, right? I find it fascinating that the dev community that gobbled so easily "You build it, you run it", doesn't question why we are not being trusted with knowing and determining what to be built in the first place.
> For example, in an area with strict financial/regulatory compliance laws...
How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?
Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.
I happen to work in a highly regulated industry, and we have an in house law expert, and an in house medical compliance team.
None of these roles are embedded in the development teams though, they are simply asked for advice rather than manage the engineers (which would be insane).
That is how it should be.
Saying it’s often some new grad is like saying there’s no point having an on shore dev team because the devs are often fresh out of university. If you continually hire terribly you’re going to have a bad result.
A PM should become the subject matter expert in the product they are developing. They should be able to field questions on most every part of it, and be able to build a roadmap of features. Communicate with all teams associated with it. Having the programmers plan all features is a recipe for disaster if your product isn’t designed for developers. It’s like saying you don’t need a qa team because the developers tested it.
The developers MUST care for the quality, not outsource it to some external team. The desire of large corps to spend huge amount of $$$ to create artificial roles to water down ownership can never cease to astonish me.
If your devs can't think of handling nulls or corner cases, you got a skill problem, and you should ASAP upskill the devs, not outsource thinking to another tea.
Making quality somebody else's problem is the exact opposite of ownership! You want agile? Damn leave the devs alone, stop building walls around them and the product they are building!
As a former quality-focused dev, I can tell you that the industry beats it out of you with a club. There is always somebody above you who cares only about their own career ambitions and has more leverage than you do. This leads to a horde of devs who just do what they're told and not much else.
Businesses are all about risk management. The safest way to de-risk a business is to water down ownership, at the cost of injuring quality-focused devs. You're only a cog. You need to only be a cog to them. They must to be able to replace you with another cog when you leave for greener pastures.
> I can tell you that the industry beats it out of you with a club.
i've seen pr's sent out for review that literally didn't work or crashed immediately on use... as if the expectation is qa will report whatever needs fixing but thats fine cause its "in qa now" so development is "done".
"When a measure becomes a target, it ceases to be a good measure".
Definitely can take a while to find one though, that much is true.
That seems like a very Bay Area mindset - advocacy is more lauded than doing something.
I used "advocating" loosely here. I hate the "advocate a lot, build nothing" mindset myself, and I am not a fan of the Bay Area and its practices (to put it mildly), so I edited my post.
What I mean is devs making tools for devs, resulting in better overall quality.
In my experience good test engineering teams can focus on having a more global view of systems while not being biased by implementation details.
Strangely enough, that's happening at a few companies (run by Amazon refugees IIRC) where they think that making devs do QA and removing QA/QE roles will speed delivery. I'm in one of those companies now, and I'm waiting for the #FAFO loop to happen.
If it's just clicking UIs all day long then obviously a QA should do it. Or have an UAT environment where a few more enthusiastic customers are willing to test and report bugs.
Nothing wrong with that, except what typically happens at larger scales is that some people enjoy wearing the hat more than others, then the team realises that it's better if those people spend most of their time doing product management, and then they tweak their job titles ever so slighty....
> How often do you have a Product Manager who is an expert in regulatory/compliance laws and has contacts with government agencies?
In my (highly regulated) industry, always? They'd be bad at their jobs if they didn't have this.
Edit actually, I walk that last bit back slightly. They don't need to be experts in those things, but they need to know enough about the broad landscape to understand what tradeoffs need to be made and set direction. Similar to a CEO not needing to be an expert in product, marketing, engineering, finance etc. to be effective, but they do need to have enough knowledge to know how to balance competing requirements across these things.
> Usually the Product Manager is Josh, who just finished uni, and a two weeks product manager course. They will have to ask experts, and then translate that to the devs. It's much more efficient to let the devs ask the experts, which will let the devs themselves become well versed in the domain over time.
I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else. I have long advocated that PMs /must/ be technical to be successful and, maybe more importantly, useful.
If you’re in an industry that is compliance encumbered, you should absolutely expect that your PMs are experts or at least professionally competent in the compliance standards you need to meet, or at minimum intellectually and contextually capable of getting there rapidly.
Hiring someone just out of college to be a PM is a huge red flag that your organization doesn’t understand the role of a PM, and that your upper level management is likely incompetent also. Without significant prior experience in some related facet to the product, it is not possible to be successful as a PM, and I wouldn’t expect a new grad to be able to do much more than push papers. PMs should always be former practitioners, if possible, but at least technically competent at minimum.
> I have definitely seen this happen, but as a very senior engineer, now PM, I can tell you this is a management/hiring failure much more so than anything else
Makes me wonder if you're saying that these cases are the exception. In my career they have sadly been the rule. Not 100% literally, i.e. my PMs have never been 22 years old, but they were, 99% of the time, grossly incompetent.
And yes they were a management / hiring failure, absolutely, but it seemed that nobody cared... :(
Absolutely this. And the engineering teams should have visibility of customer support and other functions to understand common pain points, causes of churn and opportunities for additional revenue-generating functionality. That doesn't mean answering run-of-the-mill questions or doing refunds all day, but it does mean talking to prospects, looking at escalated problems and keeping an eye on the wider industry.
Bonus the product team on reliability (as well as velocity), and the ops/sre team on feature velocity (as well as reliability), and it'll balance itself out.
I think some people simply can't get rid of the idea that there has to be some external paternalistic figure that looks over developers' shoulder and guides the poor hapless saps and their incentives. Do they give candy to the good boys/girls and coal to the bad ones? You might be thinking of Santa.
The developers and sre's incentives are the same as everybody else in the company: have a great, easy to sell, popular and reliable product. Management types insisting to compartmentalize incentives is them trying to have an excuse for their own existence.
We should all drag ourselves kicking and screaming to the reality that we can do much more with much less management layers. Even big companies, which are bloated beyond saving, are waking up to that fact. PMs are the first to go, just look at what Meta, a notoriously inefficient company is doing to their non technical PMs.
Think for a second why nobody has had the idea of letting an engineer be a 'Marketing Project Manager' of the marketing team and be calling the shots what campaigns to run, what marketing materials to produce, and make marketers estimate with poker cards how many of their leads will turn to a sale. Sounds stupid, right? Yet this is exactly what you want us to accept the other way around. Not gonna happen.
There is no excuse to have non engineers embedded in and actually calling the shots on behalf of an engineering team with the patronizing though that the engineers can't decide for themselves what to build and how to prioritize it.
Being on a team where everyone has a high level of personal ownership and accountability like that is truly wonderful, and I agree, it works great.
You just have to find (or build) a company that explicitly filters out the 99% of people who only want a job for the paycheck and don't care about the customers, the software, or the product.
The hard part is how do you design a compensation package for a developer or sre worker bee, to incentivize these? How do you make their bonus depend on something as nebulous and hard to measure as "greatness" or "popular"?
For most employees, the candy/coal model works. You're not going to find low-level individual contributors who work because they just want to make a great product.
Unfortunately, only the first part is practiced in my organization (company shares), but I am actively fighting for the second.
I have equity as part of my comp package, and I know there is zero link between how good a job I do and which way the Wall Street Wind blows today. So to me it's just like cash but with extra steps.
Maybe it's different in the startup world, I don't know. The only startup I was part of, everyone's equity went to zero when the business failed, regardless of how well anyone did their job, so I'm not much of a believer.
We just have a medical compliance team and ask them for input, but they most certainly don't tell us what to build nor drive the product direction.
In short, I question the need of a PM, not the need for domain experts (law,financials,etc).
Good PMs are often engineers or ex-engineers themselves. But a good PM will do a much better job than just sticking a bunch of engineers in a room and asking them to manage the product. A lot of developers really hate tasks like:
- Designing UIs
- Thinking through complex workflows to simplify them (unless they're developer workflows)
- Writing documentation
- Often also, identifying and fixing small quality issues like bad error messages
- Figuring out what the customer's actually need vs what they say they need
Some devs are naturally talented and capable of doing all the above, plus banging out the code too. That's great, maybe they don't need a PM or more likely maybe they will become one themselves in future. But left to their own devices a lot of dev teams will rapidly lose the plot and start producing features nobody cares about, or doing endless refactorings, or produce something that's too hard to use.
But imagine if the developers themselves could break down the external requirements into engineering needs!
Or are developers grug brains that need a bigger, superior brain to simplify scary real world into simple, safe engineering needs? Or developer grug so busy, must write code, no time look at feedback form, no time think client request, need simplified instructions, must slap keyboard, clack, clack?
Context: https://grugbrain.dev/
It's a well established fact developers love building things so much and hate wasting their time with useless meetings! The hero PM saves the developers so much thinking by being brave and talking with the scary outsiders.
The PM's selfless bravery gives the developers the time and space so they can focus on the really important part of building. The really important part of building is, of course, being in a 2 hour meeting where the PM is repeating (badly) what the experts said, and making you play card games where you pick some numbers, very much unlike a nursing home for the old playing bingo.
I love your take! You totally treats engineers as responsible adults who have multiple skills and abilities besides coding, and not at all like autistic children that would flip out as soon as somebody touches their crayons.
Correct. Most engineers dislike meetings, so much that they complain that they don't get enough focus time in the day and are constantly interrupted.
> like autistic children that would flip out as soon as somebody touches their crayons
No one said this, you're arguing against a strawman. But even still, how many devs do you know that willingly want to talk to customers?
Maybe not an expert, but literally every project I've been involved with where those things are relevant, the PM knew more than most of us, knew who to talk to, and was responsible to make sure we did the right thing. It is pretty much what half the role was about. They were often pretty senior people with long experience working in a relevant field.
I don't generally find myself in the Anti-PM camp; but I think one of the valid criticisms of the role is that high quality hiring for it is so extremely difficult that maybe its existence is an indication of a structural problem. As the article says; if the ratio of PMs to Teams should be less than 1:1, maybe the correct lens to view this role through is more of a higher-level product lead, or a separate product branch who act more like free agents that attach themselves to teams temporarily, splitting time, where needed.
I will say, I've worked in two roles where this was the case; one a very large public tech company everyone reading this would recognize, and another a 30 person startup; giving PMs higher cross-team authority felt, to me, like a really good decision. One small positive byproduct I actively observed: when speaking with our PM, who was shared with four or five other teams, he was constantly aware of all the other work they were doing, and would actively make recommendations about how our little feature could plug-in with their little feature to increase the quality of the overall product. One small negative he communicated: because the company had no entry-level PM roles, which is where he started before they refactored the org chart, its non-obvious how you backfill these roles or create an entryway for new talent to breach the industry. Their current solution to this is "well, we can't really promote internally unless an EM or Engineer wants to switch domains" which they genuinely did try to support.
- financial
- medical
- data protection
and you might need different experts' opinion for that. Do you suggest that they are all product managers?
> This let's you focus on the craft of delivery
I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machines". Me and my team mates are not a factory that simply takes input from a task master and produces code to their bidding.
I care only about one thing: solving the problem! That encompasses learning, understanding and, finally: delivery. To do that, I need to speak to stakeholders MYSELF, I need to see how they are using the product MYSELF, and any regulation I am gonna implement, I need to understand in depth. I don't need somebody to summarize findings for me, I can make my own damn conclusions.
Sure, I will ask the domain experts of their opinion, but me and my teams will decide what to build, when, and how, and do we will do it together, based on all our shared learnings, not based on what a PM told us.
Who prioritises the problems?
If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
---
> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
Ah, I see. There is a concept known as a separation of concerns that prevents this on most teams.
There is a good saying for complex service delivery that most developers operate with in application development and support. If you want to go fast, go alone. If you want to go far, go together. That "together" brings more skillsets that most small engineering teams have on staff, and is typically not beneficial for them to focus on gaining.
> If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
There's two types of problems that developers solve. Problems that they, themselves created (oh no, I wrote a bug), and problems that are given to them.
The second type (traditionally, the "business problems") are being prioritized and solved by the people who care about them. Namely, the CEO and the exco. Those guys set overall strategy, culture etc. and then the delegate the implementation and some of the detail to people with more expertise.
Developers do not run the business. They are delegated to to solve specific problems in the context of running the business. Not all of the business' problems will be solved by developers, but all of the business' problems should be solved in a coherent and harmonious way that accounts for the context of all the other problems in the domain (market, regulatory, finance & tax etc.)
For a specific product, the place where this context is managed is usually by someone wearing a hat with "Product Manager" written on it.
In times of plenty, this works, and I think it can have high velocity. Especially with very small teams that all have high levels of direct investment in the result.
There are also times of famine, however, and the work that keeps the lights on is often not work that even invested software developers want to prioritize. When making money is on the line, there's always somebody who's there to make you eat your vegetables. Who, in your conception of the problem, is that?
What kind of work is that? And why are the developers willingly not wanting to prioritize it, if the alternative of not doing it is becoming jobless? Do we need some kind of PM figure to say things like: "If we don't make this feature for the client, we are doomed, so start coding. Chop chop!". And do we need to keep that guy on the payroll for simply relaying a message?
Yes, and yes! I believe you're starting to see. Good management has value. Even if that is to deflect invalid criticism for devs.
"But if you don't do these things, the company fails!" Yeah, and look at all those small, engineering-heavy companies that do exactly that! And further--eventually, as you scale you reinvent division of labor because as much as we like to kid ourselves, software developers are not, universally, better at doing everyone else's job. (If you find yourself in a position where you are better at doing everyone else's job, you should probably find a new company to work at.)
Middle men only improve transfer of knowledge between people under very specific circumstance. Usually they just make things worse
Let children play Chinese whispers, I don't need that in my life
This isn't just applicable to some niche organisations working within e.g. finance (though there's likely to be a higher regulatory burden there), engineers need a basic understanding of something like GDPR to do their job because it impacts every organisation handling personal information in any form.