Synchronous, communication, promotes flow and flow is
generally what we're all looking for.
Not only because it's more productive, not only to because
it's within this state that we produce the best work.
It's also within the static, we feel the most fulfilled.
Hey everyone. My name is Henry Surah one.
And you're listening to the tekhelet journal.
The show will be bringing you the greatest technical leaders
practitioners and thought leaders in the industry to
discuss about their Journey ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our Journal. Hello, my friend is really great
to be back here with another new episode of the taglit journal.
With me Ojos, Henry, Surah one. Thank you for tuning in and
spending your time with me today, listening to this
episode. If you haven't joined any of the
Tecla Journal, social media channels, I would encourage you
to spend a few seconds right now, to click on the links in
the show notes where you can find this show, either on
LinkedIn Twitter or Instagram and join a fast growing number
of people. I've been following the show so
far, make sure to also, subscribe and follow this, show
on your favorite podcast app in the spirit of the Thanksgiving
day that has just passed. A few days ago.
I would like to express my deepest gratitude for all of you
by listeners out there who have been listening and supporting
the show. Since I started it in August
this year. I can't tell you how much it
really means to me to hear some of your lovely comments and
feedback and how you have been finding the show useful.
So by listening to my conversations with great
technical leaders that I've invited to the show so far.
And if any of you would like to send your Thanksgiving wishes
and messages to this show or me, you can drop them as comments or
emails on those social media channels or directly to me and
please know that I'll be reading them one-by-one.
Personally, the year 2020 has been a challenging year.
For all of us due to the covid pandemic in which all of us have
had to adapt and make Major adjustments to what our daily
lives and our work approaches and this year, many of us have
to start adopting some forms of remote work, like working from
home, especially when most countries started to implement
lockdown to limit the spread of the pandemic, while some of us
could switch to remote working seamlessly, for some others.
It might not be as smooth and productive as how we expected it
to be. And for this reason that I
invited Gonzalo Silva. The CTO of do is the company
behind the popular productivity app to do this.
And the communication app. Twist do is has been a remote
first company practically since the founder started working on
to do is in 2007 and became officially fully remote.
When it hired its first remote employee in 2011 do is has a
mission of building the future of work by creating tools that
promote more fulfilling ways to work and live do is has also
been promoting the They work, which they call the future of
work by publishing and sharing lots of great articles on their
famous block, ambition and balance.
In this episode. I learned a lot from Gonzalo
about DUIs and it's remote, working history, and culture,
including some advantages and disadvantages of remote work.
We also discuss at length about having a synchronous
communication, as the first preferred communication style,
instead of the synchronous communication, and why it is
such an Important communication style to adopt in a remote team
Gonzalo. Then shares about Dewey's core
values. The Cornerstone of every single
thing that do is dust as a company from creating processes
to decision-making and also recruiting towards the end.
Gonzalo. Also shares some engineering and
Technical practices that do is dust especially the ones
important for a successful remote team, including the
importance of pre, allocation and prioritization to avoid
being block. You work remotely.
This was such a great conversation and learning
opportunity for me, especially since I've always been intrigued
by how, a fully remote company works and that it could still
succeed and Thrive compared to the traditional working model.
And since I've been a long-term Avid user of to do is having
this conversation with Gonzalo, has also been a great pleasure
for me. I hope that you will enjoy this
great episode. Please.
Consider helping the show in the smallest possible way.
By leaving me a rating and review on Apple podcast and
other podcast apps that allow you to do.
So those ratings and reviews are one of the best ways to get this
podcast to reach more listeners and hopefully the show gets
featured on the podcast platform.
Let's get the episode started right after our sponsor message.
Are you start up in software development Which is less than
five years old. If yes our sponsor at jetbrains
have a 50% startup discount offer, which allows that Ops 2
Chase multiple products and subscriptions for up to 10
unique licenses over a period of months to find out more search
for jetbrains startup discount offer or you can check out the
link mention in the show notes. Hi Gonzalo, good to see you.
It's great really to hear some things about to do is I've been
using your product a lot and I know you are one of the
well-known companies doing the remote work, especially during
this pandemic time. It will be very precious to hear
your it's sharing the best practices and I'm really excited
to see you and talk to you about remote work today.
Hi, I'm Ray. Thank you for inviting me.
I'm very excited to be on the podcast today as well.
Thank you. So Gonzalo, maybe.
First of all, can you brief us? What is your company doing?
Do is right. Yes.
So, our name is due West, we're building two products that
people know about. So, to-do list is the most
popular one. You probably have heard it.
It's a task manager and personal productivity app.
We're also building twist, which is a team, communication app
that Says on asynchronous communication along form,
thoughtful communication. But ultimately, what we're doing
at do is, is we have this Moto that we say, we are building the
future, we want to work in and, of course, we're building the
tools for that future. But also we're building the
culture for that future and that's why, for example, we work
remotely. That's why we think about ways
of working sustainably. That's why we're investing in
things like a synchronous communication.
So we're really trying to make a dent in the workplace.
Also, by leaving our idea. Also, this comes through our
tools and also the way we work specifically before we start.
Obviously as usual. I will ask my guests to share
their courage and he so maybe Gonzalo.
Can you share with us your career Journey?
What are some of the major highlights are turning points?
What made you start it working in the remote company.
My career is a bit interesting because I transitioned from
freelancing to working remotely and I guess you could say a lot
of Freelancers already work remotely.
They're just not employees of someone.
My back started comes from open source software, so I was lucky
my first Player. Let me do a lot of work around
open source, particularly rails. So, I worked in a lot of popular
libraries back in the day, things like access paranoid
permalink who like a lot of the early rails apps use these
libraries and I was one of the either Creator or maintainers on
the technical side of things. I feel like that already gave me
a lot of remote experience because I was working with
people all around the world. After that stage.
I was a freelancer for a while and then again, I guess I
realized I was working remotely with clients in this case.
And actually, that's how do This comes into my background.
Do it was one of my clients actually my last client.
They hired me, Android app at this time, due east had four
people in total together with a friend who was working with me
on this project. We build todoist, Android app
and along the process. We were just having so much fun.
It was really a nice way to work that we thought, you know, let's
strengthen this collaboration and let's join the company as
employees, regular employees. That's a highlight going from
open source, software development to freelancing and
then todoist still as a remote company, honestly.
I feel like my in office experience, is probably lacking
at this point. Comparatively, at least.
And then, of course, I went through the turning points that
I think most technical leaders have gone through when you first
go into management and you notice, your life is turned
upside down. It's very different coming in,
writing code, having technical discussions day in day out, to
coming in leading a technical team.
Thinking about technical Direction and balancing, all the
trade-offs one must do all the while managing the people on the
team and helping them supporting them growing them.
It's a big. Jacques, I think I struggled a
lot with the reward mechanisms. For example, I think we weren't
in, programming are usually very immediate.
You do something. It looks great.
You're proud. You feel great when you're
building a team, you're kind of like setting other people up for
success and can take a long time to see the benefits.
It's just a very different way to work and contribute.
And I think the last chakra me was, when I changed from
managing people to managing managers in the CTO role.
And honestly, sometimes people say that the biggest shake-up a
person can have in their career. If they dabble into management
because they will realize they're changing careers.
I think the change from managing people to managing managers is
maybe even more drastic because suddenly it's very different.
You're managing people who have their own sets of ideals
incentives. They have their own plans for
their teams and you're trying to communicate well, and align
everybody and still also support them and Coach them in managing
people. It's a very different way of
working from managing people and from being an individual
contributor. So generally speaking these
things that I'm describing to you happened.
Over the last 13 to 14 years. And I think remote work has been
always been very core to my way of working.
What, even when I don't realize when it's not very explicit.
Like it is today at doest. So if I understand correctly,
you have never worked in the typical corporate and the price
I have. But when I did spend a
significant portion of my time, working on open source software,
so I was in the company, I collaborated, internal projects,
just like everybody else, but most of my attention was in the
open source contributions. Is because the company used
these projects. So I was tasked with improving
them as well. Even though I was in this more
carpet environment. I was spending a lot of time
working with the community which was around the world.
Thanks for sharing. Your story.
Definitely is very interesting. Somebody who came from open
source, do freelancing quite a bit before fully immersed into
the remote work. So I personally myself, Heaven
ever experienced remote work before flexi work.
Yes, all this virtual conference and things like that.
Yes, so I come from a traditional background coming
back to your Your vision of building a future of work.
Probably we can spend a lot of time, maybe educating me and
also convincing me why. This is not work.
Might be something that we all should explore about.
First of all, you mentioned that the company started with four
people when you join right? Was it remote straight away in
the beginning from the founder itself?
Yeah. At the time just started the
founder was traveling across the world.
So there was really no basis for him.
So I think it all started as a side project and he was in Asia
at this time. Eventually he returned back to
Europe. He's from Denmark, but he
developed most of the early project in Chile.
He was in Chile around the time of startup, Chile.
This big program. He met a lot of the early
people. They're like our CEO.
He met there. He was working on some other
unrelated project, our head of marketing.
She worked there. She was also part of startup
Chile at the time. And even this connection that I
have with the founder was quite similar to this.
So I have a close friend who was in Chile when I'm here, was
looking around for somebody who could build the Android app in a
specific way this friends at Hey, I know someone back in
Portugal. It was all very remote because
the startup Chile was a temporary program.
So people were eventually going to leave, even those early bonds
that only lasted maybe a few months.
They were meant to be temporary. And actually, the way I'm your
approach to building the company originally this vision of the
future of work was maybe even more extreme in the beginning.
So I'm here thought he could and maybe he could.
I mean, tried to build the company based off of
Freelancers. I'm gonna hire a designer a
freelancer to handle design a freelancer.
Handle, the marketing and Freelancers and handle this and
that Freelancers to build the apps.
And I'm going to try to build a business like this.
So he would honestly be the only employee.
Well, that didn't work. But still it's quite interesting
because I feel in some ways. That's maybe the most extreme
version of remote work, of course, still has much better
when people are actually part of the company.
They're part of the culture. The incentives are aligned.
It's much different, but still the whole history of doest is
very remote Centric from the very beginning.
I think the concept of Building Company with all Freelancers are
Recently read a book about company of one.
Maybe that's the concept all about it.
Yeah, I mean like it might work for some people but certainly do
is didn't go that route. So instead you build a company
by hiring a bunch of people remotely.
So maybe tell us a little bit, like what's the benefit of
having remote work? I think sometimes we focus on
the obvious benefits, but we talked about not having to
commute. If you save half an hour every
day or maybe half an hour plus half an hour or so one hour
every day. You're going to save a lot of
time across the weekend across the year and it's going to be
Very impactful for you. You can be using this hour to do
something else other than Community.
This idea immediately pops into our head, another idea that I
think it's fairly obvious for most people.
This is on the company side, is you have access to a global
talent pool. You can hire anywhere across the
world. And so suddenly, you don't have
to trust the location. You're in to find all of the
talent you need. You can literally hire from
everywhere, but I think there are other maybe more indirect
advantages that are worth considering.
For example, you can have a really diverse team when you
hire globally. You can have people from all
across the world, with all kinds of different backgrounds, and
you can gain immensely from this diversity in the way, this
translates to everything, you do to your culture, to your
product. And of course, you can have all
of this diversity to in a specific place, but this
requires people to move their. Well, this doesn't really happen
if you're hiring globally. And another thing that I think
is really important is when you have access to these Global
Talent pool, this improves, the odds of small companies to be
able to compete with larger companies hiring is tough, but
you have Says to really talented people in all corners of the
world. So this levels, the playing
field a little bit. I'm sure if you're in a
technological Hub, like, Silicon Valley, or maybe even do
repeating ones, like London, you sure are a big company.
You generally are able to hire better than smaller.
Companies. You have more funds.
You have more reputation. It's very different from hiring
remotely. A lot of the big players don't
hire remotely. That's changing now, but still
it's quite interesting to think about leveling the playing
field. And another thing that I think
is super important is remote. Work allows us to revitalize our
local communities. So we don't need to go and fight
for space in a very specific hubs, which becomes real live in
small places and we pay high rents.
So economically doesn't make a lot of sense and by hiring
remotely by hiring globally, you are helping Revitalize.
This local communities, which in the end, I think benefits all of
humanity. So I think there are benefits
for employees for employers and even for communities as a whole.
Those are some of the areas, I think.
Very impactful. So, maybe in that case, the flip
side of it. What are some of the
disadvantages especially, from people, maybe that you hire
coming from traditional company background because we all can
say, oh, so many things, maybe go wrong but maybe from those
people who join and then have experience a traditional and
transition into the remote work. Maybe you can share some of the
disadvantages that they went through.
I think human connection is tricky.
Humans are optimized for communicating face-to-face and
we have been improving our skills in this area for
Millennia and suddenly Percy. In behind screens in some office
or room isolated from everybody else and there's a lot of signal
we lose here body language, but even the connection, like the
emotional connection, we feel towards other people.
This is really hard to compensate for remotely.
You can do a lot of things. You can think about a lot of
ways to bring that connection back to the team, but honestly,
in an office, it's something you get for free.
People are sitting next to each other.
They collaborate together. There's a water cooler, people
have lunch together. And suddenly you lose all of
this, and you have to have a whole team.
Getting very intentionally about this problem and designing ways
to fight this disadvantage one specific example, I can give you
is, we have a tourist to eerily Retreats per year.
These are two opportunities. We use to reconnect as a team.
And one of these Retreats is company-wide.
Everybody gets together for a week somewhere in the world.
The other of these Retreats is team specific.
Each team gets together in somewhere.
Specific also annually because of the pandemic, we haven't been
able to do this and we can feel that this has an impact.
We feel less connected. Acted than usual.
In some ways that human connection side of things is not
only tricky. It's fragile.
And we need to think about it very consciously because it can
ruin our culture. If we don't uphold this.
Something else that also happens is the way we work.
Remotely is very specific. We have to rely on technology.
Similarly, to before, we're not right next to another person.
A lot of the communication we do in person is very high bandwidth
and we're used to this type of communication.
We enjoy it. We communicate in words.
We speak very fast. We have body language.
There's a Our most amounts of communication flowing back and
forth for some workflows. For example, when you're
brainstorming a new idea. This can be very productive.
You can get a lot of work done in an hour just by hashing, some
ideas out with somebody. The way we work remotely.
Generally speaking is not very productive in these terms.
Imagine having a very raw brainstorm over slack.
It's the nightmare on the other hand.
There are some workflows which are really good when you're
working remotely. Just the fact that you have all
of this buffer to sit back and think, Think about your ideas
and reflect about them and refine them and polish them.
Your kind of like editing before sharing makes it so that most
conversations are really high signal.
There's very low noise and this is really good.
Going back to the advantages of remote work, but for some things
remote work isn't really a student because we also usually
speak a bit earlier than we should we do this.
It's just the way we work. But for that early stage, when
high bandwidth is really important.
The lack of colocation is a disadvantage and it's not as
easy. You can go on a call, but you
still His body language, technology breaks down is the
thing stopped working. Sometimes you're struggling with
the tool, the whole workflow of. Can you hear me?
Am I still here instead of focusing on the actual idea?
So there's all of this friction that doesn't exist when you're
sitting next to another person. It's a disadvantage, you can
design your workflows. You can design a lot of things
to prevent and to fight back on this disadvantages, but they're
there by default. So, I think those two things are
quite big disadvantage, is the lack of human Connection by Alt
and also not being able to have very high bandwidth
conversations also by default. I guess.
I'm also quite intrigued, right? Because by doing remote work,
you can still have this high bandwidth, but I think that's
not one of the best practice like maybe do is and some other
remote companies are doing because they always Advocate
asynchronous first because it could happen also like you do
removal but you still communicate through slacks and
maybe videos meetings all the time, but that is actually one
of the best practices if I understand correctly and that
you should prefer. I synchronous bus rather than
synchronous. Yes.
So we're big Believers of asynchronous work.
We're very inspired by for example, deep work by call
Newport and we really optimize the way we work in our culture
towards this. For example, we only have five
core values at duelist. And one of them is Independence.
The thing is the future of work, we feel it's much more
rewarding. If you can block most of your
day to work on something that's very specific and tangible.
You can reflect you can do your best work and you can be done
with it. When you think about, The
regular workplace and even the chat based workplace nowadays.
It's filled with interruptions and interruptions.
Break the flow for you flow makes you happy.
So if you can achieve flow you're less happy.
Let's say. Generally speaking a
synchronous, communication promotes flow and flow is
generally what we're all looking for.
Not only because it's more productive, not only to because
it's within this state that we produce the best work.
It's also within the static, we feel the most fulfilled
asynchronous communication is really a way of promoting flow.
And also ensuring that the work we do as this connects to what
we were discussing before, is very high signal.
So when you communicate asynchronously, you communicate
with very high signal, when you work with Flo your work itself
is very high signal. So people are generally very
productive, very fulfilled, and they can do their best work
without being interrupted all the time.
So there are many advantages to asynchronous communication that
we promote for the record. We think eight synchronous
communication has a place, it needs to be there.
So usually talk about Scent of the time.
We should be doing asynchronous communication, ten percent of
the time you should be doing synchronous communication.
It's not either/or situation because there are some workflows
that are really suited for communicating synchronously, of
course, like all of the other teams, we have one-on-ones and
these things, we don't really try to do them asynchronously
because again, we're looking for that human connection, something
would require that human connection and we want to make
sure there's room for those things.
We have Team meetings, which honestly they are not very
tactical with the Our planning asynchronously the team meeting
serve, a very specific purpose. Like they look tactical on the
surface, but deep down. They're just an opportunity for
people to get together on a call.
See each other every week and talk a little bit about the
work. They're doing again.
It's looking for that human connection.
And there needs to be room for that.
But by default definitely asynchronous and optimizing for
a synchronicity when you're working remotely.
This is also the smartest thing to do, because if you try to
make things synchronous, when your remotes you're going to
struggle a little A bit you have people across time zones people
in different locations. The tooling is great holidays,
but it's not fantastic. It's a Flawless.
So if you can minimize this friction, everybody wins
generally speaking. So I get what you mean, but
again, coming from the traditional background, my
tendency will be okay. I synchronous first if I have
something normally, as a common employee, we would want to have
a response as soon as possible with this kind of setup.
What would you think we should do?
Let's say if I request for something and I have to wait
for, I don't know, a few hours, a few days.
Do you? Please have a like multiple
tracks that you looking on asynchronously.
Maybe we can share a little bit of light on that front.
It's a great question. Yes.
This is something we designed very intentionally for in our
workflows when we're working with people where blocked all
the time. And if we are fully
asynchronous, these blocks can last a very long time.
There are a few things we do to work around this so to speak.
The first one is, we are very conscious about having separate
tracks as you said. So officially, there's only
usually one main piece of work that we're doing, but there's Is
also, this idea of a backlog of things we can also do.
So, if you get blocked on something, you can switch to
something else and we try to master this workflow of context
switching. It's usually very expensive as
you know, so we try to minimize it as much as possible.
This is something we train people from day one, you will
context switch. And usually, there are ways you
can tweak this to remain productive.
For example, your secondary task should be something fairly
small. A chainable may be something you
can do in two hours fix the book.
So, it becomes rewarding very fast and this helps Brain be
motivated to work on something else.
But we also do a lot of preparation work to ensure that
we're not blocked most of the time.
So, what this means is, we had a stage many years ago.
For example, when we didn't think, as much about this, where
maybe we went into work without having thought out about how
things should work, like what the design could look like.
There was a lot of in definition and this lens to us being
blocked all the time. And this was very detrimental to
the work we did. So now we really try to
anticipate as much as possible for People we work in squads,
cross-functional squads to build things.
And before we start doing the actual work, the squad usually
starts discussing the work. So while they're finishing off
their previous pieces of work, they're already thinking about
and discussing the next thing, like how should it look?
What are the challenges? What are the edge cases?
We try to predict these things so that we can get them out of
the way on day one, when we start actually working on it.
There's a lot of definition from the team itself that will build
it on what they're building and how they're building of course
this. Bill fails every once in a
while, but just the fact that you're very intentional about
this preparation. In fact, the preparation is a
secondary track of work. Sometimes for people is very
important to make sure that you're blocked much less than
you would be by default. So I think it's a mixture of
these two things preparing as much as possible to avoid blocks
and also training on. We're going to be blocked.
Let's assume that's going to happen.
How can we minimize the impact of this blocks?
How can we maybe even make them? Productive for example, I think
something we do fairly well is handle those priority two tasks
that most teams struggle with, because they often end up in
that secondary track. So we slowly get work done that.
Maybe it's not as prioritized as the main bulk of work.
So, yeah, those two things, preparation, and also
minimization of the impact are two things.
We invest very heavily in how about emergency incidents or
support from customers? What would you do then?
Especially if it touches multiple teams?
That's interesting about us and this is something I think it's
an area where we will still grow.
So we separate those two things incidents, and user reports and
requests. We have this role internally, we
call the hero, we have one of these, There's a Hero protein,
per functional team and this person is constantly working
with our support team in improving things or customers
fixing bugs. Trajan box.
Providing technical feedback, where needed?
We have this permanent presence working with the customers and
this works fairly. Well, although it's quite
tricky, run, onehand. Hand one person is really not.
A lot of people working on this, but on the other hand, this type
of role. It's a bit like a black hole.
The more people would put working on this.
The more people will be like 100% utilized.
So we have to balance this type of work.
On the other hand, you mentioned incidents and this is an area
where I think we lack some maturity because we don't have a
really good setup for on Call. We don't have good definition of
how our incident handling look like.
I mean we have policies just like every other company, but if
I'm honest we have very few incidents and in Instance, if
this is unhelpful because it doesn't Force us to build a
great culture around this. We actually had an instant
recently with the last major incident before that was years
ago. That's like the state worryin.
We don't have major incidents but there's also lenses to not
have to solve this problem. You asked about, so I'm not
sure. I'm not sure how we're going to
scale in this regard, how we're going to nail this.
Maybe it's something around the way.
We tackle, support LED work with the heroes.
Maybe it will be something else, but I'm unsure to be honest.
Well, if I have to choose, I would choose no incidents versus
having to tackle a player for sure.
The other thing for example, I also learned this from gitlab
gillip is also one company who promotes this remote work.
So one thing they have is about no meeting unless you have a
clear agenda, everyone agrees on something.
Before they actually go into a meeting and also chat like slack
or I don't know any other chat probably is prohibited in a
sense. Does it work the same way for
do? He's actually we don't use any
chat tool. We use our own tool twist, which
More optimized for a long form, communication.
It still has checked built in but it's not front and center
for all of these other synchronous processes meetings.
As you said, we follow best practices.
So all of the meetings have an agenda, that's prepared
beforehand by everyone involved. All of the meetings have an
action section, which basically, every time you meet somebody,
there should be things you need to act on you.
Take notes on these, I will do this.
You will do that. You can like split next steps
with the other person. So we try to make them very
actionable. We also Emmet their time and we
have meetings which span from 30 to 45 and 60 minutes.
And we try to be very diligent with this.
And again, it comes with preparation having an agenda
going through that agenda and then figuring out the next steps
and documenting all of this. So yeah, we definitely follow
all of these processes and we try something else.
I did live also does that? We also do is we have a lot of
internal documentation. If most of the meetings that
would be related with understanding something, they
can be prevented because it's usually documented somewhere.
So it's more about making documentation accessible and
well organized, so that people can Self Serve and find the
information they need, which I guess circles back to how we
approach. Synchronous, communication and
meetings more specifically looking for that human
connection. So it doesn't really have a
tactical value for us. Not most of the time, of course,
exceptions, but the actually track your employees tendency
towards this meetings and chat because it could happen,
organically, right? Like for example, I just joined
a company. I just spread messages or invite
people to me. Meetings.
But you actually are not aware about that.
Do you actually track how much impact of this kind of behaviors
and activities within company? No, we don't track people at
all. Don't believe in tracking.
What we try to do is we try to Define this culture that I'm
describing you as much as possible and we do this and
doing this here with you today, but also we write about this all
the time, not only in our blog, but also internal tooling and
what we're trying to do is really get buy-in from people.
We all need to believe in this approach to work.
If somebody has a lot of meetings, we're not doing a good
job of explaining. I mean the culture and what, and
the benefits. So we see it like that, as an
alignment thing, more than anything else, but we don't
track and we definitely have a lot of room because we're all
different, even if we're all aligned on the culture, if we
all agree. This is the way forward, even if
there's a lot of by into different people will have two
different sets of needs and different sets of Tendencies.
One of these people even if they're fully lined one of these
people maybe will prefer not to have any meetings and another
person will prefer to have a few meetings.
We try to cater to these differences and even be very
mindful of this for example. Pilar team leads have mostly a
fixed Cadence for meetings with their team members, but there
are a lot of individual optimization because we're all
different examples. Individuals prefer that meetings
have very heavy preparation or hand.
Even if their personal like one-on-one type of meetings
writing down all of the topics providing a lot of context maybe
even having pre discussions before you actually meet with
another person while other people will be more type of wing
it. Yeah, let's get together a chat,
see each other face to face and we'll see what comes up.
We try to be mindful of these differences in not try to force
everybody into a single malt, but we don't track it all
definitely not how many meetings were having not what people are
doing or how they're doing it. So in a way, if we're not
convinced ourselves of this approach to work, then it's
going to be very difficult to convince the world that it's a
worthy alternative. It makes sense to certainly so
such on this next topic, which is how do you hire people,
because I'm sure not everyone will be suitable for this kind
of work. So is there any Civics that you
assess from the candidates. And after you hire them, how do
you own board them? So that they are immersed into
this culture. So something to note is it's
definitely not all roses. And we have had cases in the
past of people with whom, we've done our best, or at least to
the best of our knowledge at the time.
And things didn't work out, because remote work
asynchronous, communication. All of that was not working but
still, I think it's quite rare. I think, if I was looking from
the outside, I would be surprised at how little this
happens actually going back a little bit.
To the hiring itself. We approach hiring by publishing
jobs online and relying a lot on the internet to find candidates.
We don't scold or hun people as much as I think as most
companies do this is both good and bad.
I guess we don't do this more because we can't afford the time
right now. And also when we were smaller
and less known frankly, sometimes it took us a long time
to hire. It would be quite often to have
a job posting up for many months and not find the person we were
looking for. So I just want to make that
disclaimer because don't do what we did.
If you're looking to hire fast because that's not going to
work. The way we look for people is we
have a very strong definition of the culture.
We're trying to uphold. And again, we do this via the
internal discussion and documentation.
We have five core values. We have descriptions for these
core values and we try to use these in all of the
decision-making we do, which also affects hiring.
So, when we're looking for new candidates, we look for traits
around these core values and making sure the people will fit
into them. One of them as I mentioned
before, for example, is independence.
One people who are autonomous to take ownership over things and
who generally act like owners of the things that they are doing.
We also have another value around communication.
We obviously, we need great communicators because
communication is expensive when your remotes expensive TimeWise.
It takes a lot of time to write to think, to lay out your
thoughts in a structured Manner. And so, we need people who are
really great at communicating. We use the hiring process to
probe for these traits basically, so, my recommendation
would be to figure out What exactly you want to be as a
company? That's what we try to do.
And also be very ruthless in prioritizing.
At some point. We had 12 core values and when
we realized that some people in the company, didn't know all of
them by heart also because they're 12.
That's when we understood. Okay, we need to change.
We need to make this so easy to understand that we find
ourselves using this all the time.
Now are thinking in our reasoning decision making, and
that's what it also, when you're hiring, and you're probing for
these core values, there needs to be some room.
For whatever, technical skill, you're looking for.
If you're hiring an engineer, you should only look for the
core values themselves. You need to assess how
technically the person is able to tackle the challenges, you
want them to tackle and so on. I'm not presenting this as a
exclusive way of assessing people, but it should be part of
the process regarding onboarding.
We do some things to set up people for success as much as
possible. One of them is having again
going back to that earlier topic having a lot of documentation
available. So we want people to come in and
be able to understand How we do things, why we do things, the
way we do, we want all of this information to be very
accessible, very transparent to people.
And then we also designed the onboarding process to make it a
little bit easier to ramp up. For example, the first three
months, when people join do is start generally, they're
intentionally designed number one to provide small wins along
the way. And number two to expose people
to all kinds of work. They will be doing in the
future. There's a lightweight version of
course, but making sure. For example, I mentioned the
hero role before the person that works.
It's support new hires generally, spend a little bit of
time in the beginning, being the hero and something else we do is
they have a mentor. So there's an explicitly point
of contact for them to reach out to for any doubts.
They have. This person is the default,
right? So we try to be having a very
open culture. Everybody is accessible.
But sometimes you hire somebody, they still don't know everybody,
they're a bit shy. So to break down that wall from
day one. There is a mentor, you have a
mentor and you'll be in contact with this person on a day-to-day
basis for the first three months when we're not.
Not going through a major pandemic.
We also have people actually fly over to either their mentors
location or have their Mentor fly over to the new person's
location and spend a couple of weeks working together building
that initial connection. The mentor has a Monumental role
for us. For example, the workflow.
I was describing to you before of having a secondary tasks that
you can switch to. If you get blocked, this is
something we often have to coach people into doing, how to detect
that you're going to be blocked how to prevent being blocked.
And if you're How to rather quickly jump into that secondary
task in that return. This is something that's
obviously very specific to remote work and asynchronous,
communication and dementor of a new person were hiring has a
fundamental role in explaining. This is normal.
It's okay. It's documented here.
You can read more about this year and share all of these
experiences together with the person, I think.
Designing, the onboarding very explicitly to put people through
what their day-to-day will look like in the future.
And also set them up for success and learning expectations, being
very transparent. A parent about things is very
important. The last thing is having
Milestones, when your onboarding in a company, in a new culture,
there's things you're learning, if you're an engineer, not only
technical things. But also how do things work
around here? Having these milestones, for
example, for us after 3 months, your over to trial period.
But there's also a monthly check in on how things are going.
This is super important. We all talk about having tight
feedback loops and there's the super interesting concept.
Radical Candor. There was a book around this
very popular a few years ago you need Embrace this, if you're
working remotely because remote work can be very opaque if you
don't make it very transparent. So you might be onboarding,
someone, maybe you're having some doubts.
Maybe there's something, they're not doing that.
Well, if you don't communicate about this explicitly, most
often than not, people will not know.
This is another thing that in an office you can pick up body
language. You can indirectly.
Realize this is happening even though hopefully that's not the
only way you get negative feedback, but making sure that
when your onboarding someone you also have Room for a very
explicit feedback. Like these are the things you're
doing really well. These are things, I think you
could be doing better. This is super important to make
sure that people are very aligned on how things are going.
And then again, this is something we did struggle with
at some point in the past where we were, maybe two asynchronous
to lose to unstructured with how we were onboarding people.
There were people who didn't make it at the end of the
onboarding process, and it was a surprise for them.
This is the worst feeling. I think, when you notice
something was not working and you were not aligned in the sex,
Station. This means communicated poorly.
This means you didn't give a chance to the person to adjust.
If they don't know. I'm glad we haven't had anything
like this in the last few years, but we did went through a stage
where we were not thinking intentionally enough about you
onboarding process and this was hurting us in the feedback
stage. So for sure, I guess feedback is
that last piece of the puzzle making sure there's a lot of
room for feedback and making it very explicit.
It's okay to have occurred meetings where I'm supposed to
provide feedback to you, but I don't have much to say all is
good. This is okay.
But there is a checkpoint saying at this point with sync up and
this is very important. In the end onboarding should be
about setting people up for success.
And there's many areas to this, having them experiments, all
kinds of work. You will be dealing with is
important. Having a mentor for them.
Especially in remote is important regardless of how
accessible your team. He's and how transparent things
are. Just having that go to point of
contact makes things very easy. The third area is coaching.
There's a lot of aspects that will be specific to your Team
within remote work and asynchronous communication.
It's okay to coach people. If you have a lot of
documentation, this really helps, but also the mentor plays
a crucial role in saying, you know, this is normal or here's
how you can tackle this in the future.
This is very important in the last, as I said, feedback loops
making sure they're there front and center.
Yeah, I like the feedback aspect because obviously even without
remote work asynchronous, sometimes, like working from
home, you sometimes tend to have less of feedback or maybe you
don't know the feedback straight away.
Because It takes time or maybe you have to go through either
chat or meeting or maybe schedule, one-on-one or things
like that before you can actually get immediate feedback.
So I think, yeah. Having such a feedback Cadence
or will be important. Nevertheless, if you are working
remotely or not. So, I'm also intrigued by the
five core values, you mentioned Independence and communication.
What are the other three? The other three core values.
Our Mastery impact ambition and balance.
I know this is a trick. We're using, you could say,
these are six, but we look at ambition, and Once as a bit of a
yin and yang. So one doesn't exist without the
other. I really like the definition
that James Cleary uses of balance where he defines a
balance as being when you're working those eight hours, your
100% working ruthlessly and then when you're resting you are
arresting 100% ruthlessly, so that's what balance really means
and we really like that definition.
The problem is if you just write balance, you can be
misinterpreted maybe in B complaisance notion and we
wanted to make sure this is like we work hard.
And then we rest. Heart.
That's how we try to behave, similarly, with impact.
Its focusing on high impact things.
Basically, there will always be more work to do than we can do.
So being very explicit about trade-offs and privatization is
something we value very highly in people.
And the last one that I mentioned is Mastery.
Yeah, I guess Mastery applies to a lot of companies, but we
really want to be good in our craft.
We want us and our people like all of do is tears to have a
craft and we want to be very good at what we do and be very
ambitious moving forward. We try to keep things simple.
Both of these five core values because another advantage to
having a small set of core values is that these ideas don't
necessarily compete with each other.
Sometimes, when we find a list of core values, that are larger
15-20, you will often find contradicting points.
These core values can compete with one another in certain
situations. We want to avoid this as much as
possible. So, for example, one of our core
values is Independence, so we do expect us to be very mature
about handling work, independently finding ways to
work. Autonomously always striving to
Take ownership over pieces of work.
This is expected. And so other things like
co-ownership a something. For example, we don't do as much
and I guess we will eventually discuss more technical things
including pair programming. These are things.
We don't discard ever but we don't do them very often because
they're not aligned with our core values.
Before we go to technical discussions.
One more question regarding this remote working culture.
So what are the role of managers?
Like, how many managers does do? We have?
And what are there? Support core skills that they
need to have for working remotely.
Being a manager do is is a very demanding role.
Generally speaking. We have about 12 managers and
worry about 85 in the company. Right now.
The reason I say this is we're structured in a functional
manner. So we have a design team and
Android team Apple team Etc. And we expect teams to have a
very strong vision for their own function.
There are many things which are specific to design the, you
know, Design Systems how they're built out their lead.
We expect the design. Team to own these things.
But even for the technical teams, are Android team, Android
has a lot of new features. Every year that might not be
directly related with our products.
But we expect the Android team to have a vision about how to
bring this into the product. So I say this management role is
very demanding because our heads, for example, our head of
Android. He is responsible not only to
manage and organize the Android team, but also making sure the
team has a strong vision and that we're going towards that
strong Vision. That spends, not only technical
traits, but So functional traits and on top of this, our managers
are mostly Hands-On. Obviously not most of the time
in most cases not even half of the time, but they are technical
managers. So, our managers are able to
have technical discussions with the team to support the teeming
technical ways and even unblock the team.
It's super useful to have a manage that can try at work that
can get rid of that nagging, small tasks, that doesn't get
out of the way so that the team can focus on the big things.
So it's really a tough job. I would say so, Us move on to
the technical aspects because this podcast also has a lot of
technical aspect of it. I'm quite intrigued as well.
When you said just now, pair programming is not something
that you do quite often. It is one of the common best
practices when people talk about building high-quality software
and things like that, right? So, pair, programming,
colocation and having a lot of interactions are typically.
The practices that people will mention in terms of building
high-quality software, while in the remote work, coming back to
your asynchronous first and all the other working aspects of
Well, it seems like contradicting.
So maybe you can share your thoughts about this to be clear.
I have nothing against pair programming.
I think actually, it's an amazing way to work.
It's just not very suitable for working remotely and I want to
reinforce that we have a team that spends the whole world.
Even if there is some overlap of time zones.
This is not guaranteed and we try to work with processes that
have some guarantees. We want to ensure we have
processes that support this so we don't discard car programming
at all. If people want to do it they
should do it, but it Happen that often instead, we focus on
things that lend themselves to working asynchronously to.
So, for example, we have a very fleshed-out review process.
We have very strong guidelines on how reviews should be
approached. Our reviews are very thorough.
For example, we're not only looking at the code or the
architecture, the reviewers also check out the code and test it
and run it and look for edge cases and do a little bit of
Q&A. We try to make sure that the
code goes through this process where it is reviewed in a lot of
detail and honestly, the reviewer kind of becomes
Co-owner. I'm approving.
This. I know how it works.
I know how it looks like. I know how the user will
experience this data. Has my seal of approval and we
have really good guidelines on how reviews should be
approached. For example, to make them
consistency across teams and across the company.
Besides this, we try to automate a lot of things.
For example, we have very strong linking setups at this point.
Also to ensure that consistency when the review time comes
around, we are focused on the higher level aspects of the code
and how it looks and how it works.
Automation is a Very big scope, but there are many, big
advantages to automating things. Especially when you're working
asynchronously. If you define, I mentioned
linking in passing, but basically, what that means is
you're defining as a team and it should be a team process.
How you want the details in the code to look like and your coded
flying this into some kind of tool.
So you don't have to do this over and over again and that
frees up your brain power to focus on other aspects.
Similarly. There are other ends of
automation, which improve quality.
For example, continuous integration.
I think remote teams should really invest.
In there CI setups so that you can get out of the way.
That things work. You have good testing practices.
If you have good CI, you will, of course, this doesn't prevent
all of the problems but it actually prevents a lot of the
problems. And it lets you, for example, do
bigger, refractors more confidently alone.
So it's just optimizing for that working alone, feeling.
So that when you do have a chance to pair program with
somebody, it's a bonus. It comes on top.
It's not an expectation. And this is really important.
Something else we try to do as well.
That remotes working independently is circling back
to documentation. We have very strong, very
thorough style guides. We have a lot of documentation
on how the moving parts of our applications look like and why
they look like the way they look like the higher level ideas.
We try to document them as much as possible.
We're not there. And I wonder, will we ever be
there? But we want to get to a point
where we hire somebody they come in and we can say, hey, there's
this section of our Handbook, look at it.
And if you actually read all of this, you will know almost as
much as we do. We really try to invest in
Self-serve approach to the technical side of things.
The reason people peer review, not only because it's fun and it
leads to higher quality work. Of course.
It's also because there are two people figuring out a problem
alone. So the thing we try to optimize
for is when you're working alone, you don't actually feel
alone because there's great support for the work that you're
doing. In terms of documentation.
In terms of the tooling, all of the setup around you is set up
in a way where you're not alone where you are supporting we try
to optimize for this and then of course, We end with a very
thorough peer review to bring that human element into the mix.
So I also assume that in the beginning before somebody
submits the work for review that might be a definition of done of
maybe checklist may be used to do is to do that.
I don't know but it's like a checklist of.
Okay, here are the things that you need to check before you
actually can submit for review. Is that how it works as well.
So that you minimize all these contradicting.
Things that probably cannot be automated or maybe it's just too
costly to automate. Yes.
So this is part of our Investment in documentation, we
start most pieces of work with a speck and I'm using this term
very Loosely but what I mean by aspect it can be a product spec
if this is a feature or technical spec if this is a more
Technical Center piece of work, we try to be very thorough in
detailing. What are we doing?
Why are we doing it? And what's done looks, as you
described, the thing to note is, we don't give this to Engineers.
So to speak. We actually want the teams to
build this themselves. So even the product team as we
work through a problem. Um, is more focused on what is
the problem itself, then maybe the solution because, as I said
before, we assemble squads cross-functional squads to work
on things. And we try to ensure that this
discovery process is owned by the team itself because This
lends to our independence core value.
We're back at this again, and even technical pieces of work.
Sometimes you can start a problem with, we have a lot of
problems related. We building.
We need to refactor billing. That's the problem statement.
Then the engineer who will work on this will actually do some
investigation. Work, some tragic.
And figure out the scope of the work.
This is the amount of work. I think we should do to tackle
the problem in an efficient way. Like, of course, we could spend
years rebuilding building all the time and we could maybe do a
small fixed, that doesn't really address the underlying problem,
finding that balance between a long-term investment and a,
short-term investment. We also expect Engineers to be
making these calls again, because of the independence core
value, but we translate these calls into the specs.
So we make the process very transparent when we start work.
It should be very clear. Generally speaking.
This is not possible sometimes, but most of the times it should
be very clear. What is the exact scope of work
and what success looks like? So I could also Imagine as a
start-up. So any kind of a product
companies you have maybe hundreds of features or bucks
and you mentioned, you look cross-functionally.
There's like a product team. There's also engineering team
which is subdivided by platform using Android web and things
like that. So how do you ensure this
privatization of okay, which features should I do now?
Because it seems like the engineer will need to come up
with the investigation to try aging.
In this bag and estimation, and things like that.
So how does this process work? Is this like, you come up
together in one meeting? Okay.
Let's pick some of those things that we will do for the next few
months or so, I guess, like, most teams.
We have some conflicts of prioritization.
I mean, this in a good way. We want to do more work than
what we can do. But something we invest very
heavily and I'm not sure how much this will scale, but it's
working pretty well for us. It's pre allocation of effort.
So, as you can imagine, this is not only about which feature to
work. Khan.
It has many ramifications like which feature to work on but
also, how do you balance feature and internal work?
And also, we have two products? How do we balance working on one
product versus working on the other product?
The thing we try to do as much as possible is just pre
allocating and then making small adjustments as we go to make
sure we're putting as much effort into things as with like.
So for example, I mentioned to you before that we have one
person per team who is the hero, which is what we call the
support let roll. So we're pre allocating in,
Where things are great. We have one hero in months where
we have for some reason. A lot of issues.
We still have one hero and that's just how it works.
Even the split between two 2s and three, sweep reallocated.
You have this rough percentage of effort.
We should be putting into each of the products and we have
tweaked this in the past mind you.
So this is not fixed or static and honestly anybody can
challenge this in the company and often people do and we
adjust, but once we settle on an Umma number we commit to it, so
we're not discussing this all the time.
There's Varying degrees of pre allocation and we even try to do
this around product work. Let me explain.
We have a very transparent and Democratic process around
product. Luckily.
We have a team that is very products minded.
People have a lot of ideas on how to improve things and that's
great. And we have a workflow where
people propose their ideas, and they make a pitch, like why we
should do this as you can imagine.
We have a lot more ideas than we can actually execute on.
But the thing we do is we have these high level themes that
spent many months, usually half a year and nine months one year.
Most lately and these themes. Help us filter and narrow down
the things we should focus on. For example, this year for to do
is we decided we would be working on visualization,
visualization of your data, of your tasks, and being able to
slice and dice your data in useful ways.
For example, we introduced the upcoming view, which is like a
never-ending list of tasks for the future in all future, that
it's we introduced the board's view.
So, looking at your task in columns, instead of just being a
task list and now we're going to launch something very Soon which
we call sorting options which, you know, is being able to sort
and group your tasks by any criteria in any of you.
The reason I'm mentioning this is this pre allocation pre
decisions. They really help us prevent a
lot of conflict and honestly, spend a lot of energy, because
if we don't do this, we're going to be arguing about what to do
next all the time. And it's not always going to be
super clear. Now.
The thing to note is we try to be very transparent about why we
pick the beans, we pick. Like we picked to the rest--
views, for example, and we Documentation and at large
internal discussion on why this is the best course of action for
to do is that the time it has to do with our competition, the
market also because of the pandemic are resorting more to
task management and want to see their tasks in very specific
ways. We're all different giving all
of these options to people will position to the wrists, very
strongly in the market against the competition because it
becomes very versatile. So, we decided to focus on this
and then we look at our backlog and see, okay?
What fits into this theme? We extend this reallocation to
engineering, Ring as well. At the moment.
We try to have roughly 20% of our effort, put purely into
internal type of work. We improving the foundations of
our code improving architecture and proving testing, like things
that don't have necessarily tangible deliverable for the
other teams in the company. They don't have a design
deliverable. They don't have a product to
Liberal judges purely, internal. We try to put around 20% of our
efforts here. And again, it's a free
allocation as I'm sure any listener can imagine.
We have some code bases, which are more modern than others.
Some need more attention than others.
But still, we tried to keep this roughly consistent and then just
challenged the principles and be mindful of any changes we need
to do. So if a team lead is looking at
your code base and thinking we've been building this code
base for 13 years. And by the way, this is actually
true for some of our code bases. So we have 13 year-old called
bases that were never Rewritten from the ground up.
They have been continuously improved and sometimes twenty
percent is not enough to keep up with modernization and making
sure things are well structured this ties back to the function
of the team lead at doest which is posed to flag this and say,
hey, we're not going in a good direction.
We need more people here and then we make just a small
adjustment but we changed that pre allocation.
We're not discussing this week. We need more next week.
We need less. And then the week after we need
more again. We try to avoid this as much as
possible. Thanks for the tour explanation.
So just a little bit curious, as well.
How does the do is architecture? Look like, do you have
microservices where you have each functional team, having
their own architecture and things to manage, or do you have
a monolith Maybe? Share a little bit on that
front, if you can. Yeah, so generally speaking, we
have a monolith would call it internally.
The Majestic monolith inspired by dhh posts about base camp,
but we do have a few services to be honest.
Like there are some things which are very opportunistic and also
because we have to do is stand twist some things.
Really make sense in isolation. An example.
I like to use is the thumbnail service we use.
So both of our products have a sort of comments in both of
them. You can paste links in both of
them. We want to have a preview of
things and take some Um Nails basically speaking and these
things live very well in isolation.
There are a few opportunistic Services we have.
But generally speaking. We have a majestic monolith
everywhere, and I also think this lens to our functional
structure. We have a back-end team.
For example, the backend team owns.
The backend code bases, 1422 is 14 twist.
So we really Embrace this monolith approach to
development. I know we could spend the whole
day arguing about the pros and cons of monoliths versus
microservices. I really think generally
speaking. What's important is that you
have buy-in from the team, both approaches at pros and cons.
If you approach them in a mindful way, with Mastery, tying
back to the Corvallis. You can have a monolith and try
to make it a really good long life just like you can have
microservices and make sure you have a really good architecture
around that too. I think that's more important
than any specific approach but we use monoliths for sure.
Yeah, suddenly. I don't see any problem with
monolith as well. But as, you know, we all like
this kind of a debate sometimes in the engineering microswitch,
service business model. It.
So maybe for people who wants to learn more about this remote
booking culture, maybe some engineering best practices for
remote work. Is there any resources that is
publicly available that people can look at yes or no?
Because I think you asked two questions.
So we write a lot about remote work.
In our blog, I think do is plug is amazing.
They are contributions from all across the company from
engineering to marketing to contents.
There's really I think something for everyone and we obviously
talked a lot about The Way We Were.
And the way we see work for anything related with remote,
work asynchronous, communication, or if any of the
core values that I mentioned in the podcast, resonated with
people, there's probably something about this in the
blog. So highly recommend it as for
the technical side of things and fortunately, we don't do as good
of a job. We have a technical blog in the
pipeline, but I don't have any ETA for this, but I hope in the
future where more transparent about the way.
We approach work on a technical basis to a lot of.
Do Easter's have Twitter, a lot of doing stirs tweet about I
work. So that's also an alternative to
find more content about how we tackle the technical challenges.
So, Gonzalo is been a pleasure talking to you.
My last question. My final question, as usually,
it's about three technical leadership.
Wisdom. Do you have the wisdom for you
to share with all of us? I made some notes about this
before the interview because I knew this one was coming.
My first advice would be to stay Hands On by saying hands.
On doesn't mean you need to be deep down in the weeds doing
work. 8 hours a day management, should not be a side job.
Leading a team. You should focus on leading 19,
but staying Hands-On means. First of all, it's hard to say
this, but you can provide a better service to your team
because you can unblock them in certain types of work.
You can help, try to work when the workload increases you can
support them on a technical level 2 and also you can use
that knowledge, use that intuition that comes from
staying Hands-On to guide discussions and ask questions.
I think a lot of the work of a leader is just asking the right
questions at the right time and if you have that technical
background, it's really Apfel and, of course, since you're not
programming, many hours a day day in day out, you can even
focus a bit more on R&D. For example, to stay sharp and
make sure you have a great technical intuition.
So I think that would be my first advice to not abandon the
technical side of things. I really believe, it's a very
useful tool in the tool belt. If you have it.
My second tip is about actually something we touched on a little
bit earlier around the monoliths in the microservices.
I really think that most people in our field are Very
opinionated and that's a good thing.
But having a vision in many instances is better than the
vision itself. So I would say if you have a
team, that's misaligned, like some people want to do them on
Ali. Some people want to do
microservices that is honestly the worst situation you can be
in because this lack of alignment will lead to friction.
It will lead to low hanging fruit.
It will lead to honestly low quality work.
You will have high quality work. That's very disconnected from
each other. So I think as a team leader,
sometimes you will need to set your opinion.
Beside a little bit to find alignment within the team.
Because if you can get the team to a line under one single idea
that when you're going to get the best outcome long-term and
that's what you should focus on. And I think a lot of people in
technical leadership, they get there because they have great
ideas. You have great ideas.
You have great execution to end up leading a team and then
suddenly there's this disconnect because okay, but now you
actually need to put those ideas a little bit aside to hear your
team. See what they're telling you and
finding that alignment. This can be tricky, but it's
Really good tool to find long-term success.
Having a vision is better than whatever specific Vision you're
looking for. And the last one is also
something we, I think covers across the whole interview.
I'm a huge believer in core values.
And I talked about DUIs core values, the five ones, but I
also think engineering should have core values because here's
the thing we can't do everything.
We want with the amount of attention.
We want to put into things. We are going to have to make
trade-offs and we're constantly making trade-offs having core
values. As a team, even as a technical
team defining, these core values can be hugely important for you,
to make sure you're making the right trade-offs.
I think if we rely on our implicit ideas to make
trade-offs, they will be good. But as you scale the team, they
will disconnect some person will be.
For example, they will value performance a lot.
Their code will be super efficient, that ux will be
amazing. The whole superhuman under 50
millisecond thing. You're going to have great work
coming from that person. Maybe you have another person
who is super cute. Non scalable architecture, so
they will spend a lot of time designing, the systems, from a
technical standpoint to be extendable maintainable.
Not necessarily have user-facing traits, but be very well thought
out and put out and these things, they don't compete, but
in some instances, you won't be able to do something that's
highly organized and maintainable.
That's highly performance. That's really well tested.
And that also meets the deadline.
So, defining these core values. And again, this is something you
should be doing with your team. Let's pick some things and
things we can remember. Or by heart so 456 not more and
then use those things to make the right trade-offs to define
the identity of your team and to defining how you as a team
approach work because when people are aligned, and they're
seeing things in a similar way and they're approaching
trade-offs in a consistent way. You're going to get a lot of
compounding benefits. Like for example, pick
architecture. If you really want to build
something, for the next five decades.
Let's go really high here and you pick maintainability as a
core value. Something you always prioritize
if everybody's doing this, You're going to gain a lot
because there will be no Loose Ends.
If performance is a very important characteristic of your
product, like it is for superhuman.
And you have everybody ruthlessly optimizing, the code
that they rights, you're going to get again, compounding
benefits because there is no low-hanging fruits and you're
always building on top of other people's excellent work in this
regard. So, yeah, I guess in the end
defining what success looks like on the high level which usually
can translate to Corvallis. This would be my third tip.
I really really liked all your wisdom.
I think it's really fun. Thoughtful, for you to mention
that and share with the audience here.
Thank you so much for spending your time here, sharing your
best practices about remote work.
One thing that I learned personally, because I come from
traditional background, as I mentioned, in the beginning.
So having to know all this, I think is also a good thing,
especially even if you can't work in a remote work still.
And within this working from home, there are aspects that we
can take as well for all benefits.
Things. Like, for example, pre
allocation. I think it's also one thing that
I like because you don't actually need to always come
with a immediate response from your colleagues so pretty.
I look at things. Other things that you can do at
the site while waiting for the response, I think it's really
good and some of other things. So, Gonzalo.
Is there any other place for people to maybe find you online
or interact with you if they want to know more?
Yeah. I'm not really great at social
media, but I do use Twitter. So if people want to connect
with me, see what I'm thinking, I'm not Super Active, but I am
active on Twitter and we'll share.
Wisdom will try to Sure wisdom every now and then.
Alright, so thank you so much. You can sell.
Oh, I hope to see you again in future episodes.
I had a great time. Thank you, honey.
Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please
share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show
notes of this conversation on the episode page, at Tech Legion
of the death website. The full transcript, interesting
quotes and links to the resources and mentions from the
conversation. And lastly, make sure to
subscribe to the shows mailing list on package, you know, the
deaf to get notified for any future episodes.
Stay tuned for the next technique Journal episode.
And until then. Goodbye.