The times I've worked in remote environments that work best, they really value real asynchronous work and written, thoughtful communication. That lets people take the time to go back and forth rather than have to make a decision on the fly. From Tuple, this is Distributed, where we show how world-class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. Let's get to the real world.
Hey, everyone. Today we're talking to Cassie Sheffer, who is a staff software engineer at Wealthsimple, where she has worked for over three years. And prior to Wealthsimple, Cassie, I believe you spent over 10 years in various engineering roles, including stints. as a tech lead, as an engineering manager. And so, yeah, we're psyched to have you on. Yeah, thank you. Could you share with the audience what WellSimple's approach to remote work is? Yeah. So WellSimple's been remote for...
I believe before the pandemic, we've had a hybrid model. There's probably less than half, in terms of the developers, about just under half of them are in the Toronto area. But otherwise, my team's across North America. Most of us are in Ontario. We have one person in Victoria. Teams I've worked with, people are in the States, people are in Canada. So almost everything is remote first.
Of course, all the offices are set up with all the equipment so that you can have remote and on-site at the same time. But we do make sure we get people together. So I go into Toronto about once every three months. I'm close enough that I can go in and... go for a meeting and get that in-person time. Other people probably come in twice a year for team events and for company events. What does WellSymbol do to support the engineering team?
In light of it being remote first. I think there's two parts. There's definitely like real decisions happen in meetings. One of the problems with remote work is that it can appear like a decision is made when two people have chatted over coffee in the office. And those people just bumped into each other, had some ideas, and were like, this is great, let's go ahead with it. But really impactful decisions.
happen on a cadence and in meetings. When it comes to one-on-one developers, being able to pair program and just hop on calls easily and quickly. Something I love is like I always get the other person to drive, but then I'll take control once in a while and it's always on their machine so that they're familiar with it. That's like, I think for individual contributors, that's probably one of the biggest impactful.
technologies that we use for enabling remote work. Pair programming. Yeah, pair programming, yeah. You said real decisions are always made in meetings. What constitutes a real decision? Real decision. Versus any other type of decision. Yeah, yeah. So maybe I should... categorize that more as like real impactful decisions that impact multiple teams. So we have a biweekly meeting, an architecture review meeting, where if you're making a decision that impacts people outside of your team.
you have to bring it to the architecture review and discuss the impact and discuss the long-term maintenance and technical decisions there. Who attends those meetings? Yeah, those are usually VPs, senior managers. Principal and staff engineers are sort of the core group. And then there's a group that shifts depending on the topic. So other impacted teams will attend or the team making the decision will attend.
Those meetings happen every two weeks, I think you said? Yeah. Yeah. Okay. So does that slow things down, like having to wait two weeks for those decisions to sort of get ratified or what have you? Yeah, normally those types of... Decisions are ones that will take a long time to gather feedback and take a long time to implement. It's not like changing.
one thing from synchronous to asynchronous. It's usually a more significant pattern change that requires coordination. So the once every two weeks cadence. And then you can also just say, I need an architecture review and we'll schedule one if it needs to happen more quickly than that. Got it. Okay, cool. So the team broadly has this pattern of pair programming pretty often, which helps with...
day-to-day coordination. And then every two weeks, there's an architecture meeting that takes place where the VPs, the senior managers, staff, and principal folks are all in attendance, affected teams are in attendance, so that those really impactful decisions that affect other teams can happen.
in a synchronous place altogether and that information's disseminated out. That makes a lot of sense. How big is the engineering team at Wealthsimple? Yeah, I was just going to say, there's some good context there about size. There's about 400 engineers.
including managers and senior managers. So it's big enough and distributed across the continent enough that we do need to sort of have these regular cadence sync points to check in on things and make sure that we're all going in the same direction here. After those meetings, is there any sort of communication cadence about decisions made and making sure that what was discussed in that meeting reaches everybody else?
Yeah, I think there's something interesting too about our size and our history. We doubled in size about three years ago. So there was definitely some growing pains around like, well, how do we make these decisions now? Even three years before that, I think over six years, like it was 50, 100, 200, you know. I don't know the exact rate. So there's definitely been some growing around figuring out how to synchronize.
the group on these things and then how to communicate them. A really good example we have of a recent one was we needed a highly responsive authorization service. And we had some examples and some ideas about how they might work. The architecture review happened and the proposed solution wasn't considered sufficient.
The team actually paired up with a principal engineer, went away, came up with a new proof of concept, and presented that again at a future architecture review. So there is iteration that happens on it. And then how do we actually disseminate decisions and adapt those and bring them into our culture? I think we're working on that in some ways. Some teams...
are small enough that a few people can just say, this is how we're doing it, this is how it works, and that's fine. But my team, a platform team, we have to go to 30 different teams to say this is how we're doing it. And so change for us is a lot more gradual. and a lot more intentional because we're changing workflows and patterns for multiple people. The specifics of how there's documentation, some teams even do video updates.
once every couple of weeks to update on the status of things. And then there's also weekly cadence meetings for bigger migrations just to ask questions and check in on status.
Well, let's talk about your role a little bit. You mentioned you're on a platform team. I feel like platform engineering and platform teams can mean different things at different places. And I happen to know that, at least in your role, you support a bunch of different teams, as you just mentioned. It sounds like 30, maybe even. Sometimes, yes.
Could you share a little bit more about your role to orient folks? Yeah, so we're the API platform team. We're fairly small. With a manager, I lead a team of three other developers. And at WellSimple API Platform... really means the tools that we use to develop our APIs. So not the shape of the schema necessarily, because we believe that teams should own their schema end to end, but the tools that we use to...
develop those schemas to validate them against usage and to evolve them. So one example of that is we use GraphQL with schema stitching right now. We have a plan to move to Federation, but right now we're doing schema stitching and... We need to enable teams to know how their changes are going to affect clients who use their schema. Three years ago, we didn't have a good way of doing that. You kind of had to just go around and be like, are you using this? Do I see this in your code base?
And now we have tooling that lets them propose a change and then test it against real-time usage and say it'll impact these clients in this way. And so that'll let them decide, is this a safe change or not? Given the number of teams that you support, are there any practices that your team has that you're really proud of that you feel like allows you to work effectively with everybody else? There's two things, documentation and being available to...
Like, open a call. So documentation is a big one for the project that we're doing right now because our tooling is invisible or it should be invisible. It should just run in the background. If everything's good, the check should pass. if everything fails, then it actually pops up with documentation and says, here's how you analyze the data. Here's how you can make the change. Here's how you can decide if it's good or bad.
And putting that as close to the developer workflow as possible is really helpful because otherwise we're stuck in Slack and trying to send the same message to everyone. The second part is just like, yeah, pair programming on Tuple. People show up with questions about GraphQL, perhaps because they worked in GraphQL in another language, or they come from a REST background.
And they just need to understand how things are structured. And that's when it's like, you got to just hop on a call to draw pictures and write some code with them. Yeah. Do you do office hours or anything like that? Or is it ad hoc? Right now it's ad hoc. We actually had a conversation yesterday about like, oh, maybe our team needs like a...
Air traffic controller person who's like, this week I'm responsible for just healing incoming requests and being the front line and hopping on those calls or sharing out documentation or anything like that. Okay. So, you know, you're still figuring out whether or not that's something that you need, it sounds like. Yeah. Cool.
Well, obviously, Cassie, you've been in the industry for almost 15 years, and I'm sure there have been moments where things... I'm wondering if you could share a specific story about a situation where a team dynamic, like socially, the way that folks worked together, really broke down. So I have a dramatic story. Yeah, I love a little drama. If you can share. Yeah, yeah. This is from a past company, so unnamed company. I was working at this company and it was...
I mean, we'd still say it was a startup. It had been around for about 10 years. And it had a very scrappy approach. You could propose... a new technology, a new service, a new ad campaign or anything like that. And as long as you could carry it yourself, you could do it. There was a fair bit of tension. in the organization about the direction that we should take and tension that primarily resulted in communication breakdown between technology, marketing, sales.
And this was a small enough company that it was also in person at the time. So I could see the tension. You could look across the room. Yeah. Eventually, the CTO got let go, which caused chaos on the engineering team. This was also like... GraphQL was new-ish, and the engineering team really wanted GraphQL. The front-end team really wanted GraphQL. We had a monolith that wasn't that big, and the team wanted microservices.
And then I suddenly became responsible for the whole engineering team once the CTO was let go. And so I had to feel these things like, we are not, I'm sorry, we're not doing microservices. Not today, not this week. Not next month. And we're not doing GraphQL. We just need to keep things running. The team started to get really burnt out. They were seeking newness in things like microservices, getting rid of Ruby.
using GraphQL. But they were doing that because they were like really exhausted with what they were working with. So communication broke down. There were some people remote. at the company too. So there were back channel conversations happening, but also like, you know how in the office too, when everyone was in the office, you'd all have your headphones on, but you'd be like having back channel conversations on Slack anyways.
So a lot of that was happening. It was a really challenging, really stressful time. Folks from marketing would come over and be like, oh, I see empty chairs. Where is everyone? And that's like, well, actually, I was just on a two hour call. They're just at home and they're working. One thing that stood out to me right at the beginning of that story was the fact that you mentioned you could see or feel the tension.
in the space because you are in person, which is something that we lose the opportunity to see or feel has pros and cons, right? When working remotely. And so I was wondering if you could reflect a little bit on to what extent that serves folks. to not be able to see or feel that tension so viscerally. Maybe it's a good thing, maybe it's a bad thing, but I'd love to hear you comment on that specifically. Yeah, so open office stuff for me was really stressful.
I have light sensitivity, sound sensitivity. So I would try. I had triple monitors just so that I didn't have to see across the room. And I'd always have noise cancelling headphones on. I was basically working at home.
And feeling that tension for me added stress. It really added a lot of stress just to know that there was tension in the room. And also those like flyby comments like... oh this person's desk is empty they must not be working is like come on they are they just can't handle the the stress of being in the office so for me working remote
There's a huge benefit just to be able to like be in my comfortable space, like have the setup that's comfortable to me and be able to focus. Also be able to focus on written communication. and not have to always be ready with a response right away verbally. I think that the times I've worked in remote environments that work best, they really value real asynchronous work and written.
thoughtful communication that lets people take the time to go back and forth rather than have to make a decision on the fly. What are some of the learnings that you had thought through from this experience? Yeah. So a bit of context, I'm reading a book right now called Edgar H. Sheen, Organizational Culture and Leadership. It's like an MBA book. In the book, he talks about like three levels of culture.
There's the culture that you can observe, like the artifacts, the awards people get, the written documents, etc. The beliefs that are a part of the group. But then there's this underlying thing. They're like deep-seated fundamental truths that the organization believes to be innately true. They don't have to write it down because it is the way it is. And so something I really learned from this was that it's really important to recognize what people say, but really observe how their actions...
operate and how their actions impact the rest of the organization. And because these deep-seated beliefs that are believed to be fundamentally true by the organization... will show up in the way that people get rewards and in the way that success is celebrated so in this company when i reflect back on it like the way i started uh introducing them is they're very scrappy they have
seen success repeatedly by spinning up new projects, trying something new out, and either tearing it down or seeing that it was successful and moving on with that success and having that feedback. made it a fundamental belief in the organization that trying new things is going to excel the business. It's going to accelerate the business.
And I was fighting that. I was looking, you know, as a developer, I was looking for stability. I was looking for fewer incidents. I wanted things to not be on fire. But now that I look back at it, it was so fundamental to the business that... I either had to accept it or move on.
That's fascinating. We'll link to that book in the show notes if folks want to check it out, because it sounds fascinating, which is not something I normally say when somebody introduces a book as an MBA book. And so I think people should probably check it out, myself included, for that. In that situation, what actually led to the breakdown? You talked a little bit about what made it challenging for you specifically, but what led to that?
moment where things felt so on fire. So the technology stack was scattered. I mean, with a company that's 10 years old, you can end up with something that's a bit scattered. Because of the innate belief in new... things, the large parts of the technology team believed that just spinning up something new, microservices, GraphQL, whatever, would solve the problems. And that was directly in tension with...
What sales wanted was reliability. There's the big fish problem when you're dealing with an organization that sells their technology to a big vendor or a big client. So a big client comes in and they demand certain levels of support and certain levels of reliability. And sales walks over and says, you have to do this now. I just made the sale. It's like suddenly there's a tension between the immediacy of sales and the need for sort of space and thoughtfulness that software development requires.
And because of that fundamental belief that newness sells and selling excels the business, we were always in a state of chaos where we were always trying to spin up something new to patch something that wasn't quite working. Instead of going back and fixing the thing that wasn't working. I think the breakdown really came from that innate belief in the culture there. Totally. Yeah, it's interesting because finding alignment across teams is so tough. Whether or not you're...
Working person, remote, it does not matter. Having alignment is hard too. It sounds like the innate belief contributed to the fact that you did not have alignment between the stuff that the commercial side of the business and what engineering really believed was going to solve the problems.
Well, Simple being a remote first company and a company that seems to approach this type of stuff fairly thoughtfully, what do y'all do to drive alignment across teams? Because I'm on the UK platform team, I see... I see performance and reliability challenges from a different perspective than individual teams. A lot of teams are looking at their sliver and making sure that requests that hit their system are good.
But from the API perspective, when you look at it from the gateway, you see a slightly different picture. So we have a number of rituals. They do come in the form of meetings, but it really is intended to be distributed so that we have... individual ownership of these rituals, where we look at metrics from the client perspective. A conversation I had recently was... You can open a piece of bad code and say, wow, I really need to fix this. But it's free to close it.
If it's not costing you anything, just close the file. But if you are looking at a stack trace and you see that a client is experiencing error, that means there's a person out there. trying to get some data, trying to look at something on their phone, on their website, and it's not working for them. That's actually costing us money. If we can really focus our decisions on the clients that we serve.
Like one of the values that was simple is the client, the client, the client. You can look it up on our website. It's really about the individuals out there who use our services. And so we align these decisions around those values. One of them being the client, client, client, that we make sure that we're doing things for the people who use our software, because we want to be sure that, you know, they feel happy and secure and safe using it. So one way...
We've been trying to put that front and center is, you know, instead of just looking at things like high-level error rates, which doesn't tell you a whole lot, it's very anonymous, we split those error rates by user. So instead of saying how many errors do we have, we say how many errors does this group of users have? Or how many errors do we have per user? It makes it more personal. At least for me, that's a drive to like...
Fix it, because I want those people to have a good experience. I'm curious what the toughest part of being remote for you has been personally. Sometimes it seems like two people have a chat over coffee and they've made a decision. I don't know, there's a different feeling to talking in person. And sometimes as someone who's not in the office, I feel left out. And I'm like, hey, when did we make this decision?
How did it happen? And once I dig into it, I realized, oh, it was actually just a chat at the coffee machine, which then lets me breathe easy a bit. And like, oh, this was just you in the hallway. Okay. well then let's like revisit first principles here what are what are the actual principles behind the decision and if i can understand those i probably agree or we might come to a different different conclusion um so i think
That is one of the biggest challenges, the feeling of being left out. I have wondered, though, from the other perspective, do people in the office wonder why remote people are so far behind? Like, why do I have to do the work twice? You know, I just talked to this person in the hallway and they get it. And so I think there's a bit of tension between those two. And I think that's a challenge with hybrid more than it is with fully remote.
Is that at play at Wild Simple? Does that happen? Occasionally. Yeah. Yeah. Decisions aren't actually made in the hallway, though. Yeah. That's the thing. It's like when you do get people together into those architectural reviews, then there is genuine conversation about it. It could just be the perception of being left out or being...
not thought of because I'm at home and everyone else is in the office. Yeah. What do you do about that? Something I know is really important to me in a company culture is a sense of belonging. And that's where the challenge between being remote and being in the office really comes up where it's like, wait, do I not belong if I'm not in the office?
So, and this isn't unique. This isn't like unique to Wealthsimple where decisions are made in the hallways. And when we do have those in-person meetings or not in-person, but like video meetings and we make architecture decisions. then I do have that sense of belonging. So for me, it's really about fostering that culture where I can. I know I can't change 400 engineers and how they think, but I can work.
and make direct impact with the five six people that i'm talking to every day and maybe broaden that a little bit to a few other groups of people that i talk to every week or every couple of weeks yeah i think a lot more people are seeking a sense of belonging from their place of work, whether or not they realize that's true. And it does seem like that is harder to do
in a remote context, regardless of whether or not that's remote first or hybrid than it is in person. And I'm not 100% clear as to why, except that it feels right to me that that's true. Are there things that you do to help cultivate that sense of belonging? Yeah. There's a few things I intentionally do. When I'm leading a meeting, I'll intentionally pause and...
Like ask specific people, name specific people. There's also like the trick of waiting seven seconds, you know, after seven seconds of silence, then... No one has anything to say because seven seconds is long enough to be uncomfortable. Oh, yeah. Seven seconds is a long time. I did it once in an in-person meeting. I asked a question of the group and I waited for seven seconds. And then somebody asked me later, like...
what was with that long pause? And I was like, oh, I was like actually waiting to see if anyone wanted to say anything. You do that? Yeah, I do. It's actually really useful because often at the seventh second, somebody says, well, I was thinking. People squirm at a certain point. Around five or six seconds, people start to get really uncomfortable.
Yeah, you make them uncomfortable enough that then they're like, well, this discomfort is more than the discomfort of saying something. Exactly. So that one works well. Another thing I do is I'll start. I'll start projects and then hand them off. So something I did recently was like we wanted to experiment with a new GraphQL server on our gateway. I did a really scrappy job.
throwing something together that booted. I knew it booted and I knew you could read the schema. I didn't know if she did anything else. And then I wrote a document outlining like, why are we doing this and how to test it? and what results we want to see in the tests. And then I handed that off. Instead of taking that project all the way to the end myself, I handed it off and worked directly with someone else so that I could then point to them and say, like...
hey, this person has done all this work to do this research and prove whether or not this new GraphQL server is going to work for us. That way it's not all me. It's not... all me carrying the thing through and doing all the work, but instead I'm helping someone else by kind of starting the snowball and then letting them roll it the rest of the way so that...
I can see that person's success. So that's something that's quite important to me in terms of my sense of belonging in the workplace. And I would hope for that person too. Yeah, logistically, help me understand how that... works, because I'm sure you're not the arbiter of everybody's work and can't just randomly start things up and say, hey, you finish this, you finish that. Help me understand how that works in practice.
Yeah, so in this case, we had some specific metrics that we knew we had questions about on our gateway. Things about the amount of time spent in the event loop delay on Node.js. And we knew that other organizations had tested two different GraphQL servers against each other, and this other one was proved to be faster. So there was already a strong case that we should try to migrate to the other one.
We just needed to justify the work and prove it for ourselves. And so in this case, this was work that we were starting to queue up. But it was kind of vague just to say change from this GraphQL server to this one. We didn't know what the implications were in terms of testing and deployment and all of this. So I got the proof of concept code just out there. And then in a Notion document outlined...
Like the rationale for testing it, what metrics we want to see in order to say yes or no, this is how we're going to make the decision based on the metrics. And then what the next steps would arguably be. And the developer who took that work on then was able to develop it into a full technical brief project proposal that outlined all the consequences of the change.
So I didn't necessarily start something that was half done. My idea was to get it to a point where someone who hadn't thought about this yet was able to read through what I worked on. And take it from there, perhaps, with asking me a few questions like, why is this part of the code you wrote so messy? Which, you know, always happens. And was the other developer clued in throughout that process? Yeah.
And was very aware of the need to prove these metrics about performance improvements between the two GraphQL servers. I think something that working remote really has an advantage is that it kind of forces you to document.
things we could have sat in a room and whiteboarded and said okay we want to improve like node event loop delay by 40 milliseconds or whatever and then walked out and everyone would have had that in their head but working remote i had to write this down and hand it off to somebody and then they had to actually question are you sure about this one or explain more about this
So because we're handing things off between people across the continent, we have to have it written. And we have a history then of the decisions we've made and how we've shaped the project. Hearing about challenges and some of this stuff is always fun, but I also love to explore some areas that kind of yielded a really positive result. I'm wondering if you could share a particular project that you're proud of.
that you worked on. Yeah. So actually, I guess I already touched on it. The schema validation project is, I'm really proud of how that's impacted the way. We plan changes and communicate changes across the organization. You know, there was previously a working group where people would bring schema changes and they'd get discussed and modified. ratified and all that. But now individual developers are empowered because they see right away. They see, oh, like...
The most recent mobile app releases use this, so I can't change it until we've decommissioned those mobile apps. Or, oh, these three internal clients use this piece, so let's just go chat with those teams and make sure that they understand the changes we're going to make.
So it really has enabled distributed ownership rather than having to have that centralized ownership. And in a team of 400 developers, you need distributed ownership and you need to enable people with tools to make decisions with. You know, with real time data. Yeah, definitely. You talked about this a little bit when you were sharing about that project about.
how helping other people is a core part of what gives you a sense of belonging. I have to know that coaching and mentoring is something that you're passionate about. How do you approach that in a remote context? Yeah. The teams that I've worked with have ranged from like... very new developers, even interns, to more senior developers. So that will, coaching and mentoring will change depending on the person. I really try to adapt it to what I think the person's needs are.
Definitely one of my favorite things to do is work with an intern who is just excited about everything. We hop on a programming call and just dig into all kinds of things. Often, I mean, I'm definitely somebody who gets distracted by things I think are neat. And that's a really fun thing, working with interns to be able to show them. new ways of doing things or show them how I make decisions when doing things. So a lot of that sort of like shoulder to shoulder work is really beneficial.
I also find that really beneficial in the early stages of a project. And I try to approach pair programming as like group problem solving. Instead of me saying, here's how you do it. I want to see how they're thinking. so that I can adapt my teaching and my coaching and guidance to them. And then I want to share how I'm thinking so that we can sort of learn from each other.
And I definitely approach coaching and mentoring as an opportunity to learn something from the person I'm working with. I just don't like top-down coaching and mentoring. Even though I've been doing this for so long, it doesn't mean I can't learn something new.
Or it doesn't mean I can't learn something new about a part of the business I don't know either. When it comes to more senior developers, usually I approach that more in the try to help them understand the direction things should go and then give them space to explore. and give them space to come back to me with a solution. And that often works really well because it's not my job to be deeply embedded in the work they're doing. That's their job. It's my job to help them find the right direction.
and then come back and be that sounding board when they need to clarify decisions. So it sounds like pairing in one capacity or another is a big part of your mentorship and coaching practice. Some of the folks that I speak with, they're part of teams that... pair program eight hours a day like all day every day like work does not get done unless it's paired on and then there are other folks that i speak with who
literally don't pair at all, but maybe you're curious about getting started pairing. What are your feelings about when to pair, how often to pair? Could you give us a breakdown? Yeah. So... When and how often varies depending for me, depending on what I'm working on. I have the like notification that says when people have joined a like lounge for my team and I see my team on and off of Tuple all day.
I don't necessarily join because I might be working on something else. But I do like having that notification just to know, like, oh, I might know what they're talking about and I'm going to hop in and just listen in and contribute if I can. So for me, I pair when somebody has an acute problem. The other day, it was a question about the way a GitHub workflow worked, I think it was. And they could describe the problem to me. Then I know I can be directly impactful to their work.
The other side of that, though, if they just don't even know how to describe the problem, then I know that I need to work with them to help them understand how to describe the problem. Those are sort of the two, like if there's an acute problem or is the acute problem that...
they're not even sure what the problem is, which is very common, then I know how to approach the conversation. How do you know if somebody's in that state? They can't even describe the problem. I find either if Slack goes silent. Or if there's too much back and forth that's unrelated, then I'll just be like, okay, let's hop on a call. I have this mental rule that if there's three messages in a minute, then a call is going to be faster because we can bounce back and forth.
Just this morning, somebody asked me for help and I asked like two clarifying questions and they were able to say, oh no, it's specifically this thing. And so that like helped me know exactly where they're at. But other times if I ask clarifying questions...
and somebody comes back with something vague, or they just say, I don't know, then I know, like, okay, we actually need to work on diagnosing here. And it's like, that's great. If you know you don't know, that's a better place to be in than thinking you know. when you don't totally i mean so many folks suffer in silence either not actually taking the step to ask for help or thinking that they know the answer but then going down the totally wrong path for days on end without folks realizing it
I think this is something my team does really well at. I used to be more directly involved in it, but they do really well at saying like, I think I know, I'm not sure I know. I need you on a call just to validate. And they do a lot of that. There was a while back where we were actually pairing with a principal engineer. There were five of us. And we paired on and off throughout the day to get some work done that was new to everyone, including the principal engineer.
And at the end of the day, he said, like, I never thought pair programming could be that productive. Because we all walked away knowing how to do what he did. And we all walked away having driven the conversation for at least 20, 30 minutes of the conversation. And it just totally changed how we approached the project because no one was sitting...
alone and stuck. We were like, we're all stuck together, which was great because then we got unstuck together a lot faster. What made that particular session so impactful, do you think? Part of it was approach. that everyone approached it with curiosity, and there were no bad questions. It was a slightly unfamiliar space to most people on the call.
And when somebody asked a question that maybe a few other people already knew, no one talked down to them. People just pulled up the documentation, explained it, asked for feedback. So it's really in those, especially in group pairing, like... approaching it with curiosity and not just curiosity about the problem, but curiosity about, oh, why is that person asking that? So that you really can make sure you get to the bottom of it. Yeah.
That's cool. I love hearing stories like that where the outcome of a session like that was somebody's perspective on the practice itself changing. I'm wondering if there's an aspect of remote work that you don't really have the answer to yet or that you're still curious about.
I think there's that part about feeling left out when there's this hybrid environment where some people are in the office and some people aren't. There's a slightly different culture between in-office people and remote people. And I don't have the answer to that. And I know that's not unique to where I work now. It's everywhere. And I think that anxiety about that is one of the things that's driven some companies to say you have to be in the office.
That doesn't really work either. Like I said, I can't sit in an office with the lights and the sounds and people walking by and actually feel productive. I need some quiet space to do some thinking. And I actually recognize that. In my colleagues who are in the office, they use the office as a tool to have productive conversations, but then they work from home when they actually need to do deep focus work. So I don't have an answer to that.
Other than maybe like lots of therapy so I don't have anxiety. Therapy is a useful tool. It's definitely a useful tool. With that, thank you, Cassie. It's always a pleasure catching up. I appreciate you being generous, sharing your insights. What's one thing that you hope listeners take away from this conversation?
Yeah, I'd say just approach every conversation with curiosity, every pair programming session and or every planning session with a curious mind to kind of ask the questions why so that everyone's, you know, on the same page and doing the same thing. Yeah, I love that. And if folks want to connect directly with you or learn more about Wealthsimple, where should they go?
Yeah, on LinkedIn, Cassia Sheffer. So like Cassie, C-A-S-S-I-A instead of I-E. I also have a website. It uses my old name, when.cassidy.codes. That's where I write blog posts on the things I've been thinking about recently. Very cool. Well, thank you so much. Again, a pleasure catching up. And I hope to chat again soon. Thanks for joining us on Distributed.
If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.