Podcast 194 — The GP Book Club: Ryan Singer's Shape Up

In Shape Up, Ryan Singer shares the methodology that he and his colleagues at Basecamp use to 'ship work that matters'. The book presents itself as a guide for software developers, but what lessons does it hold for L&D?

Written by Ross Dickie
Published 12 May 2020
Share
Podcast 194 — The GP Book Club: Ryan Singer's Shape Up

On this week's episode of The Good Practice Podcast, Ross Dickie is joined by Owen FergusonNicola Boyle and Ross Garner for the third in our series of bimonthly 'book club' episodes.

We discuss: 

  • Our general impressions of the book
  • The differences between Basecamp's approach and other product development methodologies
  • Key takeaways for L&D
Ross Dickie

Hello, and welcome to The Good Practice Podcast from Emerald Works, a weekly show up at work performance and learning. I'm Ross Dickie, and this week we're returning to The Good Practice Book Club to discuss, Shape Up, by Ryan Singer, who is the head of strategy at Basecamp. I'm joined as usual by Owen Ferguson, hello, Owen

Owen

Hello, Ross

Ross Dickie

Nicola Boyle, hello Nicola

Nicola

Hi, Ross

Ross Dickie

And Ross Garner. Hello, Ross

Ross Garner

Hello, Ross

Ross Dickie

So, Owen, this book was one of your suggestions, do you want to get us started by just giving us an overview of what it's about

Owen

It was, partly because I'd already read it and partly because it's quite short, but actually because I read it to inform my own practice and I thought it was a, it, it made me think about certain ways of working that we've got here and we've already made some changes off the back of it. So, Shape Up, is basically about how Basecamp organizes their own product development process, but it's presented in a way that you can replicate in your own working practice. So it runs through the whole process from ideation all the way through to final delivery of a feature or a product. And it introduces a whole bunch of tools and techniques that you can use in many different kinds of projects that involve the delivery of some kind of digital artifact. So there's some key concepts that are all about reducing the risk that you run in those kinds of projects, of creeping scope and deadlines that continually get pushed back

The basic idea in there is that the product leader shapes or defines a piece of work, whether that's an improvement or a new feature, concretely enough, so that the team can get moving in the right direction, but without so much definition that the team maintains this autonomy to develop its own solutions. So it's trying to strike the right balance between saying, ""Here's what it is that we need to achieve, and here are some constraints,"" but without actually developing the whole thing. Which sounds vague, but they have a whole bunch of examples and specifics that explain some of the nuance that sits in behind that idea

And then they also introduced this concept of a six-week work cycle, which they say gives them a reasonable timeframe for building something meaningful, but has a firm deadline that encourages a team to use the time efficiently, and with intention. And probably finally, just as a summary, this very brief summary that I'm giving

Ross Garner

Might as well just have read the book, hey

Ross Dickie

I was going to say, nobody needs to bother now, Owen has summarized the book. Two minutes

Owen

So it's probably worth noting that it throws out some of the less useful ceremonies, or dogma, that sits behind concepts like scrum and Kanban, whilst, in my view, it routines that core philosophy behind a genuinely agile way of working. So, yeah, that's the longer summary. If I was to summarize it in a sentence, it would be, it helps product teams deliver more stuff, more efficiently

Ross Dickie

Yeah, I think that was a very good summary. One of the things I, apart from the brevity of the book, one of the things that I found while reading it is that it made me really want to try out Basecamp. I found all their arguments so compelling, or that these are the processes that they're going through, and their decision making in how they're going to develop their product. It was very convincing, and I found myself thinking, I wonder if I could use Basecamp to improve my workflow. Ross and Nicola, what were your general impressions of the book

Ross Garner

When Owen says it's a short book, I would go so far as to say, I don't think it could be shorter. We read quite a lot of business books in the Emerald Works world, and there's a reasonable number of them, looking at Dan Pink, for example, where you do kind of think, this could have been a blog, but this book is absolutely, there's no fat on it at all. It was really like a long blog, and beautiful instructional design on it, in the way that it was chunked down and well organized, easy to navigate, lots of practical takeaways. It was really well written

