There's bunch of questions that will probably never get answered ...

1. who was behind killing JFK?
2. is Elvis alive?
3. why did your local football team suck that much in the yesterday game?
4. ... and ... what's the optimal work model for running software teams? ;P

Obviously the last one is much more thrilling than the previous ones (hehe), so lets stick to it today :) In fact it's not just a single question, but a ton of smaller ones that fit well together:

• cross-competence or competence-based teams?
• individual or team responsibility?
• what are the roles & their particular responsibilities?
• who's decisive in terms of priorities, scope, quality assurance, release management, commitments, salaries, career progression, ..., ?
• how big are the teams & how do we synchronise across the teams?
• central or distributed governance?
• ...

I've been working with various software development teams for over a dozen years. Obviously some scenarios were very different - a lot depended on particular people, company-specific constraints, etc., however I've managed to assemble a foundation ("skeleton model") for "composing" (/adjusting) new work models.

I call it The Triumvirate of Power (TToP) - or sometimes - The Three Pillars, just to increase the confusion ;P.

One "Manager" is not enough ... o_O

TToP is based on the observation that to have software product/service properly delivered you need a close collaboration (in a sort of an equilibrium) of 3 different "elements": product, technology+architecture, people+processes (these 2 last pairs are so very closely coupled together, that they should be considered as one).

All 3 "elements" need very different expertise, they are all strictly required, each of them can impact complexity & each of them can affect the prioritisation of work to be done. Their focuses are different - bah, can be radically different & one of the greatest challenges is to make sure they do not diverge, but converge & advance in unison. Needless to say - all 3 of them need to be driven: they need both strategic (high-level) & tactical (in the "trenches") leadership.

As you can imagine - having 1 person covering all 3 (strategic or tactical) is possible, but really hard - it's a LOT of stuff on the plate, there aren't that many people with such a broad perspective & genuine interest (beyond a certain level).

That's why you should aim for building Triumvirates of Power. Triumvirate means 3 people cooperating closely - each of them accountable for one of these pillars (dimensions). How could it look alike on the level of a single team?

