Management not wanting to enforce a process because of speed will change, it always does once they see clients leaving because of software quality and feature development slowing down.<p>The problem is between now and then in addition to hoping the pendulum doesn't swing too far the other direction.<p>Process doesn't have to slow everything down, my guess is you have one of two types of management or maybe both feeding off each other. A, you have young new founders/management that doesn't have experience with good process so they think all process just gets in the way. B, you have some experienced management that only came from or experienced heavy overbearing development processes.<p>The fact they have hired any type of QA means they do want improvement, but just are failing to see how to get it there. You will always find that QA requires some hand holding, but in the right situation it shouldn't be taking up the majority of your time.<p>Depending on what your current role is and what you desire to do and whether you like it there all affects what you can do and how to approach it. If you really love it there but are frustrated you can still try and help things get better. Process can be as simple as starting a daily standup on the QA issues and go over them. But to keep the fear down over the "process", don't make it formal yet, just get people together and say hey lets chat about X and Y and try and save us all some time. And just start doing it, don't ask for permission, don't say it is a process. You can influence how things work by influencing the people doing the work regardless of whom they work for etc. You can start small and do little things like this, and when you start seeing results and say you start getting to code 20% more of the time then celebrate that with an email to the group. By doing that you are telling them wow look at how much more productive I have become, oh yea, its from some changes in how we are working. See what I am getting at? Also, you could try another idea of getting 2-3 of the devs together and agreeing that you will each take one week of the month and handle training QA how to test the resolved defects for that week. It also provides a second pair of eyes on defects and cross trains people into other fixes. Or suggest your management hire a development intern for this type of work.<p>I am not blowing smoke, I have done this more then once. As a consultant, many times I have been asked to come in and fix things, but I am immediately seen as the outsider and people don't want their processes (or lack thereof) to change etc. So instead you have to be creative in getting the teams to buy into the changes without making it seem like you are creating any bad roadblocks etc. And celebrating little wins is usually really helpful. BTW -- doing it the grassroots way takes a lot longer then having someone in management sponsoring the change or demanding it, but honestly, I think the grassroots team way usually sticks better over time.