First of all, I've seen all type of teams be successful, ranging from zero QA at all, to massive QA teams with incredible power (eg. Format QA at Sony in Europe). I have absolutely seen teams with no QA deliver high quality full stop, the title is nonsense.
My firm belief is that QA can raise the ceiling of quality significantly if you know what you're doing, but there is also huge moral hazard of engineers dropping the ball on quality at implementation time and creating a situation where adding more QA resources doesn't actually improve quality, just communication churn and ticket activity. By the way the same phenomenon can happen with product people as well (and I've also seen teams without product managers do better than teams with them in certain circumstantes).
The most important anchor point for me is that engineering must fundamentally own quality. This is because we are closer to the implementation and can anticipate more failure modes than anyone else. That doesn't mean other roles don't contribute significantly to quality (product, design, QA, ops absolutely do), but it means we can't abdicate our responsibility to deliver high quality code and systems by leaning on some other function and getting lazy about how we ensure we are building right.
What level of testing is appropriate for engineers to do is quite project and product specific, but it is definitely greater than zero. This goes double in the age of AI.
This is my favorite high powered individual at a company trope.
Hey you, yeah you with no power to change or order people around, yeah, you go ahead and do my job with no new tools or authority.
I have had so many CTOs tell me that I should go tell an entire department to change their entire goal system because of something they want done, but do not want to deliver any thought process of how that's going to happen or are willing to put in any effort to idk, move the gigantic ship they have in motion.
And of course, the blame only goes one direction in such a bad org, tbqh the QA person probably is happier literally anywhere else.
This clause is doing a lot of heavy lifting. One needs to have good judgement about when and how to help. A lot of people can imagine how things could go better if a bunch of other people changed their behavior in surprisingly simple ways. It's a much smaller subset of people that can correctly push the right buttons to get the other people to actually make those changes succeed at a systematic level.
In a small org it's actually not too hard for good ideas and feedback to get traction. In a larger org for broad concerns it can be fiendeshly difficult. Often the reason why a large project will fail is only truly knowable by a few senior technical people with enough experience and broad context to see the forrest for the trees. Past a certain volume of people involved you can not explain to people why it will fail fast enough to offset the army of clueless stakeholders incentivized to socialize a good-sounding narrative convincing everyone that we need to try. In these cases reductive explanations with the right counter-narrative can work, but they require significant reputational and/or hard authority to pull off.
This is why the article advocates picking your battles in a large org. Often the chance of actually helping is much lower than destroying your own reputation, even if you're right.
Yeah, ultimately you're paid to deliver results. Criticism is only of value to the degree that it leads to better results; there is zero value in predicting failure per se. Some people place so much value on being right that they lose sight of the actual goals (and I won't say I'm immune to this, but marriage helped). Nothing with a high upside is low risk, so as en employee you need to inherently frame all risks in terms of identifying the most likely path to succeed.
The only alternative is to advocate for inaction, but then why are they paying you? Those kind of bets can make sense for private equity investors, but not for employees, and my builder-brain just finds them dull and annoying.
SaaS is not just software though, it’s operationalized software and data management. The value has increasingly been in the latter well before AI. How many open source packages have killed their SaaS competitors (or wrappers)?
No that’s not really how it works in tech at all. There’s a deep recognition that individual engineers (and other functional practitioners) have important knowledge and expertise that is essential. Of course you do need some overlap and redundancy so that people can take sick days and avoid the wheels falling off through attrition, but competent shops aren’t ever treating people as numbers. To the contrary good ICs are widely recognized as being much less full-of-shit then management.
They also get crappier though. I am generally okay with a lot of the tradeoffs to reduce the cost of construction and mass production. We definitely have more crappy stuff than we need—I'd prefer if we had a little less, higher quality stuff, but the balance is not too far out of whack.
With media though, I feel it's a lot worse. It's already been trending that way for text with blogspam already diluting the value of the web even before AI. But with AI this is accelerating to video and audio as well. Not only does the AI slop drown out the best of human creativity, it also raises the floor on superficial production value so that if you don't use AI you fall behind on the initial attention-grabbing first impression. I acknowledge a big part of this is due to where we are in the hype cycle, and once we absorb the capabilities of the tools, we'll figure out how to use them more tastefully, and human creativity will shine through again. But no I don't think always making everything easier and more efficient is necessarily always a good thing a priori. Friction and effort sometimes leads to positive outcomes.
I've gotten way more out of open sourcing software than I ever could have by trying to sell the same software. Not all value is monetary, and participating in open source creates different types of technical capital (reputational, barter, scratch-your-own-itch, etc). If you want to sell software, all of a sudden you're playing a very different game that is way more marketing/sales and way less technical.
There's nothing wrong with that, but know what you're signing up for. If you just want to be paid like a carpenter, contracting for time and materials is the standard way to do that, much easier than starting a software company.
Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhausting, and it doesn't inherently get better with knowledge and experience as the gap to the lowest common denominator only increases; the only balm I've found is focusing on what I can control.
We’re currently around 30 in engineering full time and 40 if you include ops, logistics etc…with new funding and coming out of stealth etc we expect to hit the dunbar number (~150 this year)
reply