> Do you have more examples of companies that are not feature factories?
Actually, none of them are. They're just managed as if they were.
In a factory, you can literally have a machine that stamps out 1000 widget blanks an hour and if the operator does an hour of overtime, that's an extra 1000 widgets produced that day.
You've got your workers on 8-hour shifts and sales signs a contract to deliver 8,500 widgets per day? Then you know right away you're going to need 10-hour shifts, or regular overtime, or a second 8-hour shift, or a second machine, and you can figure out how much each of those would cost, and whether you've got enough car parking for the extra workers.
Whereas in software, your feature factory produces ???? per hour, sales promises customers ???? and an hour of overtime achieves ???.
Changing the topic from software development to R&D: the granular task oriented view is generally not good for greenfield research endeavours. It's a form of premature optimization. You're calcifying the search space and reducing flexibility to pivot immediately based on expert intuition and hunches. That being said, a coarse task orientation is necessary to keep people vaguely pointed in the right direction. The best resolution (time horizon) for task orientation depends on what you're doing.
Do you have any pointers for guides about how to implement this sort of methodology in software-based R&D? I'm currently in a small, partly research-focused team as part of a larger tech company, and it's proving a struggle to align our work with the rest of the dev squads who do all their work in 2-week sprints with max-2-day tasks. I'd love to better understand how research teams tackle this problem in other companies. It would be amazing if I could present an alternative strategy to management that's worked elsewhere.
The research breakthroughs will come from self-motivated, highly competent people. Figure out who they are, give them resources/help and get out of their way. Let them do nothing for 48 hours because it isn't nothing, they're thinking about what should be done. You're asking them to navigate a tremendous search space, and that will require unconventional modes of working. If you hired the right people, they should know better than you about how to best navigate that space. Keep them accountable over a 3-6 month time horizon, not a 1 week horizon. If they're juniors, they will need daily or weekly guidance, but not dictates or deadlines. Deadlines for artificial milestones do not make for better results, they degrade results because they force time-consuming proof of work. Researchers sometimes need active prodding if they are stuck in a local optima, but that's a different beast to predetermining specific tasks a week in advance. I'm assuming the talent bar is kept high so they can autonomously work in the above fashion, and I am assuming they are intrinsically motivated to produce results.
When it comes to less intrinsically motivated team members, I don't have useful advice. Maybe they can contribute to research output, but that would require more traditional management styles which I can't comment on.
When it comes to satisfying constraints imposed by other parts of the org, I can't usefully comment on this either.
Thanks. It is the "satisfying other parts of the org" part I'm struggling with, but it's helpful to see the reasoning laid out as you do in your first paragraph.
I guess the essential problem I'm trying to solve is how to respond when the MD or a product owner comes to me and says "The client wants our core algorithms to be adapted in XYZ novel ways. When can you deliver this?".
Interesting you mention 'intuition'. I feel it is a big part of software development as you gain experience and it flows through as you are doing the work and would be tough to plan for. Also remember one of my colleagues complaining after work 'code just not flowing freely today'. And then there are times when you feel you are in the zone, which would definitely be the creative element.
Too bad that's pretty much the only such example that has been touted since... The 1960s, is it? And that it was, IIRC, recently either shut down or announced to be shut down sometime soon.
Thus, using this as an example seems, if anything, to illustrate not that "there are too!" but "there are dwindingly few".
Do you have more examples of companies that are not feature factories? It seems the entire industry has adopted this pattern.