Greetings, fellow Canadian working on the same product for the same SaaS company for severals years! (Maybe there should be a club?)
I expect answers are generally going to follow Conway's Law here.
But to help you build your matrix here's some actual data...
Workforce
A product department about 95% on-site at headquarters. People WFH when they want to but most people come into the office most of the time. Reasons to WFH: you don't want to spread your cold, you've got a [delivery/appointment/child event] that makes it awkward to come into the office, or you need to work in 'Do Not Disturb' mode without seeming rude to people that drop by your desk to ask questions and you have to say 'I cannot help you right now, I need to focus on my thing'.
I always remember a conference panel where an executive from a company whose business was based upon helping other companies becoming remote-only was asked how everyone could become remote-only and his answer was "that won't work, most people cannot work well remotely". His whole company was focused on this but even he understood that remote is not a silver bullet. Some people love it, some people are OK at it, and some people hate it. Personally, I can work remote today but day-in-day-out I am not as happy or productive as when I work face-to-face with other people. I actually moved so that I could walk instead of drive/ride to work. Maybe there is a cyberpunk future where technology is at a point that the difference is negligible but we aren't there today.
Workload
This one I feel is largely driven by customers/industry. For instance, my customers are enterprise which means two things. 1. if a bug has made it through their UAT they need it ASAP because it will cost them $$$ each day. 2. they are rare to adopt changes so they don't need that new feature tomorrow (because even if it was they wouldn't take it) but when they upgrade in 6 months IT HAD BETTER BE THERE.
No one has found a magic bullet on this. Those that think they have actually have an insulation layer of money, either from VC capital (Uber, WeWork) or by a having a product that's not legally a monopoly that prints money (Facebook, Google, Valve, etc).
Process
Most of the product teams follow some form of Scrum but some use Kanban. Some teams use story points, some don't. Some teams have daily stand-ups, others have ad-hoc discussions when they feel like.
With this I always like to refer back to the original Agile manifesto which basically comes down to 'you do you' - there is no perfect process for everybody, every choice has benefits and cons and only you can decide which ones are worthwhile for you.
Organization
Teams are grouped by platform though a bit differently as you define it. In our case the Front End team would qualify as Full Stack in most places, as they do both the SPA that users interact with and the REST APIs that interact with the database. But we also have our own database so we have the C++ team that works on that foundational piece and another C++ team that works on high-performance business logic to work within the database. Then you have teams focused on specific use-cases (integration, machine learning, etc) that have thin slices through all layers of the stack, plus the devops-y people who build their own stuff that has to work with everyone else's stack :)
I know there are plenty of places that have adopted the Spotify-style tribe/guild approach and it will work for them. But I know from my experience that sometimes that doesn't work. Lets say you have a feature that requires front-end, back-end, infrastructure, and machine-learning. Cool, that happens. But how often? More likely is that the frond-end and back-end parts of the feature will need continual work but the infrastructure and machine-learning may never be touched again - so why are they dedicated to the team? My experience is that certain types of problems have certain types of affinity with certain types of platforms. While you may be able to carve out a set of features that can be handled top-to-bottom from a single group (and if you can, great!) it's not a universal concept that applies to all problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Greetings, fellow Canadian working on the same product for the same SaaS company for severals years! (Maybe there should be a club?)
I expect answers are generally going to follow Conway's Law here.
But to help you build your matrix here's some actual data...
Workforce
A product department about 95% on-site at headquarters. People WFH when they want to but most people come into the office most of the time. Reasons to WFH: you don't want to spread your cold, you've got a [delivery/appointment/child event] that makes it awkward to come into the office, or you need to work in 'Do Not Disturb' mode without seeming rude to people that drop by your desk to ask questions and you have to say 'I cannot help you right now, I need to focus on my thing'.
I always remember a conference panel where an executive from a company whose business was based upon helping other companies becoming remote-only was asked how everyone could become remote-only and his answer was "that won't work, most people cannot work well remotely". His whole company was focused on this but even he understood that remote is not a silver bullet. Some people love it, some people are OK at it, and some people hate it. Personally, I can work remote today but day-in-day-out I am not as happy or productive as when I work face-to-face with other people. I actually moved so that I could walk instead of drive/ride to work. Maybe there is a cyberpunk future where technology is at a point that the difference is negligible but we aren't there today.
Workload
This one I feel is largely driven by customers/industry. For instance, my customers are enterprise which means two things. 1. if a bug has made it through their UAT they need it ASAP because it will cost them $$$ each day. 2. they are rare to adopt changes so they don't need that new feature tomorrow (because even if it was they wouldn't take it) but when they upgrade in 6 months IT HAD BETTER BE THERE.
No one has found a magic bullet on this. Those that think they have actually have an insulation layer of money, either from VC capital (Uber, WeWork) or by a having a product that's not legally a monopoly that prints money (Facebook, Google, Valve, etc).
Process
Most of the product teams follow some form of Scrum but some use Kanban. Some teams use story points, some don't. Some teams have daily stand-ups, others have ad-hoc discussions when they feel like.
With this I always like to refer back to the original Agile manifesto which basically comes down to 'you do you' - there is no perfect process for everybody, every choice has benefits and cons and only you can decide which ones are worthwhile for you.
Organization
Teams are grouped by platform though a bit differently as you define it. In our case the Front End team would qualify as Full Stack in most places, as they do both the SPA that users interact with and the REST APIs that interact with the database. But we also have our own database so we have the C++ team that works on that foundational piece and another C++ team that works on high-performance business logic to work within the database. Then you have teams focused on specific use-cases (integration, machine learning, etc) that have thin slices through all layers of the stack, plus the devops-y people who build their own stuff that has to work with everyone else's stack :)
I know there are plenty of places that have adopted the Spotify-style tribe/guild approach and it will work for them. But I know from my experience that sometimes that doesn't work. Lets say you have a feature that requires front-end, back-end, infrastructure, and machine-learning. Cool, that happens. But how often? More likely is that the frond-end and back-end parts of the feature will need continual work but the infrastructure and machine-learning may never be touched again - so why are they dedicated to the team? My experience is that certain types of problems have certain types of affinity with certain types of platforms. While you may be able to carve out a set of features that can be handled top-to-bottom from a single group (and if you can, great!) it's not a universal concept that applies to all problems.