Ask HN: How to fix a broken software organization?
8 comments
Leave. You can't turn it around. Not to sound negative or anything :) This kind of situation can only be turned around from above, not grass roots style. There has to be VP level buy off on the importance of the product, the user interface, and engineering. Unless you are in a start up, then one implementer can make a large difference.
Agreed. Maybe leave and start your own company offering a better product that meets the needs of the unsatisfied users of your current company's product.
Let's assume that leaving right now is not an option. Recognizing that efforts from the lower ranks will have limited upside, what can I possibly do outside of gritting my teeth as I continue to suffer with this awful software?
Suggest to outsource what's not the company core competence (buy a product or hire a sofware development team). Or fight for the resources and do it yourself.
Or start to manage the software development, if you think you could do better. Keep a spreadsheet of the bugs/feature requests. Send emails asking for dates, do QA and test releases before they hit the client.
Or stage a mutiny and displace the bosses.
But anyway it looks like you can't do anything about the situation, because you're not the development boss. Sometimes it's better to accept that there things you can't control, and life goes on.
Or start to manage the software development, if you think you could do better. Keep a spreadsheet of the bugs/feature requests. Send emails asking for dates, do QA and test releases before they hit the client.
Or stage a mutiny and displace the bosses.
But anyway it looks like you can't do anything about the situation, because you're not the development boss. Sometimes it's better to accept that there things you can't control, and life goes on.
I don't know your particular circumstances, but barring a personal reason for not being able to leave... It's your first job in the industry that you just started last week and your father in law gave you the position, it is always an option to leave. And when you do leave, you will feel better for having done it.
> unhappy users who are only using the software because their organizations require it
Software is rarely any better than it absolutely has to be for people to put up with it, and these people must put up with it. You need to find a business case--either customers are defecting to other vendors, or fewer leads are converting to customers, or time to market for new features is hurting you, or good staff are resigning in disgust. If none of these things are true, then sadly the business is actually making the right call, because terrible software is cheaper and the market is all too willing to take it.
Software is rarely any better than it absolutely has to be for people to put up with it, and these people must put up with it. You need to find a business case--either customers are defecting to other vendors, or fewer leads are converting to customers, or time to market for new features is hurting you, or good staff are resigning in disgust. If none of these things are true, then sadly the business is actually making the right call, because terrible software is cheaper and the market is all too willing to take it.
From your post it seems you're not quite ready to leave. So trying to share your insights and raise awareness may be worth a shot. That is, if you can comfortably speak with upper management without being singled out.
If the company is profitable and the users are pleased with the product then from an upper management perspective there may not be anything wrong. Until the bottom line is impacted there may not be leverage for change. The key is to alert management to the state of the product and the course it's on.
Parallel development may be an option as the next release of the product would address the underlying issues. This is costly and upper management would have to understand why that's necessary.
If the company is profitable and the users are pleased with the product then from an upper management perspective there may not be anything wrong. Until the bottom line is impacted there may not be leverage for change. The key is to alert management to the state of the product and the course it's on.
Parallel development may be an option as the next release of the product would address the underlying issues. This is costly and upper management would have to understand why that's necessary.
The company is quite profitable though keep in mind that the majority of revenue comes in from more traditional consulting projects. My estimation is that the software arm accounts for only 10-15% of total revenue.
There are a few other things going on here that I haven't mentioned yet:
- We've already pulled one client from the brink of not renewing a contract by developing a much simpler, web based version of our main offering. IMO this should be the general direction of the product but some users would legitimately miss some features.
- Management is well aware that the software is problematic. I believe they've been resting on their laurels for a while due to monopoly position. Things are changing though; competitors are catching up.
- it bears repeating that users are not happy with the product at all, but they are forced to use it by our true customers: their bosses. Those higher-ups do recognize that without ROI, however, the investment is simply not worth it. Now, the actual value of the product itself is another thing entirely...
There are a few other things going on here that I haven't mentioned yet:
- We've already pulled one client from the brink of not renewing a contract by developing a much simpler, web based version of our main offering. IMO this should be the general direction of the product but some users would legitimately miss some features.
- Management is well aware that the software is problematic. I believe they've been resting on their laurels for a while due to monopoly position. Things are changing though; competitors are catching up.
- it bears repeating that users are not happy with the product at all, but they are forced to use it by our true customers: their bosses. Those higher-ups do recognize that without ROI, however, the investment is simply not worth it. Now, the actual value of the product itself is another thing entirely...
Though I am not a developer, I work with this team every day and from what I've seen, there is little in the way of development methodologies, source control is shoddy, and I am completely unaware of any user that is actually happy with the software. As somebody who plays a client facing role, it's pretty discouraging having to deal with unhappy users who are only using the software because their organizations require it.
How does one fix this? There is a push to start building a new version of the software from the ground up to do away with the tangled mess of the current version, but since resources are usually tied up with putting out fires, it's difficult to do. Worse yet, I'm afraid the problem of feature explosion and client builds that bear little resemblance to each other will persist simply because management wants to allow clients to customize as much as they want in order to keep them happy.
Things are very broken and I'm trying to figure out what I can do to start turning things around. Any advice from HN would be greatly appreciated!