But Elon has already moved on mentally and is currently on track to get Twitter relegated as well so I'm not sure we need to worry about what he could do with TSLA if it received unlimited funding from Saudi Arabia
(hmm... more overlap in the analogy than I thought!)
I don't think a regular CEO is going to be able to restore the reality distortion field that got TSLA overvalued by that much in the first place, but they might at least look interested in selling cars.
> > I don't think a regular CEO is going to be able to restore the reality distortion field that got TSLA overvalued by that much in the first place, but they might at least look interested in selling cars.
Problem is that selling cars is a much tougher business than selling hope.
I am also looking for this information. I largely switched away from lastpass over the last 12 months, and only a few low-value credentials remain in it. But if this is an old backup, then it is more concerning for me.
How is it possible that the image size is so much smaller with the WASM image compared to the Docker image? They need to ship the entire php runtime compiled to WASM, so I don’t see how it can be smaller
> The past two years created a new type of hype: PMs. Until the Tech Giants (eg: Google, Meta, etc) made PMs the ‘new normal’ of how to get any product functionally built and delivered, down to the tiniest button, startups used to do just fine with no PMs. Chances are very high you could do with less (no?) PMs. Also an excellent forcing device to kill some of your internal bureaucracy.
I think the PM fad has been around much longer, to the point one almost forgets how to build products without PMs. But from my experience, I find that the prevalence and empowerment of PMs is largely turning Devs into highly-paid code monkeys, as opposed to the highly-paid and empowered value builders that they should be. Much of the busy work that many PMs are doing can be replaced with a bit of Agile/Scrum training of a few devs per team.
At the same time, I would say that having a product owner who develops a deep understanding of the domain, actively talks to customers, and steers the vision and direction is immensely valuable. But I hardly see any of my PMs doing it.
Anyway, I am seeing a lot of negative sentiment towards the prevalence of PMs these days, which I mostly share. Would love to hear any counter-thoughts or corroborations of this. Are PMs necessary? How should they be utilized?
The important point is that someone is thinking about product vision and how you are actually going to sell/deploy to market your stuff.
If engineers or eng managers were doing that consistently, the PM role would not need to exist.
The reality is that most of the old-school engineers used to do this. As the "aperture" for engineers widened, the ratio of engineers who can actually apply this relevance/business lens to their work has decreased significantly so you need someone whose job is to be accountable for the vision and actual ability to turn code output into dollars.
As someone who moved from an open-core, engineer-driven company to a closed-source, product-driven one - this is spot on. When this article says that startups used to not need PMs, it's true, it's just that the startups that were product-focused won and the ones that weren't were acquihired by the winners for their tools and engineers.
Whether product focus came from product-focused engineers or product-focused management, it didn't matter. "Startups didn't always need PMs" really means that before PMs, engineers used to have to be product- and value-focused - they had to care about customers and profitability - and more specifically the early engineers who worked for the winners were probably better at product focus than engineering.
Also, if tech PMs who haven't worked outside of tech before read this article and feel depressed or angry, remember that there are massive sectors - agencies, health care, construction, any level of government - that need tech-literate PMs to manage vendors and contractors. You'll be the only person who knows or cares what it's like to work in tech, which is often more than enough to ship projects. If you're not looking to become a product-focused developer (which, see above), then ride out this wave of anti-product sentiment outside of startups. I promise there's space out there.
Agree. And you could argue that Founder(s), owners of the company AND product vision, should keep that role as long as possible. I see too many Founders relinquishing this role too early. One argument being: I need time to raise and recruit. True, but these having taken such massive proportions lately, Product has been delegated 'under' the Founders = 2nd priority by definition. Hence so many companies with millions in bank, over bloated teams, but not even clear PMF, let alone economic models. Economics should remain a core part of Product.
Another explanation is: we have seen a much bigger proportion of Founders with little experience in 'cross-functional work', 'integrative management' and 'user-led holistic thinking' experience. All critical to PMing.
Big fund raises allowed to compensate for that, by recruiting PMs.
Again, lots of startups, at the right stage, need PMs. I am just seeing too many startups over staffed in PMs and Founders too far from this.
1. PMs in software have been around much longer than the last couple years, in orgs of all sizes. Ben Horowitz was a PM at Netscape in '95. The author toots his own horn a lot about his achievements in the startup world - this is such a weird point to make.
But to your point:
2. I have been a developer and product manager myself. I still do both things, and hire developers. I don't think I'd even trust 1 out of 10 devs I meet with business analysis or product management responsibilities. Yes, both skills can be learned by a single person, but it takes much more than just a couple days of coaching to teach someone not only how to build something but what to build.
I have 7 years of experience in each and I still find it ridiculously difficult to juggle both skills. The context switching and the amount of skills needed (user research / talking to customers, UX, project management, full-stack development, thinking abstractly and tackling open-ended problems, vs acting concretely and solving more close-ended problems, etc.) make it very challenging.
Yes, in the 80s and 90s there were many more analyst/programmers. Perhaps the stacks were simpler, perhaps there was less competitive pressure for software companies, I can only think of hypotheses. The fact is that today, doing both is very hard even for the smartest of cookies, which is why the roles have been largely separated. This was "invisible hand" economics at play, not the whims of Google and Microsoft in the last two years (again, what a weird point to make!)
Not an expert on PMs (is anyone?) but my understanding is the value to the business is, as you mentioned, abstracting the need to manage SWEs as value builders and instead as cogs within the Abstract Agile Machine, in this Sick Reality the PM is Programmer Remade and we are reduced to function calls. Software makes a lot of money and plenty of smarter people out there have invented roles to extract some of that (your) wealth without having to touch Vim.
Due to the relative novelty of CS I think we're still going through the early motions of trying to mesh together a web of programmers from bootcamps to MIT into one cohesive corporate apparatus... eventually we'll land on something similar to medicine or other engineering areas where accreditation is prerequisite and individual cogs have a bit more agency due to licensing etc. Hopefully.
My personal, unsubstantiated, take is that we'll come to look back on this odd time, with the glacial pace and grift hierarchy of enterprise software, as quaint. Some startups are coming around to the idea that you don't need 6 person multidisciplinary teams for generic CRUD, pay one competent engineer those 6 people's salaries and you'll get it built unless it's something special - in which case you pay that engineer 60x and their name is Bellard.
The PM ladder is undoubtedly there for MBAs to perform wealth extraction from you. And it works, for now.
If you see those "day in the life" videos going around Twitter/YT where the person literally does no work, it's always a PM. Sundar Pichai (and I think Satya Nadella too) came up through this ladder. It's a role for professional office politicians created under the guise that engineers can't figure out what to do for themselves.
I don’t think the specialization of engineers is accidental.
I’ve worked at a number of companies and engineers are ALWAYS the limiting factor. Simply put, there’s a chronic shortage of people who can build valuable stuff.
I believe companies have sought to offload this bottleneck. Have engineers just build, and hire people to do everything else.
Engineering accreditation (at least at the Professional Engineer level) is not that common in the US except in civil engineering. It's basically needed to sign off on designs etc. for regulators. (You also see it with consultants who give expert witness testimony, etc.)
Even for other engineering disciplines that don’t require a PE, it’s common to require an engineering degree from an ABET accredited program. Much more common than it is in software.
I've never seen that myself but it's probably pretty common for companies to often effectively require a four-year degree from a school they've heard of--which probably boils down to more or less the same thing.
The ABET accreditation thing is interesting. Last time I looked into it there are even some things that require it for CS (becoming a patent lawyer for example).
Here's. the first job I found when I searched for local MechE jobs.
>This position requires a BSME or MSME from an ABET Engineering Accreditation Commission-approved program with a strong academic background and interest in thermodynamics, heat transfer, fluid
When searching for local EE jobs. Out of the first 5 results, 1 required a PE, 3 required a degree from an ABET accredited program, and 1 just required an EE degree without specifying ABET.
>Bachelor of Science in Electrical Engineering or related degree from an ABET accredited program.
There already is gate keeping though, and that gate is manned by corporate which, ironically, is how so much bloat can sneak in at your expense.
I am not fond of gates either; for as long as your skill can produce capital value it will be gatekept in some capacity. I'd rather see that gate moved closer to our side if it must exist.
If gambits like Musk's prove successful then there is further precedent that
lean engineering teams can still operate at scale - just with fewer layers of indirection and wealth extraction.
Do you mean Project Manager , or Product Manager? What you described as training a few devs sounded like Project Manager. If so, I agree. But a product manager's role is different. And you are right - it's about competitive research, domain expertise, customer interviews, and a product vision.
I have not seen a single product manager do the project management details in my 25 years of product/eng career.An engineering manager typically does that. I now run my own startup, and empowering engineers to define the product does not work. You may get some interesting and nice features, but you won't get a cohesive product that solves for a domain with decent usability. You need a PM/UX pair for any nontrivial product.
I agree that product managers should set the product direction. But my personal anecdote is that they have too much say in what engineers do and when, to the extent that the default answer of engineering teams to everything becomes “talk to pm and they decide when this can go in”.
I think the dynamic that creates this is that the product org becomes responsible for delivering features/products to business stakeholders, and product blames any delays on Eng not being able to deliver on time. So then Eng decides to let product plan everything to a t, such that Eng cannot be blamed if they meet said plan. Which is what motivates my use of the term “code monkeys”…
I feel like engineering should have the freedom and responsibility to entirely own the product delivery. Product managers/owners would still decide what product should be built, and then Eng would take it from there. But I don’t think I have seen this anywhere, and not sure if it would work.
Agreed. I'm surprised you have not seen this before, though. This is pretty much how most of the orgs I've been part of have operated. Product owns the "what", and engineering owns the "how" and "when". If "when" becomes immovable due to externalities, "what" is negotiated. Some times, eager engineers will say yes to "what" and "when" , and "how" suffers (quality). Some times product defines "what" so badly, both "how" and "when" suffer.
I've joined a startup with no PM and CEO assigning tasks to devs. I've spent two weeks chasing my tail and working on stuff other people were already working on as a part of some huge block of work dumped after a month of development or stuff made irrelevant by features being worked on. I quit after ~3 weeks.
The CEO was doing it wrong. They should have empowered you to talk with the customer, identify the pain point and a build a solution.
You were right to leave.
Partly on the CEO but also partly on you. If that's a startup, you should be able to figure out what's going on by talking to the others and getting an understand what is being worked on. That is, unless it's a "startup" with hundreds of employees...
The guy running the company and playing ad-hoc PM isn't aware what people are working on and is assigning me tasks being worked on already.
Meanwhile I'm supposed to onboard to the project, deal with technical mess that is start-up with a live product and get a hang of what everyone else in the team is doing in two weeks ?
imo, the #1 role of a PM is to bring the user inside the company. To be the users' advocate and voice.
Anybody who is PM without talking to users and doing that role may be a 'Project Manager', but not a 'Product Manager'. Products are meant FOR users.
PMs are essenial for B2C. You need to abstract a huge mass of end-users into discrete pain points and offer solutions.
PMs are not essential for B2B. An engineer can talk directly to the customer. Remember back when devs were called programmer/analysts? Exactly for that.
> Remember back when devs were called programmer/analysts? Exactly for that.
I remember, and I am business PM or business analyst and full-stack developer. Like I said in another comment replying to GP, I can totally see why many orgs separate the roles. It's messy. I need to fit the following activities in my schedule:
- Doing user research / speaking to customers
- Project management
- Basic UX, up to wireframing
- Design-as-I-code skills
- And of course, full-stack development, with all that this entails
Let me tell you, it can get crazy. I wouldn't change it for anything because I love being a generalist, but I'm surprised I cope sometimes. I have about 12 years of experience where I've done PM/BA, dev, or both at the same time and I often feel I haven't reached 70% of my potential.
I also hire devs and would only maybe trust 1 in 10 with this breadth of responsibilities. It's not that they aren't smart enough - some are infinitely smarter than me -, it's that they haven't been exposed to this breadth of tasks. Many of them wouldn't want to, either.
The roles have been separated because specialization is a law of nature in many contexts.
It depends how you want to split things up. You can almost certainly move PM duties into other roles. Product Marketing can (and often does) handle competitive analysis and pricing. Engineers can certainly spend a chunk of their time meeting with customers, talking with the field, etc. But it will take time away from engineering.
In my experience the overhead of adding the additional layer of indirection is almost never worth it. Engineers have to spend nearly as much time meeting with product as they would meeting directly with customers. And so much gets lost in translation that I would almost always meet directly with customers.
When I first started we had business analysts, subject matter experts, and customers that we talked to. Replacing those with PMs has not been beneficial from what I’ve seen.
I feel like most PMs in a B2B contexts are basically just Business Analysts. Which generally aren’t getting comped at the level of Product Managers who theoretically are supposed to be “mini CEOs”
This is really where I think the wheels came off cart for the role, because PMs are rarely given a significant degree of autonomy and are usually just a cog in the broader product org.
In my job search a few years ago I was shocked at how different the PM scope was across companies. Some places "got it" and were looking for a mini CEO. Others basically wanted someone to run the Jira board.
The comp for the role was a great way to tell what was what. Nearly a 10x difference from Jira monkey to mini CEO
> PMs are essenial for B2C. You need to abstract a huge mass of end-users into discrete pain points and offer solutions.
Maybe at some level, but I've also seen talented UX and front end/UI engineers idling away being fingers for PMs who just focus their days spoon feeding tasks to teams without involving them in solutions. I left a supposed startup earlier this year due to this.
I share the exact same thoughts. a good PO is worth their weight in gold. PMs are often more of a detriment than anything. Developers should not be cornered off from customer needs, quite the opposite, they should be made intimately aware of them.
Not only is seeing customer struggles a strong motivator for why they do the work that they do, but it also helps with coming up with good solutions.
A poorly thought-out task list that needs 10 refinement sessions before it is actionable is very much not that.
That said, devs are not sales people, that's why the PO is there, and the PO could very well have "PM"-like people under him to handle the customer connections before getting devs involved, but that's different from the "PMs define user stories" approach I see everywhere.
The result of that is that the PMs end up in a managerial sort of role (the name doesn't help) where they boss around the PO who in turn bosses around the devs until they get fed up with the relationship and the dev lead starts pushing back, and the whole thing turns antagonistic.
I agree but let me provide some perspective from hardware system product management a couple decades ago.
We did indeed make an effort to bring engineers into customer meetings when it made sense. However, you end up with tradeoffs.
- Bring select engineers into a few customer meetings at your company location which doesn't take a lot of time and does provide some outside perspective. The downside is that they get a very filtered sample which it's easy to over-generalize on.
- Make talking to field people, customers, etc. a significant part of their job and you're essentially making them product managers, at least in part, and they don't really have the time or focus to do nearly as much active development.
(Note that this was rather long-cycle hardware development--though software wasn't really much different. There really wasn't a lot of methodology to product management at the time except whatever internal processes we put in place.)
Yeah option 2 is pretty much a no go because of what you said, so it has to be option 1. Ensuring bad generalizations don't happen would be the PO's job in that case I suppose. If there was an obvious solution we'd probably have converged on it by now, but at least where I work the PM/Dev relationship isn't really optimal in any way. Unclear tasks, pissed off devs, messy project, etc.
Back when I was a product manager, I really was the product owner in so far as I was the point person for the field, owned pricing, attended product reviews, had at least a big say in launch decisions, wrote/reviewed external comms, coordinated with field engineering, etc. But, as I say, product management meant something different than it does much of the time with modern software. I never had any specific training on it.
Sometimes we did bring engineers in to have deeper technical backup for a specific discussion. Most of the value though was probably to provide some sense that we weren't just making things up.
I think great PMs are invaluable. Unfortunately, I find the vast majority of PMs are nearly a net negative on productivity.
My biggest issue is that I believe PMs must be technical, but many aren't. So what I often see happen is PMs come up with designs and requirements that have 0 consideration for how much they will cost to implement. Then there is a painful back and forth with engineering where we say "OK, this is just flat out impossible" or "there is a way we could do this that is 10 times easier". It's like trying to design a car without knowing which car parts and technologies are available.
This has been my experience as well. Yet finding technical PMs is difficult, I've only ever seen two in my nearly 20 years. For SAAS non-technical PMs are the worst since so much of the offerings are tech.
Yep. and worse, it's like designing a car without knowing the car's economics.
Like building a product for the product's sake.
In SW/HW, a PM that doesn't also build the unit economics is a wrong management choice and a waste of resources.
Everything is a matter of balance and reasonability. Yes, PM role has existed for decades actually, well beyond Tech (also often called Project Management).
What happened recently is: the Tech Giants organization have become so ... well, Giants, that they had to over multiply this role, as a way to get cross-functional work done, priorities upheld, etc.
Also a matter of choosing to over-specialize engineers (see how hard it is to find full-stacks now), designers, etc. And a matter of how far from the users have pretty much everybody become.
I knew PMs in these Giants for literally the 'edit' button.
Like everything else, the pendulum has swayed to the opposite extreme / exuberance.
Most startups will need PMs, after reaching a certain size and complexity. What I see is that too many startups, well before reaching that stage, have over multiplied PMs.
Finally, when your company is on a clear path to run out of cash, this discussion and trade-off becomes a matter of survival. Not of org concepts.
Are we talking about product managers or project managers? Those are completely different things. As far as I'm aware the tech giants have TPMs (Technical Program Managers) for very large cross-cutting efforts but mostly have engineers do their own project management. The PM discipline is about coming up with products and working out their details between all the stakeholders. They're not running the agile ceremonies. They're getting the copy signed off legal and working up an experiment plan with data science to choose between design's three different mockups.
> largely turning Devs into highly-paid code monkeys
Maybe senior devs can organize their work, but juniors cant. That's the reason to have PMs - cost cutting. PM cuts the problems into small pieces that can be done by some junior programmer.
> But from my experience, I find that the prevalence and empowerment of PMs is largely turning Devs into highly-paid code monkeys, as opposed to the highly-paid and empowered value builders that they should be.
Indeed. In the first ~17 years of my career in software I never met or heard of a PM. That's a job for engineering leadership (architects or equivalent).
Nothing good comes out of having a separate non-technical person making architectural decisions. Also as you say, it disempowers engineering which is a sure way to drive out the best.
1. PMs are not needed. Design+Engg launches great features and products. Design thinks about users, produces design, Engg turns into dev designs; and things are launched. PMs are useful when partnership etc. are needed (that is non user focussed activities).
2. PMs are essential in a domain driven tech space - ex. software for construction industry or rocket scientists. Here PMs with appropriate background connects Design+Engg to the industry.
The term PM is never really defined here. Is it project manager or product manager? Are we talking PMs with PM certifications like PMP or is this something else?
Love it. But one suggestion, which I’ve been looking for, is to fill the knockouts bracket based on the current group standings. That’s a great way to build up the excitement
Actually, I think it would be nicer to compute some sort of prediction based on the results so far, the strength of the teams, and the remaining games to be played.
Best of luck to OP, and there are some solid suggestions in this thread!
Just wanted to add that the wholesale adoption and normalization of WFH and remote culture in tech is worrying and will only make this type of issue worse and more common. Personally, I had consistently been able to make good friendships at work across several positions at different companies/cities/countries. That's until WFH and remote work hit, where now I rarely see coworkers in person (if at all), and often people are not in the same city. We feel more like automatons these days.
Tech work seems no longer a reliable vector for creating meaningful friendships or a social life outside of work. Like OP, many of us will have to learn to meet people outside of work.
Going office doesn't guarantee you will meet friend worthy people, if there aren't any. Where I work it's mostly older people in their 40's and 50s as someone in my late 20s there's 0 chance I'll make or want to make friends with them. We have nothing in common.
I work in ML engineering, and I’ve seen people work on a problem for the better part of a year with little to show for it. The non-progress gets on leadership’s radar, so even more resources get directed to crack what should be a solvable but non-trivial problem.
An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others.
I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.
==An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer.==
They also need the trust of their superiors to be listened to in the first place. A 10x engineer isn’t helpful if management doesn’t take their advice.
The Apache Arrow project is led by the creator of Pandas, which is one of the most important packages in the Python ecosystem. I agree Apache has some half-baked projects, but I think Arrow has the track record and backing to achieve its goals
I share the frustration with how many A/B testing driven development processes end up. Leads to a very iterative process with lots of small changes, rather than big bets. Also, trying to get statistical significance from iterative changes when you don’t have a ton of data is problematic.
I think that’s just down to a lot of folks who think ab testing is the answer to every problem not necessarily having a background in maths or stats. I see it all the time in marketing teams where people’s are so conditioned to think of testing as the default that they don’t understand what they’re doing or why.
