Is this how the developers would describe what they are going? "Chasing butterflies and adding complexity because it's more fun"?
If so, they seem to live in a bubble and are not integrated enough into the rest of the business. Developers need to understand and be involved in financial, customer, and product concerns.
More likely in my experience they are very busy working off technical debt that would be under-prioritised by the manager creating pressure. Some of them may even be innovating new solutions that will open up entire new markets. Sure, not all innovations are successful, but it's enough if a small fraction is.
R&D ("chasing butterflies") is a comparatively very cheap way to acquire knowledge, and what puts you ahead of your competition is the knowledge you have acquired and they have not (yet).
> If so, they seem to live in a bubble and are not integrated enough into the rest of the business. Developers need to understand and be involved in financial, customer, and product concerns.
In my experience that's the problem 99.9% of the time. Developers didn't get into their career to care about business, most of them are more excited about reading a new features on kubernetes than they are about solving a real business problem.
In big enough companies there's a lot of silo that is hard to break too. And specialization, someone who has 20 years of experience in $domain-specific-knowledge hardly wants to take a broader view of the world.
> More likely in my experience they are very busy working off technical debt that would be under-prioritised by the manager creating pressure. Some of them may even be innovating new solutions that will open up entire new markets. Sure, not all innovations are successful, but it's enough if a small fraction is.
Then they should communicate better. Your distinction of R&D or not is not relevant.
An important thing at play here is that for many engineers, and craftspeople in general, it is painful to do things in a way that is inelegant or "wrong," even if it's best for the "business," which is to say there are other tradeoffs at play.
There are two ways to resolve this. One is for the engineers to learn to accept "wrong-ness" through therapeutic techniques. The other is to remove the external pressure somehow.
Either way, there is pressure that needs to be relieved.
I agree with your first paragraph. Of course that the definition of wrongness or inelegant varies per engineer, which without a "pressure" towards a business solution being delivered might never converge.
If so, they seem to live in a bubble and are not integrated enough into the rest of the business. Developers need to understand and be involved in financial, customer, and product concerns.
More likely in my experience they are very busy working off technical debt that would be under-prioritised by the manager creating pressure. Some of them may even be innovating new solutions that will open up entire new markets. Sure, not all innovations are successful, but it's enough if a small fraction is.
R&D ("chasing butterflies") is a comparatively very cheap way to acquire knowledge, and what puts you ahead of your competition is the knowledge you have acquired and they have not (yet).