Console

David Mytton (00:05): Welcome to the Console podcast. I'm David Mytton, co-founder of console.dev, a free weekly newsletter highlighting the best and most interesting tools for developers. In this episode, I speak with Meri Williams, experienced CTO at scale-ups like MOO, Monzo and Healx. We discuss the role of technology leadership, what engineering managers can do to help their teams, how to best go about recruiting engineers and whether engineering performance can be measured. We're keeping this to 30 minutes. So let's get started. I'm here with Meri Williams. Meri, thanks for joining the Console podcast.

Meri Williams (00:42): Thanks very much for having me.

David Mytton (00:44): Let's start with a brief background. Tell us a little bit about what you are currently doing and how you got here.

Meri Williams (00:50): I'm an experienced CTO. At the moment I'm doing a bit of consulting for a few different firms through my own company but I've previously been CTO at MOO, at Monzo, at Healx, which is an AI driven drug discovery company. In addition to that, I chair the Lead Dev Conference and I'm also a tech advisor for Kindred of VC in London, that practices equitable ventures.

David Mytton (01:11): Great. So let's start with a very broad question. What is the role of technology leadership?

Meri Williams (01:18): I think the role of technology leadership is two primary things. One is leading the technical organization, so looking after people from a pastoral and career and personal development point of view, but the other is to ensure that there's a clear technical strategy and that the needs of the business are met by the technology team.

David Mytton (01:38): And how do you think about balancing those because they're almost opposites, people and technology?

Meri Williams (01:46): I think balance is the key word there. The reality is that if you don't know enough about the technology, then it's very difficult to guide your team and your people effectively. But also if you focus too much on the tech and ignore the people, then they don't tend to stay. They don't tend to be happy. They don't tend to be fulfilled. And therefore you end up without anybody to build anything, which is not in great service of the tech either.

David Mytton (02:09): I suppose that goes to the saying that people leave bad managers rather than bad companies. Would you say that's right?

Meri Williams (02:16): I think a lot of people do leave bad managers. I think there's other reasons for leaving as well. I talk a lot about the Dan Pink's Drive book, where he talks about needing to have purpose, autonomy and mastery. There's a fourth thing there that if you look at something like first break all the rules or similar, you also need inclusion, you need to feel like you're part of a community. You need to feel like you belong, you can be yourself and be successful.

And so I think any lack in any of those areas can cause someone to leave as well. So if they feel like they don't have a real connection with the purpose of the organization, they feel like their opinion isn't listened to. They don't have any autonomy in their day to day work. If they're not building mastery. They're not getting better at what it is they do. So I talk about that as, autonomy is build the right thing and mastery is build the thing right. And then inclusion, can you be yourself and be successful? So I think any of those factors being really out of whack can lead someone to leave as well. But a bad boss can definitely also lead people to go.

David Mytton (03:13): Are there any mistakes or common errors that you see technical leaders make that they should watch out for?

Meri Williams (03:20): I think that there's a tendency, particularly when you first become a manager, if you are the flavor of technical leader that is a manager, actually, even if you're a very senior individual contributor, hiding in the code is a problem that I see quite often, it can be very comfortable. It's where people feel that most at home, the feedback loop is so addictively short, you write some code, you find out if it passes the tests almost instantly, if you're in a good dev setup. And I think that people can hide in what's comfortable. And really the more senior you get, the more likely it is that your real problems are people problems or your real problems are influencing or getting people to align to a strategy. And so I think hiding in the code is one real problem or mistake that I see people make.

The other is assuming that there's only two modes of management, either micromanagement or completely hands off. And I think in reality, not many people need telling exactly what to do and exactly how to do it all the time. It's very... Unless someone's very, very, very new, it's unlikely that they need teaching in that way. And maybe the best person to teach them anyway is someone six to 18 months ahead of them rather than their line manager, in any case. Even if somebody has... They know what to do and they're well equipped to do it, they still need a bulldozer and a cheerleader.

