[jaymzcampbell]

Not the OP but I can believe it - where I work the main business is consultancy style work but to support that work there's custom generic software developed to sell/license to clients as part of a value add and there's dozens of internal tooling to support delivery teams. We have developers that will move between all 3 of those areas depending on their current allocation to client work.

[mooreds]

Sounds awesome! Thanks for illuminating me. How are these different work streams prioritized?

At first glance seems like the last category would suffer unless someone was "on the bench".

[IggleSniggle]

In a smaller company it's not hard for "invisible" (like CI) contributions to be actually seen and noticed by both leadership and by the people you work with every day. And on the other hand, if you're a dev working on product and getting work done is a lot harder than it should be, you've got a strong incentive to pause product work and focus on "maintenance" work.

When almost a quarter of the company (15 devs) can both see and feel your contribution to make their lives easier and more productive, you've got a pretty strong political position even if you aren't directly producing product. This is true even if you produce, say, an internal dashboard: you're known as the one dev who took time out to help the 20 sales people sell better (or whatever); you know their names, and they know yours.

[jaymzcampbell]

We have a process whereby people can request a change after a certain period (and team permitting) to allow people to rotate amongst different clients and different work streams. I think it's usually after 6 months on one particular thing you are eligible to request reassignment. Won't always be approved ofc.

[michaelt]

Scarblac's mentions a company that only has 15 developers. That means time spent on internal tooling like, say, improving the CI system has direct benefits for the other 14 developers, all of whom probably report to the same boss.