The CTO Show

Episode 2:  Toby Osbourn - VP of Engineering at The Innovation Enterprise

Episode 2: Toby Osbourn - VP of Engineering at The Innovation Enterprise

Show Notes

Things we talk about

  • 01:41 - Communicating with Non-Technical Clients
  • 08:02 - Onboarding and Training Developers
  • 11:42 - Transitioning from Development Teammate to Leadership
  • 15:10 - Leadership => Management
  • 18:30 - Growing a Team
  • 23:54 - Management Transparency
  • 27:15 - Mental Health Issues in Managers
  • 31:47 - The Lead Developer Conference
  • 34:04 - Brighton Ruby



ALI: So hello and welcome to another episode of the CTO Show. I am Ali and today we have Toby Osbourn who is the VP of engineering at the Innovation Enterprise. I met Toby as couple of weeks ago at a conference called The Lead Dev and then once again at Brighton Ruby last week, so hello, Toby.

TOBY: Hey, Ali. How's it going? Thanks so much for having me on.

ALI: Great. I thought we got along reasonably well in the brief moments we've met over the past weeks so I thought you'd be good to have on the show. So what are you doing right now at the Innovation Enterprise?

TOBY: Sure, I’ll start by explaining what we do, broadly. We put on B2B events for CTOs, CFOs, pretty much anyone that's a C-Suite executive and the engineering team here supports that by building our websites to help with promoting the events and we do a lot things like you can purchase access to the events afterwards, watch the videos, things like that, so we build on a lot of those things. The most recent project we've been working on is a complete rewrite of one of our applications for viewing video and turning it into a React frontend, which has been interesting but that involved a fairly large rewrite of the existing Rails codebase and also training a whole lot of people in React.

ALI: So you're a VP of engineering there - what exactly does that role entail?

TOBY: I basically convert human talk into dev talk.

ALI: Okay, right.

TOBY: And dev talk into human talk. Part of my job is to sort of distil business goals and objectives into something actionable that the dev can take on.

ALI: Okay, so one of the problems we have at my company - and it sounds like you may have this at yours, to an extent, as well - is we have developers that are very, very good at what they do, they have a lot of technical knowledge and expertise and experience, but when they're communicating with clients, especially if they’re up against a deadline, sometimes they forget that the clients are not very technical so they kind of going into using their jargon and the rest of it and someone needs to step in to rewrite their emails at that point to start speaking in terms that the business side can understand, so it will be interesting to hear what you think about that.

TOBY: We face very much the same issue. One way we've got around that very recently is with the notion of project teams which we've introduced.

ALI: Okay, and what's a project team?

TOBY: The idea of that is, traditionally, the way things worked, someone would come up with an idea, so say one of the conference organisers would say 'Oh, it would be really cool if we had this feature on the website. Other events' websites do it,' or whatever it is, and a developer would meet with them and get down a rough spec, and that was fine, and then we would internally decide with them a priority for that; that was all fine. Then what would happen is the development team, whether it was one or two people or maybe three or four, would go off, complete the feature, then sort of go 'Ta-da! It's done!' and the person would go 'Err... okay, well it doesn't do X, Y and Z,' and they go 'Okay, well we'll go and fix that.' So they go off, fix that, 'Ta-da! It's done!' There was only communication at the start and the end of the project and I think that happened basically because we're in the same office as everyone else; they always assume that 'Oh, if they want an update they can just tap me on the shoulder.' So what the project teams do is we try, at the start of a project, to highlight the three or four key people and say 'Right, you're in charge of this project,' so that will be a few devs, a few non-devs, and we give them their own space, so it will either be a Slack room created just for this one small project and there will be communication limited to just this group of people and the idea is that questions that arise can be talked about in real time instead of the scheduled 'Oh, a body of work has been done, let's get some feedback,' and as part of that we've now changed to formalising more the task plans upfront and, most importantly, finding out what 'winning' looks like for a particular project. A lot of the time what would happen is a task would come in and I’d be like 'Oh, we need this form on our website,' and the win condition there was 'Form is on website' but that sucks as a goal. What we're trying to do now is really dig in more and find out 'Okay, why do you want this?' and then find out what the actual metric is that, if this number increases, or whatever it is, that's a win.