Nicola

Yeah. I agree. I enjoyed it more than I thought I would when I found out what it was about, I thought, ""Not sure I'm going to enjoy this."

Ross Dickie

Last time we let Owen pick the book.

Nicola

Yeah. I agree with that. What Ross just said, it was nice and easy to read, easy to navigate. It's great reading an ebook actually, because at first I felt I much prefer actually reading paper books, but this was a really nice experience reading this ebook, and yeah, the fact that it was quite concise was helpful as well

Ross Dickie

Yeah. It seemed appropriate that was so concise, given their emphasis on completing these product cycles within six week periods, it would have been a bit ironic if they'd then rambled on unnecessarily

Nicola

Yeah. And it also inspired me to read their other books as well, because I understand they've got quite a few, so I'd be quite interested to read them

Ross Dickie

Yeah. They're also freely available on the Basecamp websites also, we'll post the link to those in the show notes. Owen, so you said that you've already implemented some of the advice in the book within the product development team at Emerald Works. What sorts of things specifically, have you been doing differently off the back of this

Owen

Well, we are experimenting with some elements of it, and some aspects of it we already had in place anyway. So if you take this concept of the six-week working cycle, what they're not saying is, everything should take six weeks. What they're saying is, six weeks is sufficient time to do most big things when it comes to software development, provided you narrow the scope well enough at the start of it. So when they organize their work, they tend to have a number of things that are in flight at the same time. So they might have what they call small batch items, which are things that take one or two weeks, and they might have a few of them, and they might have one big marquee thing that they're working on that will take a developer and a designer, the full six-week period

And we have that kind of a cadence already, so we work to a, well, it's actually a six plus two week working cycle, six weeks when you're going hard at it, you're working according to a defined piece of work, and then there's a two week cool down where you use the time for personal development, or paying down technical debt, or dealing with any fixes that you want to put into place, or that arise once piece of work goes live. So there were some things that we were already doing, some specifics that we've started to introduce

There's two techniques that they use, I think are quite interesting. One is what they call bread-boarding, which is, when you're creating, or you're first figuring out how to set out the electronics for, I don't know, let's say a toaster, for example. The idea behind bread-boarding is that you set out all the components on a wooden board and you hook them up with wires. And the intention is not that that's what's actually going to appear in, it is to just make sure that you've got all the logic worked out, etc. So bread-boarding, in their world, is that digital equivalent of that, where you sketch out roughly how the architecture of a solution is all going to hang together. Where's the data coming from? Where's it being stored? How is it going to get surfaced up to the front end? Etc. So there's one technique that we started to use

And the other one is what they call fat marker sketching. So their belief is that you don't develop high fidelity wire frames, and then work and iterate on those, what you give to the team, what the team gets, is something that has been drawn up with a fat, and so the reason for using the fat marker is so that you cannot provide too much detail to the team. You give them a rough outline of what the solution might look like, and then they go off and take it and work it up into a fully realized solution. So there's a couple that we've started to using

Ross Garner

I think it'd be worth saying what was and wasn't included in that six-week cycle as well, because a lot of what you were just talking about there isn't part of that six-week cycle. So they have teams who basically will scope or whatever the piece of work is, and they do the bread-boarding and the fat marker sketches. And they'll have lots of these ideas, everyone's got lots of good ideas all the time. When you get an idea, you don't know how long it's going to take, or what's involved. You don't know how long it's going to take to flesh out the idea and come up with the more concrete version of it

So you do that first, that distinct scoping phase, that just rumbles on in the background, and then every now and again, you have these betting tables for people, they'll read the ideas, they discuss them and they pick the ones that are going to go into this six-week cycle. So that six-week cycle doesn't involve the ideation and scoping side of it, because you don't know how long that's going to take, but it does involve quality assurance. So you can't launch it on the very final day of those six weeks and then hope it works. It should have been tested in that time

