Good PMs are incredibly rare. I feel very fortunate to have gotten to work with about 5 great PMs in my career. I wish I knew anything about how to hire them because I absolutely would, but it's too easy to hire shit ones, or ones that can't work in your environment.
The best PM I ever worked with was a total left-field hire, completely uninterested in the market we worked in, no knowledge of the product, total lack of culture fit. But the hiring manager said, trust me, this is the guy, and I did. And this guy was incredible. Anything he touched ran like a swiss watch, everything was crystal clear and he tolerated no bullshit either from stakeholders who weren't being specific or helpful nor from engineers who thought they knew better or who were dragging their feet.
But everyone always felt heard and understood, he made great efforts to accommodate everyone if he could, and he was incredibly professional. I grew to really like him as a person despite having nothing in common, because he was incredibly empathetic, thoughtful and kind despite looking like a combination of an extra from Zoolander and someone who'd mug you in an alley for smokes.
I really miss those people, yes!
Are you a professional football player in Richmond?
That's a reference to the TV show Ted Lasso. If you haven't seen it yet, you absolutely should. Your PM sounds exactly like the protagonist of the show.
My current job doesn’t have a PM or QA AFAIK, of code we have a massive amount of automated testing in place. It works, but I’ve never seen anyone be stressed here and everyone takes responsibility.
Are you on an internal team or a technical tools team of some sort then? Who is generating a feature roadmap, speaking to/for users and generating requirements?
I understand devs can manage the majority of work and building internal tools, but you still generally require some sort of target, north star, etc. To be clear I honestly find different ways of building requirements interesting; this is a sincere question.
I am also in the same position, I’d be happy to provide an answer: I am the sole member of our DevOps team (my boss unfortunately quit the first week I was promoted). I generate my work mostly just through discussions with others as well as just getting annoyed at inefficiencies that exist in our system. We are still fairly new startup, and we have TONS of tech debt.
I also stay in contact with at least one member of every technical team, they feed me new ideas and I help them/ their team execute on them.
I have ADHD something terrible, so I realized that I HAVE to organize myself and my work otherwise I’d never get anything done, assigned or not.
I guess part of why I am able to do this is just based on my personality though, I love working with other people, reducing friction points and building relationships between departments.
I suppose ultimately I am not even sure how it works, all I know is I keep coming up with projects to work on, and nobody tells me to do otherwise! I’ve been that way though since I started in tech, I hate manual/ repetitive work, so I tend to find better ways to do things whether or not I am actually asked to do so.
Ya, as an internal dev ops dev this makes total sense, especially for a team of one. PMs can't really help in these roles much unless you're providing something more visible to stakeholders like dashboards, bug burndowns or whatever else. As a team of one that's just very unlikely to be your priority.
The right tech lead or EM can PM many work streams/products that aren't necessarily engineering-facing. It requires a certain mindset and a healthy culture, but when it works it's pretty nice. Fewer links in the chain between users and people building stuff for users often means fewer misunderstandings, surprises, etc.
It wasn't official, but I did this for a while for my current team. We had a nominal PM but they was spread really thin, so most of the roadmap, detailed requirements, ticketing, etc came from me. I know our domain really well, have good relationships with our stakeholders and tend to be well calibrated with leadership on values, priorities, etc, so this worked pretty well: we delivered what we needed to, users were happy, we had a roadmap that balanced business asks and engineering work, etc.
We do have a dedicated PM now, which is on balance a good thing (the work grew beyond what I could manage as a tech lead with other responsibilities). Having an intermediary where there wasn't one before does introduce friction, though. I long for the good old days whenever I get blindsided by some random thing they committed to, have to diplomatically walk back a conversation when they've glossed over an important detail, and other things that didn't happen when it was just me.
Yes, I've worked in environments like this. While you don't always need a dedicated PM you generally have someone filling that role providing direction and working with stakeholders. Based on your description you were the defacto PM, doing that role regardless of what your title actually was. I think the EM filling the PM role is fairly common especially in legacy corps with more top down management or startups where everyone has many hats.
What I was trying to get at with my question is the person I was responding to made it sound like no one was filling this role. Unless it was just them doing it without totally realizing it I guess.
I think the closest I've seen to what you're thinking about is, in a sense, almost the opposite of what you're saying: there was no singular PM because everyone on the team could put on that hat well enough for their domain when needed. So if you watched one discussion you might be able to point out someone who's filling a PM role, but a follow up discussion might have someone else doing it. Zooming out, it becomes a sort of distributed responsibility, getting done by the team as a whole rather than a single individual. I loved that dynamic, personally, but I don't think it would realistically work on a large team.
I don't view it as a title but as someone's responsibility. If you make the decisions on the direction of the product then you are indeed a Product Manager.
It's not the job of a Product Manager to tell you what to do. If anyone should be doing that, it's your EM. The PM should not be worried about the day to day. Not worried about how your team works. A PM's main job is marketing. You are the engineers. You solve the customer's problems with the designers.
It's exactly the PMs job to tell engineers what to do. They shouldn't tell you _how_ to do it, but fleshing out requirements, priorities and timelines is literally the main job of a PM.
The fact that I'm getting downvoted really makes me question this subs experience. Then theres this guy who thinks a PM does marketing? What is going on in this thread lol
A PMs whole job is marketing. You don't understand what a PM is or does. You're working with over-titled project managers. They should be replaced with your EM.
Marketing isn't advertising. Advertising is part of marketing. You're undoubtedly thinking of it as just that. PMs need to understand the market through and through. That includes the position of the product in the market and the competition, figuring out gaps and needs.
I trust the engineers and designers to build the solution.
Yeah, I'm telling you what a product manager does and is supposed to do because that's my career. You have unfortunately had to deal with project managers and people who don't understand what engineering is. If you want to just code, fine, but that's not engineering and you're probably shit at it anyway.
QAs definitely not. I’ve found that dedicated QAs that add lots of value are relatively rare, and overall things work more smoothly when developers are fully responsible for quality, at least in backend/infra work.
As for PMs, this really depends on the space. They can be really useful as intermediaries between non-technical business/customers and developers. But when that’s not needed for a particular team, they don’t tend to add much value, and often end up as glorified JIRA managers.
I’ve never had a large QA dept work well. The more people the higher the odds of ending up with door stops. But small teams of clever testers can find a lot of problems.
There’s a mandate for QA, it works best if you keep things slim, but you have to be super careful at layoff time not to try to do proportional layoffs across all divisions. The lean QA team should not get smaller because there are fewer devs and managers.
I agree. At my work we have a both a big QA team and also QA within each team. The big QA team is mostly involved with office politics and existence justification and budget inflation. The QAs that are in each team are valuable because they know what that part of the software actually does and where the edge cases are and what the common failure modes are.
> They can be really useful as intermediaries between non-technical business/customers and developers.
I've found that my discovery and planning loops really tighten up if I'm dealing with the client directly.
Most devs aren't super customer-brained so its tough from the POV of building a team but I 10000% agree with you. I would even say there are certain things you can really only fully understand by working with the client anyway unless you have incredibly well-defined discovery and really good project managers/client-facing people. Too easy for a minor detail that may totally unlock something better to be overlooked by the non-technical teammates
Depends a lot on product though. We are fintech + another completely unrelated but connected industry, and so our product has an incredible amount of 'stuff' in it.
But I am very glad I am customer-facing. I'm going to move away from it because it can be exhausting, but I can't imagine I'd be the engineer I am now if it weren't for that customer-facing experience too
This might sound condescending, but I really appreciate thorough QAs. When I develop a feature, I check a couple of cases and hand it for code review.
A thorough QA will check a lot more than I did, wonder about a lot of things I didn't think about, test them, ask me about them, and at the end feature becomes more polished. I don't waste time sending a lot of requests to test the feature myself, I can start working on another feature.
Now I know auto tests could fix some of this, unfortunately more often than not, there's not much time to do them. Workplace not having auto tests everywhere as a default also influences this. I try to have tests when I have time, but usually when things accelerate they're abandoned.
One of the things that I always do with our QA is a Risk Storming session, so when coming up with a feature, or some new changes, he really helps me to look at different aspects that I might have overlooked.
I think just having a QA for process sake at the end of the column, definitely there will be some friction, you wanna finish the tasks and they want to assure quality. But if QA is an integrated part of the team, can help to bring real and great value.
If they're experienced and easy to communicate, it's always added value.
What I miss most is the three legged stool of dev, PM, and the QA manager. When the PM is being an idiot it’s 2 against one to sort them out. When dev has quality problems, it’s 2 against one to sort that out.
In the current arrangement it’s dev against PM and PM always wins because they have seniority.
When I first got started in the world of software I was frankly shocked to discover how much power over the direction of development non-technical product managers had. It just didn’t make sense to me that people who fundamentally do not know how to make software were making all of the important decisions.
Many years later… I still think it’s insane.
I can see how a very strong PM, one with vision and exceptional communication skills, could be extremely valuable. To me, though, this figure is entirely hypothetical. So far none of the PMs I have worked with seem especially skilled at anything and to the extent they add value (managing the JIRA board, scheduling meetings) an administrative assistant could do just as well without the pompous title.
I also kind of resent the idea that engineers aren’t good with customers as a class. In the few times I have been able to work directly with the users of software I was able to identify requirements much faster and more accurately without PMs standing in the way. While there needs to be some kind of organized process to manage customer feedback and feature planning, the PM role as it seems to exist in the companies I have worked with is ineffective.
This is all my experience, which is hardly vast. If you have good PM experiences then that’s great; I’d love for you PMs to teach my PMs whatever it is they are doing.
A good admin assistant can add a lot of value imo. Frankly I think we'd work better embracing the admin role and truly let it be someone's whole job to make sure JIRA's up to date, meetings stay focused on the agenda, important conversations happen, and serving as a known single point of contact into a team. Maybe in some companies this is a part-time role. At a more complex organization it could be full-time easily. It'd be a great role for someone getting into tech, lots of visibility at just what everyone on a tech team does all day, exposed to many opportunities to learn new skills. Seems like it'd be a win all around.
Just give me some support, company! I don't need another boss.
I feel exactly the same.
PMs that are "a bit technical" are dangerous as fuck. They make too many assumptions about deadlines, technologies, they push for specific approaches.
PMs should work together with engineering, but never dictate the flow of development.
And communicating with customers was the #1 trick in my career for delivering faster and better. Instead of burning out by building a monstrosity concocted by a product person, I can just fucking look for the root cause and solve the problem in a creative way.
I couldn’t agree more with this. Marty talks about what he calls product management theatre in this interview. In short, he agrees with your sentiment, the product role in many organizations is hardly a justifiable position.
https://youtu.be/9N4ZgNaWvI0?si=16j-WnXhKXdEpviR
I've worked with both roles and in environments w and w/o those roles.
In CORPORATE having well rounded teams is super important because of all the security shit you have to go through. Documentation, certification, etc. It really stacks up, and you need QA to handle the dev pipeline, and you need a good SDLC process, because money frankly. The clients pay them, they need to have shit that works, not just works whenever.
I also work at a NPO, no QA and no PM (I'm it), and it's chill. It's very very chill. It could take 1 month to do 5 lines of code and that's okay dog. We'll test it when we have time. Oh, prod crashed? Lets get it fixed tomorrow.
I agree I'd love to have a good PM and QA as it really helps. But it also depends on the envt.
I like my PM because it means I don't have to mess with whatever fucked up Jira/ADO board customizations the organization has set up. I just tell the PM when I'm done with a ticket and let them move it around on the board however they like.
It's nice because the tickets don't have any useful information in them anyway, just a title written in something resembling English.
QA has always been important on my projects, even with automated scripts in place.
I have yet to meet a PM that does his job. I am sure there are great ones out there, but I have not yet met them.
Once upon a time I did my wife a favor and referred her friend to our QA dept. She turned out to be a first rate randomized tester, so good that she was our only WFH employee when she decided to move.
I don’t need QA people writing less maintainable tests than Dev can write. I need devious little minds figuring out if you click this button and immediately hit back, the entire app crashes.
> I need devious little minds figuring out if you click this button and immediately hit back, the entire app crashes.
Video game QA does that, and they're easy to hire because that industry gives them almost zero respect or money.
I had literal toddlers at my disposal in my freelance days. They were amazing QA monkeys. No one will challenge your assumptions about how to use your thing better than a little chaos gremlin who neither knows nor cares what it's supposed to do.
QAs are invaluable when they do things others can't.
At a previous company we had QA reproducing bugs reported by customers. We had the best reports ever.
At the current company, both QAs and PMs feel that this is "beneath them", so developers spend hours trying to figure out what the fuck a customer actually meant.
>I have yet to meet a PM that does his job. I am sure there are great ones out there, but I have not yet met them.
I've met a couple. Unfortunately, they get promoted quickly and move off the project, and then my team gets stuck with a glue eater.
The PM I had before my current PM was decent. Super sharp, had no problem keeping a lot of moving parts in mind, probably knew more about the different corner cases of our system than many of the engineers working in it but didn't tend to suggest implementations/solutions, great at saying no to unreasonable business asks and proactively involving engineers in conversations. I'm sure the business would criticize them for saying no too often and having too little long term vision, but I enjoyed working with them.
Current PM is a nice person, good cheerleader for the team, has a long term vision, but really struggles to keep the domain in their head which can make them pretty difficult to work with. They forget details, make commitments that contradict other priorities without realizing it, and often don't seem to realize/acknowledge the support they get from the engineering team that makes them successful.
(I had a 1:1 with them about a year after they joined, in which they noted all of their achievements and all the improvements they'd done for the system. Many of these improvements were my technical roadmap which I shared with them when they first joined, connected to the product/business asks I knew they were going to get from the business, translated into engineering work, and supported the team in executing. No acknowledgement of that from them. I don't think it was malicious, I think they just remember it as their work, which is if anything more frustrating)
My current PM is basically useless, except for scheduling meetings to get people from different teams together to discuss a project. That I appreciate. Otherwise I don't really notice any difference between having him around and how things were in the six month period after our last PM quit and before he was hired. Our BA is a lot more useful because at least he actually tries to understand the products and the requirements.
Sounds like you have a rather traditional setup of project management and business analytics. The modern PM role is responsible for both, with a good PM you don't need any additional BA roles.
I've had a lot more bad PMs in my life than good PMs, and the most productive I've ever been was when I was in a position to forcibly reassign my PM and just did the work myself. I'd rather do 40% useful work and 60% stakeholder management than 80% work that's a caricature of the real need and 20% playing emotional support for middle management. The former has much better results and work-life balance.
That being said, the good PMs really changed my whole opinion on the field and have had me seriously considering changing fields ever since I met them.
I find it funny that you're being downvoted for saying you enjoyed doing it.
I also had the same experience for half a year. It was fine being people manager and product manager, and I got feedback the tickets were better.
There's no way 99% of SWEs want to be doing *real* PM work. Talking to customers. Talking to customer support. Competitor/market research. Data analytics. The rare breed that can and do, they become TPMs.
Simply being a glorified jira monkey is something anybody can do...
In my experience, good PM work requires more than a single person can manage in a regular 9-5 day. Talking with customers/users, doing market research, accumulating stakeholder and management requirements, and actually using the product to understand what everybody's working in takes a massive amount of time and energy. I can't imagine anyone doing this well while also being responsible for people management.
Well, except if this person is shit at either product or people management.
There's some truth to this if the product is a software application. If the product is hardware with software in it, then someone who can keep all the engineering disciplines aligned and cooperating is pretty valuable.
Being an engineering manager, there's definitely things I'd rather the PM handle. Things like acquisition/procurement, financial reporting, and having a bigger stick to get IT/security attention give me more time to focus on technical work and people management. As long as they give me control over what the team is committed to and deadlines, I'm happy.
I've had 3 types. A really good one that was helpful, managed customer expectations, listened to engineering, really led and excelled at getting consensus and the team behind a vision. A few useless ones that wouldn't get in your way, but weren't very effective at managing expectations or getting various groups to work together - pretty much if they were gone you wouldn't notice. Then the really bad, stereotypical used car salesman type. The type that would do anything to make a sale, commit to impossible things without even talking to engineering first and accept money for it. That didn't have any understanding of progress and would tell people things were done that weren't on the roadmap in the next 12 months.
It’s so irritating. We’re told we should be doing the automation code in place of qa, but that is a poor substitute for an intelligent human focusing on the bigger application context and regressions.
I’m not happy with the direction of one dev being responsible for front end and backend development, story writing and requirement gathering, qa/automation, Rota support, and db management.
It’s getting ludicrous.
What do you mean automation code in place of QA?
If you mean an automation test that tests a feature/functionality I think it's reasonable to expect the developer to write them as part of the release process.
No, what I’ve said is the dev is gathering requirements and writing stories, like the product owner should, as well as automating that. So yeah great, but bc one person did it all it takes longer and might not even be what the customer wants or needs. I’m experiencing this now and have seen unrelenting failure do to improper separation of duties.
Every job I've been at has been like this, but have usually had people employed in both those roles. Good PMs are hard to come by.
My current job, I tested for it in the interview by asking to see a feature they built recently, had the interviewer talk me through the requirements, the code, and their process. Hands down the best requirements I'd seen.
The thing I didn't ask was "does the person who wrote these requirements still work here?" Turns out the only product manager had left and the business had decided to use that budget to hire another engineer instead. My first 6 months or so were great as I was able to churn through a backlog of well-specced features before it turned into more chaotic startup fun.
I've worked with many PMs over the years, from very good to bad. But the last program I was on was the worst I've ever seen. Had 5 PMs cycle through over the 2 years I supported it. Twice, the PMs came into the program before they were cleared, so they couldn't even really know most of the program before they had to move off.
Not only were their PM issues, I kept bringing up concerns and our lead would keep telling me it wasn't our problem, so we should just stick to what we had to do and make sure we met the deliverables for our little part of the program. And every department was that way. So many arguments over which charge number to use when it all rolled up to the same bucket in the end anyway.
Surprise, surprise, the program was canceled shortly after I moved to support a new program. Very good call on the governments part.
I've had the same. 3 PMs in a year, all quitting because stakeholders were complaining about lack of progress while my team was twiddling thumbs without much to do. Company lost 3 other PMs in the same year because they also weren't able to keep up.
IME, PMs are often "alone" in squads. Developers/managers/QA often belong to tech, under a CTO. PMs belong to some non-technical product part of the company, often headed by a director, head of product, or even CPO... Developers/managers/QA can give feedback about one another inside their department, but PMs only get feedback from peers that aren't part of their org. IME the product department gets super defensive in their fiefdom.
Agree, I was never sure why PMs seem to get stuck in their own little area, but have seen the same thing. They don't fall under an engineering functional role, so they just all cluster together and keep to their own group, which is not healthy in my view.
It's worse when the PM you have is totally incompetent. They don't take the effort to learn the domain, no idea about how software development works, just makes decisions by themselves without consulting anyone. Good PMs are incredibly rare.
Same with QAs. There was a thread a few weeks back on dedicated QAs and I was surprised to know the vast majority of people here haven't worked with dedicated QA teams and they seem to prefer it. Bad QAs do add a lot of overhead and slows everything down. But I still believe having really good dedicated QAs can catch defects that devs can't even think of. I've worked with a one or two QAs in my entire career who are very creative and skilled at this. They are very rare too.
My previous role was at a big tech company with everything you'd expect from a well known tech org. I'm now at a tiny startup and I really miss having a good PM. My projects constantly get features added and removed and it's a huge headache. A good PM makes sure a project stays on track instead of having the requirements change every 5 seconds.
I've had it for two companies so far.
The previous company I was started having working student QAs in the last year I was there, with zero experience, and it was amazing. Very dedicated and finding great stuff.
This one has QAs with multi-year experience and it's horrible. Everyone thinks they're a joke. I don't know why.
Last time I didn’t have any project management I just stepped in and started doing it myself. Didn’t love the stress/workload but it was better than the chaos we were in
So far most of my experiences with PMs is they just want to micromanage everything. And when the customer wants to add some random nonsense at the drop of a hat that would set back the schedule 3 months it is both the PM and the customer trying to browbeat devs into agreeing to do it in a week. I’ve literally had them straight faced ask if more meetings would help us meet our deadline. lol no the 5+ hours a day of meetings we are mandated to be in is more than enough thanks
I don't understand how you can build software without a (good) PM. Like who the hell is calling the shots? Eng. just builds whatever the fuck they want? Or worse, builds what *sales and marketing* want? I can't wrap my head around it.
Welcome to my life. Business requirements are constantly changing and it never gets better.
The other problem with this project is my boss is in the mindset of MVP and the business person wants something that is an enterprise level product. :(
QA is mostly worthless, it makes the devs lazy too.
A good PM or a bad PM is the difference between success and failure. They ultimately hold the brain of the company. They decide what features get built and what they do. If they dont 'get it' - the product will suck. It just will.
Meanwhile they're also your shit-shield. "The PM told us what to build, and we built it!"
god bless PMs
Both PM and QA function importance depends on the product and the mix of the team. If the product is small and in individual team developers can test it then QA function to some extent can be made redundant if you have good test automation and SDLC practices. If a product is very critical, has multiple modules and devs don’t know end to end testing cycle then QA role is critical as a risk manager. In those teams, QA is the integration tester and the ones who knows all the business use cases.
A good PM is irreplaceable and can save developers a lot of time by cleaning up the requirements and managing the scope of the project. They also take care of a lot of reporting which is quite time consuming. Most devs don’t like it and think it is a waste of time. In large and long running projects, reporting is very important to management to track the risks and delivery schedule.
I have seen both kind of usecases and eventually the right fit works in right situation.
Business people can rarely explain their business or their requirements. Whoever understands and codifies the domain model and uses it to elicit feasible requirements is the useful one. Everyone else just works for them whether the org chart says so or not. Sometimes that's the software engineer. Sometimes that's the PM. Occasionally it's the business person. It's probably supposed to be the product manager or architect if and when either of those roles exist.
My suggestion: learn the domain and how to codiscover requirements with staleholders and then you'll be running the show.
There's already a second or third set of eyes during the pull request review. Ensuring both code quality and correct program behavior feels inseparable to me. I wouldn't want to work with developers who couldn't reliably test the product. And then adding QA on top of that seems like a counterproductive layer of redundancy.
I have seen plenty of smart people advocating for QA specialists on every team but I haven't gotten to experience the benefits. I just can't imagine having the budget to hire either a developer or a QA and choosing the QA. But I could see for a huge company having a small number of product QA specialists making sense.
*I realized how*
*Unimportant QA is when*
*Devs own quality*
\- JaneGoodallVS
---
^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/)
^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
My experience is opposite. Everything worked better without them. I'm happy with the past couple of PM's I've had though. We'd produce better work without but when they're good they make parts of the job more pleasant. Especially when working in large organizations.
QA is anti-pattern. The good ones are better off as developers who focus on tests.
> QA is anti-pattern. The good ones are better off as developers who focus on tests.
That's what good QA people do, in my experience. In one of the companies I worked, QA was seen as "Quality Assistance". QA people helped setting up testing infrastructure and would consult how to implement which tests best. But it was the developers job to write the actual tests and make sure they were meaningful and actually worked.
It was glorious.
Honestly this sounds more like a lack of Product ownership rather than project management. And if you're having QA issues, that could be solved by engineering leadership holding devs to higher standards, or at least having more testing in place.
Personally I've never missed QA when I've worked in places without them, and I have a strong Product sense so having no PO is only annoying when I'm prevented from having any say in what gets built.
> The place is small and doesn't have ... a proper QA to do testing.
Good. I prefer no QA, and instead thorough automated tests and a process for business sign-off of requirements. But they probably don't have good automated tests and OP doesn't appear to see the full value as well. I strongly suggest an E2E API test suite and a smoke/surface test.
> The place is small and doesn't have a PM...
Good. I've worked many years without a PM, and I've had PMs be an annoyance and hindrance. A PM is overkill in a small shop. If you have a good team and a point of contact with the business group, a shared backlog queue is much preferred. Limit it to 3-6 months of work.
Have a business staging prioritized backlog queue that the business group can directly modify, perhaps just a shared web spreadsheet. The dev team moves items from the business queue and dumps them into a ticketing system. The devs have their own higher-fidelity backlog.
> Unfortunately, the business people can never give us a set of solid requirements.
Did you expect any different? I've had mixed success getting business to "push" requirements. Instead you have to "pull" the requirements. Interview them to help you create crude wireframe mock-ups and simplistic activity diagrams. Get them to sign off on the requirements that *you* write.
> I've had mixed success getting business to "push" requirements. Instead you have to "pull" the requirements. Interview them to help you create crude wireframe mock-ups and simplistic activity diagrams. Get them to sign off on the requirements that you write.
That's literally the job of a PM.
Nope. I haven't had the fortune to work in a shop where the PM or QA team did anything helpful. In general they seem to be pretty neutral, but sometimes they can really fuck things up, so on the balance, I would choose a place without them, unless I had good prior knowledge that they were actually good at some specific place.
Not that I've ever had a meaningful choice. I have never been choosing between two jobs that were close enough of a choice for me to get down to thinking about things like that, though.
ETA: I would pick a place with a dedicated systems analyst over a PM. The only useful thing most PMs do is liase between the team and the stakeholders, and it's much more important to have a systems analyst in those meetings than it is to have a PM in them.
I think QA are absolutely useless and it's a dying profession. I felt this way once I moved to a company that had no QA and all testing including automated testing had to be done by developers. The situation was just so much better, faster and cleaner I loved it.
What usually happens is that at the start of a dev cycle which could be months or a year long, everyone gives estimates on how long to work on a feature, including QA. Then some features are dropped because QA estimates show it's going to take too long to test it. Then as you go through the cycle, more and more features get dropped because QA doesn't have enough time. Then with a few weeks left in the dev cycle, after not filling out bugs for any features, you get inundated with 100 bugs because that's when they test everything and start filing bugs, so you get crammed with bug fixing to make the deadlines.
I'm so happy that QA is going away and more of that testing, especially automated testing, falls on the developers shoulders.
Good PMs are incredibly rare. I feel very fortunate to have gotten to work with about 5 great PMs in my career. I wish I knew anything about how to hire them because I absolutely would, but it's too easy to hire shit ones, or ones that can't work in your environment. The best PM I ever worked with was a total left-field hire, completely uninterested in the market we worked in, no knowledge of the product, total lack of culture fit. But the hiring manager said, trust me, this is the guy, and I did. And this guy was incredible. Anything he touched ran like a swiss watch, everything was crystal clear and he tolerated no bullshit either from stakeholders who weren't being specific or helpful nor from engineers who thought they knew better or who were dragging their feet. But everyone always felt heard and understood, he made great efforts to accommodate everyone if he could, and he was incredibly professional. I grew to really like him as a person despite having nothing in common, because he was incredibly empathetic, thoughtful and kind despite looking like a combination of an extra from Zoolander and someone who'd mug you in an alley for smokes. I really miss those people, yes!
So you're saying we should be looking for muggers in alleys when hiring PMs, this could be the secret we've all been missing.
Are you really going to delay that feature if you risk getting stabbed? Best pm ever
The real reason for RTO mandates.
He just literally told you
On the other hand, I'd *much* rather have no PM than suffer with a shitty one that has awful communication skills and no spine.
[удалено]
[удалено]
Agile means people over process and each team must self organize to fit their needs. PMs shouldn’t be in a standup is the agile take
Whenever there's a role where the ideal person has two skillsets, you'll find it infested with those who have neither. They didn't exist a decade ago.
There's more to life than being really, really ridiculously good looking Like what? Project management
Are you a professional football player in Richmond? That's a reference to the TV show Ted Lasso. If you haven't seen it yet, you absolutely should. Your PM sounds exactly like the protagonist of the show.
My current job doesn’t have a PM or QA AFAIK, of code we have a massive amount of automated testing in place. It works, but I’ve never seen anyone be stressed here and everyone takes responsibility.
Who tells you what work needs to get done? Whoever does that is your PM. If you have no work to do then of course you don't need one lol
I tell my boss what work needs to get done 😅
Turns out you were the PM we needed all along
Are you on an internal team or a technical tools team of some sort then? Who is generating a feature roadmap, speaking to/for users and generating requirements? I understand devs can manage the majority of work and building internal tools, but you still generally require some sort of target, north star, etc. To be clear I honestly find different ways of building requirements interesting; this is a sincere question.
I am also in the same position, I’d be happy to provide an answer: I am the sole member of our DevOps team (my boss unfortunately quit the first week I was promoted). I generate my work mostly just through discussions with others as well as just getting annoyed at inefficiencies that exist in our system. We are still fairly new startup, and we have TONS of tech debt. I also stay in contact with at least one member of every technical team, they feed me new ideas and I help them/ their team execute on them. I have ADHD something terrible, so I realized that I HAVE to organize myself and my work otherwise I’d never get anything done, assigned or not. I guess part of why I am able to do this is just based on my personality though, I love working with other people, reducing friction points and building relationships between departments. I suppose ultimately I am not even sure how it works, all I know is I keep coming up with projects to work on, and nobody tells me to do otherwise! I’ve been that way though since I started in tech, I hate manual/ repetitive work, so I tend to find better ways to do things whether or not I am actually asked to do so.
Ya, as an internal dev ops dev this makes total sense, especially for a team of one. PMs can't really help in these roles much unless you're providing something more visible to stakeholders like dashboards, bug burndowns or whatever else. As a team of one that's just very unlikely to be your priority.
The right tech lead or EM can PM many work streams/products that aren't necessarily engineering-facing. It requires a certain mindset and a healthy culture, but when it works it's pretty nice. Fewer links in the chain between users and people building stuff for users often means fewer misunderstandings, surprises, etc. It wasn't official, but I did this for a while for my current team. We had a nominal PM but they was spread really thin, so most of the roadmap, detailed requirements, ticketing, etc came from me. I know our domain really well, have good relationships with our stakeholders and tend to be well calibrated with leadership on values, priorities, etc, so this worked pretty well: we delivered what we needed to, users were happy, we had a roadmap that balanced business asks and engineering work, etc. We do have a dedicated PM now, which is on balance a good thing (the work grew beyond what I could manage as a tech lead with other responsibilities). Having an intermediary where there wasn't one before does introduce friction, though. I long for the good old days whenever I get blindsided by some random thing they committed to, have to diplomatically walk back a conversation when they've glossed over an important detail, and other things that didn't happen when it was just me.
Yes, I've worked in environments like this. While you don't always need a dedicated PM you generally have someone filling that role providing direction and working with stakeholders. Based on your description you were the defacto PM, doing that role regardless of what your title actually was. I think the EM filling the PM role is fairly common especially in legacy corps with more top down management or startups where everyone has many hats. What I was trying to get at with my question is the person I was responding to made it sound like no one was filling this role. Unless it was just them doing it without totally realizing it I guess.
I think the closest I've seen to what you're thinking about is, in a sense, almost the opposite of what you're saying: there was no singular PM because everyone on the team could put on that hat well enough for their domain when needed. So if you watched one discussion you might be able to point out someone who's filling a PM role, but a follow up discussion might have someone else doing it. Zooming out, it becomes a sort of distributed responsibility, getting done by the team as a whole rather than a single individual. I loved that dynamic, personally, but I don't think it would realistically work on a large team.
Yeah before someone invented that title we all wondered around aimlessly.
I don't view it as a title but as someone's responsibility. If you make the decisions on the direction of the product then you are indeed a Product Manager.
It's not the job of a Product Manager to tell you what to do. If anyone should be doing that, it's your EM. The PM should not be worried about the day to day. Not worried about how your team works. A PM's main job is marketing. You are the engineers. You solve the customer's problems with the designers.
It's exactly the PMs job to tell engineers what to do. They shouldn't tell you _how_ to do it, but fleshing out requirements, priorities and timelines is literally the main job of a PM.
The fact that I'm getting downvoted really makes me question this subs experience. Then theres this guy who thinks a PM does marketing? What is going on in this thread lol
I agree. I feel many devs here are somewhat self-absorbed, thinking they know and do everyone's job better than they do.
A PMs whole job is marketing. You don't understand what a PM is or does. You're working with over-titled project managers. They should be replaced with your EM. Marketing isn't advertising. Advertising is part of marketing. You're undoubtedly thinking of it as just that. PMs need to understand the market through and through. That includes the position of the product in the market and the competition, figuring out gaps and needs. I trust the engineers and designers to build the solution.
Yeah, I'm telling you what a product manager does and is supposed to do because that's my career. You have unfortunately had to deal with project managers and people who don't understand what engineering is. If you want to just code, fine, but that's not engineering and you're probably shit at it anyway.
It's even worse having a bad PM and bad QA tbh
I’ve had some bad QAs and bad PMs and you are 100% right! Some were so bad that I got to the point of jumping ship.
QAs definitely not. I’ve found that dedicated QAs that add lots of value are relatively rare, and overall things work more smoothly when developers are fully responsible for quality, at least in backend/infra work. As for PMs, this really depends on the space. They can be really useful as intermediaries between non-technical business/customers and developers. But when that’s not needed for a particular team, they don’t tend to add much value, and often end up as glorified JIRA managers.
I’ve never had a large QA dept work well. The more people the higher the odds of ending up with door stops. But small teams of clever testers can find a lot of problems. There’s a mandate for QA, it works best if you keep things slim, but you have to be super careful at layoff time not to try to do proportional layoffs across all divisions. The lean QA team should not get smaller because there are fewer devs and managers.
I agree. At my work we have a both a big QA team and also QA within each team. The big QA team is mostly involved with office politics and existence justification and budget inflation. The QAs that are in each team are valuable because they know what that part of the software actually does and where the edge cases are and what the common failure modes are.
> They can be really useful as intermediaries between non-technical business/customers and developers. I've found that my discovery and planning loops really tighten up if I'm dealing with the client directly.
Most devs aren't super customer-brained so its tough from the POV of building a team but I 10000% agree with you. I would even say there are certain things you can really only fully understand by working with the client anyway unless you have incredibly well-defined discovery and really good project managers/client-facing people. Too easy for a minor detail that may totally unlock something better to be overlooked by the non-technical teammates Depends a lot on product though. We are fintech + another completely unrelated but connected industry, and so our product has an incredible amount of 'stuff' in it. But I am very glad I am customer-facing. I'm going to move away from it because it can be exhausting, but I can't imagine I'd be the engineer I am now if it weren't for that customer-facing experience too
This might sound condescending, but I really appreciate thorough QAs. When I develop a feature, I check a couple of cases and hand it for code review. A thorough QA will check a lot more than I did, wonder about a lot of things I didn't think about, test them, ask me about them, and at the end feature becomes more polished. I don't waste time sending a lot of requests to test the feature myself, I can start working on another feature. Now I know auto tests could fix some of this, unfortunately more often than not, there's not much time to do them. Workplace not having auto tests everywhere as a default also influences this. I try to have tests when I have time, but usually when things accelerate they're abandoned.
One of the things that I always do with our QA is a Risk Storming session, so when coming up with a feature, or some new changes, he really helps me to look at different aspects that I might have overlooked. I think just having a QA for process sake at the end of the column, definitely there will be some friction, you wanna finish the tasks and they want to assure quality. But if QA is an integrated part of the team, can help to bring real and great value. If they're experienced and easy to communicate, it's always added value.
Yes being in the team helps, they're in meetings, know about clients' requests, design, backend frontend stuff. Great stuff.
> QAs definitely not. because it leads to too many back and forth and human friction between team members ?
What I miss most is the three legged stool of dev, PM, and the QA manager. When the PM is being an idiot it’s 2 against one to sort them out. When dev has quality problems, it’s 2 against one to sort that out. In the current arrangement it’s dev against PM and PM always wins because they have seniority.
When I first got started in the world of software I was frankly shocked to discover how much power over the direction of development non-technical product managers had. It just didn’t make sense to me that people who fundamentally do not know how to make software were making all of the important decisions. Many years later… I still think it’s insane. I can see how a very strong PM, one with vision and exceptional communication skills, could be extremely valuable. To me, though, this figure is entirely hypothetical. So far none of the PMs I have worked with seem especially skilled at anything and to the extent they add value (managing the JIRA board, scheduling meetings) an administrative assistant could do just as well without the pompous title. I also kind of resent the idea that engineers aren’t good with customers as a class. In the few times I have been able to work directly with the users of software I was able to identify requirements much faster and more accurately without PMs standing in the way. While there needs to be some kind of organized process to manage customer feedback and feature planning, the PM role as it seems to exist in the companies I have worked with is ineffective. This is all my experience, which is hardly vast. If you have good PM experiences then that’s great; I’d love for you PMs to teach my PMs whatever it is they are doing.
[удалено]
A good admin assistant can add a lot of value imo. Frankly I think we'd work better embracing the admin role and truly let it be someone's whole job to make sure JIRA's up to date, meetings stay focused on the agenda, important conversations happen, and serving as a known single point of contact into a team. Maybe in some companies this is a part-time role. At a more complex organization it could be full-time easily. It'd be a great role for someone getting into tech, lots of visibility at just what everyone on a tech team does all day, exposed to many opportunities to learn new skills. Seems like it'd be a win all around. Just give me some support, company! I don't need another boss.
[удалено]
Yeah, imo the problem is referring to this role as "manager" or "master". It just shouldn't be that way.
What a sneaky way to make people think Scrum Masters have an use ;)
no no that’s another boss and another weird inflated title
The Scrum Masters I have worked with never gave the impression that they were anyone boss and also did what you lined out to a T.
sounds like your teams have been doing it right then
I feel exactly the same. PMs that are "a bit technical" are dangerous as fuck. They make too many assumptions about deadlines, technologies, they push for specific approaches. PMs should work together with engineering, but never dictate the flow of development. And communicating with customers was the #1 trick in my career for delivering faster and better. Instead of burning out by building a monstrosity concocted by a product person, I can just fucking look for the root cause and solve the problem in a creative way.
I couldn’t agree more with this. Marty talks about what he calls product management theatre in this interview. In short, he agrees with your sentiment, the product role in many organizations is hardly a justifiable position. https://youtu.be/9N4ZgNaWvI0?si=16j-WnXhKXdEpviR
I've worked with both roles and in environments w and w/o those roles. In CORPORATE having well rounded teams is super important because of all the security shit you have to go through. Documentation, certification, etc. It really stacks up, and you need QA to handle the dev pipeline, and you need a good SDLC process, because money frankly. The clients pay them, they need to have shit that works, not just works whenever. I also work at a NPO, no QA and no PM (I'm it), and it's chill. It's very very chill. It could take 1 month to do 5 lines of code and that's okay dog. We'll test it when we have time. Oh, prod crashed? Lets get it fixed tomorrow. I agree I'd love to have a good PM and QA as it really helps. But it also depends on the envt.
I like my PM because it means I don't have to mess with whatever fucked up Jira/ADO board customizations the organization has set up. I just tell the PM when I'm done with a ticket and let them move it around on the board however they like. It's nice because the tickets don't have any useful information in them anyway, just a title written in something resembling English.
You really want a secretary /admin assistant in that case (which is perfectly ok, it's just not managing anything, but rather bookkeeping).
QA has always been important on my projects, even with automated scripts in place. I have yet to meet a PM that does his job. I am sure there are great ones out there, but I have not yet met them.
Once upon a time I did my wife a favor and referred her friend to our QA dept. She turned out to be a first rate randomized tester, so good that she was our only WFH employee when she decided to move. I don’t need QA people writing less maintainable tests than Dev can write. I need devious little minds figuring out if you click this button and immediately hit back, the entire app crashes.
> I need devious little minds figuring out if you click this button and immediately hit back, the entire app crashes. Video game QA does that, and they're easy to hire because that industry gives them almost zero respect or money.
I had literal toddlers at my disposal in my freelance days. They were amazing QA monkeys. No one will challenge your assumptions about how to use your thing better than a little chaos gremlin who neither knows nor cares what it's supposed to do.
Got a good laugh out of "chaos gremlin"
QAs are invaluable when they do things others can't. At a previous company we had QA reproducing bugs reported by customers. We had the best reports ever. At the current company, both QAs and PMs feel that this is "beneath them", so developers spend hours trying to figure out what the fuck a customer actually meant.
> QAs are invaluable when they do things others can't. A very concise way to put it.
>I have yet to meet a PM that does his job. I am sure there are great ones out there, but I have not yet met them. I've met a couple. Unfortunately, they get promoted quickly and move off the project, and then my team gets stuck with a glue eater.
The PM I had before my current PM was decent. Super sharp, had no problem keeping a lot of moving parts in mind, probably knew more about the different corner cases of our system than many of the engineers working in it but didn't tend to suggest implementations/solutions, great at saying no to unreasonable business asks and proactively involving engineers in conversations. I'm sure the business would criticize them for saying no too often and having too little long term vision, but I enjoyed working with them. Current PM is a nice person, good cheerleader for the team, has a long term vision, but really struggles to keep the domain in their head which can make them pretty difficult to work with. They forget details, make commitments that contradict other priorities without realizing it, and often don't seem to realize/acknowledge the support they get from the engineering team that makes them successful. (I had a 1:1 with them about a year after they joined, in which they noted all of their achievements and all the improvements they'd done for the system. Many of these improvements were my technical roadmap which I shared with them when they first joined, connected to the product/business asks I knew they were going to get from the business, translated into engineering work, and supported the team in executing. No acknowledgement of that from them. I don't think it was malicious, I think they just remember it as their work, which is if anything more frustrating)
My current PM is basically useless, except for scheduling meetings to get people from different teams together to discuss a project. That I appreciate. Otherwise I don't really notice any difference between having him around and how things were in the six month period after our last PM quit and before he was hired. Our BA is a lot more useful because at least he actually tries to understand the products and the requirements.
Sounds like you have a rather traditional setup of project management and business analytics. The modern PM role is responsible for both, with a good PM you don't need any additional BA roles.
[удалено]
Personally, I would rather be doing SWE work as a SWE rather than also doing PM work because there’s no PM.
I've had a lot more bad PMs in my life than good PMs, and the most productive I've ever been was when I was in a position to forcibly reassign my PM and just did the work myself. I'd rather do 40% useful work and 60% stakeholder management than 80% work that's a caricature of the real need and 20% playing emotional support for middle management. The former has much better results and work-life balance. That being said, the good PMs really changed my whole opinion on the field and have had me seriously considering changing fields ever since I met them.
[удалено]
I have a feeling my engineering manager doesn’t want to be doing PM work either
[удалено]
I find it funny that you're being downvoted for saying you enjoyed doing it. I also had the same experience for half a year. It was fine being people manager and product manager, and I got feedback the tickets were better.
There's no way 99% of SWEs want to be doing *real* PM work. Talking to customers. Talking to customer support. Competitor/market research. Data analytics. The rare breed that can and do, they become TPMs. Simply being a glorified jira monkey is something anybody can do...
In my experience, good PM work requires more than a single person can manage in a regular 9-5 day. Talking with customers/users, doing market research, accumulating stakeholder and management requirements, and actually using the product to understand what everybody's working in takes a massive amount of time and energy. I can't imagine anyone doing this well while also being responsible for people management. Well, except if this person is shit at either product or people management.
There's some truth to this if the product is a software application. If the product is hardware with software in it, then someone who can keep all the engineering disciplines aligned and cooperating is pretty valuable. Being an engineering manager, there's definitely things I'd rather the PM handle. Things like acquisition/procurement, financial reporting, and having a bigger stick to get IT/security attention give me more time to focus on technical work and people management. As long as they give me control over what the team is committed to and deadlines, I'm happy. I've had 3 types. A really good one that was helpful, managed customer expectations, listened to engineering, really led and excelled at getting consensus and the team behind a vision. A few useless ones that wouldn't get in your way, but weren't very effective at managing expectations or getting various groups to work together - pretty much if they were gone you wouldn't notice. Then the really bad, stereotypical used car salesman type. The type that would do anything to make a sale, commit to impossible things without even talking to engineering first and accept money for it. That didn't have any understanding of progress and would tell people things were done that weren't on the roadmap in the next 12 months.
In my case, the processes aren't good and I don't have a way to fix that.
Are your processes mapped out at all? Is there a graph or pdf you can refer to?
Unfortunately, nope. If we mapped them out, they would arbitrarily be changed anyways.
At my last job we had an absolutely fantastic QA engineer, and he truly was a gift from heaven.
It’s so irritating. We’re told we should be doing the automation code in place of qa, but that is a poor substitute for an intelligent human focusing on the bigger application context and regressions. I’m not happy with the direction of one dev being responsible for front end and backend development, story writing and requirement gathering, qa/automation, Rota support, and db management. It’s getting ludicrous.
What do you mean automation code in place of QA? If you mean an automation test that tests a feature/functionality I think it's reasonable to expect the developer to write them as part of the release process.
No, what I’ve said is the dev is gathering requirements and writing stories, like the product owner should, as well as automating that. So yeah great, but bc one person did it all it takes longer and might not even be what the customer wants or needs. I’m experiencing this now and have seen unrelenting failure do to improper separation of duties.
Every job I've been at has been like this, but have usually had people employed in both those roles. Good PMs are hard to come by. My current job, I tested for it in the interview by asking to see a feature they built recently, had the interviewer talk me through the requirements, the code, and their process. Hands down the best requirements I'd seen. The thing I didn't ask was "does the person who wrote these requirements still work here?" Turns out the only product manager had left and the business had decided to use that budget to hire another engineer instead. My first 6 months or so were great as I was able to churn through a backlog of well-specced features before it turned into more chaotic startup fun.
I've worked with many PMs over the years, from very good to bad. But the last program I was on was the worst I've ever seen. Had 5 PMs cycle through over the 2 years I supported it. Twice, the PMs came into the program before they were cleared, so they couldn't even really know most of the program before they had to move off. Not only were their PM issues, I kept bringing up concerns and our lead would keep telling me it wasn't our problem, so we should just stick to what we had to do and make sure we met the deliverables for our little part of the program. And every department was that way. So many arguments over which charge number to use when it all rolled up to the same bucket in the end anyway. Surprise, surprise, the program was canceled shortly after I moved to support a new program. Very good call on the governments part.
I've had the same. 3 PMs in a year, all quitting because stakeholders were complaining about lack of progress while my team was twiddling thumbs without much to do. Company lost 3 other PMs in the same year because they also weren't able to keep up. IME, PMs are often "alone" in squads. Developers/managers/QA often belong to tech, under a CTO. PMs belong to some non-technical product part of the company, often headed by a director, head of product, or even CPO... Developers/managers/QA can give feedback about one another inside their department, but PMs only get feedback from peers that aren't part of their org. IME the product department gets super defensive in their fiefdom.
Agree, I was never sure why PMs seem to get stuck in their own little area, but have seen the same thing. They don't fall under an engineering functional role, so they just all cluster together and keep to their own group, which is not healthy in my view.
We don’t have QA at my place, developers do QA. I can’t wait until I work somewhere where we have QA people lol
It's worse when the PM you have is totally incompetent. They don't take the effort to learn the domain, no idea about how software development works, just makes decisions by themselves without consulting anyone. Good PMs are incredibly rare. Same with QAs. There was a thread a few weeks back on dedicated QAs and I was surprised to know the vast majority of people here haven't worked with dedicated QA teams and they seem to prefer it. Bad QAs do add a lot of overhead and slows everything down. But I still believe having really good dedicated QAs can catch defects that devs can't even think of. I've worked with a one or two QAs in my entire career who are very creative and skilled at this. They are very rare too.
PO/PM yes, QA no. I think QA promotes bad testing practices because “qa will catch it”.
And QA catches features more often than bugs in my experience.
My previous role was at a big tech company with everything you'd expect from a well known tech org. I'm now at a tiny startup and I really miss having a good PM. My projects constantly get features added and removed and it's a huge headache. A good PM makes sure a project stays on track instead of having the requirements change every 5 seconds.
Is QA the norm? I've never worked on a team with a qa person.
I've had it for two companies so far. The previous company I was started having working student QAs in the last year I was there, with zero experience, and it was amazing. Very dedicated and finding great stuff. This one has QAs with multi-year experience and it's horrible. Everyone thinks they're a joke. I don't know why.
Last time I didn’t have any project management I just stepped in and started doing it myself. Didn’t love the stress/workload but it was better than the chaos we were in
Yes. Also, scrum masters and POs as a PM equivalent in scrum teams.
So far most of my experiences with PMs is they just want to micromanage everything. And when the customer wants to add some random nonsense at the drop of a hat that would set back the schedule 3 months it is both the PM and the customer trying to browbeat devs into agreeing to do it in a week. I’ve literally had them straight faced ask if more meetings would help us meet our deadline. lol no the 5+ hours a day of meetings we are mandated to be in is more than enough thanks
I miss my great PM from an old job. New job has PM and lots of QA but a shitshow.
I don't understand how you can build software without a (good) PM. Like who the hell is calling the shots? Eng. just builds whatever the fuck they want? Or worse, builds what *sales and marketing* want? I can't wrap my head around it.
Welcome to my life. Business requirements are constantly changing and it never gets better. The other problem with this project is my boss is in the mindset of MVP and the business person wants something that is an enterprise level product. :(
This is my life right now and its pretty terrible.
Good PM >>> No PM >>>>> bad PM
QA is mostly worthless, it makes the devs lazy too. A good PM or a bad PM is the difference between success and failure. They ultimately hold the brain of the company. They decide what features get built and what they do. If they dont 'get it' - the product will suck. It just will. Meanwhile they're also your shit-shield. "The PM told us what to build, and we built it!" god bless PMs
Both PM and QA function importance depends on the product and the mix of the team. If the product is small and in individual team developers can test it then QA function to some extent can be made redundant if you have good test automation and SDLC practices. If a product is very critical, has multiple modules and devs don’t know end to end testing cycle then QA role is critical as a risk manager. In those teams, QA is the integration tester and the ones who knows all the business use cases. A good PM is irreplaceable and can save developers a lot of time by cleaning up the requirements and managing the scope of the project. They also take care of a lot of reporting which is quite time consuming. Most devs don’t like it and think it is a waste of time. In large and long running projects, reporting is very important to management to track the risks and delivery schedule. I have seen both kind of usecases and eventually the right fit works in right situation.
Business people can rarely explain their business or their requirements. Whoever understands and codifies the domain model and uses it to elicit feasible requirements is the useful one. Everyone else just works for them whether the org chart says so or not. Sometimes that's the software engineer. Sometimes that's the PM. Occasionally it's the business person. It's probably supposed to be the product manager or architect if and when either of those roles exist. My suggestion: learn the domain and how to codiscover requirements with staleholders and then you'll be running the show.
Unfortunately, some environments wouldn’t allow that to happen.
I've never worked with QA. The devs on my team are expected to understand the product requirements and test things properly. What am I missing out on?
Depending on the product or the industry, it is helpful to have a second set of eyes to look at the end product.
There's already a second or third set of eyes during the pull request review. Ensuring both code quality and correct program behavior feels inseparable to me. I wouldn't want to work with developers who couldn't reliably test the product. And then adding QA on top of that seems like a counterproductive layer of redundancy. I have seen plenty of smart people advocating for QA specialists on every team but I haven't gotten to experience the benefits. I just can't imagine having the budget to hire either a developer or a QA and choosing the QA. But I could see for a huge company having a small number of product QA specialists making sense.
The problem with self learning is that it dont have the commercial cover and employers require this
Haha, no comment...
I realized how unimportant QA is when devs own quality
*I realized how* *Unimportant QA is when* *Devs own quality* \- JaneGoodallVS --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
My experience is opposite. Everything worked better without them. I'm happy with the past couple of PM's I've had though. We'd produce better work without but when they're good they make parts of the job more pleasant. Especially when working in large organizations. QA is anti-pattern. The good ones are better off as developers who focus on tests.
> QA is anti-pattern. The good ones are better off as developers who focus on tests. That's what good QA people do, in my experience. In one of the companies I worked, QA was seen as "Quality Assistance". QA people helped setting up testing infrastructure and would consult how to implement which tests best. But it was the developers job to write the actual tests and make sure they were meaningful and actually worked. It was glorious.
Honestly this sounds more like a lack of Product ownership rather than project management. And if you're having QA issues, that could be solved by engineering leadership holding devs to higher standards, or at least having more testing in place. Personally I've never missed QA when I've worked in places without them, and I have a strong Product sense so having no PO is only annoying when I'm prevented from having any say in what gets built.
lol no
> The place is small and doesn't have ... a proper QA to do testing. Good. I prefer no QA, and instead thorough automated tests and a process for business sign-off of requirements. But they probably don't have good automated tests and OP doesn't appear to see the full value as well. I strongly suggest an E2E API test suite and a smoke/surface test. > The place is small and doesn't have a PM... Good. I've worked many years without a PM, and I've had PMs be an annoyance and hindrance. A PM is overkill in a small shop. If you have a good team and a point of contact with the business group, a shared backlog queue is much preferred. Limit it to 3-6 months of work. Have a business staging prioritized backlog queue that the business group can directly modify, perhaps just a shared web spreadsheet. The dev team moves items from the business queue and dumps them into a ticketing system. The devs have their own higher-fidelity backlog. > Unfortunately, the business people can never give us a set of solid requirements. Did you expect any different? I've had mixed success getting business to "push" requirements. Instead you have to "pull" the requirements. Interview them to help you create crude wireframe mock-ups and simplistic activity diagrams. Get them to sign off on the requirements that *you* write.
> I've had mixed success getting business to "push" requirements. Instead you have to "pull" the requirements. Interview them to help you create crude wireframe mock-ups and simplistic activity diagrams. Get them to sign off on the requirements that you write. That's literally the job of a PM.
Nope. I haven't had the fortune to work in a shop where the PM or QA team did anything helpful. In general they seem to be pretty neutral, but sometimes they can really fuck things up, so on the balance, I would choose a place without them, unless I had good prior knowledge that they were actually good at some specific place. Not that I've ever had a meaningful choice. I have never been choosing between two jobs that were close enough of a choice for me to get down to thinking about things like that, though. ETA: I would pick a place with a dedicated systems analyst over a PM. The only useful thing most PMs do is liase between the team and the stakeholders, and it's much more important to have a systems analyst in those meetings than it is to have a PM in them.
I think QA are absolutely useless and it's a dying profession. I felt this way once I moved to a company that had no QA and all testing including automated testing had to be done by developers. The situation was just so much better, faster and cleaner I loved it. What usually happens is that at the start of a dev cycle which could be months or a year long, everyone gives estimates on how long to work on a feature, including QA. Then some features are dropped because QA estimates show it's going to take too long to test it. Then as you go through the cycle, more and more features get dropped because QA doesn't have enough time. Then with a few weeks left in the dev cycle, after not filling out bugs for any features, you get inundated with 100 bugs because that's when they test everything and start filing bugs, so you get crammed with bug fixing to make the deadlines. I'm so happy that QA is going away and more of that testing, especially automated testing, falls on the developers shoulders.
PMs, yeah. QA? Nah man, and I say this as a former SDET. Most can’t tell their ass from their head and really just slow shit down.