#3 - Managing and building culture remotely with Edgar Muentes

About the guest

Edgar Muentes, Senior Engineering Lead at AMEX Digital Acquisitions

Edgar has been a Software Engineer and Tech Lead at several Fortune 500 companies. He's also been involved in different meetup around NYC area, volunteering groups and tech communities.

Checkout Edgar's latest project Camp Yampire, one of the TimeOut NY top things to do in NYC. It's been gaining popularity especially in the times of COVID, giving people an outlet to hang out, learn new things and just have fun over zoom.

Notes

We're discussing how to assess the culture when you're just joining a new team. Edgar's advice is to ask all the stupid questions in the first few months.

Find deeper questions as you get to know the people, and what their roles are. Get a sense of how people think about their teams. Do they use a specific language that excludes the partners like product or DevOps, creating them vs us mentality? Do people understand what they're working on and if there is a culture of accountability.

There is some good advice in the book "The first 90 days" book:

  • What are the strengths and weaknesses of our strategy?
  • What are the biggest challenges and opportunities we have on the team?
  • What resources can we leverage more effectively?
  • How can we improve the process?
  • What should be my priority as a manager?

Some indicators Edgar uses to think about culture:

  • Have goals, and not just worry about promotions as their goal. Teams are driven by making a bigger impact have healthier cultures than those who only work on projects that will get them promoted. You still want to know what the expectations are and work on your career growth, but it shouldn't be the culture of checking the boxes and avoiding everything else.
  • Individuals should be open to a positive change and have aspirations.
  • Know the expectations from the team, the manager, and the organization.

To keep your culture healthy while working remotely in the COVID times, Edgar recommends using video calls to your advantage. Schedule time to be silly since we don't have the luxury of bumping into each other for a casual chat and ideate on the whiteboard. For example, Google Earth trips to museums around the world or pair programming.

As a manager, you want to be vulnerable and admit you're making plenty of mistakes to let your team know it's ok to not know everything. And being remote made it easier for people to reach out for help 1:1. One person may be better at solving specific problems just because they've faced similar problems before. Think of it as components or puzzles of problems that you solve over time and it makes it easier to solve similar problems in the future.

Also, don't forget to schedule a time to discuss the problem statement before people start solving it. It's important for everyone to understand the bigger picture. This creates another problem, meeting overload. And we all have a meeting/zoom fatigue.

Some other ideas we discussed were

- Having a running zoom call with no agenda.

- Having lunch together over zoom.

- Do 2-minute team call to wish a happy birthday.

- Ship some fun t-shirts to people.

- Organize the team's internal hackathons.

- Gift lootcrate boxes for birthdays.

- Create virtual birthday cards.

Invest in the documentation. You can't just lean over and ask for stuff. It's also should be easy to find. So discoverability is important too.

Resources we mentioned in our conversation:

Transcript

John 0:13

Welcome to pragmatically podcast, your hosts are Alex Bachuk and John Masse. We have conversations with folks throughout the tech industry to get real world perspective on how people make things happen for their careers and businesses, check out PragmaticLead.com for more content just like this.

Alex 0:36

Alright, so Edgar, do you want to introduce yourself?

Edgar 0:40

Hi, guys. My name is Edgar Muentes. I'm currently a front end / full stack. We're all full stack, whether we like it or not. Server side rendering. I'm front end though. I'm a web developer and a senior software engineer at American Express.

Alex 1:00

All right. So and you're doing some leadership work, you're a tech lead?

Edgar 1:04

Yeah, I have led a handful of teams, varying from like a couple of devs. With like a focus problem, starting and finishing it and then dissolving the team to leading large main core, they called core business products and things like that.

Alex 1:20

So Edgar, myself and john are going way back. And we worked together at Priceline for a couple of years. So we've known each other for multiple years. And we know Edgar as an awesome, great engineer, and also awesome, fun guy to hang out with. So today, we're gonna talk about culture. We're going to talk about how to lead teams remotely. So yeah, so we want to get some advice from you, Edgar.

Edgar 1:47

Yeah, it'd be a pleasure. I love spending time with y'all, I love working on projects with y'all. I have a lot of respect for your engineering capability. And your interest in people. I've always appreciated that you not only take an interest in your team is like human beings, you know, wondering about how their days are going and thinking about how to make work enjoyable for them. But also trying to solve that in a way that provides engineering benefit. Yeah, it's a complex balance to have. And I've always appreciated both of your approaches to it.

Alex 2:18

Yeah, for sure. I'm going through something like this right now. And I'm interested for myself to learn from you for myself. So when you join a new team, what are you looking for in the culture? How do you assess the culture of the team? How do you know like, what your goals are, what your expectations are, as an individual contributor, or a lead on the team? Like, how do you know if the team culture is healthy and good?

Edgar 2:48