But one of the things I thought was interesting was that quality assurance for Basecamp wasn't a sign-off gate, because the coders should be writing their own tests throughout to make sure the thing actually works. The quality assurance is a way to ramp up what you're delivering, and look for opportunities to improve it. So I thought that was something that could apply to the way that Emerald Works develop eLearning, because we often will work to a three-month cycle that includes scoping. And then as we go through that scoping process, we might find it takes a day to scope, or it might take a month to scope, depending on the number of stakeholders involved and the number of back and forth, and so on

And actually we should probably just remove scoping from our scheduling process and say, once we've defined what this project is going to be, then we'll give you, let's say we'll do it in six weeks or eight weeks if we need it, something like that. But until we've defined it, we can't really say what the schedule is. And so I thought that was something that we could move across to the way that we develop eLearning

Ross Dickie

Yeah, when I was reading, I found a lot of similarities between the work that we do in the eLearning team and product development at Basecamp and yeah, specifically the shaping and scoping process. One of the phrases that stood out to me from the book was, ""A tangled web of interdependencies,"" which was something that perhaps was more familiar to me than it should have been, but they're talking about, this is not what you want to hand over to your teams. You need to spend that time upfront, shaping and hammering the scope, as they refer to it, so that they have a clear definition of the problem that it is they're trying to solve. But then also you need to give them enough leeway on their end to use their creativity and their expertise to solve the problems

This is where the fat marker sketches come in. So you're giving them an outline of what it is, but you're not doing all the creative, problem solving work for them. And I think, in many ways, not to downplay our skillset, but the actual building of an eLearning module should be easy. Not to say that it is an easy job, but if we've done our job of scoping well upfront, everything follows on from there. So if you've done that well and you've clearly defined what it is you're trying to do, then the rest of that should follow from there

Nicola

I think that can also apply outside of product development as well. It certainly made me think about spending more time actually preparing a project rather than just, say, spending 5% of my time planning it. And 95% of it actually doing it. It's made me think more about the process of just planning something out properly before I dive in and get started

Ross Garner

Yeah, like political messaging, for example. If the logic of what you're trying to convey isn't fully determined up front, then you might find yourself with a rambling 15 minute long mess of contradictory instructions and poorly designed slides

Owen

Cutting.

Ross Dickie

Topical. Topical.

Owen

Yeah. I think that there's a danger of thinking that this is simply just reinventing complete project scoping upfront, where you do all the thinking upfront, and then it's merely just a case of building it, which of course agile was a response to. The important thing here, or as part of this Shape Up process, is that is the hammering of the scope. How do you reduce the scope of it so that you've got confidence that it can be delivered within whatever time period that you're going to assign to it? But even within that, even once you've hammered down the scope and you're providing it to people, they're still building it in an agile way, they're still getting a working thing, whether it's a feature or a full product, but they're getting the thing working as soon as humanly possible, and then they're starting to iterate and add on to it

So I think there is a danger that you could listen and think, ""Right, okay, this is all about defining everything upfront."" And it's actually the upfront bit, the scoping part is, how do we reduce the risk, right? How do we minimize the number of unknowns, so that by the time the team that's going to actually be working on delivering the feature, or the product, or the artifact, that they've got clear guardrails around what we are going to deliver with this, but more importantly, what we're not going to touch. And that scope hammering is the hard part, because quite often what you're looking at is they talk about comparing it against the ideal. It's a natural tendency to look at a thing and say, ""How does it compare against a perfect version of the thing that we're talking about?"" And, ""Oh, it's still not quite good enough."" Whereas, they say that you should look against what the customer has currently got. And so if what you're delivering improves versus what's happening just now, then that's what you should be looking at, rather than how much better could this thing be

Ross Garner

Yeah. I think that ties nicely to the notion of appetite versus estimate, which I really liked, and I felt had implications for the way that learning projects are commissioned. Because often when we're involved in proposals or presentations, we'll discuss a client's need or we'll look at a request for proposal. And then we'll make our suggestion of what we think the best solution is. But we very rarely will know what the budget is, going into it. We don't know if we should be suggesting a 10 grand project, or a hundred grand project. So we'll just make our best recommendation. But we are often recommending what we think is the ideal, because we have nothing else to go on other than, ""What do you think will best solve this problem?"" But there is an opportunity cost to that problem, where after a certain point it's too expensive, or too time consuming, to even be worth fixing in the first place