ALI: Right, okay.

TOBY: And then the team is then... it's less about the specific physical task that needs to be done and more about the goal that needs to be achieve.

ALI: How have people not within the dev team, the business stakeholders, how have they responded to this new way of working?

TOBY: Really, really positively, in terms of they feel the process is a lot more open now, which is great. There's less chasing being done or less uncertainty about who's working on what and stuff like that. One of the issues we face is we have three major websites and then a lot of smaller projects always ongoing and we have quite a small team, a small dev team, so we can't all be working on all projects at once. We do a weekly update to the company, saying 'This is what we've done this week. This is what we're going to be doing, hopefully,' but it doesn't really help for some of the smaller projects. People just need to know that, yes, it mightn't be the most important thing in the world but we just need to know it's being looked at or what stage it's at, so I think they really like being able to get that. People have been telling me they really like being able to give the feedback and just feel more involved in the process and I think the quality of the work is improving because all people are taking ownership, not just the dev team.

ALI: Right, and so when you have these business people - I say business people, I mean non-programmers - sitting with the developers themselves, do they do that full time or is that something that they sort of dip in and out of?

TOBY: It depends on the project. If it's a high priority change then it will pretty much be someone will work on that pretty much full time.

ALI: Right.

TOBY: Again, because we're a small team, one thing that we have tried to implement is three days working on roadmap issues, which is for large, chunkier bits of work, and then two days working on backlog issues - bug fixes, smaller little tweaks and changes that need to be made.

ALI: Okay, that's a really, I think, mature way of doing it, because usually it's one or the other, right? Or things just pile up so badly on the backlog that people don't get to roadmap issues or all, or the other thing I’ve seen done is you'll have junior developers working on things on the backlog and the more senior ones working on what you're calling the roadmap issues, but I kind of like this because it means everyone has to do it and there's an equal amount of time, well, not equal, but a significant chunk of time spent on each, rather than sort of flip-flopping over months or quarters or whatever.

TOBY: For sure. It's interesting you bring up the junior dev thing - we have a range of levels within our company. From day one we've always said 'You will not be working on silly tasks.' The first few tasks anyone completes will be pretty simple ones, just to get them up to speed with the code base and deployments and all of that. Like we would give the most junior person a big easy task to work on and just know that they will need more support through that - and that's fine.

ALI: So how big is your team now?

TOBY: It's about nine people.

ALI: Nine people.

TOBY: It's split between some backend folks and frontend folks.

ALI: Okay.

TOBY: A guy that does kind of backend/dev ops, and we've got a dedicated designer, a UX person.

ALI: Okay, that's a common kind of ratio - one designer for one big dev team - simply because you're not an agency or anything like that.

TOBY: Exactly, and one thing it really helps with is consistency across designs.

ALI: You said you have nine people in your ostensibly technical team - of that nine, how many would you count as junior?

TOBY: Junior? One.

ALI: Okay, and you mentioned a few things about onboarding that person but, in general, how have you found that experience of training that junior up to a level of skill where they can provide value to the business?

TOBY: It's been great, actually. I think we really lucked out. He's one of the most passionate developers I’ve ever met.

ALI: Right, okay.

TOBY: He's one of those people that, you know, like on Wednesday he'll be going home and learning Scaler and on Thursday he'll be going home and, you know, he's constantly learning and wanting to know more and stuff so it's just a joy. You give him a task and he just eats it up, doing his research.

ALI: I was talking about this with a couple of other people at Brighton Ruby but there's kind of a point where a developer starts getting jaded, maybe five or six years in, where they're actually a little bit too experienced. So right now my hiring target is actually somebody at that kind of level, maybe one or two years in, where they're still very hungry, they're still eager to learn and show that they have experience and do all of those things. That strikes me as a better person to hire as a full time developer than someone with, perhaps, a very large number of years of experience. Obviously for a role like yours or a role like mine, where it requires knowledge of the day to day and also looking at the big picture you wouldn’t want someone like that but for someone that’s on the ground and wants to be excited by the job they do, that sort of target level of experience sounds about right to me.

