3 ms·
Like, maybe this is naive because I've probably never worked long at a corporation as large as the one you're probably at, but... if I were a senior VP and our
by noduerme 4y ago
Like, maybe this is naive because I've probably never worked long at a corporation as large as the one you're probably at, but... if I were a senior VP and our main software was flakey while we were pushing fringe features, I would want to hear this from you. I'm not saying that it's always worked for me, but in cases like that I've always just done an end-run past the chain of command.
- msy 4y agoWhich is why you likely won't be a senior VP. Sales are demanding the fringe feature to meet a RFP requirement & the flakiness in the main software isn't meaningfully impacting renewals. These things are not (always) accidents.
- noduerme 4y ago>> Which is why you likely won't be a senior VP I'll take that in the spirit of a compliment ;) What I mean is, I've definitely worked for organizations that were resistant to fixing things that were only mildly broken, but I've never worked for one where there wasn't someone you could talk to who would put the brakes on to fix something if you made the case that it had to be addressed before building new features. Particularly if the case was that the new features would have to be rebuilt soon if you didn't address these problems first.
- roflyear 4y agoBrother, this is the norm at small to large companies. Maybe five person shops need to get things done, but once a company hits like 15-20 people, yeah... people get hired and stay hired because people like them, rarely because of their output.
- coldtea 4y ago>Like, maybe this is naive because I've probably never worked long at a corporation as large as the one you're probably at, but... if I were a senior VP and our main software was flakey while we were pushing fringe features, I would want to hear this from you. The company lives on sales, not on software. Sale of flakey software is better than delay to un-flakey it.
- noduerme 4y agoWow. This response showed me a big blind spot of my own, and how I could have been using the same language to talk about something completely different without clarifying a basic point in advance: I've written customer-facing software and in-house employee software for 20+ years. But almost all the code I've ever written has been for companies whose business is something other than software... and where I have worked for software companies has been in the early prototypes and beta phases where bugs were an embarrassment. I've never worked on retail software that had generational code debt - or even ones that had a dedicated sales team driving features and development. I have worked with people who were more interested in feature explosion than in nailing down existing issues... and assuming they're not the boss of the company, I consider it important to speak up about fixing issues before moving on. But that is, I realize, a completely different ballgame than working for a company that primarily sells software to end users.