So I was thinking, for anyone who's looking at commissioning a learning project, you might want to look at, ""What's our appetite for fixing it?"" And, ""At what point does it become not worth fixing?"" And using that as a way of speaking to vendors, to say, ""What could you do, within this timeframe and this amount of money?"" Rather than saying, ""What could you do with this problem, if it was anything?"

Owen

And I think, again, this is one of the facets that we're looking at in terms of our own internal product development is, when they set an appetite for something they absolutely stick to it. So if during that six-week period, let's say it's one of their big batch items, one that they think is going to take six weeks. If by the end of the six weeks, there is not something that they can release, ready to go, what they don't do is they will say, ""Well, how much longer do we think it's going to take, and let's add on another couple of weeks onto this cycle,"" what they do is they say, ""That wasn't ready to go, and actually what we didn't do is we didn't define the problem, or we didn't understand the problem well enough at the start,"" and it becomes a candidate for them to go back and look at shaping again. What they found out during that six-week period is that they didn't know enough to solve the problem

And so I think that appetite setting was really interesting in that, sticking to your appetite, so sticking to your past self's inclination of, ""How much time is this worth?"" If they're saying it was only worth six weeks, or it was only worth two weeks, whatever time appetite they put against it, then if you don't manage to deliver it in that time, then it wasn't worth doing

Because it's those pieces that tend to trundle on. Very easy for six weeks to turn into 10 weeks, to turn into 12 weeks, to turn into 13 weeks, and each time it's like, ""Oh, it's so close, it's almost ready,"" and all you do is you uncover additional problems, because actually you probably weren't defining the problem well enough up front

Ross Garner

It's the gambler's fallacy, right. The longer you're there betting at the table, the more you feel the urge to keep going, otherwise it's been pointless

Ross Dickie

Yeah. The example that they return to a lot in the book is, there was a demand from their customers to include a calendar in Basecamp's product. And this never occurred to me at the time, but calendars are actually a very difficult thing, and time consuming thing to design, because there's quite a lot of functionality. And what people think of as a calendar is not just rows with weeks and the month and individual days. You need to be able to drag activities around. And so people are expecting, when they say they want a calendar, what do they actually mean? And what are they using it for? And actually they just want to be able to see what tasks are due on specific days. So they hammered that scope to drill down into what their customers were actually using it for, and then what their appetite was for building a calendar. Because they knew that they didn't want to build a calendar that could very easily take six months to develop rather than six weeks

Owen

Well, yeah, exactly. It's, ""How much functionality do you build into that?"" Because for example, Microsoft Outlook has a calendar. So, and that's not going to be something you can deliver in a six week period that is fully functioning. You might be able to get the bones of something put together in six weeks, but not the full thing. So the question then becomes, ""Well, if Outlook's the high end, and a simple list of dates is at the low end, where in between that, do we want to get to?"" So yeah, I think it was a useful example cause everyone can understand that there are different complexities of an online calendar

Ross Garner

And also, once you start developing something, it leads to other ideas or problems. So for example, our LMS Lean has a calendar in it for booking face to face courses. Okay. That's great. That's something that people asked for, and they were delighted to see it. And then they said, ""What if we could have a record of who's been on those courses? What if we could have it assign people to courses, and have notifications and messages attached to that, can people see the calendar with the difference between what they've been to, what they haven't been to, what they want to be to? Integrate with outlook?"" And then suddenly this idea of, ""Oh, we'll just create this very simple calendar so people can see what course they're coming up to sign on,"" turns into a huge disappointment for clients, where it doesn't meet all of their diverse multitude of needs

So we tend not to talk about that calendar feature, because it's not a big part of the platform, and it leads to further conversations. So you have to be careful with it. ""I'm going to slice up a little bit of this and then that'll be fine."

Owen

Yeah. But I think what's useful about this example-

Ross Garner

I know these are all good ideas, by the way

Owen

Exactly.

Ross Garner

Everything I described is a good idea, but there's time associated with creating

Owen