TOBY: Oh, for sure. If the output you want from someone at that level is just, you know, features complete, bugs squashed, things like that. The tools and frameworks that we use are changing so fast that, a lot of the time, that sort of build-up of knowledge doesn’t count for too much if you're just coding every time so, yeah, I would definitely take enthusiasm over experience for a lot of tasks, especially with the amazing resources that we developers have these days. It's so easy to get up to spend on most things.

ALI: We had a junior developer doing two days of work a week for us a couple of months ago. What really struck me was just comparing her first day as a professional developer, which was with us, and my first day as a professional developer. On her first day as a professional developer she was using version control, she was writing acceptance tests, she was writing unit tests, she was deploying to Heroku, she was using GitHub to open a pull request - this was on her first day. Think about how much - I don't know about you - but how much time it took me to build up to learning all of the things in programming, all of those things, and finally getting to the point where I could use them over three, maybe four years, whereas this developer is doing it on their first day - and I think a lot of that is to do with the level of resource, encouragement, support and general stuff that's available to people now that we just didn't have back in my day.

TOBY: For sure. I mean my first day I was definitely FTP-ing something up the live site.

ALI: Oh, definitely, yeah.

TOBY: I can't even remember the text editor I was using at the time.

ALI: I think mine was a Windows box, I was using Crimson editor, which was terrible.

TOBY: I think my first professional gig was Notepad++.

ALI: Oh, lovely.

TOBY: And before that it was some version of Dreamweaver.

ALI: Yeah, I think Dreamweaver was where I started to write HTML but then someone said something about hand coding and I didn't really know what it meant, hand coding, what were you doing, just aligned the bytes in memory with an electric filament thing? I don't know, but I left Dreamweaver pretty quickly and moved to a simple text editor. So presumably you haven't always been a VP of engineering - how did the transition from being, I suppose, a fully technical person to that leadership role happen for you?

TOBY: Yeah, so whenever I joined this company I think there were four - yeah, four or five - on the team and I was hired as a backend developer, so mainly looking at the Rails stuff, and I very quickly realised that even though we were a small team there was no one technical that was sort of taking ownership of the big picture on stuff. We were getting stuff done but there was no real roadmap test, there was no real sense of a direction, so I sort of said to the company 'I think I can provide value here and just help rally people around a sort of path to follow,' so I became, I think my first title was Head of Development, so when I was doing that I was still very much coding every day, coding maybe 70% of the time and then 30% of my time was doing this more sort of getting a plan in place, so writing up best practice and 'This is why we do things this way,' and trying to get some shape to the roadmap and then one of my tasks was to start growing the team so I made a few hires and the more people we got on the team the more clear it became that it wasn't the kind of role for someone to be coding this much and then no one really managing so I sort of transitioned more into this VP role where I now code very, very little during the day and maybe get involved in code reviews and, whenever there is a difference of opinion, sort of stepping in and throwing some weight behind one way or the other, but yeah, so I sort of moved into this. It was quite organic, it wasn’t really a discussed objective of mine but I started doing this more and more and I spoke to my best and said 'Is it okay if I do less code in the day? So you'll see less pull requests from me but what you'll see is, hopefully, happier workers and everyone else can be more productive.'

ALI: And that transitioned from Head of Development, growing the team and then managing this larger team - is that something that you wanted or is that something that just kind of happened and you were reluctant to do?

TOBY: It's weird. I wouldn’t say reluctant but I didn't wake up one day and go 'Oh! I want to send emails and manage people and do one-on-ones!' It was just I thought 'Right, okay, I need to do a bit of management so I want to go headfirst into this. I want to hear about the best managers in the world - what are they doing? I want to learn from them,' and started reading all of these books and just speaking to people. I remember I once heard it mentioned this notion of one-on-ones and I was like 'Right, okay, experts have said one-on-ones are a good thing. It doesn't matter whether I want to do them or not, they need doing. I am in the best position to do them, they're going to take this long, I can't be coding when I’m doing them.'

