When you just sort of grow up naturally in the culture of, oh, everybody moves for work to go to a specific physical location, and then to switch that to remote, you know, sometimes I am. kind of bored in my office by myself and like, oh, I've done my thing. What do I do now? But I do still wonder, like, is there a trade-off I'm missing that I don't realize I'm making? 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. Hey everyone. In this episode, I'm talking to Mike Bland, the developer experience platform architect at Engflow. Now, Mike is not your typical hands-on keyboard developer. In his own words, he's an instigator. And he calls himself that because he spent the majority of his career...
leading large-scale initiatives to drive cultures of software quality and testing at companies like Google and Apple. And what that means is he spent less time hands-on keyboard coding, though that is his specialty and discipline, and more time leading and organizing people and programs around these major ideas, like quality and testing.
And so what we're going to do in this conversation is really unpack his learnings of running these massive programs at these huge successful companies and understanding how they apply in person versus remote. how you can take these lessons from large companies and apply them to small, and really what it means to be in a remote-first environment like he is today at EdgeFlow. I hope you enjoy today's conversation.
Hey everyone, I'm Jack Hanna, your host, and today I'm talking with Mike Bland. Mike is the developer experience platform architect at EngFlow, having previously served in senior technical roles at Apple, Google, several others. Mike, we're super excited to have you on. Yeah, it's great to be here.
Cool. Well, Mike, I actually want to start with a story of change to help folks get to know you. This is actually how you and I got to know each other, which is to say that you led a grassroots volunteer effort called Grouplet at Google. which I think was to improve testing techniques in the early 2000s. And that led you to a bunch of different companies and experiences, including ultimately to Apple. And I'm wondering if you could start by sharing the story of Testing Group Lit and how it's...
core ideas evolved over the years to help folks understand your context. The actual grouplet concept was something Craig Silverstein, he was Larry and Sergey's first employee at Google, you know, in the Stanford dorm room. He created this idea of grouplets to try and keep some connective tissue between what was becoming an increasingly distributed and diverse company. He sort of created...
or announce grouplets along different, you know, dimensions of concern for the company. You know, there was code readability, there was hiring, mentoring, documentation, one called Fix-It, which I also ran later, but the, you know, the main one. obviously, that I'm here to talk about is the testing grouplet. It was basically a way to spend your 20% time, but instead of working on necessarily a technical project, you could pool your time with other like-minded people to promote.
something that was good for the company. And so I joined in August 2005 and found the grouplet a couple months later. Google really wasn't doing that much automated testing and it wasn't doing it very well. And there were a lot of emergency releases and things of that nature. Over the period of about five years, we sort of muddled through together and we found ways to break down the communication barrier and all this sort of thing.
things to get people to learn about these ideas, what it meant to do effective automated testing, and to learn the technical details of how to do it well. It struck me that we were a distributed work success story because there were only a few of us. that were distributed across different offices started in Mountain View, but then there was Zurich and New York and, you know, other places across the world that started either creating their own little testing grouplets aligned with ours.
And we one of the most effective ways we found to work together was this little project called testing on the toilet, which started off in a meeting in a meeting as a complete joke. We were desperate. We were like, we're giving out all these books, you know.
all these different talks and events and they just sit there and you know people collect them and never crack them open what do we have to do to get people to actually engage with some of these ideas and somebody toss out an idea you know like hey well if we just put flyers in the bathrooms and then somebody ran with it
You know, I have all the details on my blog. I have a testing on the toilet article that, you know, names names and goes through the early history. But one of the points I made in that article was we had we kicked around an idea in Mountain View. It was actually someone in London who noticed it in the notes and decided to run with it, collaborate with a guy in Mountain View. And the first person that really distributed it and coordinated it throughout the company was in Zurich.
And we had authors from different teams in different locations all over the place. So we kind of found a way to collaborate effectively remotely. And we had other efforts as well that fell into the same pattern to some degree. Tell us a little bit more about how some of those ideas and the project itself evolved both at Google and beyond. That's the other interesting part of it. There's sort of like the how we overcome the cultural thing, but...
At the same time, it was always a conversation around, you know, how should people, what should we say people should do for testing? Like, what are the... available tools and techniques and things of that nature. And that was the other really powerful things. It really was a constant five-year conversation, or really conversation started. Conversation hasn't stopped, right? You never really stopped that conversation.
But we were learning just so much from each other. And, you know, the ideas that someone would bring to the testing grouplet, and particularly if they wrote a testing on the toilet article about it. And boom, suddenly, everybody in the company was part of that conversation. And then we got to the point of, OK, well, Googlers love to measure stuff. Techies want to have some sort of metrics, gold stars, whatever you want to call them.
You can argue they take it to an unhealthy extreme at times, but the general principle is it's good to be able to show your work and make it visible, and that's where we develop this idea of the test-certified program. and it was like three levels, and it was designed so that level one was, you know, get your tools in place so you start having visibility, you can knock this out relatively quickly, things like...
Back then, continuous build was not something everybody did, right? Like, it was... Well, everybody, I'm not sure, does that today, Ethan. But a lot more do, right? Like, we have GitHub Actions and, you know, other systems of that nature.
And if nothing else, Jenkins, you know, people set up Jenkins now. And we didn't invent that, but it's the idea of, you know, don't wait for a few months for one person to try to patch all your code together and run it and hope it works. It's like, no, I have... automation do that for you so um so that was like level one level two was like get people together set a policy like hey we're not going to let any more code in without tests unless it's an extreme emergency and it's documented whatever
And then to set like the early goals, just sort of to get your feet wet, like, hey, we have 10% coverage, let's get to 20. And then level three is like you've built on that. foundation of tools, visibility, early success, buying in, you know, all this stuff. Now you're ready. Let's go for, if you're at 50% coverage, just try to get to 70 within the quarter or maybe, you know, higher than that later.
And that was the other thing is it fit into Google's system of objectives and key results. And there's sort of the quarterly goal alignment and measurement system. It wasn't enough just to, hey, we invited a speaker and we're going to give you a book. We had to adjust from that because that wasn't working. It's not that we stopped inviting speakers, but we realized that to be effective at really, that's what we wanted was like a whole conversation to get people engaged.
with the ideas and then eventually to apply them. As we did that, the ideas benefited and evolved and spread all at the same time. And it was a beautiful thing to be a part of. How do you change... the culture and the language around a topic like testing or quality, as it was the case at Apple or anything for that matter.
When you're working at a company with global scale and people are totally distributed in nature, how do you go about doing something like that? So I will say I really failed at it the first few times I tried. after Google and actually I was on the course to really fail at it with Apple because what we did at Google took five years to kind of pull it all together. but then i started putting a talk together i called it the rainbow of death it's on my website
The thing is, is I lost sight of the fact that it took five years. I thought I had the answer key. Hey, we're smart people. We want to do this. Here's the components of what we did. It took us five years to figure it out, but we can just go do it right now. And... I eventually became disabused of the notion of expecting to be able to just show people the answer key and have them sort of automatically do the right thing. And for various reasons.
Different individuals, teams, organizations, you know, either they want to do it, but it's too quick for them to really know how to lock in and do it. Or, you know, they might be offended that you're coming in with these new ideas and you haven't taken the time to learn about.
the history of what's already there and things like that. And then on top of that, I thought like, hey, here's all these different pieces. We can start them all at once. And I fell into the trap and I took at Apple when I was leading. The Quality Culture Initiative, you know, which was sort of the grouply thing I was creating to drive this change again, I kind of led us down the path of getting spread too thin.
I end up reading this book called Essentialism by Greg McKeown, I think is how you pronounce his name. And he talks about the trap of success and how once you're successful at something, you get more offers, you say yes to more things, you get pulled. different directions, and then you start to fail because you're making a millimeter of progress in a million of directions instead of choosing when and going. And there was also this explicit Apple principle of focus and simplify.
And so once I finally realized the mistake and I told everybody in a meeting it was my fault, I take ownership of it. What do you guys think? What should we do? I think we need to focus and simplify. What do you think? And people were totally on board with that. And so then we focused first on building up our training program. And so we ended up with a really great training program that, you know, a lot of people started faking.
Then after that, I focused on our internal podcast, which was just the most fun I think I've ever had in a meeting. And we started cranking out podcasts on the regular and getting the conversation going that way, because let's face it. Apple's aesthetic would not tolerate putting flyers in bathrooms. So we had to find another way to sort of find the right medium to get people to engage in this conversation and share their ideas. And then the third thing, I had a colleague named Francisco who...
I had taken the idea of test certified and we wanted to, you know, kind of do a version of it internally. We called it quality quest, but he ran with that while I was focused on the other things he ran within his org, trying to get, you know, some traction with that. And he did.
Between those three things, we started, I won't say we changed the world and changed all of Apple or anything like that, but we really, I think, started getting some traction. And we did start getting some wins with some larger teams and organizations.
that were able to get a handle. You know, we were able to make some of this work visible and give things names. And so I think that was... really the the formula there is not going in trying to think about everything you've done before and how you did it before and it's gonna you know be faster this time you still have to take the time to get to know people, get to know an organization, and tailor whatever it is you have in mind to that environment.
Yeah, well, there's a couple things I want to highlight in some context I want to paint for folks. If you are an individual who wants to drive change at a large organization, it taking time is sort of something that you have to expect to be the case. at the onset i mean what i'm hearing you say is that
you spent these five years developing this program around the testing grouplet at Google, arrived at some really thoughtful and interesting conclusions about what better looks like. And when you took what better looks like and tried to simply... apply that to a different context at the finish line it was met with all sorts of resistance right and then it turned out in those cases i think one of the learnings was that
you know, the process of arriving there actually matters, matters quite a bit. Now to paint some of the context for folks, if, if I may, so you were at Google from 2005 to 2010, 2011. Okay. much done by, you know, my involvement by 2010, but yeah. Yeah. And then you had a couple of stints at different companies between then, but then joined Apple in 2018, where you started the quality culture initiative, the QCI, which you talk about a bunch on your website, which we'll link to as well.
But I think it would be helpful for folks to understand what was the impetus for starting that at Apple, and then we can talk a little bit about how some of the remote components of that came into play. One of the things I did after I left Google was I started writing in my blog about all this cool stuff we did because nobody knew about it. And lo and behold, that's how people started finding me and like, you know, offering me jobs.
In fact, I basically got a email from someone at Apple saying, oh, I saw, hey, I'm from Apple. And, you know, I saw your blog and, you know, I'd like to talk to you. So my career has been very strange. It's just felt like a series of accidents. But the thing I keep coming back to is the power of building a community. And part of the reason I think I do that...
sounds kind of high-minded, but the problem can't be solved at the same level of thinking that created it. There is a particular problem that grew out of the existing organization structure way of doing business. And so when I come in, I'm looking around that corner a little bit to say, well, I need to understand how it got to be this way. Yes, I need to be able to speak to all that. But at the same time, I know just like...
Plugging into the status quo and doing what everyone else is doing is not going to necessarily get any traction on solving the problem. I'm thinking about how do I make those connections with other like-minded people who get it or are interested and they're self-motivated to do something. That is...
how I started just putting the word out. You know, there were a couple people, you know, that I connected with right away once I got there. And then we sort of built our network out. And then when we started offering the trainings, particularly the online trainings, you know, we would get... some more people who just sort of gravitated to this. I'm trying to find the right network of people to help adapt the message and the techniques and everything.
to that environment. We're not trying to tear everything down that came before. We're trying to shore up the weaknesses and maybe give it new capabilities that the existing structure or organization doesn't yet have. So that's sort of the thinking behind doing it in kind of a grassroots way. But we want to align with what's going on, you know, from the strategic leadership angle. You know, we're not trying to undermine anything. We're just trying to.
Find ideas that currently aren't in practice and how to connect them to that overall strategy and success of the company. One of the things that you said that stood out to me was both this idea of community and grassroots effort, because it sounds like during your time, both at Google and at Apple, a key component of driving the change that you were...
in the case of Apple, hired to drive, in the case of Google, kind of emerged to drive, was the intersection of different teams or sort of communities or cells that sprouted up that shared this idea. And so you had... almost a coalition of people who are like-minded, who are aligned to the mission, who could in their own little ways, in their own little areas, all sort of come together and coalesce around driving that change. And I think that in a world where...
folks aren't in person, both finding those communities and cultivating that alignment can be so, so difficult. And I think in both the case of Google and in the case of Apple, you started in a place where folks were... in-person principally, though the coordination was distributed, which I think is quite interesting. But since leaving Apple, I think you recently started at EngFlow, where you work today, which is a 100% remote company. Give us the rundown on the team side.
and then general approach to remote work because I suspect it's quite different to what you saw at these massive companies like Apple and Google. Before I get into that, do you want to say what you sort of described as far as building these networks of people? I often call it instigator theory.
You know, where it's like, if you're the one crazy guy saying we should do this different thing, it's easy to get voted off the island of your own team. But if you can make those connections and create that feedback loop and hone that message together. then suddenly people are hearing it from different angles and they're more receptive to the idea.
That's important whether or not you work at a massive company like Apple or Google or you work at a startup. Now, the scale might look different, but I think that lesson for creating buy-in to drive change is actually pretty universal. We think, oh, we're talking.
People were special. You know, we're doing things the world's never done before. And it's like, we're still these, you know, meat puppets, basically. You know, we still work the same way. It's no different from any other company or organization. But Inflow... Yeah, I mean, IngeFlow started 100%. You know, I worked remotely with some people at some jobs before, but this was the first 100% from the beginning company.
You know, it's really cool. It's a great group of people. It's about, I think I looked and it was like 48 of us so far now. And it does have a preponderance of Googlers in particular, but not at all. They do some things remotely, I think, pretty well. I mean, I think that...
There's a lot of mutual respect and open communication. And actually, I remember when I first joined, I was in some of these conversations, these meetings. Well, I was just a fly on the wall at that point, but I was watching. like our CEO and our head of engineering and our head of product, and they were just kind of going at it over various things, but not personally. It was a very impassioned, heated...
But it was all about like what's best for the company. And so I think what I've observed there in terms of the level of respect and open communication is. You know, I found it very encouraging. Are there any tactical things that you've noticed that Enflow does in the way that folks work together that kind of stand out to you as something that makes the organization particularly effective? Maybe in the way that communicate project updates, keep people aligned.
things? Do you stand up? And I think there's a rich body of things that we could potentially talk about. I'm wondering if anything jumps out to you. Well, it's funny. We're actually exploring that now because we are no longer like a dozen people or two dozen people. where there's only so many communication ties that you can keep in sync. We're actually facing that challenge now of how, even though we're only 48, the challenge is trying to ensure that we maintain.
clear open lines of communication without getting overwhelmed by the details of what's going on and also without like over over repeating you know like recently we we realized that oh we're getting updates in like three different meetings And so we've had to sort of scale down accordingly. But I would say it's an active area of interest in the company right now.
It's going to sound familiar, but I run an informal group called the Code Quality Forum, and we have conversations every two weeks about different topics that are on people's minds. And as a result, I haven't done that much hands-on work on any of the issues that we've discussed, but by virtue of like giving people a regular face to say,
well, this sucks, well, this still sucks, oh, this sucks again, and me continually asking, what can we do about that? What can we do about that? What can we do about that? Then eventually, people have stepped up and started taking care of some of these things. So I can't take credit for anything other than maybe just creating that regular space where people can talk, talk, talk, and then tip over into action.
So, you know, that's one thing. We have a meeting like that. We also do regular product demos. We also do sort of like a regular story time, if you will, where we have some of the more senior people or people who have been there the longest who know the history of... our systems and why they are a certain way and we let them just talk you know and people can ask questions but we do try to have these regular
events where people can just come together and share and then ask questions and maybe decide to do something about whatever is bothering them. Yeah, it sounds like you have quite a bit of synchronous communication, which is... Quite interesting and I think can be quite impactful. In a given week, what does that meeting breakdown look like at Insula? It's not that many, actually. There might be something like every Monday.
but it'll be like a different thing or maybe only two things depending on the cadence of how things fall. It's not like we have meetings all day, every day, which I'm enjoying that for as long as that lasts. But I think like the synchronous touch points give us some degree of motivation or whatever so that we can carry things offline.
And then whatever we have done, you know, offline, whatever, have whatever coordination we've done, whatever work we've done, then we come together and we highlight it again. And we, you know, we were doing that at Apple with the QCI as well. where a lot of the stuff we did was remote and asynchronous. We had our trainings, which we'd have multiple trainings at the same time.
Even when you're 100% remote and there is a lot of asynchronous work, it's still good to have those sort of touch points every so often so that you can put a face and a voice to... you know a slack handle it kind of just helps even when you're working i think asynchronously it just keeps the humanity to your interactions which is, I think, you know, what makes or breaks a lot of remote work situations.
Where have you seen teams struggle the most when it comes to working together effectively in a remote or distributed context? The first thing that leaps to mind was the early days of the testing booklet at Google when we started making friends in Europe. And I remember we had this one meeting where we're in Mountain View and they're in Zurich. And we're in Mountain View going, hey, how can we help you? And they're like, we don't know. How can we contribute?
And we didn't have anything concrete yet. We knew we were like mine. We knew we wanted to work together. And that's where testing on the toilet was sort of like the miracle. where we found a way that we could actually, we had something to, a structure with which to engage one another and produce something. So that's one thing.
Having an actual deliverable of some kind and a process around it, I think that was really helpful to us. The other thing is, again, the mistake I made at Apple at first with the QCI, trying to do too much. Where it's like, oh, we have 10 concrete things and we need people to do all of them at the same time. And I think that just spread us too thin.
So I think that's where the struggle is. You either you don't know what to do. You don't have something concrete to focus on. You don't have a process around it or you're trying to do too many things. I can't remember who came up with the model of forming, storming, norming, and performing, you know, the whole team stages. That comes back to why you have to be patient and take the time, you know, no matter how like-minded and onboard people already are.
You've got to focus and simplify on doing one thing well first, and then that can set you up for doing the next thing and the next thing after that. Those lessons apply so strongly when you're talking about... widespread initiatives like the testing grouplet or the QCI initiative at Apple. Obviously, at EngFlow, the scale is so much different. I think you recently wrote about one of the first projects that you worked on at EngFlow, like a migration project maybe.
It was, and I think I read in that article there was a decent amount of collaboration between you and some of the more senior folks at Enflow who had helped. build some of the underlying technology you were working with. How do you go about getting the help that you need on a really tactical level when you're going into a project not knowing how much help you're actually going to need? Yeah, we're migrating our basal bill.
from the previous framework for including external dependencies, which was called workspace, to the new framework, which is called basal modules or basal mod for short. I got into this. you know, pretty early after I got to Inflow, because I was still like figuring out like, what is it I would say I do here? What even is a developer experience platform architect, right? Like, I just sort of latched on.
to the idea that a lot of our customers use Bazel to use our product. Our product is a distributed remote caching and execution for your build and test runs. which the irony is I helped launch that at Google in 2008. Bazel is the main tool that most of our users use to engage with our platform.
There are other tools that conform to the same API, but this is, you know, the big one. I started reading about how, oh, you know, Workspace is old and busted, Bazel 9 is the new hotness, and Workspace is going away in Bazel 9. And the current version of Bazel is 7. And we still had our, you know, mono repo on Workspace. And so I thought, hey, maybe it'd be a good way for me to...
not be on the critical path of something, but do something important and useful that will get me to learn the code base a bit, you know, if somewhat indirectly, and to engage with other people on the team. Nobody else was doing it. So I went in, you know, our engineering Slack channel. I was like, hey, I'm thinking of doing this. Any reason why I shouldn't? And, you know, there weren't a chorus of screams and wails, you know, warning me against going where the dragons are.
So I just started digging into it. I've always wanted to make it like a team effort, team conversation, pull people in. So as I was going through and, you know. doing different parts of the work, I, one, try to publicly say this is what I'm doing, but then I would pick up on who bit, you know, like who was responsive. Why does that matter to you? Because...
I hate the idea of, you know, sort of like the solo technical hero saving the world and all that kind of stuff. I think we're all aware by now what a business risk that is. You know, if you've got a bus number of one on some. critical piece of knowledge or piece of infrastructure or whatever. And also, I'm very, very conscious of the fact I hadn't actually used Bazel since I left Google in 2011. I touched it. I did it a little bit.
at Apple, you know, playing with it a little bit, but not seriously. So while the tool is very, very familiar, there were aspects of it I didn't know at all. And I was aware that I didn't know it. So I figured by being transparent, making these connections... They see me, you know, hopefully it builds trust that, you know, I'm trying to do something useful and maybe I'm, you know, good enough to be here after all that sort of thing. But also if I'm going down the wrong path or.
whatever, or if there's a better way of doing something, I get that feedback. I mean, that's why we have code reviews and everything else. So for me, it really is teamwork is like... the biggest drug for me like I love connecting with like-minded people and just making things happen but also I do it because I'm very aware of my limitations as an individual when it comes to you know large complex systems and I want to make sure that I'm
I'm not going off in the dark by myself and people are like, what have you been doing? Oh my God, this is all wrong. Making your work public helps other people help you avoid those rabbit holes going down the wrong direction for too long. It sounds like it also helps... And I think...
Both of those things are worth pursuing in it of themselves. And what happened from there? Or I should say, how did you make the work public? How did you rope them in specifically? The first step was just going in our Slack channel and saying, I want to do this. I felt like... That was the right forum to basically ask permission and see if there's any reason why I shouldn't do it. And then I would start sending out code reviews. I started to get...
a sense for, oh, you know, J works on this part of the code or J's just generally interested and helpful in this case. Like I'm going to send all my code to J or, oh, you know, this is a part of the code that this group of people work on or that group of people. And then, you know, what struck me as I'm trying to do this work and I'm searching online for all this material, one, a whole bunch of my colleagues kept popping up. I kept finding Jay's blog or Laszlo's design doc or...
Yannick's pull requests. You know, I was, these are the people who, you know, have done a lot of work on Bazel or in the ecosystem in the past. And I'm like hitting all these problems.
And then I'm like making mistakes and fixing them later. There is the Bazel documentation and it's pretty good as far as it goes. And they had a migration guide, but I was hitting all these problems that weren't, you know, already in there. And I was having to scour the internet or come, you know, figure things out on my own. And it got to the point where I figured if there are this many people who used to work on Basil that, you know, didn't know this stuff or weren't already doing it.
or just as surprised as I was when I learned something and sent them a pull request and they were like, oh, really? Then I was like, what chance do our customers have of actually being successful at this? particularly when workspace is supposed to go away. And what happens if workspace goes away in Bazel 9, eventually we move on to 10, 11, 12, and they're still stuck on 7 or maybe 8 because they can't do this migration, right? So...
I've decided, let me start writing blog posts about it. And let me write the blog post not as a 10-minute pleasure read. Oh, I learned a little tidbit. That's useful. I went all in on this is like a technical. knowledge-based kind of thing. And that's sort of what I went for. I was basically writing the documentation I wish I had that would have saved me a lot of time in the hopes that it saves others a lot of time. But what I have been able to do is...
When I go into the Basil Slap community and I lurk in some of the channels, particularly Basil Mod, now I can start answering some of the questions. Send them, you know, it's a little bit self promoting, but if people have a question about a problem I've written about, I'll say.
yeah, you know, here's maybe what it is and here's my blog in case it's helpful. And a lot of times the response has been really, really good. So yeah, it's just sort of, it went from like, I'm trying to find my place here. Oh, this looks like an interesting problem that can...
be of value and then it turned into a way to get the node code base get to know the team and then it was like oh let's put something something out there they'll benefit the community and that's turned into more engagement other opportunities Now I sit there and think about it, you know, it's like how could you really sort of sit down and plan for that from the beginning? It's really just more of, I think, following through on principle and, you know, going with new opportunities as they...
As they arise, And it sounds like code review is the primary way that you are sort of engaging people in the process initially after that Slack message. And I think there's a lot to be said about making sure that the right folks are reviewing your code. you avoid the looks good to me trap. You know, there's other things you can do to avoid that too, like, you know, small commits and all that, but that's really cool. What's been the toughest part of working remote for you personally?
You can't just walk into the room and give people cookies or pizza. There is, you know, an element to being physically in the room with somebody that facilitates that communication and trust building, I think. Point of view is it's clearly not impossible to do that remotely because I think the QCI, which is still going, by the way, you know, there's still a QCI at Apple, even though I left a couple of years ago. I think we did a good job of.
creating the right space so that people could connect and trust each other and do useful things together. Like, you know, do remote trainings where we encourage people to pair programming. The hardest thing is not so much. well, you know, it pains my heart to do this. I have to power through. You do have to put in the time and energy to create the right balance of those touch points.
the personal touch point. So yes, there is a lot of asynchronous remote work and communication going on. You know, I mentioned at the QCI, I focused on getting the training off the ground, then I focused on getting the podcast really rolling, and then I worked with Francisco to...
bring you know quality quests to a place where it was really widespread and then i realized oh i don't need to have as many meetings anymore right like yeah where i don't have any i was like what do i do with you know my time and Not that I wanted just to be in meetings all the time or anything like that, but it was sort of like, how else do I maintain the cohesiveness of what we've started?
And it occurred to me, why don't I offer to do one-on-ones with people? I'm not their manager, but, you know, if we're all sort of in this together, what could happen? We met regularly like every other week or once a month or something. And so I made this offer and I started doing it with like 17 different people who were engaged in all these different efforts. And I think that that really paid off.
Now, what I eventually realized right before I left was I was talking to everybody. Everybody was talking to me. Not everybody was talking to everybody else. So then I started to focus those conversations on going, you really need to connect with the other people here, too. It's not like it's hard, like it takes a lot of actual effort to do. I think it's just maintaining the focus on communication as a priority and building the trust and the communication throughout the community.
instead of just worrying about your own specific things and who you need to talk to to do the one thing. I think that is probably the challenge for a lot of remote work. Do you think that applies if you're an individual contributing software engineer as opposed to somebody who had such, you know, I know you're obviously a contributing engineer with a hands-on keyboard in your role at Enschlo, but at Apple.
You were specifically hired to run this initiative. And so how much do you think that applies, that broader lens, when you are a hands-on practitioner? Yeah. Well, you know, a couple ways to look at that. One, I was still doing a lot of hands-on work, not so much on core product or anything, but I was actually developing some training examples and I was doing, I did a lot of the trainings myself and I would, you know, work through things hands-on.
And then there were other bits of infrastructure and things like that for the QCI that I had my hands on as well. So I was never too far from it. But just reflecting on my own experience. There are times when I just want to put blinders on and be heads down. Totally. And knock stuff out. But I'm also aware that that's a trap. And it's very easy to get sort of caught up in the brilliance of your own ideas or to just have so much context that you...
You know, you kind of disengage with reality a little bit. And so that's where having these regular check-ins, touch points with other people, maybe of group meeting, code reviews, things like that. I think it's... It's a fallacy to think that you can just bang out code without talking to anyone else and without relating to anyone else. There are certainly different people.
We need an introvert, extrovert, and you need to be respectful of that. It's not the same balance for everybody. And some people really do just need to be left alone for a while, but I also think they also shouldn't be, you know, left alone all the time for too long.
just as we shouldn't be in meetings all the time where it's like, oh, we're communicating so much, but we're not getting anything done. I think that there's, for any given person, any given team, any given task, you just have to be aware that you need... both that focus time and that communication be very intentional about trying to get that balance straight. And hopefully being honest, people say, hey, I need more time to focus on this and just be clear.
I need time to focus on this because I have to concentrate. Or, you know, say, hey, you know, before I go down this path, I really need your feedback, you know. And I actually do see examples of this at IngeFlow.
What are some of the benefits in your mind of not just finding balance generally, but seeking out, filling the cup in part with that time with others? I come back to this word intentional, being intentional about what you... want from it it's not like hey we just meet here because that's what you do you have meetings or it's not about establishing and reinforcing a power structure or anything like that if there's a one-on-one meeting sometimes you just
You just relate. You don't need to have an agenda or specific outcome. I think just building that one-on-one trust for trust's sake is always valuable as long as both people are. you know, game. But I think, you know, with regard to the larger meetings, I think it's all about having a clear topic, agenda. You're not there to just sort of broadcast and push information out. You're really trying to create.
a space for everyone to sort of engage, put ideas out there, someone else engages with it, flip it, turn it around, kind of stuff. And then the idea is something should be better as a result of that meeting. Whether everybody walks away with a better understanding of the system or we're super excited about the new feature and, you know, we've actually been prepping. That's another trick that I've started trying to do.
is have an agenda document for our product demos with a little template that says, what's the elevator pitch? Where's the documentation? Things of that nature. Where's the tracking ticket?
You know, so that we get people thinking about making that visible so that it's easier to sort of refer to later and keep track of it. Or in the case of Code Quality Forum, you know, do we have... some sort of action that somebody is lined up to take to make at least a baby step in the direction of improving whatever this thing is. It sounds like the primary benefit that you see is context-specific, right? It depends the situation and being intentional and thoughtful about.
When we do get together, when we are taking time away from that focused time, that we're thoughtful and intentional about how we're getting together, what we're trying to accomplish, what we want folks to come away from this interaction having. I'm sensitive we're running out of time, though, Mike. I'd like to ask... most folks this question because, you know, I think that while a lot of people have been practicing remote or distributed work in one capacity or another for decades,
This new normal where it is so prevalent is a new normal. And so I'm wondering, what's one question about remote work that you don't yet have the answer to? Well, I think I'm just always asking myself the question. Is this the right balance? How will I know when I've got it? Like, is there a set of principles and guidelines that either I or someone else can conceive of?
that will, you know, make the new normal more palatable and more productive and more comfortable, you know. I think when you just sort of grow up... naturally in the culture of, oh, everybody moves for work to go to a specific physical location. You just sort of are, you know, that's just part of the fabric of your life experience. And then to switch that to remote, you know,
Sometimes I am kind of bored in my office by myself and like, oh, I've done my thing. What do I do now? You know, and it's not like you just turn around and shoot Nerf guns at each other or whatever it is kids do these days. I think it's promising. I think if you go about it with the right mindset, it can be very productive. I love living in Northern Virginia now, which is where I am, and I don't have to move to...
Silicon Valley again or to New York or anywhere else to be part of this company. I'm thrilled that I could still contribute in this way and have the life that I want to live outside of that. But I do still wonder, like, is there a trade-off I'm missing that I don't realize I'm making? Could I either be more productive or more happy? And so far, I'm pretty happy. I feel like this is...
This is working out for me, but there's still this sense that it's such a new experience, only a couple years by now, and while I've been relatively successful at it, it's like, is something going to catch me off guard? Like, am I going to miss something? So I guess that's maybe it, is just sort of having a healthy paranoia about what do I not know or understand about this model that could surprise me?
I think that's one of the trade-offs with it is you have to have a healthy paranoia and just kind of wonder. Like, it's hard enough to communicate with people when they're right in front of you or in the same building. and, you know, making sure that you are being as clear, intentional, respectful as you can be at all times so that misunderstandings and missed opportunities don't...
Become an issue. Yeah, I mean, I think this communication piece is the big unanswered question i mean at least for me and that that's part of why we're doing the show in the first place trying to get answers to these questions of
You know, there's so many aspects of remote work that that are amazing. You know, folks want to live in different places, for example, for personal reasons or otherwise. And that's incredible to empower. And not for nothing, it can facilitate such incredible focus time in a way. that in-person work I don't even think begins to compare to.
But when it comes to collaborating, to working together, to building relationships and trust, I too have a healthy paranoia or concern about what's missing and what's not. And that's part of why I'm doing this, interviewing people like you and others to get a better understanding.
to enable what we can do about it. Yeah, so there is just as much as there is a potential downside and danger to missing opportunities or fostering misunderstandings. At the same time, now I've got these friends all over the place.
I see them all the time, and that part's wonderful. When you get it right, it's really great. With that, thank you, Mike. This has been such an enjoyable conversation. I appreciate you being generous with your time and insights. What's one thing you hope listeners take away from this conversation?
Well, I guess the C word we keep coming back to, like communication. And it's not about just, again, it's not about just broadcasting your ideas and expecting people are just going to listen to you genius and be inspired and run with it, right? Like it's about... really listening, empathizing with the other person, respecting them, and creating that bond of trust. It's not just informational. And I think that is the foundation for successful.
remote working relationships and collaboration. Yeah, I like that a lot. And if folks want to learn more about or connect directly with you or Enchflow for that matter, where should, where should they go? Well, for me, I have a website, mike-pin.com, where I try to put everything on. And then IngeFlow is inchflow.com. If you want to learn more about our product and what it can do for you. Thank you again, Mike. It's been a pleasure.
Yeah. Thanks, Jack. It's been great. 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.