Exactly. And how important are those ideas and features compared to other things that could be done? But this is basically what the book is about, is, can you release something that will satisfy a need? And the calendar example is something that satisfies a need, but the very nature of software development is that it will generate new ideas, and those ideas come in, and then what do you do with them? And how do you organize them on how do you determine what you're going to do next? And how do you keep the satisfying delivery of improvements, according to the various different priorities of users and clients and stakeholders, etc., etc

So I passionately think that product management as a discipline is one of the most interesting professional areas for L&D people to take a look at, because there's a lot of thinking and competing ideas out there, around how do we make things and prioritize them and deliver them well for our customers, which is very much a similar challenge that people working in L&D have

Ross Garner

I had a conversation recently with a client who was looking to, we were discussing integration between Salesforce and our LMS. And so what does integration mean? So it meant having the ability to add users in one place and have them appear somewhere else, or remove them in one place and appear somewhere else. So does that mean that all the users are getting added in Salesforce? No. Some of them might be added in the LMS, and then we would need to add them in Salesforce off the back of that. Our LMS allows segmenting by groups, so not everyone sees the same content. So if someone's added in Salesforce, how do we automate the assigning of them to a certain group in the LMS

And this conversation went on and on and on. Who has access for permissions wise to the LMS versus Salesforce? Are we happy with everyone being able to add and delete users in both places? No. So we would need some kind of check, this needs to be some sort of approval process. And it just grew arms and legs until eventually the client decided it was easier to get two spreadsheets and compare the small number of users that they were talking about, that didn't appear in each. But it was useful to go through that process, because the idea of it was good. It was, ""Could we automate this thing that's a bit of a pain every month?"

But in the hammering away of what the idea meant, and exploring the logic of how it would work, it became apparent that actually the time was better spent just doing it manually, in that case

Owen

Yeah. And that is quite often where you get to where you get ideas that come through, as you start to work through them, you realize there is no immediately obvious good way of solving this problem, because there's too many parts that you cannot influence, for example. So identity management is one of those classic ones, where it's very difficult to come up with a good solution because there's lots of moving parts that are owned by lots of different people. And the situation that you're describing there, Ross, for example, a proper identity management system would solve all of those things because neither Salesforce nor the LMS should be creating users anywhere for anyone

Ross Garner

We've touched on the relevance of this book to L&D generally. And I think Ross and I both immediately saw parallels with the work that we do and the instructional design team at Emerald Works. Nicola, I was wondering if, as somebody who works in marketing, if you saw any overlap with the work that you do

Nicola

it's interesting, talking about the six-week cycle, I was thinking about applying it, and how I could apply it working in marketing. But I think it would be more difficult, because I'm in constant communication with suppliers. I personally don't work with clients, but lots of marketing teams do. And I think, goalposts change all the time. So I think it would be more difficult to stick within a six-week cycle and be disciplined with that. I think it seems to fit better with a company like Basecamp, or an organization working in software rather than marketing. So, that was the main difference. I was convinced with how Basecamp use it, but I don't think I could necessarily... I could apply the philosophy or the principle, but not actually, I don't think I could follow it in the same way

Ross Dickie

Could you apply it to your manager, though? So, ""Nicola, we'd like you to go and perform this task."" ""Well, okay. Let's hammer out the idea and work out the logic of it. We don't want to stray too far into the design of it. I'm going to take care of the design of it. You don't have to worry about that part, but let's just make sure that we're actually going to narrow this down to a reasonable six-week period, chunk of work, before we commit to anything."" I think we could all be doing that

Nicola

Yeah.

Owen

I think, yeah, it's important to recognize that there's different urgency associated with certain things. So this is about product development, or the creation of new digital artifacts in some way, shape or form, whether it's eLearning, or features in products, or full products themselves, but Basecamp also have a customer support function that deal with immediate demands. And they've also got a team that's there to fix any urgent bugs or problems that are sitting there. This is all about the making of new things. So you need to think about, and what kills you in product development is exactly what you're talking about, Nicola, which is when the goalposts change. So priorities shift and move all the time. You don't get a sufficient periods of time to do good work