I got some excellent advice from fellow excellent engineers and excellent friends, that you both know, Mike Gertrudes he once told me that your first day when you're first starting, is the perfect time to ask all of the stupid questions. Anything that might come off as rude, or inconsiderate or whatever, like, "do we like this guy?" Whatever thing you might be thinking of. I sense intention has their attention. You know, like later on in your career. Questions like that can seem like you're taking sides, kind of putting, you're pitting yourself against whoever you're asking about, as opposed to the actual innocuous question that it is like, I genuinely don't know if there's some sort of an issue. From a past event, maybe we have communication issues that we can resolve. But at this time, people are more frustrated than they are like, at the stage where they want to find a solution. So when you're new to a team, that's the, it's like having a superpower. You can ask anything, and you can just say, hey, it's my first day, hey, it's my first week, hey, I literally just got here. And that's the first time you've ever heard of that. And you just become like a super Mario after taking a star. He's just gonna become invincible for a little while and can kind of get a feel. So I highly encourage anybody who is starting on a new team to ask all the questions and don't be embarrassed and don't worry about looking like you don't know what you're talking about. Because there are likely gaps in interpersonal relationship issues in technical limitations. So things that you know, from years of experience are definitely 100% doable, that they say are not because they are ignorant, and don't know that it's possible, but because they perceive it as like a blocker within the organization of the culture of the company. Either that there's another team that does that. So don't take responsibility for things you can avoid taking responsibility for, you know, like, you can learn a lot from asking these questions beyond the answer to your question. If the answer to that question is this doable when you know it's doable? The answer is no. You can ask further deeper questions to find out if it's a culture thing, if it's a corporate structure thing or if it's this person's opinion and gain multiple directions of insight to build a basis for your opinion about how things are going without directly calling people out, or saying that things are bad or negative and things like that.

John 5:10

So if I'm coming into a team for the first time, or if this is my first time ever hearing this advice, what types of questions should I start thinking about?

Edgar 5:19

I would say, the first thing that we should do is I was a recruiter for a while at Robert, half technology. And my job was to understand the team structure so that I could effectively share the list of engineers that I had, that we're looking for jobs, and kind of build them into the shape that their company needed. So as I'm interviewing people to get them new jobs elsewhere, I can understand what the company that they're leaving will need me to replace. And in the same way, I approach joining a new team, I asked the people that I work with, who are the people that are around you? So do you feel like you rely on are there necessary parts of your day, their requirements, so I understand what each rule requirements are in terms of the people that they're connected to. And as I flesh out the structure of the team, and the order of operations that they have to follow in order to get things to production, I can begin to find deeper questions. So basically, another excellent coworker that we both work with Steven Fereira may call it a data-driven approach to finding the questions that you need to ask. So rather than suggesting questions directly, what I suggest is finding out who the people are, what their roles are, and filling in the blanks in between, like, why do we need that? And should we be taking more responsibility, things like that, just find your questions within the structure. And if you prefer, I could also give some, some specific questions, if that helps.

John 6:44

Yeah, what would be some examples?

Edgar 6:46

So usually, I say, "who you report to?", "who's on your team?". That says a lot about who. So for example, we have platform teams whose job is to understand what other people's problems are, and help to build a solution that solves multiple people's problems. So that we don't have to think about and kind of abstract problems away from the team and build them into small reusable parts, whether that's libraries of code or processes that we need to follow and standardize and have Everyone follow that we all gain the maximum benefit across the different approaches that we have for doing the same things. So when you ask someone who's on their team, and they exclude the platform team, you know, what does that mean? You know, these, they should be talking to them daily. And maybe if they have, every time they have a problem, they should be escalating it somehow, they should be considering the platform to a part of their team, even if they're not directly delivering on their releases, they're making it possible for their releases to be smoother. And they should be working persistently on that, right. But maybe that's not how everybody feels. So if you ask who's on your team, and they say two people, and you, you start to get a lay of the land, and you realize that a bunch of people were with these people, maybe they're thinking of product as being their opposition instead of their partners in delivering things to production. Who's on your team? is a good starter question. Who do you report to? This is an excellent question for everybody. And what are you working on? is a vitally important question. And the folks who don't have an answer to that, if you see consistently from team member to team member that they don't know what they're working on, or that they can only describe the kind of passively like, "stuff for testing", you know, but they don't have any specific answers. That might not be that they're not working on something specific, but that they don't understand the business value of it. And it kind of helps you to say, Okay, I want to maybe work on some ownership with so and so you know, or maybe they have the ownership, but they don't think I'll understand, you know, so I want to work on perception about me so that they feel like I'm going to understand what they have to say or that I care. I joined a team recently, not too long ago. And the team member said, Hey, I just wanted to let you know, I won't bother you. And I said, Why do you think that you're going to bother me, we're just now talking for the first time about being on the team together. He said, that's what we've been told is, you know, if you have a problem, figure it out, your league shouldn't have to carry the weight of every single person dangling from their arms, you know, all day long, in addition to their other responsibilities. And I said, if everyone is communicating to me all the time, it's a very lightweight, I get little nibbles here and there. But if you wait until you have a massive problem, and two other people have a massive problem, and they've waited until it became a huge problem. Now I have three huge problems hanging around my neck. But if we're talking all the time, I can understand how you're approaching problems. And we can work together to improve my perception of what you're delivering. And we can work for the individual team members to see what I value and what I'm expecting to see from them so that we're persistently in alignment.

John 9:45

Yeah, so based on those questions, I got three big buckets that you're exploring. First is I really like the ask who is on your team and look for exclusions. And that helps understand how teams or at least the team you're working with sees their place in the organization and engagements. Another place I see that pop up is when people use them versus we, or them versus us or us. It's the exclusion of self from the other folks that they think differently than I do, or they work differently than I do. Therefore, we're not the same. And we're not actually a team, which I think speaks volumes for the larger culture that circles around the people that you're influencing. Especially how you tied it into how well do your engineers or your staff understand the objectives of what you're trying to accomplish? Asking questions around that topic, specifically. And a third is sounded like accountability, right? Oh, more like establishing pipelines of communication to make sure that you're getting the feedback that you need, or that you understand like understanding how open our engineers or your reports are to talking to you directly about things.

Edgar 11:08