They need someone to get things out of their way and to help them know that they're doing well in many ways. But that's the biggest stake I see, I suppose, is people defaulting to either being in micromanagement mode or in absent mode, when in actual fact, people need either help developing new skills or help figuring out what the right route is. So coaching is often the best way to achieve that in almost all cases. And it's very seldom that somebody needs telling exactly what to do or how to do it and, or needs to just have no manager at all.

David Mytton (05:07): Right. So what does that actually mean in terms of, what should a manager be doing? How do they know how to start with coaching or what should they do with their team to try and help them with that?

Meri Williams (05:18): A key tool that I teach new managers is this grid of just trying to figure out where somebody is in terms of clue versus skills and knowledge. So do they know what they're trying to achieve and do they have everything they need to try and achieve it? And if they have both of those things, then what I said earlier about a bulldozer and a cheerleader come into being. If they have neither of these things, they don't know what they're trying to do and they have none of the skills or knowledge to achieve it, then they need a teacher, but who's the best teacher for them? Is probably the right question to ask.

If you think of that as a grid, there's also people who know what they're trying to achieve but they lack some of the knowledge or skills. So they focus on skills development or where they have the skills they have the knowledge, you're like, "The best thing here would be for you to figure out what route you want to take with it." That's when coaching is appropriate. And I think there's some basic coaching skills that it would benefit literally everybody, not just managers to learn. So I've done a couple of talks on coaching and what we can steal from sports in terms of coaching, in the past and just getting more and more people to have basic coaching skills is probably one of the more useful contributions I've made to the industry over the years.

David Mytton (06:23): Excellent. So does that mean finding a course or finding someone like you, who can help with these workshops?

Meri Williams (06:30): Not to show my own thing, but I do run something called Be a Brilliant People Developer, which is a day-long workshop to really bootstrap somebody who's new to technical leadership. But I think you can also learn from books really effectively. There's a great book called The Tower of Coaching. There's The Inner Game of Tennis. If you'd like the sports angle on things, it is a very good read. There's also talks online about things like GROW coaching, which is a very simple coaching model where you literally just do a structured conversation, where the GROW stands for goal, reality, options and will. And so somebody starts out saying, what is it they want to talk about? What's the goal of the coaching session? You then ask them, "What's going on? What's the reality?"

That's the only phase in which the person who is being the coach can add any information as well. Because one of the key tenets of coaching is that you keep yourself out of it. You're just a mirror or a rubber duck in the coding framing for somebody else's thought process. So having said what the topic is and explained what the situation is, as a coach, you literally just keep asking, "What could you do? What options do you have? What else might you consider?" And really try to get that person to get a volume of options out. So it's about quantity, more than anything. It's not about analyzing each individual option to death.

It's about trying to get 10, 12, 20 options out. And then the final stage, will, is just to decide what they're actually going to do. And a key difference between coaching and mentoring, I suppose, is coaching, you don't have to have expertise. You can coach somebody really effectively, even if you're not more knowledgeable or better at the thing that they're trying to do than they are, which is another thing that I think technical managers and leaders need to learn over time is they can't always just operate in a space where they could also do the individual contributor work. Eventually you're going to have people who you are leading, who are significantly more expert at you at their own specialism or maybe more senior than you or were ever as an engineer. And so getting to the point of having that skillset where you can coach rather than always just giving advice, is really important.

David Mytton (08:34): That sounds somewhat counterintuitive, I suppose, that you are able to coach someone, even though you don't have that experience. So it's almost like as we're just speaking broadly, there's almost a reluctance to embrace coaching in technology, even though we're very used to it in other high performance teams, like all the sports teams you mentioned, do you think that's a major problem that the tech industry has?

