Feature teams make a lot of sense, but one of the problems is that you tend to end up with two bosses, one team boss and one functional boss.

At GitLab we're trying to see if we can do component teams with handoffs (UX => front end => back end). This is hard and we might have to reconsider. I've detailed the reasons in https://about.gitlab.com/handbook/leadership/#no-matrix-orga...

In any large engineering organization with a bunch of products each of which are large enough to need multiple teams, multiple bosses are inevitable. The issues and technology are just too complex for any single boss to manage everything. A typical agile team member might be accountable to a resource manager for HR type stuff, a Scrum Master for team tasks, a Product Owner for team priorities and requirements, and multiple component stewards for component technical integrity. The key is to align everyone to a common set of program goals and clearly delineate responsibilities between those various "bosses" to prevent conflicts and avoid excessive communication overhead.

A "no-matrix" structure might work in a small organization which has basically only a single product. In that case it's actually possible for a single competent boss to understand the customer, product, employees, and technology well enough to make good decisions.

As far as I know a matrix organization normally means a two dimensional one, with two bosses. You're totally right that all those functions exist and influence your work, but I don't think it is normal to call them bosses.

In most matrix organizations regardless of dimensionality each employee still has only one formal manager who deals with raises, career development, and disciplinary actions. The other "bosses" such as project managers aren't officially considered managers in that sense, although the employee may be accountable to them for certain things.

I agree they have one formal boss but I thought that in practise they had one other person they reported to for their day to day work and results.

That's not a silver bullet though.

In a large software system you can't expect any individual to be as effective working in any area of the system. So you're winning on the blocking front but you're losing on the productivity front as people ramp in on different pieces and you're also potentially losing a sense of ownership from the developers and instead giving them a sense they're cogs in a machine...

To me a better compromise is to ensure you have enough of a backlog that you can always pick something that is the right combination of expertise/interest/lock-free at any given time. If you plan properly and you have sized your teams properly things should move along better than trying to get everyone to work everywhere on some random feature. That's not to say you can't occasionally do that if something important comes along but to me feature teams in large scale software is to be avoided. [EDIT: realizing this is maybe too strong of a statement, a team can definitely work across multiple pieces and will ideally implement complete features, but those features need to be a match to the capabilities of the team as opposed to just looking a "feature team" as some sort of unit of production for any random feature]

There's another part to this which is that it can be difficult to see the inter-dependencies between features. So modelling your software development as a bunch of teams that can just pull the next feature from the queue and work on it may actually not solve the locking problem at all but create more subtle dependencies and less efficiency.

If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay. For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate your thinking in multiple areas.)

For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015...

No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.

I'll check that book out, thanks. We'll see if it can re-calibrate me ;)

In my view optimizing productivity isn't necessarily mutually exclusive with other things you're trying to achieve. If productivity is very low then most other measures will tend to fall too though that may lag. The problem is that productivity tends to have poor visibility and is difficult to measure.

What I object to with all my heart is the "feature team" as the assembly line model of software "features". I.e. the software factory where features come in one end, get assigned to a random team, and product gets delivered on the other end. This model results in low quality, expensive, bloatware at best. It may or may not at any given time make some money. It's also not the model used, AFAIK, in most successful software companies.

I've worked on teams like that before, and my biggest gripe is that it is next to impossible to get a good code review. People on your team don't have the specialized knowledge necessary for effective reviews and the people on other teams who do aren't invested enough to do it thoroughly and in a timely manner and usually won't be familiar enough with the details of the feature you are working on to do it well.

The impacted component stewards are supposed to be in the reviewers list (along with members of your own team) for any significant change.

This is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life?

To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disciplinary communication shitshow.

I wonder if there is an official name for this feature teams model or more guide on how to implement it.

Scaled Agile Framework features and components: http://www.scaledagileframework.com/features-and-components/

"Scaling with Feature vs. Component Teams" by Ken Rubin: http://www.innolution.com/resources/presentations/svaln-2015...

This is gold. Thank you for posting that.

The more general term for these two structures are Functional vs Divisional structures. In the case of software engineering, a feature based team is a functional structure, and a "database team" (or "API team", or any other specific technical concern) is a divisional structure.

so why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?

I have no idea why many engineering organizations insist on maintaining the artificial distinctions of "front end" and "back end". I think we do ourselves a disservice by labelling ourselves with those distinctions, but the entire industry seems to disagree with me.