Yeah, to that third point, I think it's vitally important to have data to make our decisions on. And I can't always sit down and draw myself a picture of everything, just from my imagination. Imagine waking up from a dream, and trying to describe it to someone an hour later, just because it happened. And just because you were there and you experienced, it doesn't mean that you're going to have the full clear picture, right? In order for me to, I would say the third item is more about creating the expectation, like setting the expectation in the standard within the team, that we should be providing data continuously. Just open your eyes when you need them, or just use your feet to walk around. And sometimes your hands, you're always using the things for the appropriate reason, and you need to establish what the reason for communication is. The reason for communication within a team is to persistently have a source of data to help understand where the team needs to grow. Or you need to take responsibility for that where you need to assign to the team, like the challenge the team to take responsibility themselves, where you need to work on perception. So something that I was talking about with the team in terms of accountability, I think more to your second bullet point, which was us versus them. What are our responsibilities? So if someone comes to your desk, and they say, you know, the room is not warm enough, we need to make the room warmer, I have a ticket, I talked with marketing and talk with design, we're going to set a fire in the living room. The room is going to be warmer and you say, Okay, well, I have some feedback, you know, I'm going to tell you the problem, and I'm going to give put the onus on you to give me a solution, you know, meet up with marketing meet up with the design, it's going to burn the rug, Okay, I'm gonna put marketing and design they want to elevate the plane off the ground. So they've designed this thing that goes underneath, it needs to go both of those points of your tickets, the complexity of your task is increasing, you have another problem, you put it on their plate, you say, The room is filling with smoke, we're gonna die. Okay, crack a window, now you have your the complexity of your ticket is increased three times because you keep putting the onus on the other side. So you say, they made it really complicated. They added this thing underneath the fire, they added this window that he used to not open it to build a new window that opens, they are blowing this out of proportion, you should be taking responsibility for that he should say in the beginning of fire in the living room, there are many ways to achieve the business goal of warming the room, I propose, I take responsibility. And I want to say that from my experience as an engineer, I think that this would be a good idea, let's get an electric heater, there's an NPM module for an electric heater, it's a three-point ticket, I don't need to do any of the code writing, we don't need to internalize it or create an open-source tool for it or something like that. Like, I don't have to have an external team approved a PRs weekend, repeat the success across multiple teams. And even if I wanted to do that, we could do that at a later time. How do you feel about my proposal, as opposed to continuously putting the responsibility on someone else and being disappointed when they're not understanding what your concerns are? Because you didn't communicate? You know, that works on the product side and on the engineering side that if we spend less time telling other people problems and spend more time telling other people what we think the solutions are, we're going to get it wrong for sure. But we're going to get better and better and better and get closer and closer and closer to getting it right.

Alex 14:29

Yeah, I really like the recommendation and like when you start, just use that time window, it's a pretty narrow window. use that time to ask stupid questions. And I can recommend one book which was recommended to me by Mike Gertrudes, "The first 90 days", read the book, pretty awesome book and it doesn't have to be only in that narrow window when you start. Just use those questions all the time because it's Never never, stupid idea to ask stupid questions. And I have like five, five questions I do out of that book, relate to what you recommended. What is the strength and weakness of our strategy? Do people know what they actually working on? So that relates to what you said? What are the biggest challenges and opportunities that we have on the team? Long term and midterm? And what resources can we leverage more effectively? What's available? What we are overlooking as a team? How can we improve the process or the way we work together? People have those ideas, and it's like, the perfect time to start asking those questions. If you're a tech lead or manager, just ask what should be my priority as a new manager on a team? That would expose what they expect from the manager. And that will give you a sense of what the challenges are? so highly recommend the book and it echoes what you said before.

Edgar 16:04

I grew up in Texas, so I use a lot. A lot of funky analogies, like burning the living room down. It's not as polished as what it sounds like the book is advicing so definitely check out that book

Alex 16:16

Check out the book. But stories, stories are better and don't down your living room.

Edgar 16:23

Yes.

Alex 16:25

Use NPM modules for electric heaters? It's easier.

Edgar 16:29

Yes. I'm not an electrical engineer. I'm a software engineer. And so I don't mind using the electric heater module. Rather than building my own.

Alex 16:41

Yeah. It's a good first step to assess the culture. But look, in your opinion, what makes a good culture? How do you know when you join a new team, that the culture needs work. needs improvement? How do you if it's perfect, "I like the culture", what's your definition of a good culture?

Edgar 16:59

I think it's important for any culture to have goals. If you notice that people don't have an aspiration if people want to be promoted, I had a team member who was saying that, you know, you know, what do I have to do to be promoted around here and X, Y, and Z and things like that? I think that's kind of the wrong approach. I think the people that I have seen, in my experience, from company to company across companies, people who are promoted aren't the people who are like, did I check all your boxes? Do those people get promoted? Sure. But I've seen what I expect to see in a good culture, is people saying I want to make positive change. You know, those are the people that I want, like, if I'm in the trenches, and I'm having a difficult time, I don't want to be around the guy who's like, oh, is this helping you to give me a promotion? It isn't? Oh, well, then I'll talk to you later. I want to be surrounded by the people who are like, I care about, they don't have to say, oh, credit. That's a great idea. You know, we should have people who are deeply in debt, get 17 more credit cards, you know, that's not what I'm talking about. What I'm talking about is in my domain of expertise as a software engineer, as a UI developer, or API, you know, provider, how can I make the ergonomics of this more comfortable for my users, if people are thinking like that, and they're being held accountable to that they're not having people come to their desk and complain that they didn't do it in five minutes. They're hearing them say, if we spend a little bit more time we can do this right. And they're happy to provide that to our users, rather than meeting their deadline.

