Work and life is an ebb and flow. It is not a constant. We have moments of up and moments of down, and those can last for a different amount of times. And they can be from things that have nothing to do with work or they can be everything to do with work. 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. Today, we're talking with Anthony Eden, who is the founder, creator, and CEO of D&Simple. where he built a remote first company before school. He actually started D&Simple in 2010, went full-time in 2013, and has practiced various forms of remote and hybrid work for over 20 years.
Anthony is first and foremost a developer and has developed very strong and well-tested opinions about how to do remote work well. So in today's conversation, we're going to dig in a little bit on Anthony's background and why he went remote in the first place. The D in simple way, including why they embraced ShapeUp, their particular approach to using GitHub, other systems and processes essential to the way that they work.
as well as some of the less often talked about human side of remote working. So, Anthony, we're psyched to have you on. Thanks for having me on, Jack. Appreciate it. If folks do not know you already, can we just start with a little bit of the origin story of D&Simple? Why did you start D&Simple? Sure. So in 2010, I was coming off of working at a startup. We were trying to do something with the dot MP top level domain, which is from the Mariana Pacific Islands. We had the rights to sell that.
And we were trying to build a product on top of it that was going to be for social media aggregation. We tried it and it never really fully worked out. We couldn't figure out a business model that was going to work. So I was coming off of that.
And at the time, I was managing my personal domain with a particular company. You may have heard of them. They might rhyme with no patty. I don't know. So this big company. And I was frustrated specifically with two parts of it. One was I was... frustrated with the experience I was having around managing my DNS zone. And I was also frustrated generally with the experience of registering domains as a whole because I'd been working in the industry for many, many years.
And I saw we were consistently adding lots of steps that felt unnecessary to me. And I was like, that was the impetus of Dan Simple. I said, I've been doing this for long enough. I've seen other people. do what worked, what didn't work. And I think it's time for me to take a shot at it. So in April 2010, I wrote the first lines of code and we launched in July of 2010 with really, I would say a lightning talk at RubyConf. That was kind of the kickoff for this.
Very cool. So you did that in 2010. You shared some of the business backstory. Why did you start the company as a remote first operation at a time when that was much less popular? So my wife is French. I am now French and American, but at the time I was only American. And we knew that we had a life in both places, the United States and in France. And we knew that we would be going back and forth.
And so I wanted to build a company where we weren't tied down. I didn't want to have an office where I went into. I was never really a big fan of that. I liked living my life and working my business in around that. And so that was kind of the reasoning behind saying, okay, we're going to be a fully remote company. So this was in Hawaii at the time. We were living in Hawaii.
We had a place that was ours back in Florida that we were renting out, and we still had family members in France, and we knew we wanted to get back to France. And so had to build a company that was structured to allow this to happen. And that there's a key point to this. Hawaii to France is a 12 hour times difference, right? Massive difference.
And so I also just said, well, I don't want to be bound by time zones, which means it has to not just be remote, but also asynchronous, which defined a lot of the early decisions about how work was going to get done. Okay, so that was the state of affairs in 2010. Since then, obviously, your company has grown considerably, both in terms of impact, revenue for that matter. How big is the actual team today, and how does it roughly break out across functions?
So we are 25 folks. We have a mixture of full-time folks in the United States and then independent contractors or contracted organizations outside the United States. And of those 25 people, I would say over half are engineers. Depending on how you count, we have 14 to 16 folks that I consider on the engineering side. A few are leadership side, but many of them are engineers. We break that into two groups. We have seven folks that are focused on application development.
and then five folks that are focused on platform. which is essentially the operational side. of keeping things running. Everybody who has access to our production systems is on call. So we do an on-call rotation. Everybody, whether they're technical or not, will do customer support. We share those responsibilities that keep things running and interact with customers.
But we still do segment-based for project work based on the application versus platform. Got it. Okay, and the application group, the way to think about it is that's like product work for all intents and purposes. Yes. The platform group is all op stuff. But despite that split... for feature development and day-to-day coding. Everybody is on call. All the engineers who have access to production systems, they rotate the on call.
The other side is we have a couple of folks that are involved in sales. We have a couple of folks that are involved in marketing and a couple of folks that are involved in support. And then ancillary business things like fractional CFO, we have folks that. We outsource a lot of legal things. Those get outsourced to an organization that we trust, things like that. Support rotation, it's something that we're tinkering with a bit at Tubal right now. How do you structure it?
So we have two full-time support folks, one in the US and one in Europe. And what they do is they triage first. So every support issue that comes in, we have a matrix of all of our team members and all of the general topics that we get. So that they can look and see which team member is suited for that. And then they will triage and pick amongst those team members and they'll delegate more challenging technical requests that aren't answerable through.
basically our support knowledge base that we already have or the things that the support folks already know. They also then handle all those things that they get regularly because we will have repeat things that they know very well. And it works out pretty well because that way folks get a very quick response. And at the same time, an engineer is available to handle those more challenging. technical questions without having to put the burden on one or two engineers.
we can spread it out amongst the whole team. Yeah. Well, I guess an engineer is probably on call about 50% of the time because about 50% of the company are engineers. Sounds like you probably also have a culture of engineers getting involved in support even when they're not on rotation. Oh, yes, absolutely. Yeah, in fact, being on rotation is definitely not an indicator that that person should get the support request. On the contrary.
The support requests are designed like we designed it. So we divvy those up fairly, try to do it fairly equally amongst folks based on their expertise. Shifting gears a little bit, one of the things I'm excited about in this conversation is that You created D&Simple as a remote first and primarily asynchronous company well before COVID created a culture of remote and distributed work that is much more mainstream.
And folks I've spoken with who have done that, like yourself, tend to be a little bit more contrarian because you had to be in order to go out and do this left field thing before it was cool. And I find that is coupled with a level of thoughtfulness. That is also quite interesting to explore. It's my understanding that ShapeUp is your primary mechanism for actually doing the work on the engineering side of the house.
So could you give us the 10,000-foot overview of what ShapeUp is, and then let's dig into the why. ShapeUp is a development process, essentially a way to get features from inception into production and deployed to customers. And instead of saying it is a fixed.
So unlimited time and fixed scope. So in other words, saying we have to complete all these things, but you have as much time as you need to do it. It flips it the other way and it says you have a fixed amount of time, which is called an appetite. You, meaning engineers, you control the scope. And so scope management becomes a negotiation between the folks that want to solve a problem. So usually it'll be the product side or business or sales.
and the engineers. And the engineers have the right to basically hammer that scope down like crazy. And I would say... It's a forcing function to ensure that what gets built is the thing that needs to get built. And if it can't be built within the appetite, then don't do it. Like it's not ready to be done. That's what it comes down to.
So what was going on that made you recognize that a change needed to be made in the way that you work? In 2021 and 2022, we were looking at a significant reduction in the amount of features that we were getting out to our customers. We were maintaining things. but we weren't really addressing their demands for features or for improvements to the system as a whole.
and we were trying to figure out what was holding it back. Features were being released, but it was taking much longer than we expected. Some stuff would take a year or more to get out or we were building the wrong things. We'd build something and it would be wrong. We'd have to take a step back and build it again. It just felt like we were kind of stalled.
Our VP of engineering came and said, hey, I saw this presentation about ShapeUp and it comes from the folks at Basecamp. And he's like, it looks interesting. I wonder if we could read through it and maybe give it a try on one project. We were all frustrated. The engineering team, most of all, was super frustrated because they really wanted to be shipping stuff and they just weren't able to, they didn't have the methodology that was working.
And so we said, sure, let's give it a try. So we picked one team. We took them aside and we said, hey, we're going to try shape up with you. And we did the bare minimums needed to shape up, which was basically we shaped a solution. to a problem that we were having. And then we showed that to the engineers and they did what's, they climbed the hill, which is look for all the unknowns. They hammered down the scope and then they started the build and it worked.
And the first project was successfully released within the time limits and was useful to our customers. And we said. Okay, let's expand the scope of this. So that was at the end of 2022. And in 2023, we started applying it to all of the application teams and to see if we could do it with the platform team as well. which presented a different set of challenges, but it also caused us to think.
okay, how are we doing our platform management? How are we thinking about this in terms of what can be done within a timeframe, things like that. And it got us to actually think about a lot of that quite differently as well. Now we do it with all teams, essentially. When was really that moment that you realized something wasn't right?
I think it was when we had a project that had been going on for a year and it wasn't launched. And we're like, man, we had a lot of people have touched this. Why is it not launched yet? Well, there was lots of parts to it. One is we didn't understand the problem. And so during that year, we were iterating on the problem itself, not the solution only.
And when we first adopted ShapeUp, the very first ShapeWe did, we did the same type of thing. We got lucky that we understood the problem well enough, I think, that we were able to do it. But we actually... added framing to our shape-up process in the year 2023 because we felt that there was a missing piece, which was a clear understanding of the problem.
And that in itself was another thing that was hard to adopt because engineers, we know what we know. We basically come with solutions. As soon as we hear a problem, we think we have the solution and we jump right to it, right? And that can be a positive and it can be a negative. But what often happens is we don't actually understand the problem. We think we understand it, but we haven't done the work to...
go through the problem multiple times, bring in folks from different teams to understand how it might impact marketing, how it might impact sales, how it might impact customer success and engineering. How does it impact platform and how does it impact application team? And so by adding the framing in there and giving ourselves an actual way to document problems and iterate on the problem first before we ever invested in shaping a solution, that I think has also helped us.
solve problems that actually need to be solved and do it in a way where by the time we get to the end of the shape, we generally know both the problem and sort of the broad strokes for the solution. Something about the way that you're talking about it makes the whole thing feel...
quite time consuming. I'm wondering from your perspective, when you first started to adopt this, what felt different in the way that you were working? What felt different was when we said something was going to ship, something shipped.
No, I'm serious. It's very good, right? I went many years as a software engineer thinking that we could never tell marketing and sales that something would be shipped at a certain time because we were always afraid that we weren't going to be able to ship the thing. I think there's a lot of reasons why that fear is embedded in the software engineering process. And by adopting a methodology that forced us to think of the problem and analyze it thoroughly and write down various things.
a shape that solves the problem but looks at various aspects without actually talking about the details of implementation, and then by allowing the engineers to truly control the implementation and making a process of negotiation through that. It allows us to remove all those fears about shipping. And when I say shipping, I mean shipping to customers and then launching something into the public, having everything ready for it. Like we ship. to our customers at the end of the cycle.
Everything, or before, will often be shipping now during that. But it's done. We say this is as done as it's going to get. And we also have processes to say, and now we're going to release it officially if it's a feature that we want to release. And we go through the marketing and sales process as well.
We couldn't have done that before. We were just too afraid to make a commitment. And I value commitment from people as to be one of those most important things you can do when you make a commitment as a person to somebody else. Even if it means negotiating changes to it but keeping some form of it is really, really important to me.
And so to know that we could put that into our development process and empower the engineers as well as the product designers to feel like they have a say in this and other folks on the team as well. Our customer success people bring. Something new to the table every cycle. They're part of this as well because they're hearing from the customers things that we say, what's broken the most? What's the most frustrating thing?
Can we frame that as a problem that we can actually address from an engineering side or not? And bring it in. So I think that's really empowering to allow everybody to have this confidence that they can bring something to the table, that it will be considered. And those things that get into the build process will be released. Like that's a big change. It sounds like that's a core component. of what establishes and maintains trust among team members. Yeah, yeah, absolutely.
There was a lot of discussion years ago in Dan Simple about how we had problems with trusting each other. Management had problems trusting that engineers were going to be able to do things. Engineers had problems trusting management that they were going to do things. And we're looking at this and saying... Is this just a human problem? Or is there actually something in our processes that is causing this mistrust? It's a little of both, of course, right? But the human problem...
of trusting each other can be addressed when you can make those commitments and keep them because good processes help you get there. Doing what you say you're going to do. establishes credibility right and when you do that repeatedly you can trust the process. You can trust each other. It's essential to building an effective team. And I think it's something that's harder to establish for remote teams when you don't have these other opportunities.
like breaking bread regularly to build human to human relationships. In our organization, we address that by ensuring that we have meetups during the year. Right now, we're doing two a year. We used to do three a year, but we do two a year. We invite everybody together. Not everybody can come to every meetup that we have.
We try to ship them around one in the US, one in Europe, for example. We may eventually try to do one in Asia so that we can get our team members over there, make it easier for them. If you're not there, then we still... We still turn on a video recording. We still bring you in via conference calling. And we do that as much as we can for every all, like we do all hands.
every two weeks. And during those all hands, every single one of them brings as many people in from remote. If they can't be there, we record everything, we transcribe everything. And we try to constantly keep folks involved.
And that actually is an ongoing effort. I think even in ShapeUp, it might be easy to create silos where your product team is working independently from your engineering team, which is working independently from your marketing and sales team. And personally, I think that's a mistake. I think that the key part is actually engaging.
as early as possible everybody so that they have a chance to at least understand what's going on and maybe a say in it because we've seen them come up with some pretty clear things that we were going down a path and it's like oh hey careful about this path you're going down could you talk a little bit about how folks actually engage and collaborate and work together on a day to day or week to week basis.
Maybe first in the shaping process and then actually in the build process, which is probably more pertinent to the developer audience. So framing... And so we collaborate on that in Google Docs with comments, things like that. Shaping is done in Miro. So that's what we use to collaborate there, which is a great collaborative platform for. And then building is all done with.
GitHub, and so we do pull requests, typical what you would expect for an engineering group. We make sure that decisions are always recorded in GitHub. So when a project goes from shape to build, we actually create a GitHub issue in a particular repository that we call our DNS Simple Business Repository.
that is this is a project and it captures links to all of the stuff that we've been talking about from the frame to the shape to any supporting material it describes things it breaks things down into tasks so the engineers control like how they're going to break up their time
We embed a hill chart, which is part of the shape-up process. You climb the hill to find out all the unknowns, and then you go down the other side for a smooth build usually. So we include that right in there. And every week... The team just puts an update on and they put a new version of their hill chart. Here's where we're at. Here's what's blocking. Here's what's flowing.
Are we on time? Yeah, we're good. Or we're not. Hey, we're blocked by this and it's causing some issues. And so that's how we maintain the asynchronous part is we do it through writing and through collaborative environments that allow us to do this asynchronously. Engineers are free to get together and pair or mob. We've seen them do that. They'll find those rare times across time zones, especially if they're very far apart, but they might pair for an hour or so.
If they can't pair, they record Loom videos for each other. So they'll do like a status update for each other internally because for every project, we create a Slack channel for that project publicly available within our Slack group. So anybody on the team can look at it and they'll discuss, but we consider.
Slack to be ephemeral and Loom videos to be ephemeral, which is perfect for updates and quick discussions as long as the decisions get onto that GitHub ticket. Like we're choosing to take this path for these reasons. It seems like there's significant importance to the fact that...
decisions are actually captured in GitHub. Because I think that's the fear that most people have is that these side conversations and private Slack channels or in one-on-one meetings that were sort of ad hoc happen. And then... The content of that conversation never goes anyplace. It gets lost to history. It seems to me at least that piece would be particularly important. That comes from having worked in an environment that was a hybrid for a while. So while I was running.
In the early years of Dan Simple, I was running it as a side thing and I was working full time for Living Social, which was a big competitor Groupon and it had a ton of engineers. And I was the lone engineer. that was not in the offices. And so I acutely felt that I was missing out on not only the decisions themselves, because those would only come down from my senior. I was like, do this thing.
And but also the why, like, why am I doing this thing? I'm happy to do it. But if as an engineer, you want me to help you make something better, I need to know why we're doing this. Ideally, I need to be involved in the process. So it started first, like. okay, here's why we're doing it. So we're going to capture that in GitHub. But the real goal, which we ultimately got to was
We're going to tell you what we want to solve, but we're going to let you, like we're going to tell you why we want to solve the problem. Are you going to make the choices about why you're going to implement it a certain way? So moving the why of the implementation became a responsibility for the people that are actually building it, which is often a good thing. Yeah. Well, and it sounds like ShapeUp naturally lends itself to that sort of structure as well.
I think it could probably be abused, so it wouldn't be. Hopefully we've done it well enough, so it fits our culture of trying to have folks involved and have the right, have them be responsible for the things that they can commit to. but not be responsible necessarily for a commitment that they didn't make. That's the person who made that commitment needs to be responsible.
Touching on GitHub a little bit more, you had previewed with me that your approach to using GitHub is particular. We've talked about some of the ways why. I wanted to heat check. Are there other components of the way that you're using GitHub that sort of differ from the traditional approach that you think are worth mentioning?
Our marketing and sales folks use GitHub. So they use GitHub Issues for tracking all the work that they're doing as well. So they're able to... say okay here's a broad task that we want to do or a broad campaign that we want to do they will put an issue and so for example in the marketing repo we have an issue for this podcast recording And as soon as we knew that we were going to do it, we started recording comments about when it's going to happen.
And as soon as we're done recording, I'm going to put in there that we finished the recording here. And when it's published, it's here. So we have this kind of history of things outside of the development process in this single environment. I'm sure that I could use a very specific tool for Project Manage that might be a little bit better. But frankly, we get a lot of mileage out of GitHub and we found that's worth
having maybe a slightly less than perfect tool is to have it all together and have an environment where every team member has access to it. And fortunately, Even if you're not an engineer, the basic interface of GitHub issues is actually pretty easy to learn, right? So that's kind of really cool and we found it very useful.
As I mentioned, not only our projects, we also track certain business things in our business repo. That's still a little different than some folks do. We still do maintain a wiki that is not in GitHub, and we do that for sort of permanent internal documentation. So if something is going to live on for a long time, that goes in a week.
because you don't want to have to go searching back through GitHub for decisions that you'd made to know how to do something that is getting done repeatedly. You want to have that in a place that it's really clear that, oh, I can do, I can follow this process. So processes are documented there, for example.
Yeah, what are you using for that? Confluence. We used to use GitHub Wiki for a while. Ultimately, we found that for this particular case, we wanted something a little bit more user-friendly. I think the GitHub Wiki... you needed to know too much about wikis. And while I know a bunch about wikis and their origins and how to use them, my sales folks don't necessarily want to know that or need to know that. Speaking of which, I was digging through the Dean Simple archives, the blog at least.
And there were so many posts about different... experiments that the team was trying in ways of working. Stuff I imagine that you aren't still doing that were treated as an experiment and tossed away. For example, there was a post about a month that the team spent, maybe it was in 2015 or 2016, rigorously time-tracking everything that everybody was doing that was work-related, which sounds Orwellian and may have felt that way for some, but
Again, we'll link to the blog post. There's some context to it. I think it made a lot of sense in the context of that experiment. There are other examples as well. What struck me more than any one experiment was how this spoke to a culture of experimentation and I'm wondering, how did you develop that culture of experimentation that seems so prevalent at Dean's?
I can't take responsibility for the time tracking thing for what it's worth. I think allowing the folks to make that decision themselves removed a bit of the Orwellian part of it. So they were time tracking. I had no visibility into it. They were doing that for themselves. And so it was a self-motivated thing that was totally voluntary.
And that's really cool. Like I'm glad that certain people who want to do that gave it a try and shared knowledge about how to do it. I think that the idea of experimentation was built in from the very early days. Partially because of the technology choices we built on and still run on Ruby and Ruby on Rails. And as a language and sort of an ecosystem, there is always has been this desire to continuously improve and try new stuff.
Rails is now on version 8 for crying out loud. Go look at a lot of the other frameworks out there. They are not on version 8. They're maybe on 1.2 or 3, right? Even though they're 20 years old. And I think that is a testament to the passion that the folks who work in this environment have for continuously trying to do better, right? They're always trying to do a little bit better. Technical choices implemented the direction the business went and vice versa.
There was also a lot of times where I had to learn to just step back and give up control of things, whether that was to other team members, whether that was to outside organizations, if we were working with vendors. And learning to accept that there are things you can do and there are things that others do better than you.
And rolling with that without trying to control everything, I think has been a helpful thing to allow that experimentation to continue beyond just me. There were times, by the way, where I did go to the team and I said, hey, I'm about to throw a wrench in everything that we do. Here's what we're doing and here's why. We're going to try this out. And it used to drive some team members nuts because they were like, oh my gosh, what is he doing? He's going to change things dramatically again.
It worked out okay because it gave that... If I'm doing it, they see the guy who's running the show doing it, the guy who owns the business, it gives them the freedom to say, okay, I'm going to try some stuff too. It might not work out, but I'm not going to be treated poorly because I decided to try something out and it failed.
I was just speaking to a VP of engineering actually for the podcast. His name's Benji Weber. And he talks about this concept of like the paradox of giving control, because in some ways as a team, In order to really have control, you have to take control, right? You have to fully own your practices and not have them bestowed upon you. But as a leader, it's your job to create an environment in which they feel comfortable doing that.
Something about what you just said reminded me of that because you were leading by example in one respect by... Coming up with your own ideas of things to try, showing that this was an acceptable thing. You can try new things, they can fail, succeed, what have you. We may adopt it, we may not. But at the same time, creating an environment in which other people felt comfortable. coming with their own ideas, not just feeling like they had to take yours as the only options.
It's not an easy thing to do, and not everybody is comfortable doing that, which may impede some organizations from growing. I have not always been comfortable with it either. And in fact, I'm sure there's still going to be something out there that is going to... make me uncomfortable if I have to give up control of it. But I think it's a necessary thing if you want to help those around you grow and you want the business as a whole to grow.
Can you share an example of an experiment that totally flopped? The time tracking thing, it's not that it flopped. It's just like... After people did it for one or two quarters, they were just like, wow, this isn't really changing anything. So just let it die. You know, that type of thing. We did try some things in terms of one-on-ones and performance management that our intentions were good and our implementation was terrible.
And so we had to throw that away because it was creating far more work for everybody from the management team to the implementers. And almost zero benefit to anyone. And after doing it for a while, I was like, okay, this just doesn't fit our organization. Sorry, we're going to stop completely. So I just said, stop, we're not doing this anymore. And now we're coming back to a variant that I think is a lot more productive for the team. It considers
both the management side and the implementing side. And it does a better job of trying to get to what is the actual outcome we want, which is Successful team, successful business, and everybody feeling like they're lifted up as opposed to one group going up and the other going down or all boats sinking. Now that I think about it, that's probably one of the most poignant examples is just performance management can be.
a disaster if done wrong. And sometimes it's better to not do anything for a while and rethink what you really are trying to do. and then try to go back and say, okay, let's do this a little bit different way. In our case, it was just let's do it in a much more lightweight way. And we're still working on it, by the way. Everything that we do is always a constant evolution. We don't just... do something and go, okay, we're done. Everything's perfect.
It lends itself to the shape-up process, right? Where you take the time to really understand the problem before driving at a solution and taking... space to do that seems useful. In what way was the first implementation just totally, totally off? Can you share any details of that? Do you feel comfortable? Sure, sure. So we were, we had Team members doing regular one-on-ones that were very confrontational.
every week, I think, in some cases. And it was just too much. Or we weren't doing them enough. And the outcome is we had a bunch of quotes data about how folks were performing and we couldn't do anything with it like the the idea is it was supposed to drive things like bonuses and things like that but we couldn't we were just failing miserably at it so we're just like okay
There was so much time invested in trying to document all of this and get folks to write stuff down from the management side. And they were spending... an exorbitant amount of time just trying to manage the process rather than arriving at a good outcome.
It's easy to lose out of that stuff when you're in it. So I'm glad you found a lighter weight approach that is increasingly feeling right. One of the other topics that I wanted to make sure that we cover is the human side of things. We've talked. a bit about process. We talked a bit about tooling. What we haven't touched on really yet is
the social-emotional component of work and how the way that you work affects that. You wrote in a blog post, one of the biggest challenges of working together remotely is building emotional connections with the rest of the team. When did you start to realize it was so difficult to build emotional connections with other coworkers remotely? many years ago when we had a small team. I think we were eight, nine, ten, something like that at the time. And we had to let some folks go.
They just weren't performing very well, or they left on their own. So we've had both cases happen. And I think when you... When everything is going great and all you're doing is hiring people or keeping things status quo, it's really easy to go to say to yourself, oh, we're doing this right. The minute that you have somebody that you either they leave on their own accord or you have to ask them to leave is the minute that you realize that.
Okay, maybe things aren't as great as they... Maybe we're not dealing with people the way we should. Maybe we're not looking at... the human component to this enough because we didn't see it coming. It's almost always the case where the writing was on the wall, but we weren't paying attention to the emotions and the way people were feeling and the way that impacted the work they were doing. to realize that something was wrong until it was far too late.
Once we realize that, then you start thinking of how are we going to address this in the future? It's an ongoing thing, just like anything else. Sometimes you have to accept that the work and life is an ebb and flow. It is not a constant. We have moments of up and moments of down, and those can last for a different amount of times, and they can be...
From things that have nothing to do with work or they can be everything to do with work. In order for us to understand each other, we have to regularly... Talk to each other when things are not going the way we expect. And also congratulate each other when things are going really well. It's important to...
publicly acknowledge good work and privately discuss things that aren't working very well. I think that's important. Do you have any systems and processes for going about either of those things? Because it's a person thing, it's harder to build a process around it other than to... train ourselves to build people up in public when we're doing all hands calls or what have you, because it's the right thing to do. We should share our successes and we should celebrate those successes.
And then to make sure that's not the forum where we talk about things that are deficiencies or things that aren't working as well and talk about that in private first and try to figure out a way. Is there a way to fix this where everybody wins? I think that's actually a really solid thing. I don't see business as a zero-sum game. I see it as an infinite amount of potential success.
It should be something we do over time and that we invest in because everybody should be able to succeed. And if they're not succeeding here at DN Simple, there's potentially a lot of reasons that could be the case. It's not that they're bad or we're bad. It just may not be working out for whatever reason, and that's okay. My goal then is to help try to get them to a place where they can acknowledge this isn't working out.
that I can acknowledge that if it's on the other side and then find a better home, whatever that looks like for them to succeed professionally if that's what they're looking for. Seems like a worthy thing to invest time and effort into. I hope so. I'm definitely far from perfect at it. I have a lot to learn. Even now, after 15 years of business every day, I'm learning. a little bit more about how to be better at that particular thing. Fortunately, I have a good team of folks who are also
on this journey with me and who helped me do better at it. It strikes me that you have a growth mindset about this, about the way that the team works, about the business estate as a whole, and that. That growth mindset is likely a key driver to the team's collective success.
I hope so. I mean, I didn't even know what a growth mindset was until my daughter brought it to me when she was in high school. And she said, I'm doing my paper on this. And I was like, oh, what is this? So yeah, she kind of walked me through it. And I said, yeah, OK, I get that. I try to be a regular learner, try to teach myself new things, try to continuously improve things that I am passionate about at any given time. And that's, I think, important as part of the growth mindset.
You briefly mentioned before how the team gets together in person. I think you mentioned that at one point... You're getting together in person three times a year. Right now, it's two times a year. And that you try and do it in different locations to make it equally convenient or inconvenient for folks across a long enough time frame. So twice a year, once in the U.S., once in Europe.
Do you have a process for how the time is actually spent together when you do get together in person? It's evolved over time. Our current iteration, we usually arrive on a Sunday. And then Monday and Tuesday, we have typically full days of presentations from different so the teams can look at what they're doing and what they want to accomplish in the upcoming year as at a high level or in the upcoming time period whatever BS before meeting twice a year
And then we usually do a full day off where we go out and we do something as a team together, whether that's we went up to Massachusetts, we toured MIT, we went to a baseball game in the evening when we were in Rome. We basically break up because after two days. of hardworking and discussions, people need a break. And then what we're doing now is the last two days, so Thursday and Friday, we're typically doing sort of
team breakouts or other things that aren't directly related to a particular team. So cross teamwork. If a team wants to focus on something specific, we might focus on that. So it's just an opportunity to do other types of things. We've done lean coffee style.
presentations where we'll just talk about something for five minutes and then thumbs up the thumbs down if we want to continue on it and change and people can bring team members can bring topics they want to talk about we will just spend those last day and a half really because friday we usually try to wrap things up just kind of interjecting time together where we're working, but it's not around specific things. like that we pre-plan. We let it free flow a little bit there.
And then we usually wrap it up and head out Saturday. Yeah, that's nice. So full week with sort of the front half being pre-planned discussions and presentations. a day off almost as a cool down period and then the back half is a little bit more flexible based on the needs of the group and the time period. I like that. We're also thinking about this a bit. We did an in-person in February that was very different than any one that we had done before, and it was what
I think folks universally felt like was our best one yet. As we come to the close of our time together, Anthony, I have a couple of shorter questions that we could get into. How do you feel about big tech's big return to office push? I think it's a mistake. One of the common refrains is, oh, if people are at home, they're not working. I'm sorry, but I have evidence from a team of 25 that proves that wrong, flat out.
They're going to do that at home or in the office, maybe in different ways, but it's not because they're bad. It's because they're not engaged in what your company is doing and what their role is in that company. So the problem lies with the organization, not with the individual. I've seen this across the board. People want to succeed. They want to be part of something that matters to them. They don't want to do something because they're forced to do it.
So the return to office is just an excuse to think that you have control. You have no control. Businesses that bring everybody in office, you have no control over what they're doing. Sorry. That's what it comes down. That's my take on it. So I think it's complete BS. I can dig it. Well with that, I just want to say thank you, Anthony, for the time. I appreciate you being generous with your time and perspective. If folks want to learn more about you or your work, where should they go?
You can find me on LinkedIn. I'm Anthony Eden there. You can also reach me at my Deansimple address, anthony.edan.deansimple.com. One thing I would like to say is I am very anti-spam. You have an opening discussion, say, hey, I want to pitch on something. You're probably going to go to spam. at least have an unsubscribe link at the bottom that I can click that might save you. but I'm really not a fan of unsolicited email.
So please don't start that way. Come see me in person. I go out all over the place. I'll be in New Orleans next week at MicroConf. I'm going to probably be up at RailsConf later this year. Come talk to me as a human first. Don't invade my inbox with your pitch. That's all I have. this thing. I love it. More hot takes. I'll take it. Well, Anthony, thank you again for the time. It's great chatting with you. Hope you have a great rest of your day. Thanks, Jack. Thank you for having me on.
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.