4 ms·

Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a

Every thing you just said rings true. I went from 20 years engineering into engineering management, and took my first PM role last year. I took the role at a twenty year-old software company that's never had good product management, and the place is horrible. Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof. Twice this year, I had to explain to 20 year-tenure engineers that don't understand why it's a bad thing that one API is TLS 1.3 only, another is 1.x, and another doesn't even require TLS. Customers hate us. For my product, they literally wrote the marketing materials first, and let the engineers figure it out. One stage of my product takes Oracle data and puts it into parquet. The guys who did it did it in three different languages, two other DBs inbetween (MySQL AND PG), and was going to introduce Redis before I stopped the insanity. Everything is fragile and sucks. Thankfully, PE took over two years ago and we now have an ultimatum to make money or else. We are a twenty year old company that has never made money (we've been a cost center). Even if we don't meet it, I feel like the Universe will be better off without the travesties against software design that we created.

aeternum 3y ago
In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
- snapetom 3y ago
  I do believe that the traditional PM role/background should be considered obsolete, especially in software companies. Well-rounded engineers should be in these roles these days.
  - kranke155 3y ago
    Are there enough of them?
  - aurareturn 3y ago
    The vast majority of engineers I encountered do not have what it takes to be a good PM. I'm an engineer myself.
- rewmie 3y ago
  > In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x? I mean, is that a relevant aspect of the vast majority of products? If not, why should a PM bother about irrelevant details? One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
  - aeternum 3y ago
    Generally it is quite important especially for SaaS. Old TLS will cause SOC2 cert, PCI cert failures and similar. It is the kind of thing that can derail a major deal as often the 'whale' clients are the ones that really care about security certs while smaller companies and startups don't. Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
    - rewmie 3y ago
      > Generally it is quite important especially for SaaS. You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice. But that doesn't seem to even register a concern, both from the client and from the PM point of view. Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue. > Non-technical PMs tend to gloss over things like that (...) See, this is where I think we disagree at a very basic level. There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
- BlackJack 3y ago
  A good PM doesn't have to know the differences, but should understand that mixing encryption protocols is going to break things. Ideally an eng lead would be flagging these issues.
Matthias247 3y ago
This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and bugfixes are too slow, and then its up to the engineering team to improve on this. But also for 10 out of 10 PMs feature development will always be too slow, since customers are asking for things being done yesterday, so this alone isn't a great indicator that engineering is broken. APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.
- snapetom 3y ago
  A lack of engineering leadership is certainly true. As is often told, the VP of engineering enjoyed creating PRs more than actually leading. There has never been an architect. The point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
  - sokoloff 3y ago
    I don't claim greatness at modern product design/theory, but I'd expect "what version(s) of TLS are supported?" to be primarily an engineering responsibility (say 80-90%) versus a product concern (say 10-20%).
- d0gsg0w00f 3y ago
  I think that most "good" engineering managers share the same traits as good Product Managers. - Someone to understand the customer's desires and shut down unnecessary work. - Drive the team to deliver features that the customers/business actually needs. - drive tech decisions to prevent future inoperability with other products - roadshow and maintain a team's reputation across the org - etc
simmerup 3y ago
How does a company not make any money for 20 years that sounds insane
- alwa 3y ago
  I don’t know if it applies to the situation the GP described, but profit != revenue. It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
  - stcroixx 3y ago
    I work at a 20 year old company about like this. We’re all comfortable, it’s really nice.
- snapetom 3y ago
  cost center
swells34 3y ago
Most the problems described here are just bad software engineering. Never seen a PM with any oversight on which DB is used, how shiny the tech is, how the API works, any of that. It definitely seems like there's a lack of coherence and customer focus, which would be in the PM's wheelhouse to deal with, but that's it. Need a better lead engineer with the time and authority to implement good practices.
yieldcrv 3y ago
the grift is strong with this one. well just remember that engineers do this to have portfolio pieces on their resume. they need validation from other people that they worked on a software stack, and to be able to do live interview assignments about that software stack. this actually just another symptom of a really bad interviewing process where nobody can tell that you're a competent engineer unless you pigeon-hole yourself to one stack that might not always have jobs for it, or for very long. there is also pressure to work on the coolest software stacks, because maybe you will be a scarce resource for a few years and get a major premium in compensation on the fastest growing companies. the other symptom is that companies aren't doing training, they're allergic to it, so they only want engineers that have years of potentially verifiable experience working on the exact stack they have, so that engineer could "hit the ground running" despite needing to keep the job opening up for 6 months to find that person.
FireBeyond 3y ago
> I took the role at a twenty year-old software company that's never had good product management, and the place is horrible. > Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof. I read this and thought you worked at my previous employer (household name in IT). Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so. And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?" And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept. And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show. I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.

aeternum 3y ago

In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.

snapetom 3y ago
I do believe that the traditional PM role/background should be considered obsolete, especially in software companies. Well-rounded engineers should be in these roles these days.
- kranke155 3y ago
  Are there enough of them?
- aurareturn 3y ago
  The vast majority of engineers I encountered do not have what it takes to be a good PM. I'm an engineer myself.
rewmie 3y ago
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x? I mean, is that a relevant aspect of the vast majority of products? If not, why should a PM bother about irrelevant details? One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
- aeternum 3y ago
  Generally it is quite important especially for SaaS. Old TLS will cause SOC2 cert, PCI cert failures and similar. It is the kind of thing that can derail a major deal as often the 'whale' clients are the ones that really care about security certs while smaller companies and startups don't. Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
  - rewmie 3y ago
    > Generally it is quite important especially for SaaS. You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice. But that doesn't seem to even register a concern, both from the client and from the PM point of view. Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue. > Non-technical PMs tend to gloss over things like that (...) See, this is where I think we disagree at a very basic level. There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
BlackJack 3y ago
A good PM doesn't have to know the differences, but should understand that mixing encryption protocols is going to break things. Ideally an eng lead would be flagging these issues.

Matthias247 3y ago

This certainly sounds like your company is having a gap. But the gap sounds to me more like the lack of technical leadership (a strong lead, principal engineer, etc) than a PM. 10 out of 10 PMs I worked with (and it had been more) wouldn't commend on software architecture and internals and wouldn't prevent the needless complexity and unmaintainability aspects. They can at most point out that feature development and bugfixes are too slow, and then its up to the engineering team to improve on this. But also for 10 out of 10 PMs feature development will always be too slow, since customers are asking for things being done yesterday, so this alone isn't a great indicator that engineering is broken. APIs using different TLS versions falls into the same category. Unless the TLS version is part of the product (which is the case for e.g. API Gateways, webservers and proxies) PMs will likely not care. They should however care about the difference between no TLS at all and a "somewhat modern TLS", because "no security" is definitely an important gap in the product.

snapetom 3y ago
A lack of engineering leadership is certainly true. As is often told, the VP of engineering enjoyed creating PRs more than actually leading. There has never been an architect. The point is though, product never challenged on approaches, and you’re right. They never came from technical backgrounds. Product managers were promoted from the BA ranks. They never raised technical questions like that - “Is it a bad thing if the customer has to connect this way for this API and another way for another API?” If the idea is that engineering asks those questions, I’d counter with that’s venturing squarely into product’s realm.
- sokoloff 3y ago
  I don't claim greatness at modern product design/theory, but I'd expect "what version(s) of TLS are supported?" to be primarily an engineering responsibility (say 80-90%) versus a product concern (say 10-20%).
d0gsg0w00f 3y ago
I think that most "good" engineering managers share the same traits as good Product Managers. - Someone to understand the customer's desires and shut down unnecessary work. - Drive the team to deliver features that the customers/business actually needs. - drive tech decisions to prevent future inoperability with other products - roadshow and maintain a team's reputation across the org - etc

simmerup 3y ago

How does a company not make any money for 20 years that sounds insane

alwa 3y ago
I don’t know if it applies to the situation the GP described, but profit != revenue. It seems to me, especially in the wild and woolly mom-n-pop end of the market, that there might be ample room for a company to sustainably put food on a certain number of employees’ family tables without much left over to characterize as profit.
- stcroixx 3y ago
  I work at a 20 year old company about like this. We’re all comfortable, it’s really nice.
snapetom 3y ago
cost center

swells34 3y ago

Most the problems described here are just bad software engineering. Never seen a PM with any oversight on which DB is used, how shiny the tech is, how the API works, any of that. It definitely seems like there's a lack of coherence and customer focus, which would be in the PM's wheelhouse to deal with, but that's it. Need a better lead engineer with the time and authority to implement good practices.

yieldcrv 3y ago

the grift is strong with this one. well just remember that engineers do this to have portfolio pieces on their resume. they need validation from other people that they worked on a software stack, and to be able to do live interview assignments about that software stack. this actually just another symptom of a really bad interviewing process where nobody can tell that you're a competent engineer unless you pigeon-hole yourself to one stack that might not always have jobs for it, or for very long. there is also pressure to work on the coolest software stacks, because maybe you will be a scarce resource for a few years and get a major premium in compensation on the fastest growing companies. the other symptom is that companies aren't doing training, they're allergic to it, so they only want engineers that have years of potentially verifiable experience working on the exact stack they have, so that engineer could "hit the ground running" despite needing to keep the job opening up for 6 months to find that person.

FireBeyond 3y ago

> I took the role at a twenty year-old software company that's never had good product management, and the place is horrible. > Over and over, the staff were pounded with "we are an engineering first company." Well, that means the engineering teams were allowed to do whatever the hell they wanted and chase the shiny newest techs. There's 3.5 main products (really 4.5) each made from a different tech stack. There's another eight or so legacy products we have to support due to legacy demands. There's no inter-operability of standardization between products. Basically, there's no knowledge transfer, so the cost of development is through the roof. I read this and thought you worked at my previous employer (household name in IT). Engineering first company. Oof. This meant that as a PM, I got introduced to two of the products I'd be managing when Engineering and Architects had come up with a grand idea to build a component/subsystem to replace a previous one which had been over-engineered and never gained traction. They hadn't talked to any customers who used it, or that had liked the idea, but not the execution. They were just given a wide latitude to experiment (don't get me wrong, some experimentation and exploration is useful), got a greenlight for some time to prototype it, and did so. And then, and only then, was I called in as a PM, and told, here's our prototype, here's some vague documentation of what we wanted to solve with this - "Now, Mr PM, can you shoehorn a Product Requirements Document around what we've already built and where we see it going, and can you do the Market Requirements Document to answer the questions we probably should have asked before getting this far?" And then I would get catch-22s. Express doubt over the needed research and potential for the product and I was told by management that "PMs need to be passionate and fearless advocates for their products"... and then when I do try to eke something out, but lo and behold, our internal 'market', let alone customers are ambivalent about why we are working on a "v2" of this feature, when the market is either accepting the weaknesses of "v1" or have long built out their own solutions and moved on, and as a result we have a stakeholders meeting where we decide to end the experiment, and I'm chastised for "poor product management judgment" for not killing the project far earlier... the project I have no authority to kill, because it's an Engineering first company, and the project whose existence I learned of when it was tossed into my lap as a 90% complete prototype/proof of concept. And then you have a few hundred (yep) Product Managers in our BU all trying to do their own thing, some empire-building, some truly product-focused... and it's a shit show. I love being a product manager. I took a similar path as you... although most of my engineering background is SysAdmin/Devops/SRE/infrastructure and then management thereof. I love being a product manager, and thought that this role, at this company, would have untold potential and I could settle in, learn, grow, build from there. But it was everything from a Dilbert cartoon.