John 18:35

I was thinking about what you said, I really like how you phrased it, the people that are getting promoted aren't the ones checking the boxes. But there's a position that we put ourselves in, within each company and the ask for a promotion, or that most that putting that pressure on the manager that demand or so like, my expectation is that you will promote me in versus the how can I? How can I be of service to my team and to the company? says a lot, I think it sounds like to the character of the individual. One is a very selfish perspective, thinking of personal growth, which obviously is is important. But it's from the position of I do this thing, or if when I put this in, I expected that get this back, versus the opposite is I'm just going to continue to put in and hope for the best.

Edgar 19:27

Yeah, I think folks should definitely take responsibility for their career growth. And they should be asking those questions like, if you don't understand if you don't have the data to shape your action, so that they can be reflected the way that you intended them to, right. If you're a surgeon, and you perform life-saving heart replacements, like 10 times a week. And somebody says, what do you do and you say, I cut people, you know, they might be scared of you, you know, they might not want to put you in front of a promotion panel. And like vouch for you because you cut people, you're phrasing the way that you if you don't understand from your manager, what the expectations are, I just want to clarify that I'm not saying that going for a promotion is bad for the culture or something like that, you should be aware of what the expectations are. And you should hold yourself accountable to not only delivering on that, which you're probably doing now but clarifying that you're delivering on those expectations, by understanding what they are. And knowing when somebody asks you, you're grabbing a cup of coffee, and your manager asks you, Hey, I was thinking about promotions are coming up, have you worked on anything that shows your leadership and you literally don't know, that's too late, you should be thinking about that in advance. And your manager should be helping you to like shape, that data, like understanding how what you're doing is positively impacting the company. And that was one of the great things about working at Priceline, we had Steven Daimler on our team. And Steven spent a lot of time gathering data to say, it's important to me, for you to know that our users have been significantly positively impacted by the work you did this week, great job team. I'm not just saying a great job, and giving out high fives, I had data to back it up. And you should be taking that responsibility yourself. So just to clarify, I'm not saying that wanting to be promoted and put in the work to be promoted is bad. What I'm saying is that having a culture where you care about things being well, just creates a more fertile ground to build more on to, if everybody feels like their job is frustrating, and things like that, that's understandable Work is work. But it's different to be like frustrated by work than it is to have like a culture that just kind of beats you down for trying to do your best, so a culture where people encourage you for trying to find what is good about what you do, and find the best way to approach a problem. And that helps you to grow in your engineering capability. And that's the kind of culture that I want. So for example, I remember we had a team member who had just started. And the first thing he did was put in a pull request to remove a bunch of dependencies that we didn't need, they were like one liners that were NPM installing, and he significantly positively impacted our deploying time for testing for going to E3, everything was a lot quicker. We had a lot less situations where we got something flagged as a new dependency, and we're not going to allow you to deploy it to any environment, just because we haven't checked yet, not because there's a problem with it. But because we need time to validate that there's not a security risk here or something like that, right. But nothing had changed. Really, maybe it was like documentation or whatever it was we we saw the way sometimes, like 24 hours, and we're trying to test for deploy in any way. But package.lock takes care of that now. But at the time, we weren't using it.

Alex 22:43

So you're saying is you're looking for a goal or vision-driven culture, rather than a promotion-driven culture.

Edgar 22:55

Any goals, basically, I mean, it doesn't have to be like corporate goals, it can be like personal goals for professional development. As a manager, at least, if you don't have a path that your team wants to go down, it's hard to lead them there. You have where you want things to go, obviously, you have where your company wants things to go. But if you're not helping your individuals get to where they want to go, then they might be going to another company, you know, they might be going to another team. And a culture of goals. a culture of aspirations is a culture with lots of opportunities to create positive change and to give people a roadmap for how to get there. We're not all genies or anything like that, we're not always going to have the answers. But if people are open and willing to work with you, to get there, like I was saying before, the person that says, That doesn't sound like it's gonna give me a promotion. So even though you're my manager, and even though you want to touch base on this, and you want what's best for me and the team, I'm not going to interact with you, because I don't perceive it as an opportunity for me to immediately get a promotion or something like that, you know, basically, promotions aside, the idea that people are not open to positive change, the idea that people don't have aspirations and things like that, that's very detrimental to any team's culture.

Alex 24:15

It's almost like promotion should be a side effect of all the positive impact and all the things that we do. So promotions are just recognition for what you've done and all the impact that you've created through the code or software or whatever interactions you have.

Edgar 24:33

And I find that very interesting to what you said, a lot of teams feel that the work that they do, isn't curing a disease or something like that, they'll never be recognized for the work that they're doing. And I don't believe that that's true. Maybe the culture has some blockers to that. But what we need to work on is fixing that if that's a reality, not dismissing a "BAU" - business as usual work. Maintaining the Business is highly valuable it was Michael Jackson, from React training fame, who had said that we shouldn't refer to legacy code as legacy code, we should refer to it as revenue code. It's the code that keeps all of our paychecks coming. It's the code that keeps the lights on. Everybody's contributions have value. And as a team, we should be working especially like as managers, we should be working to understand, just like I was saying, each individual should understand what their manager is expecting from them. We should be understanding what the organization expects from our team, and helping to show the leadership in the work that they do helping to show the innovation, the technical capability, and things like that, even a BAU.

Alex 25:47

Yep. So now that we all working remotely. And it's important to keep the culture, maintain the culture and also the communication, keep everything going. How do you do that? How do you maintain that, while working remotely?

Edgar 26:03