ALI: Obviously.

TOBY: Yeah. 'Therefore I need to do less coding to fit things in.' And it sort of goes on from there. There were just these tasks that it wasn't that I was unhappy to do them, it was just I was the best person to do them and they needed to be done, as far as I was concerned.

ALI: Okay, but let's say, for example, for whatever reason, things finished up here at the Innovation Enterprise. Would the next thing you looked for be another management/leadership type role or would it be going back to the weeds, technically?

TOBY: Good question. I think because I still have so much to learn in this role I’m excited by it so that would probably be my next move, more management stuff. Because of the amount of open source stuff there is I can always code at the weekends.

ALI: Yeah, exactly.

TOBY: There's always a creative outlet.

ALI: You’re not the first person to mention this. The other thing that someone said, when I was asking them about what they wanted to do next, this is a very technical person who has a lot of experience and, until now, hadn't indicated at all that they were interested in management but the thing they said was, while they can provide value as a coder, as a technical person, or even someone who reviews pull requests and gives people technical direction as a sort of architect, there's actually much more value that they can give as being a voice for the technical team in the management meetings at sort of higher levels in the company, so in that regard being a development manager or something like that ends up be4ing better for the organisation and it means that you can have a bit more autonomy in the sort of ground rules of your workplace.

TOBY: Yeah, I definitely, definitely agree with that. One big thing that I think I’ve been able to do in this company is act as a force multiplier for the productive members of staff because I can basically remove as many roadblocks as I can, which I think is harder to do whenever you talk like tech to people. If the problems you're looking to solve are very technical and the conversations you're having are very technical, business people don't care about that stuff, whereas whenever you can communicate with them and talk on their terms it's much easier to say 'Right, give these guys some autonomy,' so yeah I definitely agree with that and I think there are so many people that are really, really passionate about development that it's never an issue hiring someone - you can get developers. I think it's harder to hire people who are passionate about management and passionate about leading developers.

ALI: But at the same time, honest to goodness, I don't think I could trust somebody who is a manager of developers who hasn’t actually done the job of being a developer. Do you know what I mean?

TOBY: Oh, for sure.

ALI: Because you need to find a developer who has either fallen into or has chosen to become a manager of their own accord. Those people, I think, are reasonably rare. They don't just decide that. Because you can be a developer your entire career. You can be a technical person for 20-30 years and retire or do something based off of that, and I think many people end up doing that.

TOBY: Yeah, for sure, and I think that's something I’m still in the process of working out here but I think a lot of people get worried about 'Oh, I am a mid-level developer in a relatively small dev team. Where can I go from here?' because I think a lot of people get scared by the idea of doing management and that sucks because you don't want to take somebody who's very productive with what they’re doing and go 'Oh, they’re really good at this, therefore they're going to be really good at managing.' It's like, no, that's bollocks, that's not how it works.

ALI: I'll talk a little bit more about this later but I’ve been in that exact situation only I was not the manager, I was the one being managed by the person who didn't want to learn management. It was a really horrible experience. Anyway, you mentioned a few topics ago that one of the things that you had to do when you became Head of Development was to grow the team - can you talk to me a little bit about any sort of tactics and strategies you put to use in your hiring process when you had to do that?

TOBY: Yeah, it was fairly standard, to be honest. The main thing we did was a code challenge upfront, so it was specifically quite a vague thing, it was a game people had to make, a little console-based game where you had to shoot aliens, so first of all they could attack it anyway they wanted. The only thing we said was it had to be in Ruby or Rails because the technology, we don't care that much at that point what they use, and we specifically included an overly complex formula. We said 'As an example, the directory could be this, it could be worked out based on this,' and it was a really, really ugly, badly worded formula and it was just to see how people would react to a poor spec, essentially.

ALI: Okay, and I guess what you were looking for there was for them to perhaps rewrite that in a way that achieved the same thing but was simply or something like that.

