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 "tech tech tech tech" all the time, so I really only have experience in this one place. I'm curious about culture, how legacy code is handled, team size, management style... Just anything/everything, really π
I always find it a bit tricky to talk about my work TOO much because I always wonder where the line is when it comes to over-sharing the details of your employer? Are there unspoken rules about that kind of thing? I don't even know π³ But here's a little snapshot of my work situation to get the conversation started.
My employer is remote-first at this point, although when I was first hired most people were local and worked out of the office. Over time things have changed, people have moved away but continued to work for us, and remote people have been hired. I quite like the remote lifestyle and I don't think I could go back to a regular 9-5 in office anymore!
We don't have set working hours but people tend to work anywhere between 8am and 5pm in their respective time zones. Sometimes people work weirder hours if it makes sense for them (a co-worker was in Japan for a month and decided to start their workday at 6am Japan time, for example) We chat online and use conference calls for when something face-to-face feels like a better fit. Sometimes we fly people into town for IRL team bonding.
The devs are really dedicated to building things properly and thinking a feature through holistically before writing any code, but it can sometimes be a struggle between development and product managers, trying to find the balance between doing something carefully/properly and shipping something by X date. I imagine this is fairly common in the industry. We have crunch times where things get hairy and we have downtimes where things feel a little smoother for the devs.
We are a small team, so during crunch times, juggling bug fixes, support requests, "can you quickly squeeze in this small quick feature" (lol) as well as working on whatever our current "big long-running feature" is, can sometimes be very daunting, and we're always trying to find ways to manage this workload better, but I don't think we've found the magic bullet yet. Has anyone???
Our dev process is also quite loose: We have a weekly planning meeting where we go around and each dev talks about their progress, how the week went, and what is up for the next week. We take notes each meeting and upload them to a "meeting minutes" repository on github. We also use a task manager to track assigned work. Sometimes I wonder how/if this could be improved. I like how simple it is but I don't think it works perfectly either. Does anything work perfectly??
Dev team is split by platform
- API (back end)/devops: Rails, Elixir, any devops-y infrastructure work needed.
- Front end: Single page web app so a lot of JS needed. Plus CSS of course. Front end team also manages an electron app.
- Mobile: iOS/Android devs.
Rarely do devs contribute "full stack" although it's not entirely unheard of. Recently we had a front end dev move to our API team because they wanted to grow their skillset, which is awesome and I'm so glad we were able to accommodate that.
I used to grow a lot technically due to the the people above me being excellent mentors, but more recently as I've become more senior I've found this to be harder. Now I find I need to go outside of work and read articles/try to do side projects to explore new technologies. I don't feel like I'm super great at this and I wish I was better! Since I am managing people I think it's partly my responsibility to research and bring things back to the team that I think could be good for us. An area for me to improve for sure.
I find the culture here to be very good. Management has historically cared deeply about employees and their lives and making sure people are supported, which is really nice.
Ok your turn! How is your job different, or the same??
Top comments (4)
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 )