Software development is expensive. It takes time, requires various & uncommon skills and on top of that - the developers' salaries are among the highest ones in the company. It's also affected by hard-to-grasp, unfavorable factors like technical debt that tend only to accumulate over time. No wonder that managers and executives of all sorts are looking for every feasible way to increase time developers spend on "pure" feature development (in their opinion - equivalent to raw value creation).
In fact, I'm sort of vouching for the same - I praise high Development Agility (DA), advocate for "freeing the man-days" first (to build up the capacity to make a difference), etc.
But real life isn't white and black. When you're freeing developers' capacity, you can also do it the right and the wrong way. And the latter can have truly catastrophic consequences. Would you mind an example?
Short-cutting
What are the most tempting (& obvious?) options when it comes to "freeing" developers' time? To identify all the activities they do, that can be in fact delegated to someone else (less qualified, less paid, more disposable, easier to hire, etc.) - for example:
- quality? someone else can test this stuff ...
- support? let's build a few layers of support to filter stuff out before it reaches the devs ...
- speaking to business people? analysts!
- everyday operations? IT ops!
- giving feedback? non-tekky team leads!
- organizing/planning work? project managers!
Where/how does this madness end? With a development team in a center of a nebula of satellite roles & positions, among all the tangled communications paths, crossing priorities, an unmanageable web of disjoint knowledge silos ... A development team that is entirely devoid of any natural feedback loop - they don't experience any consequences of their own decisions - all the other specialties do that instead!
180° turn
This approach, even if it looked smart at the very first glance, is against all the modern practices that have proven themselves very effective recently. Literally I mean: true Agility (no proxies), DevOps/DevSecOps and "you build it = you run it". Stripping development teams of any duties that are not a pure new feature development is nothing else but ditching all the painfully acquired teachings the whole industry has worked out in the last 15 years.
I honestly believe that the exactly opposite way is the one to go:
- if it hurts, do it more often (so you have an incentive to automate)
- always be the first one to drink beer that you brewed yourself (the shortest possible feedback loop)
- own the product end-to-end
- acknowledge the fact that each product also has an essential set of non-functional qualities: performance, operability, maintainability, robustness, ..., etc. - you should OWN them as well
- it's far better to own a smaller product, than to own it end-to-end than to spread yourself too thin over something you don't really control (& hope that someone else can do it for you)
But what if your company has optimized the recruitment (& culture) for narrow specialization for several years? What if your developers don't want to / don't know how to test / document / plan work / etc.? I am sorry, but there are no shortcuts here - if you don't want to succumb into madness I've described above, you need to shake the foundations here.
Start with some "fresh blood" to ignite the cultural change - by looking for true "software engineers", not just "programmers". The people who won't mind dealing with all the various aspects of product creation, not just the code-work & commit. Nothing triggers the imagination of observers as much as a working example.