TOBY: Yeah, or just dismiss that and say 'That's rubbish. Here's another implementation.' I like people who reject ideas.

ALI: That are dumb, yeah.

TOBY: Yeah, exactly.

ALI: That was your initial challenge that you put to potential applicants - what happened next, after that, in your hiring process?

TOBY: So they would submit pull requests, link it up to code that they'd done, we'd review that as a team and go 'Yeah, we have a good feeling about this person, let's go on,' so we'd arrange a meeting with them. We're based in London but we are set up for fully remote work - we actually have three full time remote folk at the moment. So if a person is near London we'll get them in; if not, Skype call, and yeah, we'll just have a chat and one thing that I really look out for is more of a cultural fit than anything else because it's 2016, we can look at people’s GitHub repositories, we can read their blogs, you can get a pretty good sense of what the person is capable of without ever needing to speak to them but what you don't get a sense of is how they’re going to be to work with and I very strongly believe that bringing one toxic person into the team does far more damage than bringing in one person that doesn’t actually know how to use Rails.

ALI: Have you had that experience before, where you've hired someone where it turned out to be a mistake because of a lack of cultural fit?

TOBY: I haven't hired anyone, luckily, that's been like that. I have been someone that was the wrong cultural fit.

ALI: As have I!

TOBY: So I worked for Buffer, social media sharing code. Whenever I applied I was very excited, I really liked their values, I really liked their approach to things, and I applied, got through the interviews and the questions were very much geared towards culture and I got in and we were just not the right fit at all. There was just like, I don't know, it seemed almost like that sort of clichéd American positivity that really ran deep in the company, which is fine but I am not that type of person that's extrovertedly happy.

ALI: I think also, if they published that, if they published values that said possibility is one of the things, like in my company, internally, I’m one of the most negative people in terms of if there's a problem I’m not going to pretend it doesn’t exist, I’m going to say 'That's a problem, we suck at that and we need to take steps to fix that,' without laying the blame for that on any one person. Basically it's my company so everything's my fault, but for me at least that results in a much stronger sense of the things that we do correctly have been vetted by my own internal void of negativity.

TOBY: I like that.

ALI: So that's the strategy. The end result may be the same but I prefer to be a little bit good at something rather than pretend to be amazing at everything.

TOBY: Yes, so I think by the end they weren’t happy with how I was interacting with people and I wasn't happy with how people were interacting with me and it was very obvious that that culture was so important and out of a failing of mine or a failing of theirs, I don't really know, but it didn't work out so I sort of took that forward and whenever I’ve been hiring people I don't, like during interviews I hate companies that pretend they're better than they are. I've been sitting in interviews where I've asked someone 'What's the most annoying thing about your company?' and they're like 'Uh, can’t really think of anything.' It's just complete rubbish - everyone always has at least five things they're angry about in their office, and if they haven’t then there's something wrong.

ALI: These people are asking you in an interview - if they didn't have five things they were annoyed about, why are they leaving, exactly?

TOBY: Exactly, exactly. So it's just like just be honest.

ALI: The concept of an interview, no matter how well you explain it, is inherently hostile and they're trying to put their 'best foot forward'. They may believe, in the moment, that you're trying to get something out of them to use as evidence against them. It's true, though, right?

TOBY: Yeah.

ALI: So they don't want to be negative, even though they've built up all of this angst in their current workplace, which everyone does to an extent so I don't think I could judge them in the interview for that. So you mentioned, as part of becoming a manager, you did, for example, one-to-ones - is there anything else you've done as a manager, any practice that you feel has gone well or gone badly for you, just in starting in the leadership role? TOBY: One thing that I have tried to do is be super, super transparent with people. So that means that I distil information down quickly, I don't sit on facts, and I’m also very, very open with people, so an example of this is I have depression, I’ve had it for a while and it's under control and stuff but one thing I did fairly recently was let the team know. I got a lot of positive feedback about that. Even if people weren't coming back saying 'Oh, me too,' or anything like that, they were just happy that they could work with someone that was open about that type of stuff. I've pretty much told people 'At any point just tell me how you feel and if you want to go totally off the record with stuff, that's 100% fine.' The way I see my role is I have to act as an amplifier for the dev team to make sure that development team issues get recognised within the company and they get sorted. I'm not a mouthpiece for corporate goings-on. Like I’ll translate human into dev in terms of technical stuff but I’m not going to just tow the company like for stuff. So fairly recently we were acquired by a company, Argyle Executive Forum, and it's been great - we've grown in size, the scope for what we can now do has increased, but there was certainly some uncertainty over the future of the development team.