I think it's definitely been a significant change. I work with a team in cross teams. Inside of Amex. We volunteer two hours a week to curriculum development for code nation, a nonprofit that teaches students from under-resourced high schools, software engineering, and connects them with the folks at these companies. They actually, before the pandemic, we had a classroom of 24 students that would come into the office, we provide them pizza, and we would rotate out instructors, with people that we had sourced as volunteers, we have 30 folks that we would rotate out as volunteers to teach the class, a core team of four engineers. And when we ran into some issues with their laptops, running slow and things like that, right before the pandemic, we sat down and reimage all of their machines to be Linux machines. So they have zoom and VS code working from an image that we installed on all their laptops, just in time. As soon as we went remote, it was the only reason we were able to continue teaching these students. We had already been in the habit of collaborating remotely on these things. We would spend an hour during the workweek, wherever we were on whatever floor we were at with whatever project or team we were working on, we would just get on a WebEx also, we were lucky, we had a lot of practice beforehand. Basically, something that I've run into now running intern programs and teaching these classes is that you have to schedule a time to be silly, you have to schedule a time to ideate on a whiteboard, you can't run into each other anymore, and just happen to talk about a problem. So what I've been doing is one thing, I've been making sure that the team has fun together, I do Google Earth trips to museums around the world, I take my team, I open it up to the entire company, message it on the big channels, and we just walk around the museum people can chime in and talk. They laugh together with a reference at later and meetings. Another thing that we do is we have technical discussions in small groups, we either have like one on one pair programming now, which we definitely did not often do in person talking out loud or desk right next to someone else who's trying to work and doesn't have an interest in that. We have the opportunity now to have these isolated moments where we can schedule time to pair program for a half-hour or an hour on something and leave them to continue completing it or schedule some more time to work together on it. So pair programming is definitely increased significantly since we went remote.

John 28:37

So pair programming. How do you think being remote has had a positive effect? Do you think with more engagement in pair programming?

Edgar 28:48

Yeah, I think pair programming was awkward before because you're in a room and other people and you can't admit when you don't know things. You don't want to be the person who created he did the spike. You're the one who figured out how we're supposed to implement something. And there are things that you're running into, you're running into, you're hitting the wall now, and you don't know what the issue is. A lot of people, especially people who are hoping to get promoted or like more junior people on the team, for whatever reason, they think that it would be a little embarrassing to publicly be repeatedly having problems and to look like you're unable to overcome them publicly. So I like to start off our meetings, especially like pair programming meetings with I make plenty of mistakes, you know, I let them know, I've made enough mistakes to know that this, you know, rather than saying you're doing it wrong, rather than saying this is the right way. I like to state things in such that they clarify that. I know what the right answer is because I've gotten it wrong plenty of times, you know, and I just kind of set the tone that way. And so we're both able to get to a point where they feel comfortable making mistakes and talking through problems and things like that. And it helps me as their manager to understand where I can help to guide them. things. So I think that isolation has improved people's willingness to be open and honest.

John 30:07

That's really interesting. I suspect that's super common. You see people talk about imposter syndrome. Or you might get anxiety in public speaking or trying to share their ideas. Because there's that fear there that will somehow be invalidated by our peers.

Edgar 30:26

I agree. One thing that I find interesting about the imposter syndrome concept like people see me solve a problem. And they say, Oh, I never would have gotten that or something like that.. And usually, I try to, like nip that in the butt, like immediately, something we were talking about earlier, problems are composed of components. After years of running into different problems, you start to see components of problems that you've seen before and the problems that you've never seen before. It could be a misunderstanding, it could be a perception of something as a blocker, when you can come to the same outcome without doing whatever you think you need to do that you just physically can't, for whatever reason, and, asking the questions that you need to ask yourself to figure out which things are real blockers and which ones you can kind of issue. It's easier to have those conversations about what you don't know in isolated situations, pair programming or debugging, and things like that on zoom calls.

John 31:27

For me, it sounds like while it might bring, like blanket comfort when you go to bed at night, you put the blanket over you, you feel safe from the boogeyman. It's unlikely addressing the problem that someone can break into your house.

Edgar 31:45

Right, yeah. Yes, that's a real blocker. Get some bars at that boogie man's out there.

John 31:56

I wanted to go back to something else. You said Edgar, I thought was interesting was when you have to schedule everything now. And we can't rely on being some of us, maybe we can, because some folks are actually back at their office for those of us that aren't. And for those of us that actually will never be back at the office. If I could draw a parallel to the question I'm trying to ask is there was an interior designer that was designing offices, and I forgot what their name is, I'm gonna butcher the story. But when they designed it, they put the bathrooms on opposite sides. So they forced traffic. And people have to actually cross the entire office to get to the opposite side to get to the side of the restroom or some kind of facility, or they would put kitchens on either side of the office to get people to actually physically walk by each other. And they saw that that had some positive effect on the culture of the office. When you say now we have to schedule everything that kind of story popped into my head. So if I, what are the like probably like the three things that are new I would want to consider scheduling time for? I think you said, fun, right?

Edgar 33:03

It is zero dollars, which used to be a big-budget problem. They can have fun, but it better not cost me anything. They can have fun, but you're paying out of pocket. They deserve it, but I just don't have the money in the budget for it. So that's not a problem anymore. So you have fun. The second thing I would say is casual conversations where you run into a problem and you now need to talk about it, where you might just like, be visibly having an issue at your desk and someone could jump in and be like, Hey, buddy, can I help out scheduling time for the team to meet about things as the manager? Like it's nice if the team self organizes. But I've encouraged knowledge here a lot more. So I've scheduled time for people to describe the problem statement. A lot of times they don't have an answer for what the problem statement is. They just know what they're supposed to be doing. But the problem if the problem could be solved in a different way, we haven't discussed it. So scheduling time to make sure that the team understands so like problem domain and is approaching it from how do we get the desired outcome rather than how do we do what I was asked to do? So I try to schedule a time for that kind of ideation, like the pre-coding ideation. I don't know the top three definitely fun, definitely ideation. But it's hard because you want to avoid meetings in general. You don't want them to be too long.