Meri Williams (08:55): I think we're very proud of our technical skills and I think that's understandable. We work hard to develop them and letting go of that, facets of our identity can be very difficult but I think once we embrace it, we can be just so much more effective that... And let's be honest when we were engineers ourselves and we were hands on keyboard doing stuff. We usually liked our own plans better than other people's plans anyway. And so I think if we recognize that helping someone figure out their own way to achieve something is probably what we would've liked when we were in their position as well. A lot of managers fail at that very basic first test of thinking about what bad experiences they've had themselves or what good experiences they ever had themselves as a person being managed or being led and then try to replicate it, which I think is minimum viable success for a leadership role is, learn from what happened to you in the past.

And I think too often we throw all of that out the window, as soon as we take on the mantle of leadership and forget that we know a lot about what doesn't work, even if we haven't always had the best examples. Everybody I know has had some examples of what is not worth emulating. That's the minimum viable guidance for anybody, I think. I think we're also just, we're not very cognizant of the fact that some of the best coaches in the world are not better at the thing than the person they're coaching. Andy Murray's tennis coach, I don't think he's better at the sport than he is. And the England rugby team's history is littered with examples of great players who did not become great coaches. There's the occasional great player who also became a great coach, but it's almost like they're slightly different skills and being great at doing the thing doesn't make you great at teaching things.

So I think when we recognize how valuable those coaches are in some of those other industries, I think tech is getting a bit better at it. We've seen a rise in coaching from managers but also in executive coaches and similar being used and making a real, real difference to organizations. So I think we're starting to grow up a little around it, but yeah, traditionally we've been very in love with our own expertise and very unwilling to believe that someone who's less expert can still be helpful. I think we're starting to see that the reality is being good at coaching can be an expertise all in itself, that then adds a huge amount of value and same for mentoring, same for teaching.

David Mytton (11:14): Going back to those two components, you mentioned that are possibly opposites but not necessarily, the people and the technology side of things. You often see startups having just a single person who does both of those and then it changes over time as the company grows. Do you think that engineering leaders need to pick between people and technology?

Meri Williams (11:36): I think there's certainly a point in your career where you have to choose whether you want to still be hands-on in the tech. But I was at a conference recently called Leading End where a CTO who's got thousands of engineers under them at this point said, "One of the secrets of technology management is the more senior you get, the more the tech matters again." And I think that's very true. I think as you get more senior, technology strategy becomes such a key part of your role, but if the only way that you can stay up to date or keep current with tech is by coding yourself, I think that's limiting in some ways. So the most successful technical leaders I've seen for a while really focus on the people management side because that is a skillset that we don't develop as engineers.

It's not something that you learn a little bit more of along the way from entry level to mid-level to senior engineer. We get to senior engineer and then suddenly someone expects us to manage, and it's more like a career change than it is a progression. And so I think at engineering manager level, that first line manager level focusing really on developing those skills of people management, pastoral care, looking after people from a career point of view, from a personal development point of view, I think there's a really good argument for heavily, heavily focusing on that whilst in an EM or SDM type role. But then once you get to engineering director or VP Eng or CTO, there's a whole bunch of technical strategy that you need to engage in again.

And so one of the quite interesting topics, I think for technical leaders, particularly those who've been in leadership roles for a long time, is how do they keep current enough with the technology that they can ask good questions, that they can evaluate people's proposals, that they can understand the reality of what's being proposed when you're talking about an architectural change or a change in ways of working? If they are not able to regularly be down in the trenches, actually using the tools day today, it's quite an interesting challenge and learning how to learn well and learning how to learn in different ways, it ends up being a key part of every leader's journey, whether they think about it very actively or not.

David Mytton (13:39): How have you solved that, your different roles keeping up to date with things?