So it is about carving out a reasonable amount of time where you can get some chunky stuff done, but also be able to get new ideas coming in and new opportunities that can be fleshed out for the next cycle of work that comes along. So otherwise all that happens is that everything happens more slowly. You're not actually responding to needs, all you're doing is you're delivering something suboptimal, slowly

Ross Garner

My strap line in life. Owen, what is Emerald Works' approach to the backlog? Because that was something that I found interesting. I have sat in meetings where we have gone through a big backlog of hundreds of tickets. Basecamp skew that and say, ""We don't have a backlog at all."" Ideas, once we flesh them out, they just disappear. If someone cares about them, they'll care enough to hold onto it and bring it back to the table later on. But we're not going to constantly review hundreds of ideas that are just sat there waiting

Owen

Yeah. And that is an interesting one, because we do have a backlog and every time we look at it, we go look at all the things that we haven't done. It gets quite depressing

Ross Garner

It's a psychological tool for the developers there, this Basecamp guy talks about

Owen

Yeah, exactly. And I'm really interested in what he's seeing because basically, it's not that they don't have backlogs, it's, as you mentioned, people will hold on to those ideas anyways. So the backlog is distributed, but it's not centralized and held there as a list of things that we haven't done or haven't got to, or in some cases might never actually get to because whilst it's a good idea, it's not as important as all the ideas that are currently sitting above it, plus all the new ideas that might come in there. So yeah, we are thinking about, ""How do we make sure that we don't lose sight of what's important?"" But equally that we're not necessarily doing that in a central repository that gets stale and constantly has to be combed out. There's a bureaucratic overhead to managing a backlog. So, and there is something to be said around, you've probably got a really good sense of what's the most important few things you could do next, just based on the internal collective knowledge thing exists in the company

Ross Dickie

I find that answer wooly and unsatisfying. It needs to be hammered out a bit more, I think

Owen

Absolutely. Which is why it's a case of, well, we do have a backlog, and we are looking at, is it a better way of managing that? Should we be doing it differently? And that's one of the things that this book has spun out, is forcing us to look at some of the things that we've just been doing, because it's one of the things that you do, keeping a backlog is a thing that you do, it's a well-recognized practice. And actually they're saying, ""Yeah, but maybe you don't need to do that."" So, it's very attractive

Ross Dickie

So we can add this conversation to the backlog. Nicola, sorry, I cut you off

Nicola

Yeah, one thing I was going to say is that it struck me there, the teams who work on these projects as well. So they're quite small, like one designer, two programmers. And I just thought you must have quite a senior team in place to be able to let these people go off for six weeks to work in either small batches or big batches and be able, hopefully, to deliver something at the end of it. And I just wondered if that was something that was maybe exclusive to Basecamp or would that be more difficult to replicate in other organizations

Ross Dickie

It's quite a lot of trust, I suppose, that's what you're saying

Nicola

Yeah, exactly. Yeah. Trust and also experience in the roles. You must be fairly senior to be able to do that, I would guess

Ross Garner

It's how the instructional design team at Emerald Works operates. Each instructional designer is, they're an instructor slash

Ross Dickie

We're all very experienced.

Ross Garner

Yes, Ross. Instructional designer slash project manager. So, I manage that team, but yeah, I've very little understanding of what they're doing every day. Because I trust them and at the end of whatever the cycle of the project is, it gets delivered and I'll give my thoughts on it, and hopefully that improves the product, but I don't need to be involved day to day to know that they're doing great work. Helps to do the opposite, in fact

Owen

Yeah. And the same would go on there on the software side, actually the number of people that are working on chunky new features, like the new playlist feature for example, was one designer and two developers, one doing more backend stuff and one doing more front end stuff. So that was a fairly significant feature on the toolkit product. But it was a small team that was working to a pretty well defined concept of what needed to be delivered, not exactly in the way that Basecamp do it, but that idea of those small teams working on discrete pieces of work, it's pretty close to what we do anyway

Ross Garner

You should be hiring professionals, talented people who you can trust to get on with the work. And if you find out that someone can't, they will get found out quite quickly