ALI: Because they have their own development team or something like that?

TOBY: No, specifically because they don't so they've always outsourced development, so the feeling was 'Oh, Christ, are they going to be outsourcing us?'

ALI: Right.

TOBY: So I had a very candid conversation with the dev team where I was just open, saying 'Look, I don't know but I think everything’s going to be okay, I think there's positives to this, blah, blah, blah,' but I gave everyone my mobile number and personal email address and said 'Look, if you want to chat there will be no log or anything that anyone can ever search, go for it,' and again it wasn't so much that people took me up on that exact thing but I think if you're open with people they appreciate that and whenever something is nagging at them they feel more able to speak to you about things.

ALI: I mentioned this, I believe, in the previous episode but a lot of the things we end up doing as managers are kind of signals rather than the actual content of the thing we're doing. So for example one-to-one meetings - the one-to-one meetings and doing them regularly means that when you have a one-to-one meeting and something serious happens you've got this reservoir of goodwill built over time so that when you have negative feedback to give someone it's not just in a vacuum, it's not the only thing you've said to that person in three years of knowing them, it's one of a hundred one-to-one meetings you’ve had. So the context of when you give that feedback is very different. In the same way, what you’ve said there, where there may have been nothing going on in that particular situation but it means that later on everyone feels open enough to get in touch with you when something serious is actually happening. So yeah, I think that's a really important thing for a manager to be doing.

TOBY: For sure.

ALI: So the other thing I think you said you wanted to talk about, and I have some things to say about this as well, is mental health issues in managers. You touched on this briefly but is there anything in particular you wanted to talk about with regards to that?

TOBY: Yeah, one thing I found very interesting in myself, as I said, I suffer from depression, is whenever I was feeling a bit low in coding there's always a very black and white, like the tests pass, the tests fail, like you can't write code in a depressed state, it sneaks through and ends up affecting anything. It mightn't be the best code in the world but there are tests for it. But when it comes to one-to-one meetings or how you respond to someone who's asking you a genuine question, how you're currently feeling about yourself has a massive impact on the type of reply that you could sent and, you know, your email client is going to go 'Whoa, calm down there!' So yeah, so one thing that I’ve really had to consider is that sort of shift in work from the very well defined things where someone else can say 'This wasn't great, we're not doing this,' to this sort of softer stuff, where once you put an email out there, it's out there, so how I’ve personally been handling that is just to kind of try and just constantly taking two seconds before hitting send on something or before responding to someone and just making sure that the response is thoughtful and it's coming from the right place. I think because I have taken the time to build up this rapport, as you said, there's this sort of reservoir of goodwill, people will know that if, say I don't reply to an email for a day or two, it doesn't mean I’ve forgotten about it because I’ve built up a history of always replying to people so people know it will get handled, it just means that I can focus on other things and tell them in the right sort of headspace.

ALI: When you're coding it's all of these binary decisions, which is not necessarily the case when it's like a design issue, but even then there's less of your own emotional self-involved and just purely your intellectual self, right?

TOBY: Yeah.