Meri Williams (13:44): I'm always willing to admit when I don't know, I worked really closely with my senior ICs when I was at Monzo. I was lucky enough to have an absolutely amazing VP of architecture, Ollie Beattie. He'd never judged if I asked a dumb question or I think you probably valued that I would admit, I didn't know, rather than pretend it or style it out as some people do. And so I just work really closely with senior ICs in my organization, ask what might seem like dumb questions sometimes just to make sure that I really understand, and I'm autistic so I tend to ask very direct questions and not be scared of asking questions anyway, which is probably one of the few benefits of that neuro diversity. But more generally, I follow a lot of people on Twitter who are still much more hands on technical and tend to pay attention to what they're interested in.

What are the big debates that are happening? What new frameworks are becoming popular? What tooling are people excited about? And so I tend to follow on Twitter, go to conferences, see what's being talked about. And then I'll take that as a list of things to investigate in more detail in my own time. And I'm lucky in that, just the learning style I have, I'm very capable and quite happy, just swallowing a book. And so a lot of the time I will just buy a technical book and read it. And I'm lucky in that I can absorb a lot of the context and understanding from reading rather than having to build it myself in order to understand it, which I think is a, just happens to be a benefit that I have because that meshes my learning style. I don't think it's worse except that it's a bit more time consuming if you need to build in order to learn.

The one thing I'd love to see more of though, is for people who, for all technical leaders actually, to make it obvious that they are using time during work for learning. Because I think that's a important and positive way of role modeling because expecting everybody to have coding as their hobby, as their free time activity, as well as their work activity, just isn't very inclusive, like if you've got kids to look after or parents that you help support or even just hobbies that are not very tech-centric, it can be difficult to feel all the time like you're meant to be living and breathing tech at all times in order to keep current with what's changing all the time.

David Mytton (15:53): I suppose that's almost a stereotype, isn't it? The engineer who spends all of their waking hours coding, and maybe that changes over time as well. You might be able to do that when you are younger and have no responsibilities, but it does change as things change in your life and being able to show that to your team and the company to set that as a norm is really important.

Meri Williams (16:11): Yeah. And I think there's people from certain demographics that even when they're really young, they don't have that privilege. They don't have the opportunity to just spend all of their time. The reality of the world is that there's still a disparity in who does certain activities and tasks and how much caring is expected of different people. So I think it's healthy even at every stage in the career to make room for learning on the job as well. Because if people aren't learning, then things are eventually going to suffer in the job anyway. So it's worth building it in from the outset.

David Mytton (16:41): Yep. So if you were starting from scratch with a brand new startup, where would you begin in hiring and how would you design the development processes?

Meri Williams (16:52): I'm often hired at the point where things are about to scale massively and then you come in and all the things that were fine when it's a small closely knit team are about to get very, very painful. If there are things that are just arcane knowledge or things that just live in people's heads. So I would probably get quite focused on good tooling, good onboarding, good documentation, quite fairly on, but that's very colored by my experience being the one to come in at the point where it's not been paid attention to. And then suddenly you're going to double the team in the next six months and when half your team are less than six months in tenure, then the things that are only known by the original crowd, the OGs is, it becomes more and more problematic. So I think I, compared to the average startup, would probably hire someone who thinks about platform infrastructure and tooling a bit earlier than most other organizations might.

And ironically, I'd probably also lobby for there to be a people person, like an HR style person a bit earlier as well. Because I think designing people processes, like making the people experience better, is really important from early on. It's something that I thought Monzo did a fantastic job of, not under my watch. It was already really, really brilliant by the time I joined there, they really focused on the employee experience being really good. They had a team that not only did tech support but very proactively made the experience of using the technology really, really positive. And people would remark on that.

They joined from much bigger, much better funded organizations and just be like, "Everything just works. It's just wonderful how everything just, it just works." And the level of surprise from people coming from these huge enormously well funded banks, just being so surprised at how frictionless things were, was really interesting and important. But I also think the reality of a very early stage startup is, sometimes you have to just use every available penny on the product that you're building to try to figure out whether you've got product market fit. And I think that's fair. So possibly my answers were better answers for once you found your product market fit, what would you then hire? That's probably the way I would frame it.