Ross Dickie

On that ominous note.

Ross Garner

Yes, we are hiring

Ross Dickie

Ross has got your number, folks

Owen

Get out.

I say that. We are hiring, actually. I wonder if this is an opportunity, I'm going to put it out there on the podcast. So we are hiring a UX UI designer and a UX researcher for a really exciting project. So if either you are one of those, types of professionals, or you know those types of professionals, then come onto the Emerald Works website and there'll be signposting somewhere in there to apply for the role

Ross Garner

And if you need further incentive, you won't be reporting to me

Ross Dickie

Okay. So we'll move on now to our regular feature of, What I Learned This Week, where we each share something we picked up in the past seven days. Owen, do you want to get us started

Owen

I went on a bit of a keyboard shortcut binge last week. So one of the things I do to help me work more effectively is trying to find more efficient ways of doing things that I find myself doing all the time. Sometimes that's about playing around with new apps, but often it's about finding quicker ways of using functionality that I've already got access to. I am a Mac user. So I find myself using Command + Shift + 5 as a shortcut that I use all the time for taking screenshots or screen recordings, rather than go through the menu system to find that

And last week I tried to make better use of an app that I've got called, Alfred, which is like a souped up application launcher, that's part search tool part command line. So you can use it to launch applications or find files with just a few keystrokes. One of the things, I think I've mentioned this before, but when I'm trying to force myself into a new habit, I tend to use a Post-it note with the keystrokes that I need to do something in order to carry something out. So I've had a little Post-it note stuck to my monitor at my desk at home, with some things that I'm trying to force myself to do rather than use just the mouse and double-clicking etc. So I've learnt a whole bunch of new things that I am trying to force myself to do

Ross Dickie

This lockdown's just flying past for you, isn't it? Nicola, what did you learn week

Nicola

I came across an organization that has just been launched in response to COVID-19, and the crisis that's happening at the moment. And it's called chefsinschools.org.uk, and it's basically taking chefs, who used to work in restaurants and everything, and taking them and using their skills to supply children who usually get free school meals, etc., in schools. So it's just responding to that need. And at the moment, they are doing a shout out for chefs who are maybe redundant, or furloughed, and just looking for them to volunteer to take part in this initiative. So I just wanted to highlight that and mention that

Owen

Great. Sounds very positive.

Ross Dickie

Yeah. We can post the link to that in our show notes. Ross, what did you learn this week

Ross Garner

So I was off last week. I was on annual leave-

Ross Dickie

Wahey.

Ross Garner

Wahey. Yes. Yes. I'm still on all the upcoming podcast though, so listeners, don't be too concerned, but I was needing a break just the whole thing, to be honest, I don't want to get into using the C word and whatnot, but I was needing some time away from Zooming all day at work and then Zooming all day in the evening. So I cut off Zoom, I had almost no personal Zoom calls and no work at all whatsoever. And instead I read, The Wind in the Willows, which was absolutely charming. I've never read it before. And it was the perfect tonic for these troubled times. So I learned that, The Wind in the Willows, is a really good book and a nice distraction from Zooming every day

Ross Dickie

Oh, lovely. I think I've only ever had it read to me possibly. I don't think I've read it myself

Ross Garner

Yes. You feel like it's with you in some way without ever actually having read it.

Ross Dickie

So my, What I Learned This Week is, last week was a landmark moment in podcasting in many ways. This American Life, won the first ever Pulitzer Prize for audio reporting for their episode, The Out Crowd. This American Life, was my gateway drug to listening to other podcasts. And I haven't actually, I think in the last few years, I haven't really been listening to it that frequently, but having seen it had won the Pulitzer Prize, I thought I would check out the episode

The Out Crowd, is about basically looking at the Trump administration's migrant protection protocols. I think, whatever your political views about Trump, given his personality and the way that the media feeds into that, I think it's easy to lose a lot of the nuance in these stories and the episode of, This American Life, digs into the impact of this policy, not only on asylum seekers, but on the people working in asylum within the US, of all people. I think it's easy to think of these people as blunt instruments of the administration, but a lot of people got into these jobs because they wanted to help asylum seekers. And then they're now being forced to send people back to camps where they're at risk of violence, and abduction, and various other things. So it was just a very good episode, highly recommend it, and it seemed like an important moment for podcasts, generally