ALI: I think you saw at the Lead Dev conference, I think one of the first talks was talking about the fact that you, as a manager will make mistakes, no matter what, you don't have a choice in the matter, and what's kind of terrifying to me is the idea that when you make a mistake when you're programing, fine, production goes down but you've probably got processes in place to handle that and you can kind of fix that. When you make a mistake as a manager, especially a systemic mistake, you can make somebody’s life a living hell for like two, three, six months at a time and not even realise that's the case. Knowing this - I kind of knew this when I went into becoming a manager as well - and the best I can come up with is doing a lot of the stuff that you're doing, so doing the one-to-ones, but also making clear to everybody on my team that I am a junior manager, I am not an expert at this, I’m going to make mistakes and I’d really like them to tell me when I’m behaving in a way that they feel is unfair or is inconsiderate to how they feel or what their point of view is. At the same time, I think a lot of people just won't complain about that kind of situation, they'll just take it so no matter what I say, even as a signal to say I care about not messing this up, people won't complain or haven't, at least, complained much of the time yet, so that's something that's constantly bugging me.

TOBY: Yeah, on that actually, it's interesting, my wife is not technical at all, she's an intensive care nurse but she has been doing a lot of training recently, like delivering a lot of training, on how teams can cope under stress and as part of it all is sort of initiating the feedback loop, giving them feedback early, and she knows about this stuff. Anyway, I was telling her about something very similar to what you were saying there, that I have actively asked people for feedback before, like specifically constructive negative feedback on how I’m doing, and of course everyone is just like 'It's fine, everything is great,' and it's like 'Oh, rubbish,' there's no way someone, as you say, new to this role is doing everything perfectly. I was telling her this and I was like 'What can you do?' and she said it's in the way you word the question, so what you're meant to do is, instead of saying 'How am I doing?' you ask 'How would you score me out of ten?' and obviously no one's going to give you 10/10. If they’re going to be sucking up to you they’ll give you a high number but then as soon as they give you a non-10 answer you can then initiate the conversation and say 'Oh, brilliant - what can I do to get there?'

ALI: Right.

TOBY: It starts the conversation more that way.

ALI: That's excellent.

TOBY: Yeah, I thought that was very interesting. I haven't had time to implement that theory yet or try it out.

ALI: So we've been to a couple of conferences together recently - what did you think of the Lead Dev?

TOBY: I thought it was brilliant. I honestly thought it was one of the best conferences I’ve been to, period.

ALI: I was surprised. I was expecting to just go there and talk to some people I knew, some people I didn't know, and the talks would be kind of secondary but the whole thing was really well organised and the talks were brilliant.

TOBY: Yeah, definitely. From about five minutes into the very first sort of intro that Meri Williams was giving the whole closed captioning thing that was happening was just amazing. That really did blow my socks off. It was just a small thing to do. It was just so amazing, and just the code of conduct, like that's the first conference I’ve been to where it was actively called out, like this is a positive thing and going into detail on how to act on it and everything. I thought it was just so perfect.

ALI: I think some companies, we don't have an official policy, but some companies are now saying that they won't pay for tickets to conferences that don't have a code of conduct. I think that's probably a good way to indicate that this is something that's important to you.

TOBY: Yeah, for sure.

ALI: You talked about the closed captions thing - I was at, years ago, Ruby Conf Uruguay and in Uruguay, if I remember correctly, they speak Spanish and they speak English as well, so some of the talks were in English and others were in Spanish and they had simultaneous interpretation, so you could put headphones on and listen to the talk as the speaker was speaking, or a few seconds behind, in your own language and it was kind of amazing. I called them out in my talk - I said 'The simultaneous translation has been amazing'. I can't believe how many technical words they got, like I was talking about remote code execution vulnerabilities using the Ruby on Rails session cookie and they were getting all of it. My mind was blown at how good they were.

TOBY: That's fantastic. If nothing else, I would imagine that you would feel you're in the UN.

ALI: Something like that, yeah.

TOBY: Headphones on, just nodding along.

ALI: The other one we went to, Brighton Ruby, what did you think of that?

TOBY: Again, I really, really liked it. That was my first time at Brighton Ruby. I was expecting it to be a lot smaller than it was.

ALI: It was small a few years before. This was as big as it's ever bene.