David Mytton (19:03): Right because the priority early on is finding out if you're going to be able to get users and maybe would they pay for something? Not necessarily, maybe would they pay for something? And then you can figure out, well okay, now we've got this massive mess and we've figured it out on the company business side of things, how do we fix all the technology and scale that?

Meri Williams (19:19): Yeah, it's better to have a viable business that has a bit of technical debt than it is to have a perfect technical system that nobody's ever going to use. Technical debt gets talked about as if it's a university bad thing and I don't think it is. I think it's like financial debt, financial debt is just fine. Just don't put your house on the credit card. Let's make sure that we're paying the appropriate interest rate. So you don't want to borrow financially in an irresponsible way. Tech debt can be a way of going faster, doing things manually at first can actually be very healthy. I've seen Amy Hoy, I think calls it Flintstoning. Do it the stone age way at first. And don't try and automate until you've got the process ironed out manually. And I think those are actually quite good lessons for early stage startups to have. What becomes problematic is when they cling on to those ways of doing it beyond the size at which it's sensible. I think that's the bigger challenge.

David Mytton (20:13): What were the specific things that you saw at Monzo or other companies that they really got right, that made that well, you described it as frictionless, was it things like onboarding or like the build system works really well? What examples could you give me?

Meri Williams (20:27): Tech ops, the tech ops team did a really brilliant job of making it so your machine arrived with you and it already had all the software that you needed. It already had your account set up. It was literally open go, which was just beautifully frictionless. They did an absolutely fantastic job of that work. I think they've bogged a bit about some of the things that they did and they're very worth reading those blog posts. But the people experience team had focused very heavily on onboarding very early on. And it was a company, whilst the years that I was at Monzo, it was a company that was very, very rapidly growing and so making it so people's... I called it mean time to productivity, how quickly can somebody join and be independently productive? I think it is very important. We've heard versions of that from other companies too.

I know Etsy is very proud of any engineer who joins, they ship something into production on day one or day two in the company and I think that's very important. There was also at Monzo an engineering excellence team that focused specifically, like a dev tooling team essentially, on making things as easy and as seamless and as low risk as possible for new people joining and for existing people just to make the working on code and then deploying it as frictionless as possible. So I think those were all very good investments that were made at Monzo early on.

David Mytton (21:45): Right. So at the point when you join the company and it's starting to scale pretty rapidly, what kind of changes do you see or do you try and implement or work to get deployed?

Meri Williams (22:00): There's a bunch of things that I think get harder, the bigger you get. I think the internal communication matters a lot more, as soon as you're above more than about 20 few people, even 50 people, you've already got to focus a lot more on internal comms than you expect to. I'm from a Python background, so I love the DRY principle, the don't repeat yourself principle, and it's fantastic from a coding perspective but terrible from a human perspective. So accepting that with humans, you're going to have to repeat yourself probably more than you want to in order for the message to really sink in is quite important. And I think there's generally just different inflection points. There's different things that matter at different points. So once you've got 50 engineers, somebody definitely is asking quite consistently for a career progression framework.

They want to know how they get better. They want to know what matters. So I think that's worth investing in at that point. But generally I've never regretted investing in better onboarding, onboarding and documentation, anything that makes it more likely that somebody new can find their own way rather than having to find the person who knows, having to navigate that kind of arcane hidden organizational knowledge, anything that makes that easier, tends to be worth investing in at almost any stage but definitely at the point where you're going to very rapidly have a significant portion of the team be only three months or six months or nine months in, at the company.

David Mytton (23:20): And in terms of recruitment itself, that's often the hardest problem that I see in early stage businesses or even any stage business, how to hire good engineers. How do you think about that problem?

