I feel so sheltered! I've worked for the same SaaS product for about 8 years, and I don't live in a place like SF where it seems like everyone is "...
For further actions, you may consider blocking this person and/or reporting abuse
Your work environment sounds very similar to ours. We're remote, we do weekly meetings and minutes in a very similar way, we're not typically deadline-oriented outside of exceptions for the most part.
We, DEV, are a consumer-facing web app, of course, and we are a Rails shop where most folks do at least a bit of fullstack work even if they specialize in part of it.
We're not based in Silicon Valley, but we are in a tech-centric space so we need to be a bit more "plugged in" in general. Us founders have a lot of business relationships that run through that part of the world, so we go there from time to time to tune into the trends.
It's definitely interesting to see how different folks do different things.
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.
I've worked at / with a few product companies, here's my take on a couple of points you made:
I've experienced less of this friction when developers have a part in setting the product goals and scope. That way the product manager can accurately communicate realistic timelines for work. Looking back on teams where this was a problem I would say it was usually a case of "If we had communicated on this scope earlier we would have come up with a different timeline."
I think perfection in a process is the ability to evolve it over time. To that end the most important meeting in my mind is a retrospective meeting. This is where you honestly look at your process to see where it might improve, and track those improvements.
I have worked in small organizations like this, but dividing teams this way as a default makes you default to working across teams to accomplish big product initiatives (since it will involve work across the server / client / infrastructure / ect). I think for that reason all the teams I've worked on at larger product organizations have been cross-functional, and organized around some cross-cutting but coherent concern. Like "The Presence Team" who works on all aspects of presence within the product. That way you can accomplish big initiatives around that idea, and work across teams in a way that aligns more with how the product works.
You make very good points, and it's great to hear the experience from a smaller team :)
In our company, two of the devs in our full-remote team have been working here for more than 10 years (literally longer than anyone else), so they know the product down to the most minute details, and have happily spread the knowledge to our team.
So the funny part is that UX, design, or product-wise, we usually find a lot of edge cases that they didn't think of.
We have more than 100 million users (around 30 million are active), some have been using the product for a decade. It happened before that we didn't share our point of view directly with Prod/Design for fear of been too naggy, and guess what, support tickets flooded our staff when we released new features and a bunch of legacy functionality was not there.
We build things fast (some features that take other teams months take us weeks), so it has been hard for QA, Product, and Design to keep up.
This becomes quite frustrating so we have worked hard as a team to reduce the amount of criticizing (that's hard for me!), and to praise first. Usually there will be 10 to 30 missing details that we will need to let them know slowly, without overwhelming them.
This considerably slows down development, so I've resorted to doing documentation, refactoring, and developer-friendly features such as maintining our Storybook in the meantime.
Hurray for remote! π₯³π₯³π₯³
(BTW, not sure what is the best way to reach you or someone on your team, but I noticed getflow is using a development build of React, in case you want to check it out -> image )