> stepping outside the mold just upsets people in the corporate world. This is the crux of the problem for me. How many of us are literally not allowed to wor

> stepping outside the mold just upsets people in the corporate world. This is the crux of the problem for me. How many of us are literally not allowed to work on stuff not on the backlog, which is usually driven by product people. We only deal with the product roadmap and other issues (technical debt, inefficiency, security issues, etc) don’t get resolved unless it somehow impacts the product. If you’re very lucky, you’ll have an actual technical CTO who has the power to say no and allow the developers to remediate issues (one CTO I worked with had to spend enormous political capital to get a single sprint dedicated to upgrading to Java 8 so that the developers could benefit from lambdas - something that for our code base literally cut development time in half due to the way we ingest and process very dynamic ingested data). There must be some law of software engineering that all engineering teams eventually become run like assembly lines where management disallows ground-up thinking. One place I worked finally only implemented a proper security program when a potential customer demanded it, and it was ultimately implemented as a checkmark-based solution to meet the terms of the contract. This meant burning CVE’s more than writing secure code. This was frustrating as management at the time decided microservices were what we needed, but then resulted in a distributed monolith because they weren’t allowed to spend the time on architecture work, tooling to secure communication between services, or even have proper distributed tracing.