How I Work is having a little break over the festive season, so I've picked a handful of my absolute favorite episodes from the last eighteen months to play for you in this best of series. I hope you enjoy, and I'll be back with new episodes twice weekly from January twenty eight.
Do you remember when working from home was a rarity.
Maybe you knew a couple of contractors who had a home office, or you'd heard of a few companies with pretty flexible working arrangements.
Then all of a sudden, it seemed like almost.
Everyone started working from home thanks to the pandemic, and things changed for good when we all realized we could get by with things like Zoom and Google Docs.
But what if we were wrong?
Adam Nathan is the co founder and CEO of Almanac, which has structured collaboration software for remote teams. Worried that where we work has changed, but how we work hasn't.
So what needs to change?
Well, it all starts with Almanax principles of modern Work. My name is doctor amanthe Immer. I'm an organizational psychologist and the founder of behavioral science consultancy Inventium, and this is how I work. A show about how to help
you do your best work. So if you visit Almanac's website, as well as learning all about the software, there is a whole section dedicated to Adam and his team's thinking about how teams, and especially teams that don't work in the same location five days a week, can think differently and a whole lot better about work. And I was keen to know why did Adam even create these principles in the first place.
We started the company off the pretty simple thesis that where we work has changed, but how we work hasn't. And I think anyone who's lived through the past three or four years knows what I mean. But just to put some data on it, before the pandemic, about twenty two percent of at least white collar professionals in the United States worked remotely or in some kind of distributed context to the numbers closer to seventy percent, so you're seeing something like a four or five x increase in
remote work. And the number has actually grown since the end of the pandemic. And I don't love the I don't love the phrase remote work. I'd rather call it internet work, because what I think is really happening here is this broader shift from working in the office to working on the internet, and this has happened in phases over time. Even before the pandemic, a lot of people, even if they went into an office, were working in Google Docs, communicating on Slack, meeting on Zoom. A lot
of large companies were distributed. Before was cool because they had offices across different cities and even countries. But remote work is the pandemic was really a one way door inter remote work for a lot of people, and it was obviously a surprise and overnight people couldn't go into their offices anymore. And it turns out that we could kind of get by at work with the basics of
creating and collaborating with the tools that we had. But what happened also during the pandemic is that indicators around things like burnout and job satisfaction and management efficiency started blinking red because we were still all working online as if we were in an office from nine to five in the same place. So meetings and messages started to become overused as tools of getting stuff done when people
couldn't be around their colleagues anymore. Things like trust and connections started to decrease precipitously, and so people started to burn out at work and become very dissatisfied, and even when before the pandemic that wasn't happening. And we think the root cause at Almanac is that we've now changed where we work, but we haven't actually evolved yet how
we work. And so this mismatch between kind of the context in which we now all work and live and the way that we're doing our jobs is causing a lot of pain and frustration to extent that some people quit their jobs or take themselves out of the workforce, which is obviously not good for them, but it's also not good for our economy.
It's not good for businesses.
There's actually been a slowdown in innovation over the last twenty years, where a lot of the growth we're seeing today is actually a byproduct of fundamental innovation that was created before nineteen seventy. And so I think in order to keep keep our planet spinning and making sure that we're solving our greatest challenges and reaping our biggest opportunities.
That requires great collaboration.
It requires teams to work well, and that means we need to figure out how to work together in this new normal. And so when we started the company, we weren't just trying to build a better tool. In fact, there's I think nothing wrong with document editors like Microsoft Word or Google Docs. It's more that people are are trying to use a tool that was designed for a different world for something entirely different.
And what we.
Think people really need is a different way of working, not just a different tool. And so when we started the company, we didn't just sit down and start coding away based on philosophy found and other products. We went first to talk to the best teams on the Internet, people at companies like Amazon and Apple and Netflix and get Lab and do is to understand, like how they
were working so well. In many of these cases, they figured out how to optimize their processes, their management styles, their norms for the Internet way before the rest of
us did. And so we've done over five thousand interviews at this point with people from these super high performing teams to understand, like, how did you figure out how to work, what was the initial insight, how's that evolved into a best practice, And what we did from there was kind of abstract away from specific instances to broad generalizable principles that anybody can use, regardless of their company or context, to work faster on the Internet.
That's amazing.
I love the depth and the research that went into creating these modern work principles. I've read through them all, and you know, when I was preparing for this interview, I thought, I'll just I'll pick up my favorites, But really I've picked out most of them because most of them are my favorites. So I want to go through a few of them because what I'm really interested in
is what does that look like in practice. So let's take principle two, which says the best managers focus on outputs and outcomes instead of hours worked or messages sent. So I don't think you get much argument from you know, forward thinking leaders about that. I feel like a lot of leaders and managers say, you know, it has to be about outcomes and not ours, but they don't necessarily behave in that way when they're, say, evaluating their staff.
So I want to know, how do you do this practically speaking.
Yeah, it's a great question.
And just for some context here, if you think about historical management theory, modern management really came about with the advent of the modern factory in the nineteen thirties and forties, and the job of a manager there was to measure outputs. And the outputs in this case was like stuff coming off the factory line, and some managers could sit above the factory floor and you know, look at like reports essentially of outputs and see how the factory was performing.
And in that case, workers were kind of like cogs in a machine, you know, they were sorting stuff and doing specific, single oriented jobs, and so management was I'm sure it wasn't simple then, but it was pretty straightforward. As work. A lot of work moved from blue collar work to white collar work, from kind of factory work to creative work. You couldn't see the output of individual
employees anymore. In many cases they were complex or creative, and so the job of the manager short to evolve to managing presence, which is to say, did the employee show up at a specific time, were they in the
office to another time, did they attend meetings? Even things like how how good of a communicator are they, how good are they appearing to collaborate, And a lot of that I think has been kind of parodied and reviled in modern media around kind of how a name that is because even in the office, just because you showed up wasn't necessarily correlated to whether you were doing a good job. But it gave managers the same kind of control I think as standing above a factory floor used to.
And now in modern world where we're not.
In the same place at the same time, we've removed the ability for managers to manage my presence, which I think is a good thing because it allows us to fill it in with something better. But to your question, how do we give managers tools to actually manage outcomes rather than just presence? And I think the key to
the insterercomes down to transparency. And so if you think kind of about a spectrum, in order to get to outcomes, you first have to measure outputs, because somebody can't be doing a good job if they're doing no job at all. And so I think the core form of this is to actually just look at tasks of the things I've asked you to do, did you actually do them? If you haven't done them, there's no way that you did any any job at all. You could do a good
or bad job, you've done nothing. And so creating transparency around kind of the basic collaborative tasks that people do every day, I think is the foundation to starting to measure outputs and outcomes instead of things like presence and so in our tool in Almanac, we have a concept call request, where you can ask someone for feedback or approval, or to complete something, or even just to read a document.
And this is really similar about how software engineers have been working largely asynchronously for twenty years, where even when they're on the same place as software engineer, through tools like GitHub, can ask another engineer to review their code or approve something. And in GitHub there's basically like a lot like ann activity feed from Facebook where you can actually see did the person first like see my request, kind of like a red receipt in I message, You know,
have they looked at it? What comments have they made that they're attached to the request, What metafeedback have they given? And so there's a lot of clarity around like where the request is improp And if you think about like even basic task management tools from the office culture era, you may ask somebody in an office to do something, but even then you really have any clarity like where is this work with Susan?
You know digjo complete the task.
And so I think for managers to start to manage by outcomes, you have to dis understand is your team doing the things you ask them to do, and that starts to get you a sense of kind of quantity of output, and then you can start to layer on quality. And I think ways to measure that are to look at again through transparency and analytics. What was how many comments did people put on their work? How many comments did they put in other people's work? How do you
did people react to those comments? Where their threads, where
they're things like reactions. If you think about kind of the consumer world as a parallel for enterprise, if you go on Twitter or Facebook or Instagram, you can generally tell the quality of a post by the amount of reactions that it's getting, the number of likes, amount of comments that engagement in other words, and I think starting to apply a lot of the same principles to enterprise collaboration on comments and tasks and reviews, and then aggregating
those analytically so that a manager can see how did Adam actually do this week? Did he complete his tasks? Did people think they were good? Was he responsive to what other people on the team need you can start to get a picture of kind of quality and quality of output.
By individual, and.
That starts to give managers the tools they need to understand is the team doing their jobs?
Is the team moving the needle?
And that I think in the end builds trust and a sense of connection between managers and their teams, because even if they're not in the same room, the manager is a sense of is the ball moving forward, who's contributing to the work, who's falling behind? And I think that lack of that lack of trust that exist today for a lot of teams comes from a lack of transparency.
It's interesting, like the distinction between outputs and outcomes. And I know at Almanac you use okay as so objectives and care results.
That's correct, isn't it, Adam, We built our.
Own system because I think all cars can be kind of like a dark art or r magic for a lot of teams where they're actually quite I think they take a lot of work to implement, and many teams don't do them very well. So we've actually designed our own system at Almanac that's largely based on setting a strategy every quarter, translating that down into goals per month than to goals per week, so that everybody understands how we plan to get to the long term place we
want to go. And then having individuals in their work streams list their own goals for the week in a public document and at the end of the week grade themselves and if they got that work done, and so on this output point I was talking about before, understanding like did you do the thing you said you were going to do? We built a system at Almanac largely based around these weekly tasks just to understand like are
people doing their jobs? And you know there are cases, of course where people are doing their work but it's not very good. But there's a very strong correlation between people who aren't completing their task and people who aren't producing outcomes in other words, moving the needle on an important project.
The outcomes almost like the quality and outputs sort of the quantity or is that simplifying it too much?
It's basically it's about impact on the spectrum, and so outputs I think of as a as something that happens as a direct result of your activity.
And so if.
Let's say we're playing a sport and we're playing baseball, and output is you know, the number of times that I am batting and I swing and I connect with the ball. You know, it's a verifiable activity where my action led to a direct result. Everybody can see it. It's pretty easy to measure whether or not I'm hitting the ball. How is how much is that correlated with my team winning the game?
Who knows?
Probably not that much. I think about an outcome though, as my team winning the game. You know, it's something that happens that I'm contributing to, but it's not a direct result of my activity. And so out outcomes for businesses are things like we want to grow this quarter, or we want to improve profitability, or we want.
To produce new products. An output might be if.
I'm an engineer, you know how many lines of code I've written, if I've completed a feature. If I'm a marketer, you know how many ads I've released or how many lines, how many.
New tweets I've sent.
If I'm a you know, salesperson, it's the number of calls I've made or number of demos I've booked. Just because I've you know, done it a bunch of demos doesn't necessarily mean that the company will grow, but they are correlated, and so there's this relationship between the work that I'm doing, how much of it I do, the quality that I do it at, and the long term goal of the company that many people are contributing to that is also affected by outside factors. And so outcomes
are often what companies say their goals are. And the trick is how you tie that to the actual work people are doing every single day.
And so is what you're saying that the goals that individuals are setting, they're the outputs, and then they ladder up to company outcomes. Yes, okay, interesting, And so in the language of okas, the outputs the key results like the quantifiable, measurable things that the people are ultimately assessed on.
Yeah.
So in ok ours okay stands for objectives and key results. An objective is kind of a qualitative big idea, something like, you know, this quarter, we'd like to grow the business, and a key result is attached to that objective. That's a quantifiable metric that will help the team understand if
they achieve that objective. So, if our goal is to grow, if our objective is to grow the business, a key result might be, you know, revenue increases fifty percent within three months, and so you're measuring the key results to understand if you've reached the objective, and then those often ladder down. If that's, for example, a company goal, those
could ladder down to team goals. So product team is thinking about how do we build new features, the sales team is thinking about how do we sell those features.
Marketing team is.
Thinking about how do we increase top of funnel awareness, and that can let it down even further to individuals objectives and key results. So the system is meant to scale from what a company sets all the way down to what individuals are doing every day, so that there's broad alignment and clarity through the organization.
One of my other favorite principles, As I said, they're all kind of favorites, but I really like this one. Principle seeks collaboration should always start with a document instead of a mating and I feel that that is completely conjurary to how most organizations run things. So can you tell me if it starts with a document, what does that document look like?
That's a great question, and I agree with you that it sounds simple write everything down, but it's very unintuitive to a lot of people and not often followed in practice of what to write down. I think the best
practice here is to use templates. And so if you think about every document, not as a lot of people do, as kind of a place to store like a final version of a contract or an agreement, something that happens at the end of a largely informal process that's being conducted in meetings, but really as the process itself, as the place where you write down the initial idea, where you get feedback on it, where you get formal approval, where you then distribute it as knowledge to the rest
of the team, even something that then gets updated over time into future versions. The document isn't just kind of like a piece of paper that goes in a filing cabinet, as we used to regard them, but really as the core collaborative surface for the team. And so the best way to kind of codify a process so that people follow it is to use a template. And so I think the best practice here is to have document templates
for different types of processes. So, for example, a PRD is a great template use for creating and aligning as a team on product requirements for a new feature. Using a sales template is essentially a form of starting a process where you go through negotiation with a potential customer, agree on terms, get them to sign it, and.
Then distribute it.
And so.
The simple but hard answer is that creating good templates for the key processes that your company is doing is the best way to make sure that those processes begin with a document rather than a meeting, And by starting with basically like a plug and play document, you can actually not just reduce the number of meetings, but reduce the amount of hours you're spending on the work, because most of what companies are doing every day aren't like
totally new creative processes. Even if the point of a process is to come up with a creative idea, the process itself is often codified and structured in some ways, and what a lot of companies are spending time doing is reinventing the wheel on the process itself, and templates are a great way to prevent.
That from happening.
We will be back with Adam soon where we talk about what actually deserves a meeting at Almanac and what is best done asynchronously. If you're looking for more tips to improve the way you work can live. I write a short weekly newsletter that contains tactics I've discovered that have helped me personally. You can sign up for that at Amantha dot com. That's Amantha dot com. So at Almanac, what deserves a meeting?
Yeah, I think there's two types of meetings that I have found really valuable. One type of meeting that we have often that I think is worth the time is when we have a problem to solve that is a complex problem that has a complex answer, where you can't just send a document to somebody and say.
Do you approve or not?
And to be clear, there are a lot of processes where there are simple answers, simple questions that can be automated and completed asynchronously. And so you know, things like approving marketing copy or redlining contracts or getting feedback on new product proposals. Those are all things we don't have meetings for out Almanac. But when we're, for example, trying to figure out, you know, what's our approach to AI or what should our growth goal be this month? Those
aren't things that are easily done asynchronously. They often require lots of input from diverse stakeholders. A bit of conversation where I think the conversation can lead to a better outcome or answer than we could ever get to if we were just communicating linearly and for example at comments thread. So those types of complex problems with complex answers I
think require a meeting. I think a second type of meaning that we have that's helpful is something that's urgent, where you actually just need to get something done now, and we often that's where often people are in slack or another communication channel and we're just getting on the phone can actually get to an answer faster. And the third important type of meaning is to create a sense
of connection and reinforce the culture of our team. And that's less from like we have a business objective to complete and more we're a bunch of humans working together every day and spending a majority of our working hours together and recognizing that we are people.
And that we need to connect with each other.
And part of the joy of work is working with is getting to spend time with people that you like and respect and trust. And I think a great way to reinforce that is through meetings where you get just so much more information by seeing somebody their body language, how they react to what you're saying. And we actually spend a lot of time in our kind of weekly or even daily stand ups starting with a kickoff question.
We have a whole library of them at this point, like a thousand questions that we figured out over time, things like what did you want to be when you grow up?
Or what you're perfect Saturday? Or you know, what do you serve.
On Christmas Evening? That help people understand more like who they're really working with, because we're all so much more than our jobs, and I think spending synchronous time to get to know each other and build culture ultimately leads to better work, more satisfied teams, and faster business value.
I want to talk about principal seven, which is the more you ask for feedback, the better your end work will be. I've got a few questions around that. Firstly, when do you ask for feedback at what point in a project?
All the time, And we've learned as the principle has gone it and we should have learned this sooner, judging from all the researchery done where people talked about the importance of feedback that you know, essentially you know if you think about I think one a lot of the universes.
Compounding that progress over time becomes greater and greater because you're actually just building on the progress of the past, and so that it turns into a log curve, which looks like you know, technology growth, but that's also how growth works for people and their behavior and teams and their actions. You know, it often starts looking pretty incremental,
but over time that that reaches an inflection point. And so if you believe in compounding, what that means is that you know, in a given period of time, if you were to only iterate once, let's say you you know, your version was so good that it was twice as good as the thing you did before, then now you
have a two x improvement. But if in that same period of time you were to iterate let's say ten times, but each of those times only make like ten to twenty percent progress, you'd end up with a byproduct at the end of that.
That's something like eight to ten x better.
So what matters, just based on kind of math, is not like how good you are a version of a version on something, but really the amount of times you try, and by trying me the amount of times you put something out there and get feedback on it. And I think that's true for basically every function. The amount of times you show a prototype or a new feature to
customers and get their feedback. Often people want to hold it and try and make it perfect, but it's actually better to get it out there get feedback, because you're going to learn so much more about what's good and what's bad and be able to improve on the good things and get rid of the bad things. It's true in marketing where you're testing copy. It's true in sales where the number of times you kind of pitch something to potential customers. It's true in management, where you're asked
feedback from the team. People don't like asking for feedback because it's really uncomfortable to expose yourself and to potentially be wrong and to hear things you don't want to hear. But I think that's if you can learn how to do that and be comfortable with the discomfort, you end up gaining so much more and you end up winning so much bigger because the end result is so much better than anything you could have done in the echo chamber of your own thought.
Some Beliefs Principal three says creating a calm, sustainable team culture with no surprises and few fire drills leads to
faster velocity and better work. I feel like in like all the different organizations that I've worked with in terms of clients of Inventium and even within Inventium, you know, I can I can think of so many surprises and things that come up that you just could never have planned for, like that are outside of our control, like a client requesting something at the last minute, or a supplier changing the terms of a contract or something like that.
How again, how does this actually work in practice at Almanac?
I think if I were to boil the modern work method down to six words, it would be more structure, more transparency, I fewer meetings. And with this idea that a lot of the work that humans I think are meant to do should be creative work. But we are spending a lot of time on repetitive processes that aren't
at all creative, and we are dedicating time. We are treating things that happen continually as if they are creative processes, as if they're new phenomena when maybe it's near the first time it happens, but if it happens a second or third, or tenth or thirty at time. It's something that we have seen, it's something that we have done.
We may have been good at solving it or bad at solving it, but we certainly have experience, and so we can start to codify a process around it, learn from what happened, and if we apply structure to it and intentionality to it, we can take it from something that takes creative brain power and turn it into something that's more automated, something that we don't need to meet about or talk about, but something that just runs smoothly
in the background of the organization. And so I think a lot of what we are advocating for is even things i'd be surprises upfront or things that.
Might be unpredictable, and when they start.
For at Almanac, it's things like customers filing tickets for bugs or asking for future improvements, or the site going down god for a bit. You know, those aren't things we can predict. But everything that happens after that moment is something that we can handle. And even we can design a system to account for the unpredictability and the risk. There's that something humans do all the time with systems design.
Every system has a bit of ambiguity in it, and so there are ways to mitigate or plan for that that uncertainty. And the way he started just by recognizing their's uncertainty and talking about it and coming up with a process. As I'm sure you have an inventium on
things like you know, customer fire drills. I think where a lot of teams go wrong is they don't something happens the first time and it is truly a fire drill, and then it happens the second time, and they treat it as if the first time didn't happen, rather than after it happens, doing a quick retrod and saying.
Hey, hey, what what just happened? How did it go?
Like?
Do we think it's going to happen again?
And you know, should we build a process for it? And I think the more structure you have and how your team works, the more fire drills don't have to be fire drills, and you can spend that time instead on creative and meaningful work that is really moving the needle. The reasons people actually wake up in the morning to do their jobs and the reason the company exists, which is to serve customers and add value.
I'm reflecting on the last couple of weeks that Inventium, where I feel like we have had fire drills in the form of consultants or inventeologists who were booked into deliver workshops. One got COVID, another got really sick with a flu like bug, and they were down and we were like struggling to find replacements.
And I kind of I look back on.
That now and it's like, that is happened many times in the sixteen years that I've been running in Ventium. We've never actually sat down and said, Okay, what is our process for when this happens, despite the fact that it has happened many many times in the time that I've had this business. So it's yeah, for me, that's really interesting hearing you, because I'm like, yeah, what about humans.
You can't predic humans, But it's like, no, you can predict that.
Humans will get sick and they will need some sort of a replacement in the thing that they were meant to be doing that week.
Yeah, you can certainly account for the uncertainty. There's whole industries around this management.
That are about that.
Most of our legal and governance systems are really about accounting for risk and uncertainty and just two anecdotes for you.
One.
When we started this work, I used to think that people got satisfaction from work, from spending time on deep work. There's whole books that are really great written about this, and I thought it was all about flow and focus and that's where people find meaning. And when we talked to these amazing professionals, what people evaluated whether a week was effective based on if they got stuff done on
their to do list. And the enemy of getting stuff done is a fire drill, and so what people hated them most wasn't that they sometimes are just processing cast but it's when something got in the way of them being able to cross stuff off their to do list.
So it shifted our thinking from how do we enable through our tool time for people to do deep creative work, to how do we help people just get through their to do list faster so that they can and get done with their days get back to other things that
might matter them. Because everybody hated ending a week feeling like they weren't able to get important work done for themselves and their teams, and so this idea of minimizing fire drills became an important principle to this end, because it's not just about something that makes the team faster, but it's also directly correlated to people feeling like like their week was a success and getting meaning and value from work. The second idea to your point is that
we love this slogan from the US Marines. Slow means smooth and smooth means fast. Where a lot of teams go wrong isn't that they had to respond quickly to a new event that they've never seen before.
It's that they.
Don't stop afterwards, take a breath and say, like, what just happened, how did it go? How do we make sure that the next time this happens that we have some smoothness in how we respond. Because this, when you have calmness and order and structure, it's not just a more enjoyable experience, it actually increases business and team velocity, and so you can actually go faster while it feels
like everybody is moving at a sustainable pace. If you look at paddling races, what you'll see is that the teams that win aren't the teams with the strongest men. They're the teams that are putting their paddles into the water at exactly the same time, because when everybody is moving together, you get more momentum behind the boat, and that's much more important than just like chaotic strength throwing stuff into the water that actually ends up working at
cross purposes. And so what's critical is that a team is working together with some structure, with some transparency, so that in the end everybody feels like they're doing work that's sustainable for them, but the whole boat is moving faster as a result.
Adam, For the listeners that want to connect with you, what is the best way to do so and also to connect with Almanac.
Yeah, So if you're interested in everything we've talked about today, go to Modern work method dot com. I think we have hundreds of free templates on there that help you take a lot of these ideas and turn them into practices your organization can use now. And if you're interested in actually adopting a lot of these behaviors, the whole point in building Almanac is to make a seen less for your team, just to start to work faster and
better without you having to spend time on it. And you can get a demo and try the product at almanac dot io and I think.
I'm on Twitter and LinkedIn at Adam p Nathan Adam.
I have loved this chat.
I feel like I've had quite a few penny drop moments that's really making me rethink how we do things at Inventium.
So I just want to say thank you for.
You for putting such deep thought into how work can be done better in this new world.
Of work that we're in.
I've personally just found our chat so incredibly valuable, So thank you well.
Thank you very much. This has been fun.
I hope that you got as much as I did from this chat with Adam.
I know that it gave me so.
Many ideas to think about how we work at Inventium, where we've been a remote first organization since twenty twenty. And if you know someone who's currently in the process of maybe rethinking how they approach their work, maybe you might want to share this interview with them to help spark some thinking. Thank you for sharing part of your day with me by listening to How I Work.
If you're keen for.
More tips on how to work better, connect with me via LinkedIn or Instagram.
I'm very easy to find.
Just search for Amantha Imba How I Work was recorded on the traditional land of the Warrenery people, part of the cool And Nation. I am so grateful for being able to work and live on this beautiful land, and I want to pay my respects to Elder's past, present and emerging. How I Work is produced by Inventium with production support from Dead Set Studios.
The producer for this episode
Was Liam Riordan, and thank you to Martin Nimba who did the audio mix and makes everything sound better than it would have otherwise.