TOBY: One of the things I was saying to a colleague in work this morning was anywhere you go, the content of talks is very rarely ground-breaking. It's always either the person’s given the talk ten times before or it's an adaptation of a blog post or a book, you know, some concept that's very rarely someone making an announcement that is new to the world and I think that Brighton Ruby really, really helped get to the core of what makes a Ruby community great, which is the sense of just comradery and just having fun with code and I can't imagine that, what was it, Just a Minute game shop working...

ALI: Like the strange loop or something.

TOBY: Yeah, exactly. It was just so perfect for this type of conference, it was just real fun.

ALI: It was a lot of fun and I think, in my experience at least, some conferences, after the first or maybe second or third or whatever instance of them, they kind of lose that kind of energy they have in the first ever one, where some things aren't that great but they're having a good time and it's very small and, like you said, there's this kind of comradery. What's nice about Brighton Ruby is they’ve kept that over the three years. I suspect it has a lot to do with Andy Croll, the organiser, and his personality more than anything else but, anyway, yeah, I enjoyed it a lot. I got my golden three times Brighton Ruby badge as well, which I was really proud of, but I’m pretty sure I lost it on the way home.

TOBY: I'm so jealous. Before they explained what the badges represented I saw someone open an envelope with two badges and I was like 'Oh, goddammit, I only got one! Why is that?' and then I was like 'Alright, fair enough.'

ALI: Cool, we're running low on time a little bit. I mentioned in the prep for this if you have any picks, recommendations for people, it would be good to mention them.

TOBY: Yeah, for sure. There's three picks if you don't mind. The first two actually come from the Lead Dev conference. The first is the slides from the Lead Dev conference are currently online. There were some amazing talks and I think a lot of the slides were written in such a way that you can have context without having seen the talk and I believe the videos for it are going to be released very, very shortly so I’ll send you the link for show notes if you want but if you just Google 'Lead Dev conf slides/video' you'll get them. The next one is there is a leadership Slack channel.

ALI: Okay, interesting.

TOBY: Rand gave a talk about it at the Lead Dev and he sort of mentioned it, almost a by-the-by thing, and I recently joined it. So far I’ve been doing more lurking than anything else but there is a ton of amazing people in there, loads and loads of separate channels for every conceivable issue that you would run into as a technical leader. As someone who's new to being a technical leader it's great.

ALI: Useful to have, yeah.

TOBY: Yeah, for sure. And the final thing I wanted to recommend is a book that I have just finished re-reading, Thich Nhat Hanh, I think that's how you pronounce it. He's a monk, he has several books out. This one is 'How to Sit'.

ALI: 'How to Sit'? Okay.

TOBY: Yeah, it is a very, very short read and it's just on meditation practices and you don't need to be fully invested in having a full-on meditation hall.

ALI: Incense burning.

TOBY: Yeah. It's basically saying that you can meditate while you brush your teeth.

ALI: Great!

TOBY: It just sort of explains what meditation actually is and how you can give full focus to whatever you're doing, which I really appreciate it. I like that sort of thing.

ALI: I'm trying to get better at this as well, looking at what's going on around me more than just being in my head all the time, so I think I might take a look at that.

TOBY: Yes, for sure. He mentions a lot this notion of coming home which I really, really like. It's mentioned throughout the book but it's just this realising that the present is the key thing that matters and just this calming everything down and just bringing it back.

ALI: I think maybe a lot of technical people are adverse to what they see as new age mumbo jumbo stuff but there's a lot of stuff out there about meditation and mindfulness that doesn't actually require you to believe in reincarnation or the next life or even much of a spirit or a soul. It's really just about, I think, observing your thoughts and gently bringing them back to the present when you have the opportunity to do so, right?

TOBY: 100%. I have read several of his books and I don't think spirituality has been mentioned once.

ALI: Okay.

TOBY: It’s all just very practical; it's about you, which I really like.

ALI: Okay, well thank you very much for being on the show. I hope you’ve enjoyed having this conversation.

TOBY: I really, really have. Thanks. It's my first podcast so hopefully I haven't stumbled around too much.

ALI: You've been a fantastic guest - and listeners, thank you very much for listening. I hope next time will be as much fun as this time was. Take care.