What sets a high performing team apart is a team that can iterate very, very quickly and can make their choices and understand their system well. 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 work. Today, we are talking with Carlos Rosau, Director of Software Engineering at New Store. Carlos, we're excited to have you on.
You obviously have 15 years of hands-on experience as a developer and have recently moved into leadership over the past three to five years. And your experience brushes both the corporate side, working at... big companies like Newstore, as well as consulting firms like Equal Experts. And so we're excited to have you on today and learn from your diversity of experience. Could you start by sharing a little bit more about what you're specifically responsible for at Newstore and maybe even what...
new store does for folks in the audience who don't know. In very simplified terms, what the new store does is we create an iPhone app that allows refillers to manage everything related to their stores just by using this app. If you go to one of our customer stores in the UK or in the US, instead of the people that work in the stores, you won't see them standing behind those old school.
point of sales behind the counter. They will be walking around the store just by using the with the earphone in their hand and they will be able to do everything. related with managing the storage just by using the iPhone. So they could sell the products to me and you or they could even fulfill an order that was placed online and it was sent to the store because they said there was a goal in the store. So this is what new service product is all about.
I started in your store around five years ago and I first started as head of engineering, responsible for two teams. Today I'm working as a director and I'm responsible for two big areas of the organization. One of these areas is what we call selling, which is everything that allows the workers in the store to sell using our product. And the second area is payments, which is a quite common area all around the service, a lot of companies. So these are the two big areas that work really.
We are mostly remote, so we have people spread across Europe. And we have around, or in my reporting line, we have something like 40 to 50 people today. Oh, wow. Very cool. And so you said you're mostly remote. Can you unpack that a little bit more? What exactly does the setup look like? We have three offices today. while in Berlin other than Amsterdam and we just opened a London office and we have engineers working from these countries.
where they can go to the office, but we also have engineers working in other countries in Europe. Our rule of thumb has always been hiring. really strong people independently of the country as long as they are more or less on the city times all and by more or less i mean plus one minus one hour even though people are remotely we want people to work
collaboratively to work together for as much time of the day as possible. If people would have eight hours time zone difference, this would be quite hard, but having one hour time zone difference, this was quite easy. Because the teams do pair programming a lot. So by default, the people are working in pair programming. So with eight hours time zone difference, that would be pretty much impossible. So you're maximizing for...
time zone overlap independent of where anyone is actually physically based. And it sounds like you've got some in-person offices that folks can optionally go to. Is there any required in-person attendance or is it totally optional? No, it's optional. There's no requirement. It's optional. and what we try to do is try to get people together at least once a quarter or at the beginning of one. Imagine if we're building one new functionality starting early next year.
we would get all the people involved in one office for kickoff and guarantee that everyone is on the same page. And this also helps ensure that people have a face-to-face connection here and there to make sure that that's not lost.
at the same time all the offices do a once a month team get together it's not mandatory or anything but the office was better there's food ordered and there's even sometimes meetups and people go there once a month even in places where we don't have offices but we have a considerable number of people we do the same example in lisbon which is where we where i am today
Once a month, we do a team get-together, and I just rent a co-working space, and we get all the team here. We rent a co-working space for the full day. It sounds like there is a pretty strong priority on synchronous time. both remotely and in person. And you talked a little bit about the moments in which getting together in person feels like a higher priority. Could you talk a little bit about...
how the organization or you and leadership think about what are the right moments to bring people together in person and what you're seeking to do when you actually get in person? In terms of goals of getting people together. I think we can summarize those goals by, one, making sure the human face-to-face relation is not lost.
and so that it's we are just more than faces on the screen so that people get really get to know each other face to face including also having lunch together and having dinner together so that people also have
this human contact beyond just a face on the screen. At the same time, the goal of the face-to-face meetings is also to make sure that everything is... is ready to start or to pick off a new project example we want to do to run a user story mapping session and before starting a significant project it's important to do this pace to phrase because this will all
everyone to be in the same room and everyone to have a better understanding and also be able to question it there right at the beginning. Of course this could be achieved remotely but I think at least when we start something... It's very valuable to have this face-to-face communication. We try to do this once a quarter and this helps when we have new members in the team. When there are new members in the team.
We ensure that at least once a quarter of a new member gets to meld the rest of the team in person. This also, I think, helps with onboarding and helps also people feel part of a larger group and not just being isolated, if we can call it. Newstore seems to really prioritize getting that in-person time together. Could you describe maybe the team's culture and what it feels like to work as an engineer at Newstore? I think it's frustrating.
It's important to clarify what you just said. We give a lot of value to in-person contact, but... Not every day. We don't mandate people to be in the office every day. Right. I think it's important to... Good clarification. To clarify that. Now, what is the environment like at Newstar? We are organized around... I call them power teams. Sun Literature also calls them streamlined teams, which are teams around a given domain or vertical, and these teams are fully responsible for this vertical.
from ideas all the way to taking these ideas to production and independently of what technology or what part of the system requires to be implemented this idea. We have one area of the system, which is the shopping cart. We call this the checkout team. So everything related to the shopping cart, independently of it being work on front-end, work on back-end or even work on infrastructure, this is done by this team.
And this thing is the one responsible to, one, speak with customers and understand with customers and understand also from the market and the business what is more important. Okay, this pattern of the organization. Prioritize it. getting it done and validated with real users if our original hypothesis were it uh were the right one so in summary i think the working at as an engineering news or as an engineer at new store is
Something that makes people feel very empowered to make changes onto their today. Contrary to other... places i've seen engineers will not be told do this do that do this here's a task go and do it people are way more empowered to make decisions of what's more important for that specific area of the business of course These are not just engineers, these streamlines or empower teams include other roles like product managers, UX designers, and if needed, more people.
Together, they partner and build this part of the product as a group, as a team. So in general, working at Nusa, I think it feels a very collaborative environment, very close with the end users. which usually are very, very receptive to working closely with us because they end up getting early access to new functionalities and they feel that their voice is heard.
when we are building new things. Because if they are there from the start with us, they can say, oh, we would love it to be a bit more like this. Or this problem that we're trying to solve is good, but this other problem is probably more important. So something like this. Interaction between customers and the teams is very, very powerful for me. We also do face-to-face time with customers. Our customers are, like I was saying at the beginning, they are mostly retailers, so they have stores.
Here and there, we try to get the themes in the stores and work. That's cool. as if they weren't one of the users of our product. Because you need to read your own dog food, right? So you need to understand exactly how it is. Customs don't have stores in all the countries in the world. For example, there's a few stores in Berlin, there's a few stores in London, and there's hundreds of stores across the West. And here and there, we do the store visits.
And we even have situations where, because our antennas work in the streams as if they were one of the best-story blood. This is what we've been trying. Have this as part of your onboarding. This is not there yet, but two pieces and one of the goals that I want to bring to the organization is that that's part of the onboarding. You shared before the show at a different conversation where you and I were catching up that...
New Store has been trying to standardize a bunch of practices across the engineering team as well. So there's this dichotomy between some practice standardization and independent team autonomy and empowerment. Could you talk to me a little bit about what are the practices?
that Nistar is standardizing or has standardized around, what practices do you feel like set the team up to collaborate and work together so effectively while being remote? What I described in terms of having close contact with... the people that use our product this is part of something that we feel is so important that we want it to be standard across the organization so in terms of we can call this
product engineering or whatever you want to call or customer focus customer first we this kind of thing this is one of the most important things and i believe that this is at the top of the things that we rule with standardize across across the teams okay from a more technical or more ways of working perspective we've also brought forward the standardization around better programming
test-driven development and a few other things around the extreme programming. The reason for this is that we believe that these practices Encourage a set of behaviors and encourage a set of quality in the code and in the things we build. That is exactly what we need.
example pair programming together with pair rotation ensures that we have as little knowledge silos in the teams as possible so that if people they get sick or if people end up being gone parentally or if people leave the organization, the impact on the teams is smaller.
because you don't have the same person always working on the same kind of functionality because this person is the person that knows more about this and they will always work on this. It can seem very effective at first but this will be as the time goes by. you will be fully dependent on this person for that particular part of the code and you will like i usually say to my colleagues this is a
A marathon is not a sprint, so you're here for the long run, as we need to optimize for the long run and not optimize for what's easy and what is faster today. I mentioned also test-driven development, and this is a way of one, not just in training. quality as the tests are in place, but test-driven development can also be used as a design tool, as a way to guide design and guide architecture choices because if you want to start by writing the tests...
you need to build your software in a way that's easily testable. And doing that makes your code also easy to change. There's a bunch of self-reinforcing things that together... They contribute to a product that is stronger, easier to change and to a team that feels more comfortable doing the changes in the source code. One of the most common problems in the software industry is miscommunication.
And when you're talking instead of just writing, it's easier to understand exactly what the person is trying to say. If you're talking constantly with someone and working together with the person or with the team the full day, you have the opportunity to... A clarifier when you misunderstand something. And it's cheaper to misunderstand something because you can clarify it easily because the person is on the call. That's so interesting because...
Miscommunication is one of the things that I hear is one of the most prevalent challenges of working remotely. And what I'm hearing you say is that your practice of pair programming... eight hours a day is your primary approach to preventing that miscommunication. Am I hearing that right? That is part of it. I think the other part is ensuring that teams are empowered to make their own decisions, which then leads to less communication.
I mean less communication back and forth, because if the team can set their own goals. But to be able to set these goals, the teams need to have clarity on what is the business trying to do. from a general perspective because the team's goals and what the team tries to do with their part of the platform needs to bubble up to the company-wide objective. Let's say the company needs to grow five times this year, as a random example.
the team then figures out what they can do with their part of the system or with their area or their domain to be able to lead the business as a whole to achieve this. If it's not clear for the team what is... what is the business goals. The team can communicate well within their area and they can execute quite well and choose very good forms.
in that area, but they might not be doing the most important thing for the business. So I think for the communication and miscommunication to be less prevalent in a remote kind of environment. I think it's important to, one, have the business goals clear to everyone and not just clear to the leadership team to make sure that they feel clear throughout the organization. There are, let's say, rallying cries and other kind of techniques that help with this.
And then make sure that the team is empowered to make their decisions to get there. Because if the decisions are just top-down... This will be quite hard and there will be a lot of back and forth that then will lead to your screen division, I believe. It's nice to talk about this stuff in theory. I think it's often more illustrative to provide specific examples of...
decisions or projects that were led with autonomy to help folks understand what this really means in practice, because I am sure that over the course of your career, you've seen it done the other way, right? Where teams were not autonomous or not given. that level of autonomy and empowerment to go out and do things themselves. So could you share a specific story? I can give an example and I can go back to the same area we were talking before, the area of the shopping cart.
So, one example from... I imagine this was already last year, so the timing flows quite fast, but... I remember that we, as an organization, we were struggling with one area which is a POS point of sight with this part. This part was not being differentiated as we wanted to be. And this was... causing us to lose the new deals of it. As in prospects, we're not signing as much as we wanted. And so it's part of what we can call it rallying cry or we can even call it objective or one of the company.
business goals was let's make POS great again. Of course there was two metrics to help everyone understand what this means. But there was no saying, you need now to go and do this, you need now to go and do this and you need now to go and do this. The different teams then were empowered to make their own choices.
And one of the examples from the shopping cart team was that we understood that the checkout process was too long. It was taking quite a long time. And the team invested... a lot of effort on reducing this time and taking this by making some steps more early as intuitive for the user and actually even removing some other steps and i think i'm not mistaken in terms of data remove the average
from one minute and 20 seconds to some like 30 seconds. And in terms of the customer satisfaction, the customer satisfaction grew by 30% in the industry. From a business perspective, this was perfect. This was amazing. This was what we want. But there was no top-down saying, now go and build this feature. The team was empowered to decide for this specific part of the product what do we need. I usually end up saying, which is when you treat people like adults.
they behave like it off. And if you're hiring smart people, give them direction and give them guardrails, but let them make decisions for that part. If you're just hiring smart people and telling them what to do, they won't just... be frustrated then because they will just be robots and no one wants to be a robot, right?
Yeah, of course. And finding that balance is tough. It sounds like what NewStore does is there's sort of this high-level objective, something to the effect of make POS great again, with some supporting metrics, but no direction on... what projects or tasks or features should be delivered against in order to improve the metrics. Am I understanding that right? That's done on team level and not on company level.
Of course, there are situations where it requires several teams, but there's always one team that is the... driver or the initiator of this and then there's required collaboration and then we get this done collaboratively between two or three different teams if you need. I always like to ask folks about the highest performing team that they've ever been on because I find that
Every person I speak to, even outside these interviews, has a single point of reference for that one team that sort of set the standard in their mind for what great looks like. And so when I talk about this.
What is that team for you and what was that experience? What sets a high-performing team apart is a team that can iterate very, very quickly and can make... their choices and understand their system well and can iterate based one on the customer feedback and two on the analytics that we're getting from the customer users and three
on the system itself and how the system is behaving and where are the bottlenecks that we need to fix. The team that can do this constantly and by constantly I mean every day.
all the time is a can be a very very high performing team in order to get here there's a lot of things required but the team that can do this is uh in my perspective is a high performing team The first time in my career that I saw something of this sort was in my previous job at Equal Expert and ever since then that helped me.
guide my thought process around what is an effective team and how to build an effective team. The practices I mentioned before contribute a lot. The practices around pair programming, around test-driven development. taking this one step further to try and preserve all but then continuous deployment to production of course as long as the tests are green all this ensures that
Committing code and deploying code is like a second thought. You don't need to think if you're going to break anything or not. You are so confident that you can do a deploy at 6pm on Friday because you are confident that it's... Either the tests are green and it's going to production or the test will catch the failure and it won't go to production and you will fix the failure without impacting anyone in production. This is how a high-performing team looks like.
It doesn't matter where people are, if they are remote or if they are in office. I think the impact of that is less. What I think is important is that people are happy and they feel that they have an impact on the day-to-day of the team. And they also... feel that they can make their own choices on where they were by that i mean it's okay to have an office but please enforce people to go there give the option and if the people that want to go there they go and the people that don't want don't go
And when we want to get people together, like we were talking at the beginning, we go get people together and we use the office. But don't force people to do what they don't want to do, because when you do something like that, you will lose the best. Following this and trying to get to this state is what I've tried to do with all the teams I've ever worked with ever since. Was it like that in E-Star when you joined?
No, not at all. It was very, very different from that. One of the things that I've also learned throughout these years is that if you want to transform a king... you really need a critical mouth in the team that understands what good looks like in terms of what you were talking. Because if you don't have a critical mouth understanding this, it's really, really hard to... to do the change in a way that it sticks, that it doesn't just disappear the moment you look the other way.
Of course, you can do that progressively. You can have critical mass in one team, train people, and then start moving people to the second team, and so on, and so forth. If you want to do a transformation like this, and you want to remove 50 or 60% of the organization, you end up destroying the organization.
That's unrealistic, to be honest. Totally. Where do you start? Like what practices or... It's not the customer that is telling us that there are problems in the system. It's not the customer screaming, hey, things are not working. And we say, really? We didn't notice that. So I start by making sure that we really know what's wrong with the system before the customer does.
In order to do this you need to have proper dashboards, you need to have proper instrumentation on the apps you use, you need to have proper monitoring and alarms on the different microservices or whatever you want you are using. Clean your system. Once you have this, you start to understand where the bottlenecks are and you have a better understanding of where the problems are. And this also allows you to, when you do, change.
you can more or less understand where problem second i start bringing people that have a very good understanding of what good looks like in my perspective in terms of quality standards in general things that lead to software that it is easy to change and once we start doing this progressively we can also we will start building a proper
test coverage when you have a proper test coverage around one part you can use it's usually called the strangler pattern and you can isolate one part of the system and start doing changes there and the tests make sure that all the changes you
you are doing as long as the tests are green they are not destroying or they are not packing the rest of the system you start this progressively and if you have a critical mass in the team this critical mass can help coach the rest of the members in the team in order to until you have a proper confidence and you are deploying software production every day you are validating with users every day and then you use this as an example team and you start
spreading these practices and this culture to the team next door and so on and so forth. You mentioned that to drive some of these changes, having a critical mass is your number one thing.
One of the primary tactics for doing so is bringing in people who know what great looks like. Imagine you're not in a situation where you have a direct influence over the hiring piece. How would you approach some of this stuff? If I would not have influence on the hiring process... I would try to lead by example or try to lead by showing what could look like to people around me and to people that happen in funds on how the hiring process would fire.
You try to do that by showing that it works. It's not theoretical. It actually works. You can start influencing the people that can make the decisions and start to be part of the hiring process too. I didn't say something before, but it's important that when you're doing this transformation you were speaking, you are hiring for the transformation you want. You are hiring for the culture you want. You are hiring for the standards you want, not for the standards you have.
because you are changing. And it's important that you are strict, very strict in terms of who you are. Because sometimes you really meet someone fast, but it's tempting to just hire.
first person because oh i need someone it doesn't matter but it's it's damaging it's damaging when you're trying to do a transformation and then you end up hiring the people that are not going to be a change I often find in my own experience that it's harder to identify that you've made a bad hire in a remote context than it is in person because it...
things are less glaring like people can can fly under the radar longer and so i i would just double highlight what you mentioned in an environment where the team is working in a very collaborative fashion where there's programming running all the time In a lot of situations you even have modeling work because there's... certain problem that a group of two people cannot solve or they don't know how to solve or they want to ask feedback from more people and the team just gets together.
this is quite hard to find the reader like here like you said it's way easier when people are working completely separate and just opening pull requests for for others to review it sounds like Pairing, mobbing, working synchronously and collaboratively on code is a really central or fundamental component of the way that your team or teams get work done. And it seems very closely aligned with your personal.
beliefs. What is your team's approach to pairing, mobbing, working synchronously on code together? What is part of the standards and what I encourage is that there is frequent rotation at least twice a week. so that there's not always the same pair working on a specific task. Together with this, I also am very keen on pushing the teams not to...
pre-assigned tasks to people. By that I mean you have tasks to do before they are started to be work and you start putting phrases there on the task just because oh this person knows about this lightning foot.
this phrase here that person knows about that let me put that question no in my prospectus and this is and this is how we work very much when people are free they pick the next thing on the top of to do they don't show us they pick the next thing on the top of to do independently of being a support request or a user story or whatever Doesn't really matter, independent of what area of the code we do. Walk me through the specific...
process by which folks pick the work that they work on. Because I imagine for most teams that don't work the way that you work, this is going to sound extremely foreign and scary to them. So let's get in fine detail.
look like so let's start from the beginning the teams usually have stand-ups every day and we are also very keen that the stand-ups are not as tough as i played The stand-ups are usually used for people to raise blockers, have blockers, and to discuss the things that have been moved to them, completed, and to make sure that those...
Hey, this is moved to Dawn, there's communication with that team, if you can help it with that, something like that. No. to say i did this yesterday i did that yesterday i don't care the board should say what uh what people were doing and in the end i don't care if person a was working on task a or person b was working on task b i really Don't care. What I usually also say is that the minimum unit of ownership should be the team and not an individual person. We own our code as a team.
it's not individual person owning seven parts of the code it's the team the ownership is on the team when there's an incident the ownership is on the team it's not an individual person and we celebrate when we do mistakes and when we do when we When we do good things, we celebrate together. It's not individual. It's important to have per rotation. So I'm going to give the example where certain teams have per rotation sheets, where they say...
Imagine Monday and Tuesday person A is working is pairing with person B and person C is pairing with person D. Wednesday and Thursday person A is pairing with person C and person B is pairing with person D. Something like this. So imagine person A and person B on Malloy. They have nothing to do because they have finished their work on Friday. They start working on the first stuff that is on the to-go list and they bring it to in progress. They work on this.
They get to the end of Tuesday, for some reason they haven't finished this work. One of these people continues with the task and the other leaves and moves to the other pair and the other will. And we want to make sure that there is one person from the original pair that continues in the task and there's one new person coming and rotating so that all the knowledge of the work plan so far is lost.
People finish, they move it to down. And by finish, I mean all tests are run, this is the point of production, it's running in production, it's working properly in production. And I don't mean done, it was sent. to someone else's review i mean dollars is done in production running with real users we have this as part of the definitions of that and then people just pick the next task on the top of today
For this to work well, you just need to ensure that your to-do list is updated and ordered by priority. Who manages the to-do list? The team. Of course, usually the manager, the engineering manager and the product manager and the UX designer, I usually say they have kind of the first level of priority, but the priority is decided by the team as a whole.
Certain teams do sessions once a week to guarantee that this is up to date. But for very mature teams, they do this every day. For example, they can do this every day. Right after the end of the stand-up, just a few minutes, okay, this is out of date. It's not, oh, I think this one is more important because this customer is screaming or something is happening. So let's move it to the DAW. So I'll kind of get a team test. And they'll do that publicly during stand-up.
yes and the and the board is uh is uh open or imagine during the day oh there is this fire happening we really we really need to move this to the top of to do i'm going to do this and i and what do you think something like we will work this like i said people are are adults they are not children they want the best of them for the product we're not playing around so you trust them they will they'll come back and do
We're better than what you expect at first. Yeah, I mean, I totally agree. And obviously you've gotten your team set up in a way that they're operating. Very effectively. I want to repeat back some of the stuff that I heard to make sure I understand it right. So your teams, they'll have a daily standup that's centered around identifying blockers, not focused on status updates, right? Because as you said, that's not something you specifically care about.
does work in pairs. The pairs switch at least twice a week when... assigning work. There is no process for assigning work, right? There's a process for managing the priorities in the to-do list. And as folks finish their tasks deployed to production with live users, they just grab the next thing on the list.
And that just happens continuously. And pairs rotate in and out, independent of whether or not an individual piece of work is done. It just happens as it happens. Am I understanding all of that? All of that, right? Exactly. This requires a level of ownership and a level of maturity, but it works quite well. Everyone can work on everything. It ensures that if there's work on backend, anyone can do it. If they're working for them, anyone can do it. It doesn't matter.
And of course, there's people with more expertise than others in certain areas, but hey, this is a key. If you need help, speak up. No one will blame you because you need help. No one here is an expert on everything. So we need help with this pickup. When you started at Newstore, was everybody also remote and distributed in the way that they are today? No, when I started, this was a few months before COVID, and everyone was in the office.
when COVID hit people were forced to work from home as you remember. I had some experience in remote work because it was remote first and so I ended up helping and guiding the engineers and beyond that on best practices to work remote. What are some of the best practices that come to mind to you that you feel like every remote team should absolutely consider?
A lot of these practices, they don't just apply to remote work, but I think they take remote work itself to the next level. One is make the work visible.
Make sure that there is no invisible war. So everything that the team is doing is part of the team support. Because if you don't see something, you cannot... manage it you cannot understand if there's bottlenecks you cannot understand if there's problems if person b has been working on the same thing for two weeks and they are just working but it's not part of the board how can you make sure
that doesn't happen or how can you make sure that other people are available to to help so one is make work visible two is make sure that
where programming is in place because that helps a lot I think also with remote worlds. And then there's a few things that are very small things that I believe are... quite helpful in the in a remote environment one is make sure that the person has their face on on all the tools we use example slack it's very funny when people have some Bart Simpson or some other character on the instead of the picture but if you never saw someone
This is quite hard. You need to remember that person A is Bart Simpson and person B is Darth Vader or whatever. That becomes a mess in a remote environment. So make sure that people have their face in Slack, in... in Confluence, in Jira, whatever. Also, make sure that people really manage their calendar properly. If there's a meeting schedule, respond to it. It's okay to say no, but respond to it. Just don't leave it.
Nothing. And if you're going out on holidays or you're out sick or something, make sure that your status is updated on Slack saying that you're out from holidays up to day X and you're... and your calendar is also out of office and the same for your email. Just make sure that no one is looking for you and they know that you're out. It's not the...
You cannot be out. It's just important so that people know what to expect. These very small things make sure that remote work works well. And then there are other more... high level things example when we when we have meetings if there's a person that is working remotely likes to make sure that we all hacked as if
all are remote example there's five people in the room and one or two went home let's all just open our laptops and make a call like as if everyone is at home because if not the two people that are remote will have a terrible experience Right. And when you're ringing video calls, turn your camera on. Make sure that your camera is on and not just off. It makes it a lot easier to communicate when you see video. the other person's face. So all these simple facts go a long way to make Reynolds work.
that's what the show is all about. So I appreciate you, you abiding on it. And a lot of what you said is stuff I've heard from a handful of others. And so it sort of reinforces this, this message that doing the simple things to keep information flowing.
Between people, you know, we talk about it at Tupelo is keeping the garage, working with the garage door open so that everybody is aware of what everybody else is doing, where people are, what they're up to makes makes a huge difference. And that. any barrier between having a personal human connection, for example, having an emoji or...
fake avatar as your face in Slack or any of the other tools or not having your webcam on should be removed, right? Like you need to do the things to establish more of a human connection when you aren't working together face-to-face. You were speaking about Tuple. I see examples every day. Imagine an engineer arrives early and he just says, oh, I'm in Tuple room X. When you come, just join me there.
I'll be there starting this part. When you start working, just join me here. So people have these public rooms and never anyone can join. So this works really, really well. Thank you, Carlos. I really appreciate you spending your time with us and being generous with your insights. If folks would like to connect with you personally or learn more about NewStore, where should they go? They can find me on LinkedIn, but I also have a sub site.
called talesofengineeringleadership.substack.com, so people also can help me there. I wrote a few posts about some of the things we spoke here, about remote work, about high-performing engineering practices, and so on. Very good. Well, thank you again, Carlos. Appreciate you being here. You too. 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.