John 34:28

People get that meeting fatigue. Almost does now we spend all our time in meetings we lose the impromptu or the benefits of impromptu conversation.

Edgar 34:36

Yeah, kind of a minor segue there. I was reading an article recently that if you see people in person and you talk to people or on zoom, you see people on zoom or whatever, you talk to people over these teleconference software's, it feels Okay, you're talking to them you know, but your mind your human body has an experience it's used to when you're done talking to someone they will Walk away, when you're done talking to someone, they physically have to leave the room or, you know, they might still be next to you and not speaking anymore, your conversations over and they're working alongside you. But when you're on a zoom call, and you're in a room full of people, and suddenly that room full of people doesn't exist at the end of the call, there is a part of your brain that rejects that, that says it's not physically possible for a roomful of people to just evaporate. And so the zoom fatigue I have read comes from your body being used to certain aspects of reality, that are known to be like the hard fact of your daily life no longer exists. And it's jarring to not hear people leaving the room and feel that sense that you're there. It has like a significant negative impact on our psychological like emotional experience, as we're going from a meeting, some things I've seen people do, that I've actually done on a couple of non work meetings, is to have kind of like outdoor sounds going. And as people are leaving, you know, they're not outdoors anymore, they're clicking off, but maybe they're going inside, and they were outside, you know, just kind of having like light audio going into the background and things like that, to kind of give it a feel. I haven't gauged anybody's interest in that or measured the outcome. But having read that, I've been thinking about how I can make people feel less of that fatigue as the day goes on. And my meetings, for our volunteer work. And for our like extracurricular activities. I've gotten a lot of positive feedback from people saying that they don't feel like their meetings at all. But at the end of it, they feel positive feelings when they leave, they feel energized when they leave, and they want to do something else. They've said that that wasn't work. I'm leaving this meeting to go do some work. But that doesn't count as work. So I think it's been having a positive impact.

Alex 36:59

On one of the teams, I was part of, we scheduled, probably like twice a week, we scheduled an hour or two-hour running zoom while working. And people can just talk or be quiet. Just like a casual conversation, trying to recreate that office environment where people can talk or be quiet and just talking about whatever. So I was interested in the experiment.

John 37:26

How long did you run that for?

Alex 37:28

A couple of weeks? I think it's still actually still going. Not sure exactly.

Edgar 37:34

You may remember the Priceline window?

John 37:36

Oh, yeah. Between offices? Yeah, we had that. That was there was a television, right. And there was a live feed from both offices from the office in Connecticut in the office in New York. I can kind of see people there.

Alex 37:49

Yeah, something like that.

Edgar 37:53

That's pretty fun. I remember seeing a lot of waves of people I hadn't seen in a long time walking by pretty fun. had not occurred to me, but maybe that'd be a fun thing for our team to do for a little while. I tried to organize lunchtimes. And then everybody eats lunch at the same time. So I wanted to organize like group lunches the team, you serve people lunches, I also have been organizing calls for birthdays and things like that. One of our guys works in the UK. And we call them up and just put the message out to everybody, you know, hop on a call real quick two minutes, saying Happy birthday. Go back to work, just like you would at your desk. So we've been having kind of like guerrilla meetings just popping up out of nowhere, just for fun.

John 38:40

Did you ship cake to everyone?

Edgar 38:44

Yeah, we did not ship cake to everyone this time. Although I did find a drop shipper, we made a shirt. And all they had to do is go to this website. And they can each just pay the shipping for their own shirt. And I went ahead and paid for the team shirt. So I don't know if you're familiar with drop shipping. For anybody listening that doesn't know what that is. We don't have to specify the recipients. each recipient can go and just collect their own item. They'll send to however many addresses. I don't have like received the box at my house and then mail them to everybody else.

John 39:22

You don't have the right you don't have to have your own storage and factory. They just they'll white label it. They'll say it's from Oh, this is from Edgar.

Edgar 39:31

I didn't spring for any sort of Edgar labels in the shirts or anything like that. But yeah. Fun, fun, silly stuff.

John 39:39

So you're something I'm an Alex too. So the fun part when you're scheduling fun. You mentioned Google Earth as a kind of team activity. I'm looking for more ways to spend time with my team to draw engagement to build morale. If you have any ideas that we haven't gone over yet, that you've tried?

Edgar 39:58

One thing that we did, which we Didn't do remotely. But that we did in the past is we organized our own hackathon, we gave our team two days to hack on whatever they wanted to hack on. We organize it internally within our team, I gave them the opportunity to have fun to collaborate with people within our group that they don't normally work on a daily basis with. And they delivered really excellent tools like they brought significant positive business value that they just didn't feel like they could work on during their regular day to day exercises. So I'm looking forward to, we actually just got done with like the all hands entire company hackathon, so we won't be having it anytime soon. But I'm looking forward to scheduling one in the coming months. For our virtual group, I would highly recommend giving that a try. And a lot of fun, I didn't get to hack too much, I had a lot on my hands for organizing it, because the last one was in person. So I think I might be able to join a hack team this time around now that it'll be virtual.

John 40:56

