I’ve worked quite a bit in enterprise software development, and later in teams that are transitioning from startups/mid-size to enterprise and in my very anecdo

I’ve worked quite a bit in enterprise software development, and later in teams that are transitioning from startups/mid-size to enterprise and in my very anecdotal experience it’s always down to the internal processes. Software developers like solving issues. Most people, myself included prefer building new things, but a lot of us actually like solving bugs as well. At least that is my experience. What I’ve seen get in the way is when the processes around reporting, examining, describing and prioritising the “tasks” get so convoluted that that developers get either overwhelmed or detached from the issue by too much bureaucracy. Which happens very often in non-tech organisations in my experience. Maybe it also happens on tech organisations but I’ve never worked in one, but from buying software from around two hundred it didn’t seem like it was a problem in quite the same way it can in regular enterprise. I realise this may be a little more clear in my head than for you as the reader. So I’ll try to explain by an example I encountered recently with a parking app. My wife and I were visiting a midwife for a comfort scan, and they have you register your license plate in an app so that their patrolmen/parking-guards/whatever they are called don’t give you a ticket when they scan your car. Anyway, the app wasn’t working and the midwife was like: “oh, that happens from time to time, don’t worry that means they can’t check if parking are legal or not”. As though it was the most normal thing in the world. Because it is… IT failing is the most normal thing in the world to a lot of people, but think about it. That app being down, at least on a city scale maybe even global meant that all those parking-guards were paid to do nothing for however long it took to fix it. It also meant anyone could essentially park for free… and that was a semi-regular thing? When you work in enterprise organisations. They often become accustomed to IT not working. Part of this is because the process people they put in between IT professionals and their organisation don’t actually know IT. They are very good at defining processes, making things lean and what not, but that’s not how you actually make things work in my experience. I’m guessing this is true outside of IT as well, but once you have more process managers, scrum masters, product owners and what not than actual technicians, then you’ve probably ducked it up. This is because programmers are often the best people at determining what’s important, not always, but often, and despite an entire industry’s attempts at “streamlining” the development process I suspect it’s also why sometimes a team of 4 developers can do more quality work in a shorter amount of time than 10 teams of 10 people combined. It sounds like the author has encountered some of this. They have an important issue. It loses some of its importance on the processes and then once it finally gets to the technicians it can’t be reproduced… Of course it doesn’t get solved. Especially if the organisation has set up systems to reward not solving seemingly unimportant reproducible issues, which many enterprise organisations end up doing. Corporate culture is hard.