1. Product: Product Owner - a decisive representative of business stakeholders, who understands the Product (software/service you're building), its value for the end-users/consumers and both long- & short-term business strategy; this person is supposed to have a hands-on contact with the Product while it's still being shaped & control a "release gate". It can't be a "messenger", "chronicler" or "requirements proxy", but an active (yet non-technical) collaborator.
2. Technology+Architecture: Tech Leader - an owner of the technical vision for the Product, able to map Product-specific needs onto system's architecture (as-is or to-be); accountable for non-functional requirements regarding the Product & day-to-day control of the technical debt; team's reference point when it comes to technical aspects of delivery: tools, frameworks, patterns & idiomatic constructs applied on the daily basis.
3. People+Processes: Delivery Lead - a "getting shit done" person who understands full SDLC, supervises the knowledge exchange, keeps a tight grip on risks, effectively coaches teams on key delivery aspects & terms like: WIP minimisation, waste, phased (evolutionary) delivery, culture of escalation, "divide & conquer", facts over opinions, etc. This person streamlines the communication, makes sure that priorities are being kept, guards the overall transparency & drives the optimising of team's overall effectiveness.

See? Three completely different disciplines, demanding radically different knowledge & yet - all of them are absolutely essentials if you really want to build a decent Product.

Like 3 bloody Musketeers.

F.A.Q.

I guess that such a "committee-based" setup provokes certain questions - lets have them addressed straight away:

1. Who leads? Who's in charge? Who provides feedback?
   All of them are. But everyone in different aspect - aspect of their speciality (Product, Technology or Process).
   
   
2. But what if they disagree? What if they can't come up with common conclusion (one they all agree upon)?
   Then it's their joint failure. All of them are to be held responsible. In 90% of cases it means that either someone's ego got out of control or someone has lost a proper focus on the overall goal (value delivered to the end-users).
   
   
3. So it means that people have 3 bosses who can give them conflicting orders on what to do?
   Hell-no. First - these 3 leaders are servant-leaders with a primary focus on removing the impediments, not taking the autonomy from the team(s). Second - the space for conflict is limited: Product Leader drives WHY to do (the business goals & expected outcomes), Technical Leader drives HOW to do (technical excellence) & Delivery Leader drives WHAT to do (what kind of work has to be done, in which order, how it should be monitored, communicated & verified).
   
   
4. What's the role of other team members? To follow & execute?
   Absolutely not. Everyone should be a Leader of something - initiative, idea, experiment, functional area - Triumvirs are accountable for growing their people in their corresponding areas AND delegating the responsibilities: by setting up expectations, providing regular feedback, asking meaningful questions & of course applying their own expertise. But NOT as external coaches, but directly involved, hands-on collaborators. Freaking skin in a freaking game.
   
   
5. Wait, ain't everyone doing Scrum these days?!
   Maybe you are, we're not. Scrum had perfect intentions & (with a proper set of people & attitudes) it can bring awesome results - but in 95% it's easily twisted & brings far more serious (& long-lasting) problems than advantages. So no - we're NOT doing Scrum. These days it's more a cancer than a cure (to software development problems) - feel free to quote me on that.
   
   
6. Does it mean you're ditching all elements of Scrum (Sprints, Dailies, Retros, etc.)?
   Hmm - when we adopt a practice, we don't investigate thoroughly its origin - e.g. we're doing Sprint-like increments (regular cadences, stable delivery rhythm so people know what to expect), but not because they were present in Scrum, but because we find them valuable.
   
   
7. Matrix-style organisations are so passe in 2018. Who's my formal supervisor?
   People+Processes person is (Delivery Lead). Do you feel any better now?
   
   
8. Who provides me feedback in such a complex setup?
   All the people who you co-operate with - that's the only response that makes sense, right? So - in more simple words: your "full team" - including all kind of leaders.
   
   
9. So many leaders/owners/managers - what about project managers - who's leading long-term projects?
   We all do. If there's a need to crunch a bigger topic (one that spans several increments), we "split the elephant" in all the dimensions (Product-wise, Technology-wise & Process-wise). We're developing a Product (our Platform), but it doesn't mean we're allergic to the word "Project".

Triumvirate(s) in Shedul

And how does it look in practice (in our case - the organisation I work for & develop together with my crew)?

• nothing is carved in stone, we keep evolving our model all the time
• currently we consider our platform a one single Product (with code available as an internal "open source") so our Product Owners switch focuses - but we keep 1:2 ratio (1 PO per 2 teams) & it seems a healthy balance
• we've set a very high bar for technical excellence & we're aware that this will pay off long-term ONLY if we keep this bar where it is (don't let it slip) - that's why we have a single Tech Lead in every Team (1:1 ratio) & they are no push-overs
• our Delivery Leads evolve into something more like Delivery/Engineering Managers - teams don't need that much support in basic, day-to-day activities (ones that were kept by so-called Scrum Masters), but they struggle when it comes to orchestrating bigger changes, managing more complex endeavours & navigating hyper-space of endless compromises, ABZ plans & MVPs - our guess is that 1:2 ratio is about what would work best for now
• these "triumvirate" is kept on a strategic level as well: POs report to VP of Product, Tech Leads to Architects (& CTO), Delivery Leads to VP of Engineering. Those three jolly individuals cooperate on daily basis to make the whole company sailing smoothly through the stormy waters of global Beauty & Wellness industry ocean :)

And this works like charm.

Everyone has a role to play. Precise, clearly defined & easy to grasp. Everyone understands we're on THE SAME TEAM. Everyone's to collaborate - there are no primadonnas, no solo players, "ninjas" or other crap. The weakest link(s) will certainly slow us down, but we're well distributed, w/o bottlenecks, single points of failure or "artificial" roles w/o a clear purpose (or precise value to be added) - able to "self-heal", correct & learn from mistakes (that are inevitable).