Okay that’s what I thought. I have a couple of thoughts on this that are kind of broad reaching so apologies if the organization isn’t great.
The multi-cycle type projects with LOTS of backend work is alluding to at least one difference between your company and Basecamp which might require your approach to be adapted. They have a philosophy of monolithic, html-over-the-wire application architecture on Rails, which I’m guessing you don’t have. So Integrate One Slice, in a practical sense for many of their cases, probably means implementing the smallest model change + smallest controller change + smallest view change that equals something new working, and repeat. Specifically, as an engineer is going to be able to make some progress on a specific slice at the same time a designer is discovering options for the final front end deliverable.
I think what makes sense here is to figure out a better definition of your slice. Here’s an example from one of our products. It consists of a web application that handles some administrative tasks and an electron application that is more “user centric”. We’ll sometimes do a project that touches both applications. Integrating slices in this case, because of the actual separation of concerns in the different applications, might mean that one engineer takes a scope slicing up the work related to the web app, and one engineer takes a scope sliced only on the electron app.
One final contrast, at least for us, you said backend engineers, we specifically avoid a situation where engineers become specialized. One of the reasons my team specifically is encouraged to follow the slicing methodology is because it gives everyone experience with everything and doesn’t pigeon hole them into a specialty.
All that to say, it’s definitely possible that you’ll need to adapt your definition of slice to the actual context of your products.
There’s something to be said about “R&D Mode” and “Shape Up”. Shape Up is about shipping work at the end of a fixed time variable scope project. In order for Shape Up to be valuable in R&D Mode, you have to decide what it means to ship work, and whether your analogy is getting you the feedback you need in order to continue shaping and iterating.
If you don’t have any customers you’re not iterating, you’re just building!
Okay, theory aside (but not speculation), my default opinion with more context on the product, short term goals, and business strategy is going to be that you and the head of engineering are right. My bet is that the engineering teams don’t like that approach because they’re already pigeonholed into specialty roles and hearing about working on all the things is scary.
For mobile and backend the generalized software engineering role is sometimes not practical. Assuming backend means “APIs”, I’d consider shaping backend work as if the mobile team is the customer. So integrated slices will still mean shipping something to the mobile team. The mobile team then shouldn’t be working on projects that depend on the backend work of the same cycle since they’re dependent on API work.
Sorry for rambling, interesting dilemma!