That makes a lot of sense, it gives us an opportunity to use our skills to explore ideas that we might have, also says that it's okay to put things aside for now. And be free to explore something on your own. And that kind of gives us a sense of relief, I suspect as well.

Edgar 41:15

And people seem to have a lot of fun, I think it also helps to improve the perception of like coding, sometimes people, especially in this remote environment, whether they have kids dangling from their arms, or whether they're putting a lot of pressure on themselves, to show that working from home. For a lot of people, this is their first time working from home. And they don't want the perception that it's having a detrimental impact. Maybe they enjoy working from home, and they're hoping that they'll be able to continue it even after things clear up. And they're putting a lot of pressure on themselves to have this be the best code they've written, or at least to not introduce more bugs than they normally would. So we can be under a lot of stress. And so hackathons are an opportunity to look at coding as something fun, a passion and interest, more than just something that you're being held accountable to deliver.

John 42:06

I could share something that I've had some fun doing because our team culture is a lot of the folks on my team, we have similar interests. And I had a personal goal to do more for birthdays or to celebrate the birthdays of the folks on my team. And so I thought Lootcrate would be a fun way to ship something like a box of randomness to someone. And once it arrived during the daily standup they would unbox it and then show everybody what they got. And we've kind of celebrate together loot crates been largely inconsistent.

Alex 42:40

But that's where randomness comes in right? It is a random design.

John 42:46

What's that it's a bummer. What's a bummer is when like you order for a birthday, and it doesn't arrive until they're half birthday.

Edgar 42:53

Yeah, wow. That's a pretty big offset there.

John 43:01

It is. But stuff like that's actually something that that I've tried. It's something like people kind of look forward to, you know, it gives people something to look forward to. And it's also there's a social contract with everyone else that you have to wait and share this with the team.

Edgar 43:18

I love that idea. I've been trying to figure out virtual ways to do stuff like that. My job isn't graphic design or anything like that. But in the past, I've made like little virtual birthday cards and have people we use a website. I forget the name of the website as I'll send it to you all as soon as I remember it. But there's several I'm sure where you can have people sign a birthday card, and the pages are infinite. So they just had signatures from all over the place. I think tribute is one of the website's tribute has kind of an unusual kind of signup process, it kind of looks like you're going to have to pay for a tribute is you don't have to, in order to use it. But tribute is a video one. So we did that for like birthdays and graduations and like in our regular life. And it's another tool that I think would be an excellent one to use for celebrating people at work where they can keep those videos forever. or however long tribute exists. If they don't download them. Yeah, everybody can just send like a video birthday wish to them and they can flip through spend a few minutes flipping through and finding joy from their team.

John 44:35

This is really interesting. It looks like you can create an occasion and then record invite people to share a video.

Edgar 44:44

Yeah, so you might say like Masse's promotion or, you know, Masse's new product launch, you know, thanks for your leadership Masse, thanks to the entire team, whatever, and everybody submitted videos thanking the team and they'll be able to watch and rewatch those videos. have their peers celebrating them as they might have in person? Yeah, and have them for reference in the future.

John 45:06

I think I'm gonna try this, this is a great idea, we did something similar to with the card signing, I think that does have a really nice effect, because it gives everyone an opportunity to kind of share, like positive feedback about how, you know, we affect each other's lives in the workspace.

Edgar 45:23

Yeah, there's something built into Amex, I don't know. It's called the blue rewards. They can be money or non monetary gifts that you can give to your coworkers for helping out. If your company has a program like that, make sure you're flexing that program, you know, flexing that muscle, and taking advantage of the opportunity to celebrate your team with financial little hat tips. And if they don't, perhaps build out a system where you can do just the verbal thing is, if you don't already have one, they also provide that

John 45:58

that's a great tip. So like, explore what your company or your organization might already offer, because some of those things could be not hidden, but not talked about a lot.

Edgar 46:08

For sure. I know, in our case, there are budgets set aside to thank each other significant budgets. So within our team, actually, we've had some people be thanked enough that they were able to buy themselves a very fancy bike. Some people got themselves like GoPros, and things like that with months of people thanking them here and there a little thank yous and things like that you really add up?

Alex 46:32

Yeah, we have, we have a similar thing. at LinkedIn. It's called kudos, I think. There's internal program, the more kudos you earn as a person, you collect points, and you can convert those points into some kind of products. And they have a category catalog of products. There is a budget. But like you said, people forget about that, and neglect it for some time.

Edgar 46:59

Some people are embarrassed to ask. Mine sends me over a kudos, you know, that kind of thing. And I think one of the really, really cool things about a program like that is something that you were going to buy yourself anyway. It just adds significant meaning to it, to be receiving it as a thank you. I was going to buy this for myself whether as like a thank you for my hard work, or is it just a general thing, I just wanted to buy myself, but now it has meaning forever. Maybe two companies later and still, you know, proud of having earned.

John 47:30

That's interesting, that's almost springing a material manifestation of the things you're doing in your career.

Edgar 47:39

Yeah. And, like the general appreciation, like you might have like a shelf where you're like, this is the GoPro of me being good at software engineering. This is the you know, bicycle of me being good at writing documentation and,

Alex 47:52

Or taking that extra step and actually helping people and making a positive impact outside of what my responsibility in JIRA tickets that I had. Some people actually took time and said, Thank you to me and appreciate it what I've done,

Edgar 48:04

