>And instead of throwing code “over the wall” to operations, we say: “You build it, you run it.”
>But we still tell people that they must write code in Java, or write their data to MS SQL Server.
>Or, much worse: that they must hit a specific internal deadline, with no stakes except a manager’s pride.
These things are not equivalent.
If your software team builds and runs software, it can autonomously decide the framework, database and so on, but deadlines, even internal deadlines, are not necessarily arbitrary.
Let's say you're building a tool to, I don't know, help your sales teams do some data analysis which can improve sales margins. If you deliver the product 6 months or 1 year late, you're effectively limiting profits, which costs money. It's not arbitrary even if the customer is internal.
Another example. You're evaluating two third-party products. You like product A and you decide to run a proof of concept. You spend too much time with the proof of concept without getting any result (positive or negative). At some point, though, you have to decide (maybe because you need a product for your own team!), and you end up making a less informed choice.
arter45•1w ago
>But we still tell people that they must write code in Java, or write their data to MS SQL Server.
>Or, much worse: that they must hit a specific internal deadline, with no stakes except a manager’s pride.
These things are not equivalent.
If your software team builds and runs software, it can autonomously decide the framework, database and so on, but deadlines, even internal deadlines, are not necessarily arbitrary.
Let's say you're building a tool to, I don't know, help your sales teams do some data analysis which can improve sales margins. If you deliver the product 6 months or 1 year late, you're effectively limiting profits, which costs money. It's not arbitrary even if the customer is internal.
Another example. You're evaluating two third-party products. You like product A and you decide to run a proof of concept. You spend too much time with the proof of concept without getting any result (positive or negative). At some point, though, you have to decide (maybe because you need a product for your own team!), and you end up making a less informed choice.