This post would probably be longer than usual. I’ve been pondering the concept I’m going to cover in it for a while already. It all was ignited by the initiative to slice and dice workforce at the company I work now into a small, delivery oriented teams. The idea per se isn’t bad at all but as it usually happens the context is key. That all made me think what kind of context could make it actually lift off.
Handovers Slow Us Down
I believe handovers to be one of the key factors which slow down delivery. In an enterprise it’s soooo slow that it hurts badly. Nevertheless the assembly line fallacy (check mighty Uwe on the topic) is still here and dominates the space. As Uwe highlights in his piece, “software development” is actually a high collaborative design process. It’s not a conveyor of well-defined role-based workstations. Still “software development” in most organizations revolves around passing a work item along the line of “analytical”/”architecture”, “development”, “QA”, “DevOps” etc workstations. That’s called “agile teams” these days. Or if an organization is a bit laggard it may be even worse with “Dev” / “QA” / “DevOps” specialized teams stretched thin across multitude of projects.
What’s wrong with that? Software development is painfully complex hence we need all these deep specializations, right? Would it be better if we close up all these people in a room? So they collaborate on the stuff together as car manufacturers do? Won’t it be even more chaotic?
I claim that the primary “tax” here is cognitive overhead each specialist involved have to pay for each work item they get hands on. No matter how hard assembly line adepts tried they failed to invent proper “interfaces” between workstations. Hence if as a specialist you want to do a good job you have to figure out WTF with the item you got.
Can we do better?
Full-stack Developer as a Precursor of Zero Handovers Delivery
I did a lot of software development from the ground up all by myself. I also worked as so called “full-stack engineer” and pondered where it even came from. Web frontend development turned out complex enough for frontend devs to become a thing on their own. Hence one reasonable explanation would be savings. Why hire frontend + backend devs when you can have “full-stack” which will do everything, right? =)
Whatever the case I noticed one important thing. As a full-stack dev I can work on an item end-to-end and all gears needed click in my own head. The comparison of it with a collaboration — as either front or back dev with another person in a complimentary role — would be like a CPU going into main memory for a piece of data while before the CPU took it right from L1 cache, i.e. 100x slower. And there’s no way around it – our communications as human beings inherently require flattening thoughts into words and passing these words along in a hope to recreate somewhat similar thoughts in another person mind.
That made me think what kind of setting could enable let’s say zero handovers delivery. Meet feature, solution and platform engineering concept!
Overview of Feature, Solution and Platform Engineering Concept
I heard something about Team Topologies (TT for short) but never had a chance to look into what it suggest. While pondering Feature, Solution and Platform Engineering (FSPE for short) I intuitively felt I should take a look. There’s a lot of similar ideas, so I would refer to these for cross reference.
Basically we can look at software delivery from the angle of 3 different engineer types:
- Feature Engineer (FE):
- works on a particular solution, e.g. a LoB app
- collaborates extensively with solution’s stakeholders but mostly important delivers every solution increment end-to-end (E2E), i.e. from idea to production
- gets help from a corresponding SE team whenever the solution lacks some enablers for the work at hand
- FE teams correspond to stream-aligned teams from TT
- Solution Engineer (SE):
- works on a portfolio of similar solutions — which could be partitioned by tech stack, business domain or some mix of two
- ensures solutions meet stakeholder’s demands and unblocks delivery of FE teams by enhancing solutions
- gets help from PE teams whenever the platforms which a solution is built upon lack some enablers for the work at hand
- SE teams correspond to enabling teams from TT
- Platform Engineer (PE):
- works on a particular platform, e.g. a database as a service (DBaaS) managed service
- PE is a PE only for external context — for internal context it’s actually a FE of a platform solution, i.e. here we get the concept recurse into itself =)
- PE teams on one hand correspond to platform / complex subsystem teams from TT for external context, on the other these are just stream-aligned teams of platform solutions for internal context
Here’a picture which as usual worth a thousand words:
Feature and Solution Engineering Team Takeaways
FEs preferably work by kanban. Stakeholders provide work items, FEs pick them up and carry through grooming. FEs delivers work item E2E and ensures all DoDs are met. FEs focus are DoDs and throughtput — besides hopefully obvious customer happiness.
If current solution implementation lacks anything then ideally work item is blocked upon SE team corresponding to the solution. Alternatively is it’s a pressing matter then it’s possible to fudge the implementation but SEs then gets a tech debt item to resolve.
I believe FEs Adizes’ PAEI profile (or some similar approach to psychodiagnostic assessment) should be somewhat like pA-i. FEs are typically junior-to-middle with probably rare senior level devs.
To make such approach work FEs should be supported by very mature platform solutions for all activities along the delivery path.
SEs start new solutions and work on them as FEs until MVP gets our of the door. They architect everything and set up initial “rails” for feature flow. That also means glueing up all the platform stuff to enable delivery pipeline. As pace of architecture changes slow down FEs replace solution team workforce.
SE team is still there to oversee how well solutions in portfolio perform — that’s their focus. I use “performance” here broadly, meaning “keeping customers happy” whenever that means quick feedback on new ideas, meaningful TTM or low response latency.
SEs Adizes’ PAEI profile is likely to be like around PaEi. These should be typically middle-to-senior devs, probably mostly senior.
Platform Engineering Team Takeaways
PEs are contextual since they are same FEs which just work on upstream solutions. So their duty is to make their own customers happy which are primarily downstream FEs and SEs.
From the inside we get the same FE & SE teams just working on different solutions.
Applicability of Feature, Solution and Platform Engineering
Different organizations would benefit from different mixes of FSPE, so let’s consider possible cases.
For companies which mostly deliver value to customers by customizing prebaked solutions, e.g. building sites or e-commerce shops on corresponding platforms, it’d make sense to have only FE teams and leveraging upstream SE/PE teams from the platform vendor.
Most software vendor companies can leverage both FE & SE teams of their own and outsource PE work to cloud computing providers and other platform vendors. I believe most startups which innovate with software also can work in this mode.
Large enterprises typically are hard mix of FSPE with some solutions & platforms built in-house and some provided by external vendors. Still it’s possible to untangle relationships and structure these along with FSPE concept to hopefully optimize delivery — as much as red type would allow of course.
Conclusion
I don’t think I invented much here but mostly gave structure and perspective to what already happening in the industry. The concept is definitely not a recipe for success but a thought material. As mighty Uwe says “All models are wrong. Some are useful!“, so hopefully at least you’d find this material useful to some extent =)