I've noticed that the majority of points that I've seen going back and forth to people that report to me and show it, like a list of people receiving and giving and things like that, you actually get notifications. If you haven't thanked someone in a while. It'll say like the last time you think someone was two months ago, things like that. But I've noticed that, typically, it's when we're going out of our way to help other teams. That's usually when I see people thanking each other with blue rewards, I don't see it happen as often within the team. And again, I think it's kind of one of those like BAU things. Sometimes people don't think to thank each other for just keeping the lights on. But it's vitally important. And it's the core of our business. Keep those lights on. So those programs are amazing. And I'm really glad that they exist. And I hope that anybody listening has a program like that at your company. And if not, hopefully, you can be the positive change-maker that helps to be the first one.

Alex 48:58

Yeah, if not, you can always slack somebody and say thank you and appreciate them. Just recognize them. It doesn't have to be a fancy program with GoPros.

Edgar 49:11

100%. I love that. Yeah.

Alex 49:15

All right, cool. So any other tips before we wrap up, I know you have to go. Anything else you would recommend in terms of managing or leading and just working remotely with your team, or just culture in general.

Edgar 49:33

Something that I've escalated significantly since we weren't remotely is documenting everything. Every time we have a problem like a meeting, I have a template. I state the problem statement, I might be fresh to the problem. And I asked enough questions to be able to fill in a problem statement, fill in, like the things that we've tried, fill in what our desired outcome is, because not everybody in the team might know but everyone on the team is most likely capable of contributing. I think it's more essential now that we're remote to empower everyone with enough data to be able to see the opportunity for them to contribute, it's a lot more manual, they're not going to overhear something that's going to click with them, because they're not in the room all the time, or they might not be fully paying attention. Because it's their 38th WebEx or something like that of the day. So we need to make an effort not only to document which is useless if people can't discover it, but to also make it so that people are aware of it. And the team has a standard for where to find these things. So that the discoverability is high. Discoverability and documentation are two vitally important things that now that we're in the pandemic, I found, have a significant positive impact on empowering others to help find opportunities.

Alex 50:49

This change will be beneficial, even if we come back to the office. Documentation is always important to have.

Edgar 50:56

Yeah, people always think they can just, you know, lean over to the person next to them and ask about stuff or whatever. But a lot of times you're in the zone, there's no one around, there's no sound that's going to trigger you to remember, hey, I should talk to somebody else or something like that, you know, you're in isolation. So if there's not a process in place for communicating these things, we're going to have the realization that we have a minute to do so. And we're not going to do it, because it's not going to be on our radar to do it.

John 51:24

That talk the way you describe that sounds like you've heard of asynchronous workflows, are companies thinking asynchronously. Sounds the way you described it is when you go through it, and you document it in such a way that invites for continued collaboration over a period of time, in my opinion, sounds like it, it welcomes that type of work.

Edgar 51:45

Yep. Something that we have that I've been participating in more recently. It's called architecture decision records. So you guys heard of those ADRs? So architecture decision records.

Alex 51:57

Yeah, GitHub posted a blog post couple of weeks ago. About that pretty short, you know, to read Yeah.

Edgar 52:05

Architecture decision record, we own that we're making a decision. And we own that we're making it based on the data that we have. And we update it to own when we realize that we were wrong, or when we realize that there are areas for improvement. And what this does is it gives the team the ability to be wrong and to still execute. It gives the team the ability to communicate, months later why we did that. And rather than perceiving it as a mistake, we can perceive it as the right thing to do with the data that we had. And we're doing a new right thing based on the new data that we have. And persistently give ourselves credit for being the capable engineers that we are, and try to help ourselves fight any organizational built-in imposter syndrome, from those sorts of things. So that just general, anything that we can think of that helps to provide a comfortable known way for us to communicate with each other asynchronously, is going to be vitally important as we go forward in this remote work style.

Alex 53:12

Thank you. It was a great, great conversation. All right. So Edgar, anything else going on any side projects you want to talk about? where people can find you and reach out to you?

Edgar 53:25

I am working on side projects, I would say I don't really I don't necessarily have anything that I want people looking for me for. But I would highly recommend that folks with the engineering capability to empower other people, to have a similar career should reach out to code nation, and should work with them to teach students from under-resourced high schools, to software engineering skills, to get careers in today's challenging, changing environment. They're teaching remotely, so they're going to be well equipped to continue working as engineers in this remote situation that we're in. One other thing that I've been working on that folks might want to know about. Camp Yampire is an international online summer camp for adults. We had 150 activities, our last one, and they range from machine learning class for beginners to just butter cow carving, you know, just get your mind off of whatever the stresses of your week are. And join us for silly activities, artistic activities, professional development activities. We're online on a zoom call for 30 hours over the course of three days. Each Camp Yampire weekend. And our next one is Halloween weekend. So our camping empires on Instagram, Facebook, and it campyampire@gmail.com for anybody who has any questions. We're just doing everything that we can to make to bring joy to folks in public developments of folks who are struggling with this new remote, isolated situation. And we encourage you to do the same. I didn't mention that. We have dozens of volunteers from around the world. So wherever you're listening from, we've had volunteers from Kenya, people join us to follow along in sessions from Serbia. We've got people coming in from all around the world. So if you have anything to contribute at all relying on you to help us to affect positive change all around the world. So whatever it is that you have to bring to the table, it's valuable and we'd like to hear about it.

John 55:35

Awesome. Very cool, Edgar.

Alex 55:37

Alright, thanks.

John 55:39

Thanks for tuning in to the PragmaticLead podcast. If you found this conversation interesting or helpful. We would appreciate your feedback. If you want even more content like what you just heard. Check out pragmaticlead.com. If you have a story to tell, send an email to pragmaticlead@gmail.com and someone will be in touch. Thanks again.