Meri Williams (23:33): I think there's a mix of places where your problem might be. I think that there's a lot of companies where their problem is at the top of the funnel, if you will, they're just not attracting people to be interested. And that tends to be best addressed by doing something what... If you're being ponzi about it, you'd call employer branding work. But it's just being known as a place where good work is going to happen and people are going to develop well. And it's actually something where I think startups often have a real advantage over established businesses because they can be really clear on what the purpose of the organization is. They can give a lot more autonomy. You almost have to actively try not to be on a really steep learning curve if you're in a startup environment.

And they have a lot of opportunity to work on inclusion to that sense of community, making people feel welcome and like they can be themselves. And so I think it's a real advantage that small organizations have sometimes. Your attraction, your top of funnel, enough people are coming in wanting to be interested in you. It's then about making sure that your actual funnel, your process of whether it's reviewing CVs, then a phone screen of some description, then a technical task some description. Then some interviews, making sure that, that is even handed, that you're not being accidentally biased in that process and losing good people along the way. I think that the biggest improvement I've made to recruitment processes in places I've gone in is to get them to be much more realistic, much more akin to what their actual day to day work will be.

So if you're doing design from scratch exercises in your interviews, but actually most of the time people are going to be adding to existing systems or improving existing systems, then that's not very realistic. It's not telling you whether they're going to do well in the actual job. And so a lot of the time I'll, whenever I go in, I'll ask everybody to map out for me what the process is and then go, "Cool and which part of the real job is this testing for?" And the number of times that there's three or four phases where nobody knows which part of the real job it's testing for is quite worrying. So I'm a big fan of, I think you've got to walk the line carefully that you don't seem to be asking for free work from people when they're doing their technical task or whatever else, but being more real in how it's assessed.

So if your company pairs a lot, make it a pairing interview, don't make it a whiteboard coding exercise. I don't think anybody ever writes code on the whiteboard in their actual day to day job or anybody who does, should write to me and explain to me when and how because I just have never seen it in the day to day. I think it's wonderful to whiteboard together when you are figuring out a design or talking about architectural choices or similar, but the chances that you're actually writing code on a whiteboard, I think are very slim.

And so try to make that process a lot more similar to what the actual day to day work looks like and that tends to improve things. It's a mix of that, making sure you're seen as somewhere where people can join and learn and grow and deliver good work that they care about. But then also make sure that your process is actually checking what they will do rather than any kind of abstract idea of what good looks like. Because almost always under scrutiny, those very abstract things don't stand out. Even Google these days has given up on their. How would you move Mount Fuji? Style questions that they used to ask that they thought were very predictive of success that turned out not to predict whether people would succeed at all.

David Mytton (27:01): What about trying to measure the performance of engineers once they're in the job, how'd you go about doing that?

Meri Williams (27:06): I think almost all modern work is a team sport. I'm a bigger fan actually of measuring team performance and then measuring individuals based on the feedback of their team. If you measure with the team is performing and then you get 360 feedback from around the individual so that they know what they're good at, what they need to continue to get even better at and then what gaps are causing a problem. I think there's a tendency sometimes to just look at gaps, but gaps only matter if they're what I would call a controlling weakness, so a weakness that is essential for the job. If you have a gap that isn't essential for the job that you've got or the job that you want next, then it's your choice whether you do anything about it, you can just leave it.

Not everybody has to get perfect at public speaking in the course of their career. I think you can be a very, very successful leader and all the way up to CTO without ever embracing public speaking is a need. There are some CTO roles where it's pretty essential but I don't think it's every role. And I think sometimes people focus too much on the things that they're not good at, at all or they're actively bad at that don't matter, over focusing in and going "Well, actually, if I focus on going from good to great at this thing I'm already good at, I'd be much more effective."

David Mytton (28:17): Right. And I suppose that's why it's focused on the team because someone else in the team might be better than you at something and that's perfectly fine because you're working as a group.