Ross Garner

Not just a Pulitzer, but also Ross Dickie's recommendation

Ross Dickie

Well, exactly. And that's all for this week. If you'd like to share your thoughts on the show, you can find us on Twitter. I'm @RossDickieEW, Owen is

Owen

@owenferguson.

Ross Dickie

Nicola is-

Nicola

@Nicola_BoyleEW.

Ross Dickie

And Ross is-

Ross Garner

@RossGarnerEW.

Ross Dickie

We were talking about, Call of Duty, before we started recording this, and, Call of Duty, you will have a clan tag. And what I noted there was that Ross, Nicola and I all have the Emerald Works clan tag, and that Owen doesn't

Owen

I've had my Twitter handle for a lot longer and I'm not changing it.

Ross Dickie

You can also tweet @Emerald_Works. To find out more about what we do when we're not recording this podcast, including our performance support toolkit, custom eLearning and LMS, visit emeraldworks.com. If you've enjoyed the show, please leave us a review on the Apple podcast store, or simply recommend us to a friend. Thanks for listening. Bye for now

All of Basecamp's books, including Shape Up, can be downloaded for free on their website: https://basecamp.com/shapeup

The macOS app Owen mentioned was 'Alfred': https://www.alfredapp.com/

You can find out more about Chefs in Schools by visiting: https://www.chefsinschools.org.uk/

You can listen to This American Life's Pulitzer-winning episode, 'The Out Crowd', on their website: https://www.thisamericanlife.org/688/the-out-crowd

If you work in UX/UI and you're interested in joining a team that doesn't report to Ross Garner, check out these job listings: 

https://emeraldgroup.current-vacancies.com/Jobs/Advert/1931140

https://emeraldgroup.current-vacancies.com/Jobs/Advert/1931141

Ross Dickie

Ross Dickie

Learning Experience Designer, Emerald Works

Ross has been working in L&D since 2015 and is a key member of the instructional design team at Emerald Works. Most of his time is dedicated to writing articles, scoping infographics and contributing to video projects.
Connect
Nicola Boyle

Nicola Boyle

Marketing Communications Executive, Emerald Works

Nicola has over six years of marketing experience. Her responsibilities include managing social media, podcast and webinar channels, as well content management and event planning. Nicola enjoys identifying and anticipating client needs and delivering the best possible experience to build successful long-standing client relationships.
Connect
Owen Ferguson

Owen Ferguson

Product and Technology Director, Emerald Works

A self-confessed nerd, Owen is passionate about taking an evidence-led approach to developing digital products that solve real-world problems. He is also a regular on our weekly podcast.
Connect
Ross Garner

Ross Garner

Head of Learning Experience, Emerald Works

Ross has been working in L&D for seven years and he heads up the instructional design team at Emerald Works. In 2019 he completed a Masters in Digital Education and was named Learning Technologies’ Learning Designer of the Year. He is also one of the hosts of the GoodPractice Podcast.
Connect

About the author

Ross Dickie

Ross Dickie

Learning Experience Designer
Ross has been working in L&D since 2015 and is a key member of the instructional design team at Emerald Works. Most of his time is dedicated to writing articles, scoping infographics and contributing to video projects.

You may also be interested in…

Podcast 223 — Unpacking the L&D Detective kit

Author, speaker and presenter Kevin M. Yates last joined The Good Practice Podcast back in Episode 117 to share his insights into whether we can measure the impact of training. This week, he's back with a new e-book to help you do just that.

December 2020

Read More

Podcast 222 — The impact of Covid on L&OD

Covid-19 has profoundly altered our lives. Some changes have given us the space and time to build more positive habits; others have been purely restrictive.

November 2020

Read More

Podcast 221 — Start your Learning Health Check now

Sorry everyone, there's no podcast today! Instead, here is a brief reminder to complete your Learning Health Check.  

November 2020

Read More