Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
The Systems Behind Managing High-Performing Remote Teams with Jon Seager
Play On
03 JUN • 2025
1 hour 6 mins
Share:
In this episode, I’m joined by Jon Seager, VP of Engineering at Canonical, for a deep dive into the systems and practices that make remote teams thrive. Jon’s experience scaling Canonical’s distributed engineering organization offers unique insights into what really works in remote leadership.
We start by exploring how Canonical structures its fully distributed engineering organization. What particularly caught my attention was Jon’s approach to measuring output rather than activity, and how this fundamental shift in perspective drives better results. His explanation of calendar ownership as a performance predictor reveals the subtle but crucial aspects of remote work culture.
The conversation gets especially interesting when we dive into the practical aspects of remote team management. Jon shares valuable insights about structuring effective one-on-ones and retrospectives, emphasizing the importance of clear communication and documentation. His perspective on setting up ergonomic home offices and maintaining healthy boundaries shows how physical workspace impacts remote productivity.
I was particularly intrigued by our discussion of documentation and knowledge sharing. Jon’s approach to combating documentation debt and tribal knowledge reveals how Canonical maintains clarity across its distributed teams. We also explore the delicate balance between trust and accountability, with Jon offering practical strategies for building autonomy without micromanagement.
If you’re leading remote teams or scaling distributed organizations, you’ll find plenty of practical insights here. Jon brings both deep experience and thoughtful analysis to the discussion, making complex remote management concepts accessible while maintaining their practical depth.
Transcript
Show/Hide Transcript
I think the million dollar question particular for boomers coming into kind of like the post Covid world is how do I know my remote work or my remote staff is actually working when they're not in the office and I can just look over their shoulders to make sure they're working.
Yeah.
And it kind of goes from a scale of like, really creepy to less creepy, I suppose.
I think the.
To me, the important thing is to try and measure people on the outcomes you want them to have, ultimately.
And I don't actually believe it's very easy to measure people much better when they're sat in an office.
You can certainly measure that they're sat at their computer and that they're in their emails, but I don't generally believe that there are particularly rigorous ways of really measuring true productivity.
But you can measure people based on outcome.
Today I'm joined again by Jon Seager.
Welcome back, Jon.
Good.
So you were on before and we spoke about Nix, and that was a very popular episode, actually.
But in today's episode, we're gonna speak about something a bit more generic, which is remote work.
And you've been doing remote work for a long time and so have I.
So I thought this would be a good episode to kind of dive in and compare notes of what we've seen.
Maybe we start with kicking this off.
Like, I think the million dollar question particular for boomers coming into kind of like the post Covid world is how do I know my remote work or my remote staff is actually working when they're not in the office and I can just look over their shoulders to make sure they're working.
Yeah.
And it kind of goes from a scale of like, really creepy to less creepy, I suppose.
Right.
I think the.
To me, the important thing is to try and measure people on the outcomes you want them to have, ultimately.
And I don't actually believe it's very easy to measure people much better when they're sat in an office.
You can certainly measure that they're sat at their computer and that they're in their emails.
But I don't generally believe that there are particularly rigorous ways of really measuring true productivity.
But you can measure people based on outcomes.
You can agree, or you can posit a set of things that you think it would be reasonable for someone to achieve in a given time frame and measure them against those things.
Yeah, I mean, there are so many horror stories of this, like management in particular in the post Covid world you saw in post Covid world like the spike of like the mouse wigglers.
I'm sure you saw those as well.
Right?
Like some companies honestly measured productivity based on were you touching your mouse or not?
And that's obviously pretty, pretty short sighted way of looking at productivity.
Right.
But I think what you're saying is, I completely agree with, it's about figuring output, not hours spent.
Right.
And but I think the reason why a lot of companies struggle with this is because they haven't defined that in the first place.
And I've been guilty of that myself as well.
So maybe let's start by unpacking what that means.
Like how do you even define these workflows or processes I guess for defining without going into the complexity of like okrs and all those like super complicated frameworks that frankly most companies are not ready to adopt in the first place.
Right.
So how in a simple way do you go from zero to you're on the same page and you can kind of agree on the is realistic for this set outcome for the set period.
Right.
So I think in any situation like that you have kind of what I would call macro planning goals and more micro planning goals.
Right.
So a macro planning goal might be what are we going to achieve this year or in the next six months?
I think trying to predict much more than about six months out is difficult.
Yeah.
And so I think that's what at canonical we describe as road mapping.
So we do a pretty product roadmap sprint every six months where we essentially sit down and look back over the last six months and see how much we achieved.
And we set goals for the following six months for each team.
We also do a review of that in the mid cycle.
So at the three month point we will say okay, three months ago we committed to this.
This is how we're doing.
Like the following things are looking great or already done, the following things are at risk and maybe here are some things we know we're not going to achieve.
But maybe here are some things that we had to react to because of a of couple customer request or an outage or something like things that pop up that you can't necessarily foresee.
That's the macro scale, right?
That's 3, 612 months.
But those are on a sorry job.
But those are on a per team basis, not on a per individual contributor.
So I think that then, so I guess what I was getting to is that then drives the micro planning.
Right.
So the micro planning Is your sprints, your pulses, which might be one week, they might be two weeks, they might be four weeks, depends.
We do two week sprints at canonical broadly.
And I think that then becomes more the responsibility of the manager of each team, right.
To understand where people's strengths lie, what their individual capacity is like over a two week period on average.
I think estimation is an art, not a science.
Like it's very difficult to reliably get that always right.
And I think one thing that I've seen cause quite a lot of distress when posited, but can be really effective is during those sessions where you're trying to work out what people are going to do, assign tasks for two weeks, for one week, whatever, assign that based on an estimate and then in the retrospective actually go back and write down how much that time that took.
And that shouldn't be seen as a way of saying, okay, well you said that would take eight hours and it took you 12.
What's wrong with you?
But over time you'll see the trend of like, okay, well this person generally said will generally underestimate by 20% or generally overestimate by 20%.
And that allows you to keep kind of calibrating as people grow and as the project grows, how much you can allocate.
And then beyond that there's, in terms of actually managing how people do their work, that's then a different prospect.
Right?
But at least from the perspective of like understanding what needs to be done in a time period and then assigning tasks out, I think that's a good starting point.
So, so basically you do poker, sprint poker, planning essentially for, for story points or do you estimate them in hours or how, what do you.
Because that's a science by itself, right?
Like time estimation or complexity estimation.
So economical is a mix.
Right.
So some people are using story points.
I think most people are using story points.
But I don't really mind.
I don't think it matters.
It doesn't matter to me whether it's t, shirt sizes, story points, hours.
Like so long as there is a consistent framework, the team can develop some muscle memory understanding of.
I don't think it really matters.
As for the day to day, I think people who are more structured and perhaps a little obsessive like me, tend to do better.
Like I'm somebody who will look at an empty day, flap a little bit and put some structure into it.
I get up and have breakfast at the same time every day.
I go to the gym at the same time every Day I'm just one of those weirdos.
I think not everybody is like that.
And that comes with its own strengths.
But one of the things you lack by not going to an office is the kind of imposed structure.
And so for me, one of the first places I look and the first places I start work with new managers or new employees is how they're going to plan their day.
And that I've had some people say, oh, you know, it feels a bit micromanage y and it's not that I am necessarily particularly interested in what's going on all day.
It's rather that people feel like, okay, there's a time every day where I'm going to meet my colleagues in a stand up.
I think in remote work, daily contact with cameras on and mics on is absolutely essential.
But I think it's also really good to have dedicated time where it's like, okay, well on Tuesdays I'm going to do pair programming for two hours in the afternoon.
If you're more senior, perhaps you're helping mentor someone.
If you're more junior, perhaps you're being mentored.
Perhaps you schedule in a couple of hours a week, which is spec review as a team, where you will dedicate some time as a team to be in a room talking about a design problem.
I think if you just particularly in more junior folk, maybe folk who have graduated recently and never worked in a more traditional workplace, it could be very easy to just get lost, right.
And feel like you're spending all your day on your own, you're getting blocked, you're not really speaking to anybody.
It's difficult to break out of it.
I think a leader's role, whether that be a manager or just a tech lead or something, is to create enough structure that people feel like they have enough touch points to make progress, get some social contact, unblock themselves, that kind of thing.
There's a lot to unpack in what you're saying here.
I think, I mean the structure, I 100 agree with that.
And I mean, I think the other thing to be, I think quite honest about is I don't think remote work is for everybody.
There are certain people that just can't hack it, right.
I mean I've had staff that just simply couldn't do it either because.
And they tend to be more junior to be fair, but they tend to come back to what you're just saying.
They, they don't have the self discipline to kind of structure the day and just sit down like, oh, here's I have a Blind canvas of eight hours.
How do I break that down into like a productive day?
Right?
It's very common to go like get stuck down rabbit holes and they just like waste an entire day of something that you really shouldn't be that.
Right.
So how do you like tie this back to kind of managing and productivity?
Like when you do quarterly annual reviews of a team, are you tying that back to the story points or whatever quantify you use for productivity and outcome?
Is that one of your key drivers for assessing performance?
Because again, if we're assuming that output, not time is what we're benchmarking, that seemed like a natural way to benchmark people.
Or how do you.
Because also it's difficult, right?
Because you can't.
One story point, one person is not same as one storage point for another person per se particular spanning teams.
Right?
So unless there is a real problem in a team, I don't care for looking at individual story points and things like that.
Like I just don't.
I'm not that bothered.
What I care about is a team's output and the way, the reason I would go and look at a team in more detail is by studying what happens at those six monthly and three monthly reviews.
So if a team shows up cycle after cycle with a 100% green delivered roadmap, my spidey sense tells me they could maybe be a little more ambitious.
Not that they're slacking, but maybe we could turn the wick up a little bit and introduce a bit more pace.
Maybe they can do more.
If a team start turns up cycle after cycle with a red roadmap, they haven't delivered the vast majority, that can actually indicate a few things.
It can indicate that the manager is maybe too ambitious, or it could indicate that the manager has the right level of ambition but the wrong staff or something else.
So I would definitely go and look in either of those cases.
If a team shows up 90% green with a couple of, you know, things that they missed, a couple of things that were like 90% there but didn't quite make it across the line, to me that's about right.
Like I, I generally ask my teams what I see most of my teams do is they say okay, well I've got five people this many days, so I'm going to end up with so many developer hours to spend in this cycle, they'll then take out things like leave and perhaps they'll say okay, off the remaining time I'll take 20% out to reserve for bugs triaging reacting to things.
And that leaves me with this many days, hours I can spend on developing features that works quite well.
But it's still an inexact science.
But I try to ask people to basically push for kind of 110% and knowing that means they're going to show up with some things unfinished, I don't see that as a huge problem.
Right.
Like, I think it's good to be.
You don't want to get it so much that the engineers see the end of the cycle and 50% of their roadmap is red.
But if they miss one or two things.
That's life, Right.
Like, I think that's okay.
Well, that aligns with the okr framework.
Right.
Like you're not supposed to hit like 100% of everything.
It's like, it's the same kind of 89% is kind of like good output.
Right.
I also think you talked about like it not suiting some people.
I think it also is more suited to some trades.
So I think in the early stage, if you're doing something novel where there's lots of whiteboarding and thinking, I think there is still a huge amount of value in standing around a whiteboard, walking around a room, talking about it.
And I think one of the things that makes, in my experience at canonical, we are 100% remote, but we do have these regular things where the whole of engineering, so it's every six months for engineering, we all go to a place and stand in a room.
And then depending on your role, you might have roadmap sprints to go to, you might have individual design sprints for particular things.
And I think in design, particularly be that technical software design or be that, you know, UI ux, I think there is something about a bunch of people in a room, there is a sort of energy that is really hard to replicate remotely.
It's not impossible, but it's much harder to replicate.
And I think honestly the key to remote work is actually some in person time.
Right?
Yeah, I couldn't agree more.
And I, it's funny because I was, I went to like a CTO dinner a few weeks back and we had this conversation about in person versus remote.
And I'm very much, I've done remote for like 15, 20 years by now and I'm very much pro remote.
But I mean some people are firm believer that being in the same room is the best output.
I, I mean I can say firsthand that I do not perform best in a room 100 of the time.
But to your point, we started doing like this long time ago at school.
We started doing annual summits where we fly in everybody for a week and we just spend an entire week in the same house or houses by now or whatever it is.
Right.
Like, and that is so fundamentally important to culture because the shift in your interactions after summit, particularly when you have new staff, is so different because you can read people on a completely different level and you can unblock.
Some things are better done in person, right?
Absolutely.
We also see people talking about hybrid teams and I have kind of mixed thoughts on this.
I think the conclusion I've come to is that hybrid teams can work, but hybrid meetings never do.
So you can have teams where some people are in the office, you can have teams, some people are remote.
One thing I've noticed at Canonical, where we've tried to make it work is let's say we have one of these sprints and someone can't make it for whatever reason.
Right.
Like some family commitment they can't avoid or a health issue and they dial in and there's like 20 people in a room and three people on the end of a screen.
It doesn't work.
The three people on the end of the screen are always at such a disadvantage that to the extent that it's almost just worth waiting and doing that as a first class remote meeting when those people have the time to dedicate.
Right.
Like the hybrid meeting thing just sucks.
The hybrid team thing, I can see ways that we can make that work, but I think it's hard.
The meetings thing I've never seen.
I'm not a fan of hybrid, to be honest.
I think you go one or the other because.
Yeah, I think that's more effective, right?
For sure, yeah.
Because the thing is like to your point about summits or these like hybrid meetings, because a lot of the insights and a lot of the communication, they don't happen destructive way.
They will happen by the water cooler or at dinner after the event or like drinks.
Like that's when like the real, a lot of the real insights and communication happens.
They're not like, oh, we have an hour to speak about this topic.
But it's not like it's going to be time boxed that hour because like you might have an idea like two hours later you're like, oh, we should have thought about that.
And those are the real insights, right?
Yeah, yeah, I think so.
And I think to your point about the stuff happening more naturally when you're in person, one of the things I try to say, particularly to newer leaders at Canonical, is it is worth every penny of investment for a good audio video setup.
It's already hard enough being on the end of a camera.
It's especially hard if you're blurry three feet away, being.
Being looked at from under your chin with a microphone that is lossy.
Like, I think you've got to give yourself the best possible chance.
Right.
Yeah.
To be as well understood as you can, given that you're on the end of a camera.
Yeah.
So that kind of gives me a natural segment to set up.
Because I think that's something that's often overlooked in remote companies.
We've been toy with that of like stipends and things like that and like making sure people have a good ergonomic setup.
Because after all, like, if you work from home, like, you need to have a good setup.
Like, doing, like doing work from your kitchen table is like a recipe for disaster.
Right?
How like, so you mentioned cameras, mic.
I 100 agree with that.
Like what.
How do you see that?
Like, do you have, like, here's a blueprint for your home office or is it like, is there a stipend?
Or how.
How have you approached that in the past?
I think there's a couple of principles that you can adhere to, irrespective of what your company does or doesn't provide.
I think if it is within your reach, within your grasp, you should have a dedicated space to do work in.
Like in my house is mostly one floor.
My office is one of the only rooms that is upstairs, essentially.
And it means that when I go downstairs, I'm sort of leaving work.
You mentioned about people who naturally are less well suited to remote work because they struggle to gain structure and get stuff done.
The other half of that problem is people who struggle to set a boundary and actually not overwork themselves into the ground.
That's a thing.
So I think the main thing is, if at all possible, trying to maintain a permanent space with a computer and a monitor and a camera and a comfortable setup with a decent chair, etc.
Is a game changer.
And I personally like that.
When I walk down the stairs behind me, that's kind of like me stepping away from work when I go.
I think that's really important.
It means that I fully recognize that the role that I'm in means that sometimes I will have to work of an evening or on a week.
That's absolutely fine.
But I think it's important that part of that is like, I have to physically go upstairs and go to work and make it a conscious decision.
Right.
It's not my computer in the corner of my bedroom.
I couldn't agree more.
Right.
Like the having that mental cue that I meet at work or I'm not at work is so important for your mental well being, I think.
Right.
So there's that for me.
We are actually surprisingly early in this journey at Canonical.
For a long time we have been a bring your own device company and we would every three years provide people with a sort of cash bonus type thing to go and refresh their tech that might be buying a laptop.
I actually spent mine, my first one, on a really large monitor for my desk just to.
Because that's what I felt like I needed.
My computer was good enough.
We are now moving into providing people with laptops.
We haven't yet got as far as figuring out what extra monitors and workspaces.
Like, we're doing the laptop thing first.
I think it.
I think it ultimately is important, but I also think people.
People have such varying preferences.
Right.
So I think in general, some sort of stipend is probably a good route.
But I honestly, I don't have a lot of experience with this.
I know in my previous company, which was a massive multinational company, when Covid happened, they were basically like, hey, you can select a desk and a chair and we'll send it to you.
Yeah.
And that was.
That was excellent.
But.
But I think.
I think having good desk and a good chair is underrated.
Particular ergonomics.
Right.
Like getting skimping on a chair like.
Well.
Or skimping a desk like you're setting yourself up for failure, like back problems and all those things in the long run, particularly if you're spending long hours just seated.
Right.
Yeah.
So, yeah, like stipends is probably the way that I prefer to purchase, but I.
There are like, depends on how flexible you are, I guess, with.
With.
With this.
Right.
Okay, interesting.
So we talk a bit about how you measure people this, but we talk about setup.
But you are.
You wrote a blog post about owning calendar and essentially owning your time.
Right.
So we kind of entered at this already.
You kind of like how you do this.
How.
So walk me through how you structure your days.
Because I think that's.
That's actually one of my interview questions.
How I ask people how, like how they structured their days.
Because I found that's fascinating.
Right.
Because it tells a lot about a person.
Yeah.
So I think that blog post was in response to a number of conversations I'd had with People at Canonical, particularly with new leaders who perhaps step into a management position and suddenly find themselves over the period about the first month becoming overwhelmed.
Like the calendar fills up with one to ones and you know, cross team syncs and things like that.
And they get this sense of like things getting away from them.
And the role I'm in at the moment at canonical, I'm spanning two organizations and I think 12, 13 teams, which is arguably, you know, probably too many.
And so I have to be quite deliberate about how I structure my time.
And so I think the first thing that's important, particularly if you're in a multinational remote company, is make it very clear in your calendar what you're working hours are just straight up.
So if you look at the blog post, it kind of, it starts with an empty calendar and slowly builds it up.
And the first thing I did in my calendar is I put a block in from 8 till 9, saying anything before this you need to ask me.
And a block in from 6 till 7, saying anything after this you need to ask me.
And then I put an hour in for lunch.
Now the hour in for lunch.
In the ideal world, you would step away, go for a walk, eat something, you might maybe do a bit of email catch up, answer some messages, but I try not to.
I try to use that as an actual break clean.
Most my routine at the moment is I go downstairs and make a slice of toast and I go for a walk for half an hour and I come back to work kind of refreshed, having stretched my legs a bit.
After that I have a half an hour thing in every morning because I've got those teams and lots of products and because the company is all remote and lots of different time zones, normally when I wake up there's a pile of messages waiting for me.
And so I put half an hour in at the start of every day called Catch Up.
Just a focus block called catch up, in which time I triage my email, I read my matter most messages, I set up my Obsidian notebook and I stare at my to do list and think, okay, well what do I need to do?
The next part of that is I think it's important to have at least an hour a day set aside for focus time for doing your job.
And the way I do this is I have them as general blocks called focus time for an hour a day.
And on a Monday, as part of my morning catch up, I try to sit down and think, in this week, what do I need to achieve as VP Engineering Ubuntu to be Successful.
Like what does success look like for me this week?
And in that time I will say, okay, well like I've got to write a blog post.
So one of those hours will get labeled up in my calendar.
Focus time blog post.
Maybe there's a specification I need to review and make a decision on.
So another one might get labeled up, review spec, whatever the spec number is.
Another one might get labeled up, you know, hiring pipeline, review, that kind of thing.
And so by the time I get to 9:30 in the morning on a Monday, every single one of those focus blocks is labeled up with a purpose.
So that, and this is twofold, right?
This means that people know what I'm doing, people can see what's on my mind.
So these are public calendars within the.
Yeah, yeah.
No, it's in like my personal calendar.
But people can.
Yeah, yeah, but they, Everybody can see what's.
Everyone can see it, right?
So people can see what I'm doing.
This is nice in a sense that if they have asked me to review something normally what I would.
If someone sends me a doc and says, can you review this?
My first port of call is to look to my calendar, find an empty slot, put the thing in and say review, blah, blah.
And that person can then see exactly when I've done that.
The other thing is as my calendar fills up, as I roll out of a meeting, I don't have to think about what I need to do.
I just glance at my calendar and it's like, oh, I scheduled this for blog post writing.
Start writing the blog post, right?
So it actually helps me because I don't have this like five, ten minutes of like, well, what should I be doing?
What should I work on, right?
So after I've done my working hours and my focus blocks, I then try to schedule in all of my regular meetings, right?
Like I've got one to ones with people and consider, are they weekly, are they bi weekly, are they an hour, are they half an hour?
Try to aim for an hour with everyone every week as a best case.
And then I've got regular team syncs and by the end of it, what I hope is still every day there is some white space because every week stuff happens, right?
Every week stuff happens.
And over time you get meeting creep.
And so I tend to use our sprint cadence as a way, as a timeline for reviewing my calendar.
So every three months I do some sort of roadmapping and at the end of that week I sit and stare at my calendar Over a two week period and think, is this still working for me?
Like, have I collected some one to ones that maybe I don't need?
Have I been added to a team sync meeting which is either no longer successful or doesn't need my input?
And I would literally spend maybe half a day just shuffling things around, removing things.
And then that sets me up for the next three months, right.
To make sure that I've still got focus time every day, a bit of white space and things are looking sensible.
And then the final trick I play, which is a bit of a privilege in the sense that I have people in every time zone in my role is I like mountain biking and I like going outside.
I'm a bit like a plant.
If I don't go outside, I start losing energy quite quickly.
And so in the winter I tend to get a bit sad.
Like particularly in the uk we don't get loads of daylight and it's rush because I have people in Australia and New Zealand and in the US on the west coast and most of the company is in Emea or like east coast.
Those people end up shifting their hours quite a lot, which I'm trying to get away from.
So what I do is on a Monday afternoon in my calendar from midday till 4, it says I'm mountain biking, okay.
Not in work.
And then I do all of my one to ones with my Australian New Zealand folks on a Monday night.
So I come home for dinner at 6, I have dinner with my kid and my wife and then I go back to work at 7 and I work through like 10 o' clock at night, something like that.
Right.
Some people don't like that.
For me it works great.
I get daylight in the winter, I get to go out and ride my bike and do some exercise.
And it means that the people that are Australia, New Zealand, that's one less one to one that they would potentially have to do a slightly awkward time for.
Right.
It's a good trade for me.
It works out nicely.
But the one rule for that is it's always a Monday at the same time.
Right.
If it's, if it's raining on Monday afternoon, they don't move it to Wednesday and cancel all my meetings.
It's just like, okay, well that didn't work out.
And I think the key is some combination of like transparency and predictability.
Right.
So people can know when they can count on you being around and book meetings and that kind of thing.
Interesting.
So I wanted to ask you about ones because the particular as your team Grows and you kind of like you said like you calendar kind of get stuck with like one and catch ups and whatnot.
Like how, what success metrics and what format do you run these in?
Because I've definitely felt like when I've had some of these sometimes you're like we're just going through the motions.
We're not actually like we're just sitting here like this calendar block every week and we're doing this sync up and then like actually could this have been an email?
Could this have been like a better way to structure this?
Like how, what success criteria, what documentation format for this?
Do you have a blueprint for that or how do you approach that?
Yeah, so I would say as a general rule try to encourage at a sort of team level.
Well really for everyone I think if you have reports you should try and give them an hour per week.
So in a team at Canonical team would generally be a Manager and then 8 to 10 engineers.
Ideally 8, which means 8 hours per week seems like a lot.
But if you think about like in reality you need to.
Where should your investment be in your team?
It should be in the people in your team.
I have read lots of stuff online.
There's a sort of common opinion that like one to one shouldn't be a status meeting.
And I think they shouldn't be a status meeting.
But that doesn't mean you can't talk about status.
It shouldn't only be a status meeting.
I think it is still interesting to talk about what's going on in the context of that person right in the work they've been assigned, how things are going.
You'll get snippets of it in stand ups.
Some teams are better at that than others.
But I still think it's perfectly reasonable to discuss.
Well this is what I've been working on for the last weeks, what I'm going to work on the next couple of days.
I like to anchor one to ones around sort of long running professional development type things.
So we do six monthly 360 review type activity at Canonical and I will generally try to, I generally try to encourage people at that point to work with their reports to set some goals for that cycle.
I don't prescribe a framework.
Some people like smarter, some people like OKRs, some people like it a bit more kind of free range that's fine.
But I think there should be some time in an ideal situation where you have the right number of reports and you have time to dedicate where you're talking about that, like, how can you.
Maybe someone wants to get better at using aws or maybe they want to learn more about a particular programming language.
And I think just having that point in the week where someone's going to ask you how that's going and help you plan what you're going to do in that week and make sure you've got the time to do it is kind of important.
And I also, honestly, I try to keep them quite breezy and quite light.
Right.
I tend to take notes in Obsidian and the way I do it is I have a note person.
So if you were one of my reports, I'd have a note called Viktor.
And each week I just go to the top of that note, I put a heading with the date of the meeting and I start taking notes.
So he's rolling so you can quickly.
Rolling note for Viktor.
Right.
So what's really nice is immediately when I open it up and I haven't written anything about today's meeting, I can see the context from last week's meeting and use that to riff on, like maybe there was something that was bothering them, some personal thing, maybe they went on a nice holiday, had some weekend plans.
Like, why not use that time to actually just have a nice conversation too?
I think, you know, for 90% of the time when things are going well in people's lives, it's bright and breezy when things may, when maybe someone has a more difficult time, you have a greater appreciation of their life if that's something they're willing to share and you can maybe come up with a better arrangement to work around whatever it is that they're struggling with.
Yeah.
So it's some combination of status, what's going on in your personal life, what are you interested in, what to do at the weekends and working towards some goals, you know, over a three, six month period.
Right, okay, fair enough.
That's good.
When you kind of alluded to this before, like when a new manager joins a team, what in particular if they're more from a traditional background, what do they tend to get wrong?
What is the biggest.
Like here's my Cliff Notes.
Let me save you some agony for the first six months.
Like what are the Cliff Notes that you share with, like all the new remote managers?
Good question.
I think the first thing I would do, if they don't already, is call them out for having a bad mic and camera and ask them, I don't know, specifically, remotely.
I think one of the things is trying to figure out ways to create opportunity for more organic chat with your team.
Like I, I've seen companies do this in different ways.
We've got a few initiatives at Canonical where there's like random coffee mornings.
Like you know, once a week you'll get a half an hour slot with someone random on your team or in your department.
I quite like that.
I think trying to find ways as a manager, I think you particularly with your junior folks have to try and find ways to allow them to network.
I think, I think creating opportunities for people who are less obviously extroverted and mouthy to go and network and spend time.
Whether that is creating perhaps somewhat contrived situations where they have to work with somebody on an adjacent team or they have to co deliver a spec or something with some other people on your team.
It's just important to make sure that I think every day I think everybody should probably have some face to face contact.
I think there are people who really like getting in the groove for like several hours at a time and that's important.
But I do think sitting on your own all day for eight hours a day staring at a code editor, while very good for some people, is still mostly only good for most people some of the time, not all of the time.
Yeah, because that's the flip side of that, right?
Like you don't want like to enforce context switching either, Right.
Because if you are trying to solve for a complicated problem, just a 15 minute catch up in the middle of the day can derail your entire afternoon.
Right.
So that's where I think calendaring comes in though, right.
So I think I agree with you and I think that's why the blog post was titled own your calendar.
Right.
Because you will know how best you work.
I work better in the mornings, for example.
I try to schedule brainy work in the mornings.
Yeah, that's how I work.
I think also even the thorniest, most technical, deep problem, most people cannot sustain concentration on that for more than two or three hours productively.
Like how many times have you been raging at your keyboard all day long?
Not solved it, gone for a shower and solved it in 10 minutes, right?
Like oh, 100%.
So I try not one of the things that I've become quite averse to is like 5 hour long focus blocks that aren't labeled with any purpose in someone's calendar.
I'm a bit like, not that I don't trust them to sit there and work at it for five hours rather than.
I just question whether that is the most productive use of their time.
Would that better with a two hour block saying I'm working on this thing, a half hour break to do whatever it is, maybe review a doc for somebody, just break clean and do something else.
And then another two hour block to say I'm going back to this thing.
Right.
Or do you enforce calendar usage across all the records?
I try to in my org because I think it's a healthy habit.
I think it, I don't, you know, no one's getting screamed out or fired for not using their calendar.
But I, you know, in places where I've had to go look because maybe someone's been struggling and we've needed to have conversations there.
There is a very high correlation between people who have one thing in their calendar every day, which is a 15 minute stand up and nothing else, and people who struggle over time.
Yeah, I have definitely seen a lot, particularly on the engineering side of things.
Like some people don't even check their calendar.
Right.
They have the one thing and then like they, that's not how.
I mean, I think it's for a lot of I, at least ICs.
It's not a natural thing to use a calendar because that's not like they have their stand up and that's like that's the meeting.
Right.
But I think it doesn't, I think maybe particularly people who come from a non remote background, that's because there is a sort of natural flow to the day in an office environment.
Like if you're there and someone needs you, they can maybe tap you on the shoulder or like you'll see things going on around you know, whether that's some kind of like stand up or other ritual.
I think it's very easy to assume that you will pick up on those things remotely and just not.
And so I don't know.
I, I don't.
It's not like I spend all day staring at people's calendars and I've got better things to do.
I just.
The first thing I go look at when I hear someone is struggling or I notice something is off is to go and see how they structure their day.
Like I would encourage ICS to use their calendar for them.
Just start.
One of the things I used to do at my previous employer is I ran a team.
We were building a sort of cloud platform for a while and on a Monday we would spend the two hours in the morning every other Monday planning, doing Sprint planning, you know, dragging things off the backlog and assigning it and maybe doing a bit of refinement there and then.
And I would encourage, and that would be up until about lunchtime and I would encourage wherever possible, the engineers on the team to not start cutting any code or doing any work for the rest of the day and to spend the afternoon thinking about the things they've been assigned and working out how they were going to spread their time over the next couple of weeks.
So like you have your sprint planning as a team, you get told, these are the things we'd like you to complete in the next two weeks.
Give yourself the time to sit down and go, okay, I've got this pile of things to do in two weeks.
How's that going to fit into my day?
Like, how am I going to schedule that?
Right?
To me, that was a really healthy habit.
Like, it would certainly help me understand when I wake up in the morning on a Tuesday, where am I going to get started?
Like maybe start writing a bit of an outline of the doc you've got to write or maybe, you know, go reread the design documentation for the thing you've been assigned.
Just take some time to kind of center yourself on what you've been asked to deliver.
And that's the same reasoning behind my Monday morning catch up where I try to sit down and think what am I going to do this week?
What's important for me to achieve this week?
Right.
Documentation, I think is, is super important in particular in that world.
Right.
How do you kind of build, think about, manage?
You say you use Obsidian yourself, but that's obviously for you, not for the team.
How do you structure, how do you enforce standard operating procedures?
Documentation process to avoid, in particular to avoid documentation rot and how to avoid documentation silos.
Right.
How.
What have you seen that works for that within teams?
I think the first rule of documentation in almost any situation, whether it's onboarding docs or engineering docs, is make it easy to contribute, make them easy to edit, put them somewhere where people are.
If your team lives in GitHub all day long, have a repo full of markdown that is compiled with MK docs or something, put them where people are.
If your team is a heavy confluent user for things, put your docs in confluence, whatever it is, doesn't matter and make it easy and obvious how to contribute.
It's a little bit like writing tests.
If you make them really hard to write, people don't want to write them even less.
Yeah, yeah.
I think the other thing is that on how stale they are and Those kind of things.
Like, new people are a superpower.
Like, new people are a superpower.
If you onboard somebody, if you're onboarding somebody and you say, here are the docs.
Every time they send you a question that ought to be setting off a little alarm, like, and obviously, like, that either wasn't covered or wasn't obvious in the docs.
Yeah.
And so we do have a.
I believe at Canonical, we have a process where as people have got to the end of their onboarding, they have a kind of small interview with somebody on our Talent Experience team to say, like, what was missing, like what didn't, you know.
And a habit that is really common, I think, as companies grow, is like, people end up collecting bookmarks right on their bookmarks bar.
And if you don't have the magic bookmarks bar, you don't know where things are.
And again, I think that's something that's really hard to break out of.
Right.
But you've got to try and build habits around like, okay, one of the tools that I use every day and are they documented somewhere?
Right.
We're actually doing this in Ubuntu at the moment, starting a whole thing around documenting processes in Ubuntu, the things that build the distribution.
Because over time that's just become sort of institutional knowledge in people's heads.
And a lot of it is the docs are out of date or they're not there and it's really hard.
If you think about Linux distribution is kind of like a big old remote company, right.
Like, it's distributed, it's complex.
This is a really hard problem to solve.
But I think having good tools that are easy to access and a set period by which you kind of review that.
Yeah, because I think the institutional knowledge is definitely a big problem.
You don't have to become as complex as doing a distribution.
Like, this is a problem for I think most companies, right.
I mean, just like, how do you set up a dev environment?
Right?
Like that's like as simple as that.
Like, well, this is what.
How it was.
But then obviously X, Y and Z changed and like the reading is now out of date.
Right.
Like that these happen.
But there needs to be conscious effort, I guess, in making sure that review Psychonact.
Yeah, I think your note on remote or new hires being a gold mine for this, I think that's spot on.
Right.
I've seen that firsthand as well.
Like, they're like, this shit doesn't work.
And you're like, well, it does, except that you have to do all these seven other things that is not quite covered.
Well, it's also, it's kind of a nice path, I think in software engineering it's kind of a nice path to like your first contribution in the company.
Like you check out the code repository, you go through the contributing MD or whatever, you try to get stuff, it doesn't work.
Open a pull request, right?
Yeah.
To correct it, like pull first contribution.
Right.
There's no.
I think that's an interesting way to get started.
It may not scale exactly to other roles, but in software engineering I think that works quite nicely.
Yeah, I mean that's what I know a key metric in some organization is like time to first commit.
Right.
Time to first commit to production.
You want to make sure that.
I think some companies try to do like you should deploy to production first day.
Like you should have code in production the first day.
Right.
Which is an extremely ambitious goal.
But that means that in order to accomplish that you need to get a lot of things right because you need to have all the tooling right.
You have the documentation must be spot on.
All that things.
Right.
It's.
Yeah.
Cool.
Let's talk about hiring in a remote world because I find this an incredibly difficult problem today.
I think I haven't spoken to anybody in the last two years that has said, oh, hiring is super easy these days.
I have a great pipeline that works, right.
Everybody's like, AI is great, but everybody's using AI.
So like it's hard without raising the bar too high where you then filter out everybody who's actually qualified from the process.
It's just so incredibly difficult.
Like we had at Screenly, we had a fantastic pipeline for upwork that just generated like really good candidates.
Like, weeded out all the crap.
Just a few screening questions.
You can just like, yeah, you know what you're doing.
Do the same thing today.
You're going to have even the most, least talented person going to give you like a PhD computer science.
Answer that question.
Right, right.
How have you.
What works today for you?
Yeah.
So I mean, our hiring process has been the subject of much debate on the Internet.
I think you have to pick how you're going to filter.
Right?
So we are in the privileged slash awful situation where we have I think 100,000 applications a month or something to canonical at this point.
Now a good number of those at this point I suspect are bots and you know, people writing little bits of code for themselves.
To apply to lots of jobs, you have to pick a Couple of metrics or a couple of things that are going to help you filter early in that regard.
One of the ways we filter out is based on academic track records.
So, it's not always been super popular.
But we ask people about their high school grades, their college grades, whatever, and we set a bar.
And if you don't get across that bar or you don't, you know, we try not to filter too aggressively.
Like if you haven't got great academics but you have proof that you have throughout your life done quite exceptional things, that's also fine.
But we try to set a bar that basically takes the 100,000amonth down.
And then we have a number of assessments.
So we have a.
I written an interview where we ask people questions about their opinions on various aspects that might relate to the job, their experience with things, the types of projects they've worked on, where they think Canonical is positioned in the market and who their competitors are.
Right.
Like people interested a little bit.
And this is kind of like a, you know, they apply, they chuck a CV in which in general is a relatively low effort thing.
You put a CV together, you might have a couple of different versions that emphasize different things.
You submit it.
That's a relatively low effort thing.
The next step in Canonical is you get sent this written interview which is a bit of a time commitment.
Like it does require you to.
It's 20 odd questions about your life and your thoughts on things.
And that is.
That's been controversial.
It has been mostly successful.
We've had some genuinely stunning written interviews from people where people really elaborate on their thoughts on things.
And that gives us a lot of insight for an interview.
Like it's a good starting point.
You read it before you interview someone.
You've already got some background on them.
It is.
The game is changing a little bit with AI, I think we do a lot, we ask people not to.
We ask people to put a sort of declaration they won't just use chat.
No.
I think some people still genuinely take it really seriously.
I remember doing mine for Canonical.
It was quite cathartic.
I quite enjoyed it.
But it is complicated if you don't have loads of time.
Sort of.
Yeah, I recognize that.
But in our situation, how do you go from 100,000amonth down to, you know, we're only a thousand person company.
Right?
Yeah.
And then we have a bunch of interviews.
Interviews are hard.
They're flawed.
Right.
They're flawed for a bunch of reasons.
Everyone is biased.
It doesn't matter how much you try.
Everyone is biased.
And there is one of the interesting things which I know I have been susceptible to and I try very hard not to be.
And I see it a lot interviews at Canonical.
People who are very relatable, very easy to speak to, very pleasant to speak to, tend to perform well when it comes down to the end of the interview and someone sitting down and going, am I going to give this person a yes or a no?
Someone who is very relatable and very enjoyable to talk to will nearly always do better.
And when we're trying to train interviewers at Canonical, I guess the question is like, one thing, one aspect of hiring somebody is how nice they are to work with.
That's definitely a thing you want to optimize for.
You don't want to work with someone who's not nice to work with.
But you also have to ask yourself, is this somebody who I want to have on my left and right?
When things get really hard, when we've got a production incident or we've got a scary bug that's really deep, does this person have the skills and knowledge or the drive to get through that?
Or are they just really nice to talk to?
And that's just really hard to get to the bottom of.
Right?
Yeah.
But let's go back to the first step.
Sorry.
Because like, okay, you get a CV landed on your portal, right.
And you say, you screening for academic records.
But do you actually validate that data?
Somebody says, oh, I graduated 4.0 from.
From Harvard.
Okay, cool.
Did you?
But like, that's.
Yeah.
So yeah, we do expensive process.
Right.
To do.
We do later in the process.
So one thing we don't opt.
We're not looking for like Ivy League schools and fancy Russell Group unis in the UK or whatever.
It is basically, like, how did you grade sort of against your peers or your.
Your colleagues at whatever institution you were at.
If you were at an Ivy League university and you aced it, good for you.
You were the top of the class.
If you were in a small school in a remote town somewhere in Asia and you still aced it in your class, that's good enough.
Like you did.
That's good.
We ask after people have gone through the assessments and they have had their first couple of interviews, they then do an interview with our HR talent team to talk about the logistics of contracting and salary and visas and all those kind of things.
And as part of that, we asked them to submit documentation to back up their claims.
This is not quite as aggressive as just asking for it up Front and I think slightly more so.
My understanding is a lot of the big tech companies do this kind of at the offer phase, often after seven or eight interviews.
And that I think is perhaps the wrong balance in the sense that if you're only asked for that right at the very end of the process, and there's something wrong with that, you've invested a lot.
By the time you get to hours, you have done some interviews, you've definitely invested some time.
But we try to ask for it before you go sort of down the rabbit hole into deep interviews with the team you're going to join and start talking about offers and those kind of things.
Things, right.
Reference checks.
How much do you index on that?
Not very much.
It's a hard one, right, because nobody's going to outright say this person was an.
Don't hire him.
Right.
In particularly in the US like that.
You could get sued over that.
Right.
So like, but we don't, as far as I know, we don't ask for references.
I've never done that at Canonical.
I also think they're always biased, right?
So like, if I think about it, if I were going to go and look for references, I'd go and figure out all the people I've worked the best with and done the best work with and ask for a reference.
That's how you do it.
That's naturally what you would.
Of course you would do that.
Right?
But do you even check if somebody claimed they work for Google?
Like, do you even validate that data?
Because again, these are like very expensive process to do, right?
To validate, like grades, validate that you actually work for a company.
You said, like, do you, how do you go about that?
So I don't know whether we do any formal check.
I don't think we do.
I would certainly say, I mean, I definitely go look people up on LinkedIn.
We work in open source.
Like the first thing I will do normally after an interview, I try to do it after.
So I'm not coloring the interview with what I might find.
I will go and look at someone's GitHub profile or their GitHub profile.
I will go, if it's obvious, I will try and figure out, do a bit of research.
Do they interact on mailing lists?
How do they interact?
Do they come across really well in an interview and then flame everybody out on a mailing list every 10 minutes?
Like, that's something I want to know.
You wouldn't have.
So I, I do like to put a bit of extra Time into just trying to learn what I can about somebody.
I'm not going to spend hours on it, but I definitely, you know, if someone says in an interview I'm a absolute testing that I'm completely obsessed with testing my code.
And I go to their GitHub and they've got 50 projects and none of them have any tests.
Like that's a weird thing, right?
Like it's an odd, there's, it's certainly interesting.
Yeah.
So I tend to put some time in.
Right.
Not to the point of obsessing over it, but I will try and get a sense of.
Okay, you've worked at Google as a staff engineer, you talked about this project.
Is there any evidence of that project around?
Like how was it received?
Did you communicate about it kind of thing.
When you do interview, like how do you, I guess, screen against AI tooling used interviews these days?
Because like you, I mean you seem, I mean we both read about these stories, right?
People using them in real time and they're getting feedback and what kind of questions do you ask and how do you probe when interviewing like this to understand like deeper levels?
So I think competency based questions are a bit flawed in this.
Like tell me about the GIL in Python.
Very easy to kind of read that off a prompt.
Right.
I generally try to ask people to relate things to their personal experience.
So like I will, when we're hiring seniors or managers, there's always a bit of component of the interview about coaching and mentoring.
And I will say to someone like, can you give me an example of where you have mentored somebody and it has gone well and you've been successful and can you give me an example of maybe where it's not gone so well and like reflect a little bit on why it didn't go so well, how you might change it.
Like it's a totally natural thing when you mentor somebody that either it goes very well and they get what they want, or maybe you didn't quite strike up a personal connection, it was less successful.
But I think being able to relate questions to personal experience is interesting.
Like talking about process change in an engineering team rather than what are your favorite engineering processes or what are the practices you'd like your team to adhere to.
A different way to ask that might be, can you give me an example of a time where there was something going wrong in a team and how you executed the changes to make that happen now?
Sure, there's plenty of clever AI tools out there that can give you a prompt, but if you then correlate it with maybe what they've written in their written interview to some extent, like you start to be able to pull together a bit more of a picture.
Right.
And also we.
You have multiple interviewers.
Right.
The multiple interviewers can talk at the end of it.
So do you always do team based interviews?
It's like, is it a one one interview or is it a team based interview with multiple people?
Always one to one interviews, as far as I know at Canonical.
But someone will have maybe three early stage interviews.
One might be focused on a particular technical skill, maybe go.
If it's a go thing, we'd ask someone to do a sort of coding type interview, problem solving questions about the language.
They might get an architecture interview.
Right.
Software design concerns kind of removed from the language itself.
And then they might have a leadership management skills interview or they might have a networking interview or something.
So we would then kind of try to correlate a little bit.
Right.
Like we don't always do like a big panel where we all talk about it at the end.
Like often the person in charge of that pipeline would basically read all of the scorecards and try to assess whether it's worth moving that person forward, basically.
Talk to me about the scorecards because I think that's something that in particular in newer organizations, like you don't really have the blueprint for this.
Right.
Like, talk to me about like, how are these something like you inherited in your structure hiring or is something that you build customized tweaks in your org?
Or like.
Yeah, like how do you try to compare apples to apples so you get like an unbiased view.
Yeah.
So we have developed sort of question bank type things.
So we try.
It's obviously hard, like if you have 50 candidates coming in and 50 different interviewers, the interviews are always going to be somewhat different.
Right.
And people's standards are different and what they expect is different.
So what we've settled on for now is we've created a bank of like standard interviews that we can pull into our pipelines and each.
So let's say it's a go interview.
There would then be a bank of questions, like 1015 questions that are kind of in the easy category with a sort of expected answer.
1015 questions that would be in the kind of medium difficulty and 1015 questions that would be in the hard category.
And then like maybe a handful of.
Unless you're literally the person who wrote the language, you might struggle to answer it.
And we allow the interviewers a little bit of Flex on which questions they ask depending on the person they're interviewing.
Like, we have the same question bank whether in the go interview, whether you're a graduate or a staff engineer.
Clearly if you ask all of the uber hard questions of a graduate, you're less likely to get a great hit rate than somebody who is a staff.
Right.
So not every single interview is exactly the same.
I don't think that's possible.
But every like, over time, the questions are very, should be very similar.
They might be tweaked slightly by the interviewer, but like they hint at.
It's not just the question.
It's like we're going to ask this question to see whether they understand complex use of the type system in Rust or whether they understand polymorphism or whether they understand functional programming versus.
So they're more conceptual questions.
Yeah.
And then some examples of questions you could ask.
Right, right, interesting.
So then you have the output and I guess there could be a scenario where multiple people ask the same question and then they can compare notes or like.
Or there are safeguards against.
Try not to have like.
We wouldn't ever give someone to just like golang interviews.
I don't think we do have the situation where sometimes we have someone who applies to like 5 different jobs with subtly different email addresses and we fail to notice it until somewhat later down the process when they say, oh, by the way, I'm in the process four other times, which is a little frustrating because we sometimes end up sort of being given the same interview, which is a bit of a waste of their time and hours.
Right, yeah, yeah, Interesting.
Okay, are there any like obvious red flags that you can spot like when you interview?
Like, what are like the one things where you're like, yeah, bit of a.
Flashpoint for me is claiming you're an expert in anything.
Like, I find it really hard to overlook when someone writes on their CV I'm like a 10 out of 10 expert in Python.
I'm like, maybe you are like.
But I don't.
All of the people who I know who I would class as 10 out of 10 experts would probably call themselves a six out of 10.
Right, right.
And so I find, yeah, it could easily be right.
Other red flags, I think is precisely being.
Being unable to relate what you're saying to a situation at work.
Right.
So unless you're going through like a bit of a career change where you maybe haven't had a chance to practice it at work.
But if you say, yeah, I'm really into Testing and I say, okay, can you give me an example of where you've been able to affect that positively in your role and they kind of struggle.
The other thing, you know, on the expert thing, anything where anybody claims to be an expert is an immediate point for me to question.
So if someone says I'm an expert in kubernetes, a question I might ask is, okay, you're sat down at a machine, it's set up like you've got a kubeconfig file.
Tell me how you would schedule an NGINX container and expose that to the Internet.
Yeah, if you fail to answer that question totally fluidly, it's going to leave a pretty poor impression, if you see what I mean.
And so I just try to, I don't, I'm not a fan of asking convoluted trick, complex questions.
I don't believe in that.
I think it's silly.
Right, because the, your day to day work is not going to be full of complex convoluted trick questions.
Might be hard, full of hard problems.
But.
Yeah, but so one of the things that I know a lot of you try to screen for, well and start screen for is like trying to screen for people with big E against or try to filter out people with big egos.
Right.
Because that's usually doesn't make for a good team member.
Right.
Are there any, have you found any good probe mechanism?
I guess it ties into like I'm the 10 out of 10 python and you're actually a 5.
But yeah, there's actually two sides of this.
Right.
Because one of the things that's really hard if you read someone's CV or you interview them is if there's lots of we.
So like we did this, we did that.
So there's a good side to that which is that this person can see the value of being part of a team.
I'll often say, like it's great that your team achieved that.
Like what was your contribution like on that team?
Which will be made up of diverse skills, personalities, views, like what was the strength that you bought?
Do you know what I mean?
Like, what was the thing I also would ask certainly of like managers, leaders, like what something they're most, you know, most proud of something a team has achieved, for example, or how do you, how, for example, what would their plan be for building a nice culture in a remote team?
Like how do you make help people feel connected?
That kind of thing.
But I think that's really hard to filter for.
And I would say the other thing is I.
I think you can get a lot from interviews.
I think they're really important.
I think having a diverse interviewer panel is interesting, but they're still flawed.
Like, until you actually work with a person for a few weeks, even if you did 10 interviews, it's 10 hours.
Right.
Still a work.
Single working day.
It's just not very much time.
Yeah.
So we are canonical.
Have a probation period for everybody.
It's mostly six months in some places for various legislation and things, it's less.
But I think it's important to use that and think objectively at the end.
Like, does this.
Does this person fit in with the team?
Are they able to do what you think they're able to?
That doesn't necessarily mean you have to let them go.
It's just maybe, are they at the right level?
Like, should they have come in as a senior rather than a whatever.
Should they have not.
Do you know what I mean?
Like, I think it's important to use that time to give a true.
Because I think as a manager, if you shy away from that, the rest of the team is also potentially stuck with somebody who doesn't fit that well.
And that's quite destructive, too.
Like, as uncomfortable as it is to say to somebody, look, you know, three months in, four months in, I'm sorry, I don't think this is working out.
You can give people a chance to improve, give them some feedback.
Like, it should never come as a total surprise to them, but if it fundamentally doesn't work, it's better to have that conversation early than double down on it and live with it for three years, four years, five years, right?
Yeah, no, absolutely.
The last thing I wanted to kind of dive in a little bit to is team autonomy and, like, being able to move independently of, I guess, micromanagement, which I think is, at least for me, is key in the real world.
What I mean, how.
How do you kind of foster autonomy in a team without, like, it turning into chaos?
Or like.
Like, how.
What are the safeguards?
How, like, what are the processes?
Like, how do you think about, like, you're setting up a new team?
Obviously, the right people in place is obviously key here.
But assuming.
Assuming you have the right team and with the right talent, like, how do you kind of structure that?
So I think two things.
One is it's all based on trust.
So I think you.
It takes time.
Right.
You have to understand how people work, how they communicate, what tasks they're likely to be Good at, what tasks they're likely to not be good at, where are they going to need help?
So like, as a new.
Coming in to lead a new team is hard, right?
Because you don't have, you sort of have to play it a bit intuitively.
I think the thing is to encourage autonomy by, but also setting clear boundaries so that you're setting them up for success.
So the three things I try to think about if I'm delegating a task or asking somebody to do something for me is like, who am I going to ask?
Like, who is the right person to ask for this task?
Based on a number of factors.
How busy people are, the skills they've got context, that kind of thing.
When do you need it done by?
Like put some time on it, like put a date on it and how and how often in and how are you going to get reported on for that?
So some tasks you might say, okay, we've got a year to do this.
Let's check in every month for the first six months and as we close in on it, we'll then check in every week.
That check in might be a standing agenda item in your one to one.
It might be a JIRA ticket.
And you just say to the person, hey, every two weeks at the end of every pulse, just write me a couple of bullet points on where we are with this thing.
If it's stalled.
That's fine.
Just.
Right.
This is still in my mind.
I haven't made any progress on it this week for this reason.
This is my plan for the next two weeks, right?
And so I just think it's like if you just say to somebody, particularly with the kind of more vague things like, oh, you need to increase engagement in your team over the next six months.
What does that mean?
Like, what does that mean?
Whereas if you say to someone, okay, like, you've got a bit of a problem, we've identified a problem with engagement.
You, your team, can you, by the end of next week come back to me with a plan with five points on it for things that you're going to like, what is your plan for addressing this?
Once you've got that, you can then say, okay, cool, we've got these five things, we've got a year to work through it.
Let's spend some time in the first two months on this.
Let's talk about that.
Just give people the, you know, I like.
There are certain ways that I like to be informed about how things are happening and that will vary from person to person.
Right.
It doesn't.
You don't have to be in there, ping them every day like hey, how you getting on?
I wouldn't do that.
Are you sure?
You just need to make it clear how you want to be communicated to as a leader and how often and by what means.
I think.
Interesting.
What.
I guess wrapping this up.
If somebody is joining or building a remote.
Either joining or building a remote team.
Like what are like the main things that you should really.
Build?
Like what are the.
Yeah, let's.
Let's take a step back.
You're building from scratch.
You have a complete empty canvas and you're starting a new company.
Where would you focus on?
Were you building like your first 5 headcount?
Like how would you structure that team like you do?
John John Co is now a new startup doing AI.
Insert blank.
Right.
So I think the first thing is, I mean it's kind of obvious hire great people.
But I.
By that I mean you probably want for your first few hires to hire people who naturally tend towards more structured work.
Like you.
You want to have people who I think are going to be interested in communicating and not being in meetings all day, but communicating and interested in the craft of building the remote company.
Right, Right.
So people with a bit of a track record of understanding asynchronous distributed work.
I think you probably don't want overly kind of egotistical, extroverted people.
I talk too much.
I talk loads.
Like it's a thing, it's a flaw.
But if you have five people and they all want to talk loads, that's maybe not great.
But you do want people who are going to I guess set some structures and boundaries, I think.
Right.
Because it's very hard to retrospectively fit the remote culture you want to a company when it's grown to 100 people.
Yes.
If you start with a small group of people who have somewhat aligned values as you onboard more people.
The example that people will see is the example you want.
Right.
So you have to have people who are somewhat opinionated and also somewhat willing to compromise.
Like everybody has a slightly different way of doing things.
There are VPs left and right of me at Canonical who I respect the hell out of who run their orgs completely differently.
To me that's fine.
Right.
So I mean like they're very effective.
They get things done.
People in their team seem happy.
Yeah.
But I think when you're really small it's.
That would be kind of hard.
Right.
You've got to have some aligned and even you Know, like even these people who run things differently, there are some common values at Canonical, some common boundaries on how we do performance management and hiring and, you know, roadmap reporting.
Are there any other composite?
I mean, GitLab is obviously a big one that if you want to pull a playbook from somewhere out in the open, where would you pull a playbook for like running things and like.
Or find more information, I guess.
Like where.
Where would you draw inspiration from?
I think it always has to be a mix.
I think with anything leadershipy, if you just try to imitate something else, it's inauthentic and will come across as such.
Right.
So I think you could definitely take some inspiration from GitLab.
You might like to hope that people would maybe take some inspiration from Canonical.
We've been doing it for 20 years.
But I would, I would generally encourage people not to pick a company and just solely abide by like.
So one of the companies I really enjoy reading about is Fly IO.
They're really interesting.
It doesn't mean I would 100% imitate everything that they do.
Like, they.
That the combination of like, market people, et cetera is always going to mean that your setup is going to be a little different from everybody else's.
Right.
So I would just say go pick five or six companies of varying sizes.
Like there's interesting things that can be done in very small companies that make no sense at big companies and vice versa.
So I would just try and take a broad view of four or five things, companies that you admire for one reason or another and try to form something that works for your group.
Right, Fair enough.
All right.
This has been really good, Jon.
I think we've had quite a lot of insights from your many, many years of managing Remote.
Any last words, any shout out people that you need for your teams or things that people should be on the lookout for in the world of Ubuntu Canonical.
Lot's happening in Ubuntu.
We are hiring like crazy for Ubuntu.
So if you're interested in full time remote work on really interesting open source, then definitely take a look at what we have to offer.
But no otherwise.
Thank you very much for having me.
Awesome.
Again, pleasure having you on show, Jon.
Thank you so much.
Have a good one.
Cheers.
Found an error or typo? File PR against this file or the transcript.