Meri Williams (28:26): Yeah. It's like the Avengers. You want all those different skill sets that come together. I would watch the hell out of a seven Hulks movie. I think it would be absolutely hilarious if we got one like Spider-Man the Multiverse, into the Multiverse where you had all the different Spider-Men. But I think in general you want the team to have a set of strengths and it doesn't matter much which individuals those come from as long as the team is cohesive and works well as a unit and delivers well. And in terms of measuring team performance, I think we know from the work that Dr Nicole Forsgren and similar have done, the only things that really matter are those DORA metrics. That's probably the most useful measurement of team performance in technology that I've seen is people trying to do really good implementations of the DORA metrics.

David Mytton (29:14): Okay. Well, before we wrap up, then I have two lightning questions for you. So the first one is, what interesting dev tools or tools generally or maybe books, if you've not been playing around with anything recently, what have you been playing with or reading that's worth mentioning?

Meri Williams (29:30): It's not very technical but I've been reading a lot about burnout. I think in the last couple years we've had with the pandemic, there's been a lot of burnout. Kate Houston writes very interestingly about this. She writes about the reasons for burnout that are not related to overwork, which I think a lot of people assume that burnout's always about working too much, but there are six causes of burnout, work overload is just one of them and lack of control, lack of reward, absence of fairness, lack of community or conflict in values are the other five. My reading pile is a whole bunch of things about burnout and resilience and how to help people recover from burnout or even prevent it in the first place. Because I think it's one of the more challenging things that we're dealing with. And I think when people are lucky, they've got the opportunity to take a big chunk of time off and try and recover but not everybody's got that opportunity.

So I'm keen to understand that whole process better and try and figure out how to help people more when that burnout sense. I'm also just not very well equipped at the moment, technically. I'm traveling at the moment, my laptop died and I'm traveling with just an iPad Pro and finding all of the ways in which it is not really a Mac replacement right now. Although the one thing I do love that I have that is, I suppose, technical is I have one of the reMarkable 2 tablets and it is the first time I have ever managed to actually move away from my paper notebook, I have tried so frequently in the past. I've tried every type of Evernote, Scribner, everything I could try to move my notes out of paper and never got it to work but this tablet is genuinely remarkable. They've named it very well. I've been very impressed with it.

David Mytton (31:09): Interesting. And does that sync with your Mac when you have it?

Meri Williams (31:12): Yes. Yeah. It also tries to do OCR but my handwriting is particularly terrible. People assume I should have been a doctor level of terrible. I grew up in South Africa and when you're a smart kid in South Africa, you're not ask what you want to be when you grow up, you ask which you want to be when you grow up? And the choices are doctor or lawyer and the terribleness of your handwriting tends to determine which people think you should go into. I was definitely in the doctor category from that perspective.

David Mytton (31:39): So then that was my second question about your current tech setup is so you normally on a MacBook.

Meri Williams (31:45): I'm normally on a Mac Air, at the moment I'm traveling as I said, with an iPad Pro, reMarkable 2. I've got a lovely little fold out split keyboard because I've had a lot of trouble in the past with RSI and similar. So having a little ergonomic keyboard setups is really good. It's beautiful, it's less than a centimeter thick when folded and really nice to carry around. I use a trackball. Just a very typical one to work whenever I'm around. And one of those little folding laptop stands. But yeah, ironically, just as the pandemic started, I had really invested a whole bunch at having a much better travel setup because I was starting to work with multiple companies. Then the pandemic happened. My wife took all of my travel stuff and it became her homework set up.

David Mytton (32:32): Excellent. Well, unfortunately that's all we've got time for. Thanks for joining us, Meri.

Meri Williams (32:37): Well, thanks for having me.

David Mytton (32:39): Thanks for listening to the Console Dev Tools podcast. Please let us know what you think on Twitter. I'm @davidmytton and you can follow @consoledotdev. Don't forget to subscribe and rate us in your podcast player. And if you are playing around with or building any interesting dev tools, please get in touch. Our emails in the show notes. See you next time.