You can find Steve around the internets here:
- Twitter: @sbartholomew
- GitHub: stevebartholomew
- Website: www.stephenbartholomew.co.uk
- Company: Reallyenglish
Things we talk about
- 03:55 Reallyenglish Challenges and Day to day Operations
- 09:15 One to one meetings
- 15:28 Remote Working: Tools and Practices
- 21:33 Growing Teams and Hiring Processes
- 27:20 Management
- Code: The Hidden Language of Computer Hardware and Software by Charles Petzold
- Fire in the Valley: The Making of The Personal Computer by Paul Freiberger and Michael Swaine
- History of Japan Podcast
- The History of the Cold War Podcast
ALI: So this is the first ever episode of the CTO Show. I am Ali and today we have a very good friend of mine, Steve Bartholomew, who I used to work with at a company called Really English. Hello, Steve. How are you?
STEVE: Hi, I'm good.
ALI: What's keeping you busy at work right now?
STEVE: At the moment, working on shipping an updated version of our mobile app out. We're quite a small team so we've got a kind of crazy hybrid app that ships out to iOS and Android.
ALI: And so before RE what were you doing?
STEVE: I ran a company, since 2006.
STEVE: So we were a small agency doing custom, bespoke development for various different companies and some councils, things like that.
ALI: That's exactly what our company does as well, so I remmeber having quite a few conversations with you warning me of some of the pitfalls and what have you about that. So what made you decide to wind that up and work for RE?
STEVE: I think I probably got, the conversations we've had, normally, in the vein of how not to do it, the company didn’t end in a particularly good way, we did end up going into liquidation after primarily, really, taking on too much work, not really managing things properly, not charging properly, those kinds of things, so the move to Really English, initially, was more a kind of 'I have to do this' in order to pay back the debts of the company.
ALI: Yeah. I think, yeah, your story of why you had to wind that up and start work contracting, to begin with at least, was one of the key reasons that I didn't or I was put off getting a co-founder ever for my company, no matter how many good examples I see of people doing well with that model. I don't mind working with other people, I don't mind doing joint ventures, but the ownership of the company, I feel like, has to be mine - which hasn’t bit me in the arse too badly up until now but sometimes, like for example today, I honestly feel like having a co-founder to just commiserate with would have been nice.
STEVE: It's difficult for me to say because I’m not in the habit of bad mouthing the co-founder of my company.
ALI: Sure, okay.
STEVE: We got on really well for years, we worked together for a long time prior to starting the company, and when we started the company it felt like a no-brainer to do it, it was one of those very natural things and it felt really natural for quite a few years. I think the thing that comes out over those years are those small differences. There were a lot of things that we had in common but there were things that we differed on, and things that we didn't really have influence over, like our own personal situations - we both started families, those kinds of things - put pressure on any business relationship, I think, and, yeah, it's so hard to see those things coming so, yeah, even if you think you've got the right person it is really hard and I think that’s why I was saying, obviously I was quite negative at the time, that this was not the right way to go. I'd probably still, if I was to start an organisation, a company, in the future, I’d probably do the same thing still.
ALI: I feel like I already have a co-founder for the rest of my life so I don't really need a co-founder for my business as well, do you know what I mean? Like having a life partner is already something you have to work at and think about and really, especially when you have kids, the whole dynamic changes when that happens. I feel like I don't have the energy to manage that at work as well, and I don't think that is necessarily an objective thing that's true for everyone, it's just that with my disposition I like to not have any question as to what to do and the direction the company is going in, which is probably why I was a terrible employee pretty much everywhere I worked. Okay, so right now, at Really English, what are your main challenges? What are the things that are keeping you up or what are you focusing on right now?
STEVE: It's kind of a mixture of things, really. I am the quote-unquote 'lead', the tech lead. I say quote-unquote; this is because I have a real reluctance to be in the position I’m in. When I came out of running the company, what I really wanted to do was say 'Okay, I’m just going to focus on programming. I have a lot of business debt to pay back. I just want to, you know, get a job, go to work, do the job, do it well, but basically focus on programing,' but apparently part of my personality wants to get involved in more of the management side of it, I guess, but I’m very reluctant to do it, I don't feel 100% sure about the decisions that are made all of the time and I’ve been told that that's actually a benefit, the sort of reluctant leader.
ALI: Right, okay.
STEVE: It sometimes does okay. So basically what I get involved in doing is, day to day, probably I split varying percentages between doing programming - I primarily work on the mobile side of things, this area I’ve got quite a lot of experience in - and doing more management duties, and those fall down to sort of bridging the gap between the business people and the development team. We've got a lot of really smart - well, I say a lot, we've got a few really smart - we've got a smart team, basically, but there's not very many of us. They're very smart but not everyone has the patience or the willingness to listen to business people, which is something that, having run a business, I’ve got more sympathy for. It sometimes puts me in a difficult positon because I’m in the middle of understanding the business goals and understanding the technical desire in a particular way and that can put you in a bit of a difficult position to know which way you go and you sort of have to smooth out things on both sides.
STEVE: But that's what I do, so product side of things, instead of having, we don't have one person that 100% guides the product, what we did here is there's a lot of different people putting in their requirements or ideas for the product so what we decided to do is have a kind of trio of an education person, a design person and a technical person and I am the technical part of that three.
STEVE: So what happens, naturally, is we sit in a room and argue.
STEVE: We argue out a backlog of work and then I go and sort of identify the technical side of that with deliverers. So that's one part of it. The other part is kind of taking a long view, technically, because I find that sometimes, when you're working on just a single backlog of work, the focus can be on 'Let's ship this feature.' History has shown that if you don't think six months, a year ahead and just consider it, that you can end up shooting yourself in the foot where you didn't need to if you'd just planned things slightly differently, so I take on that role as well.
ALI: I remember being at Really English and there being copies of the lead start-up sort of lying around and all of this start-up-esque literature just sort of being ambiently there and we kind of joked that, actually, this is a company that's been around for nearly ten years now and it may be time to start thinking a little bit more long term than buzzword of the week or whatever so, yeah, it's interesting that you've mentioned that thinking long term about technical decisions is something that you're doing now. I think you mentioned that you have this sort of trio of people that argue things out - I think a lot of people in business are kind of afraid of conflict but having a bit of healthy conflict, because it's not like the people there are at fault, having that conflict there, that conflict was already there in the business, in the fundamentals of it. Making that explicit and hashing that out I think is probably a very healthy thing for the business
STEVE: Definitely. It's one of the things that I was keen, when I came into the company, one of the interesting things about having a failing company is that you reflect on that and you can see the things that you did wrong and then, taking that into another company and another team, you start to identify those areas where they're doing the same thing but you've had that kind of reflection time to say 'Actually, no, we need to do things differently.' The company I ran was nowhere near the size of Really English, which isn't that big either, but it was still interesting to see the same kind of things come up and I do think the conflict thing is important. It can get negative, but I think that's why you have to have someone who can step up and just say 'No, let's do it this way.'
STEVE: And we limit that to three people, basically, so I often have to take the flack when I’ve got two people who are talking about subjects that they're arguably smarter than me on. As a technical lead, I’m looking at these two solutions going 'But they're both pretty reasonable...' and I have to say 'Okay, which one is going to fit in with either the long term vision or the desire to, you know, we've got to ship for this deadline,' and I have to pick the one and upset someone and kind of be okay with that. One person’s going to think I’m stupid and that's okay, that's the way it goes.
ALI: You mentioned that sometimes that kind of thing can get negative - so for example, from the management playbook, a lot of people have heard of the idea of having a one-to-one meeting or just generally meeting with people that you work with, perhaps outside of work or something like that. A lot of people don’t really see the value in those one-to-one meetings but I think that one of them, especially when there's nothing going wrong, there's nothing negative or there's no bad feedback to give, I’m not sure why they should do one-to-ones. I think, for me, one of the biggest benefits of having a one-to-one and continually just having a little bit of space to talk to someone about their problems or just about how things are going is that you're continually adding to that store of rapport and the goodwill in the relationship so that when things do go bad and when things do go negative you're in a kind of trusting environment and you know this person does really have your best interests at heart, it's just that in this particular case we have to get a little bit negative and in each other's faces to get this work done, and I think that's much easier to do if you have this baseline level of knowing that this person has your interests at heart.
STEVE: Yeah, definitely, and, interestingly, that's a little bit of a challenge here because we have a lot of remote working and also a large portion of the team have various family commitments as well so we don't, you know, stay super late all the time, go out for drinks at the pub, that kind of thing, so I’m kind of mindful of trying to make sure that I’m checking in with people, so having those catch-ups, it's hard, because you don't want it to sound like it's a review, like a performance review, because, you know, I can see the benefits in those kind of things but it shouldn't be that kind of formal 'I'm the manager, sitting down with you, we're going to outline your performance over the last six months,' and having more of an informal chat but kind of cover the same kind of things - 'How's it been going? What do you want to see over the next couple of months?' those kind of things.
ALI: From an employee or somebody who's your direct report, especially if you don't do them regularly, if you do them just whenever you have a free moment, having like a meeting, a one-to-one meeting, your boss suddenly saying 'Hey, let's meet in this room, you and me, we need to talk,' out of the blue, is fucking terrifying, right? So that's another reason to do them regularly, is because you don't want to induce all this anxiety and then just turn up and be like 'Hey, how's it going?' so, yeah, that's something I’m cognizant of and if I’m not doing the one-to-ones I will tell everyone 'I want to do one-to-ones more often,' so they know, at least, that it's something that should be happening regularly, as opposed to when they get the email them just being terrified of whatever the results could be.
STEVE: Yeah, if there's things going on, especially if you've got a team that's working on multiple things, which presumably you do with the agency style, and we are starting to have now because we've got various things on and we're still a small team but we have a couple of people working on this thing over here, a couple of people working on different things, and so it's important. Maybe I’ll be doing it once a week, just quickly going around everyone and saying 'How’s it all going? Where are we getting at?' and sometimes that can be a good chance for course correction, because if a developer has got a focus in one particular area and is just focusing on getting that particular piece of work out, they may not be aware of that thing that you just discussed with a client or business a few days ago. It's actually going to impact their work and if they do that change now it's going to make the future work easier and I find that if I don't do that then things, you do find there's a sudden surprise when, at the end of the two weeks, you look at the stuff and you think 'Ah, we could have done that differently.'
ALI: Things are a bit less complicated for us because we have one developer on one project and that one deliverer really is given the full leeway to do basically whatever they want in order to make the client satisfied with the work, so there's no middleman between that developer and that client. That’s easy for us to do because there's only one developer and the teams are small and are clients are typically quite technical but, yeah, the only times that clients have ever been actively angry with us because we've messed up has been because of a miscommunication, like somebody told somebody else to do a thing and that message didn't get relayed or I was in the middle of it and I forgot to tell someone and that is where all of our problems come from. They're not technical, they’re not bugs, there's nothing like that, it's always been about communication. That’s the only time we've tripped up on client services pretty much ever.
STEVE: Yeah, I think from my point of view it's more about... Well, okay, so one of the biggest things that I was trying to address was that short term thinking issue, so once I started to have more control over 'Okay, how do we build this stuff?' I wanted to get everyone to be thinking about reuse, so building things to be used for upcoming features. A lot of the patterns that I saw here were things like whenever you wanted to create a new course to teach a new particular type of English study or whatever there would be a whole new Rails app made or a new design or just a complete rebuild of a lot of common concepts so what I was keen to do was start to lay the foundation of a platform on which you could make courses so it was quite important, as those pieces were getting made, the pieces themselves could have been made in a way that still box you in if you weren't aware of that longer term thing, whereas I guess if you're doing a job for a client, you say they're quite technical?
ALI: They tend to be quite technical, yeah.
STEVE: Yeah, so they've got an idea of what they're trying to fit things in with, technically.
ALI: And like I said, for us, things are not always earlier stage but typically much earlier stage, like where it's a green field project and the idea of courses wouldn't have been thought about and we have a lot of leeway to just basically dictate what the architectural terms are and, unless they come back to us in a couple of years’ time, we're probably not going to have to deal with it ourselves, so it is a different situation from you guys. So you mentioned that it's a Japanese company, so you have some people in Japan and some people in the UK, presumably - how has remote working been for you?
STEVE: It took a while to get everyone on board with it but I think, generally, it's worked really well. We have one remote worker who is actually in Japan. There is a development team that's in Japan that works on another part of the technical architecture and that's like a different challenge to the day-to-day because we have to kind of align our goals but then also we have different paths and different tracks that we're going on. I feel like my role there is I’m still involved but it's more advisory - I go over to Japan once a year.
ALI: Okay. That's nice!
STEVE: Meet with the tech department - yeah, it's good! We talk about what's being worked on and the way we should approach things. There’s more of a kind of advisory role there. Directly working remotely, it's great. The crossover of time can be a bit difficult sometimes.
ALI: Yeah, Japan-UK is really hard.
STEVE: Yeah, it is, yeah. Especially at the moment, because we've got a junior developer on our team and she works primarily with the remote developer in Japan and that can be challenging, especially as a junior, to be in that position of needing to, you know, he's also quite high output as well, so you can get in at the beginning of the day and there's a ton of stuff that's changed and then you need to go in and kind of understand where that's going and what's been done and then be able to pick it up. But apart from that we've found remote working to be pretty good. We've got on top of doing our daily stand-ups remotely - I know this is kind of general logistical stuff but it works quite well.
ALI: When I say tools I don't mean like Slack, etc. but what sort of practices do you have for communicating as a team that you use, I don't know, weekly, monthly or daily even?
STEVE: Well we do daily stand-ups and we just use Hangouts for that, for group stand-ups. We try to talk as much as possible, like straight after our stand-ups in the morning we'll often have little breakouts where we'll talk, and the thing I like about the daily stand-ups is you just get to hear about those blockers. It can be really easy for certain developers; they just keep going over the same problem instead of talking to other people about it who could have unlocked them really quickly. So, yeah, that kind of regular checking is really important so we try to talk as often as we can. What we've started to get into very, very recently - this is quite new - this is going to sound a bit stupid but kind of documenting our discussions.
ALI: Okay, that doesn't sound stupid at all.
STEVE: Well, stupid as in ‘Why would you not do that?’
ALI: Exactly, right?
STEVE: And I don't know why, but what we've found with some of the biggest technical decisions that we've made, obviously I want to get input from a lot of different people and often there's a lot of different opinions about maybe the way we should be doing things or different people have got occurrence in different areas and it's kind of hard to get all of that in 'Let's arrange a meeting for 11 o'clock and talk through it all.' We use Confluence, which is basically just a Wiki, and I’ll write up 'This is the discussion, or this is the overview, of the thing which I need to solve and here's some ideas,' and just get the discussion going around that, and it’s been so effective, it does just have that no-brainer feel of 'Why weren't we doing this?'
ALI: Yeah, that practice of going to everyone and getting their input when doing a proposal. Do you think that you brought that into the organisation or was that something that you were already doing other parts of it? There’s a reason I’m asking you.
STEVE: It wasn't going on with any formality anywhere else but it's also not really something that I think I personally brought to it. I've been four years and we've only just started saying 'Okay, let's see how this would work.'
ALI: In Japan they have this practice called ringi seido and it's basically a form of consensus building and what it is is, instead of, what we might do is have a proposal put out for the team in public, or an email sent out to everyone, instead, in a fairly formalised process and it's been around for 20-30 years, it's not like a new-fangled management practice, basically what you do is you to everyone whose opinion you want, who you want to have their say or may potentially disagree with you, and you get all their concerns down on paper - in private, so it's just one-on-one with each person - so that when you build this proposal, when you send it out to the rest of the team, you've already covered a lot of the points that people are going to bring up and, to an extent, you now have everyone as your advocate, so everyone's already agreed with what you have to say in principle and registered their objections, they've put it out there. So it is a management practice that's been around on pen and paper for a long-ass time and, yeah, you're right, I’m just surprised that more companies don't operate like that because it's just way more, I hesitate to use the word, but harmonious than the typical debates we have in our companies, right?
STEVE: Yeah, actually I feel like I’m kind of misspeaking because, as you say that, the kind of product side of things has bene doing that for a little while now because one of the issues that we had, or we have had over the years, is getting that understanding from our sales people. Our sales people are quite varied - they have clients in education, in corporation Japanese companies, some big companies as well - and they all have input that they want to put into it. Now obviously you're not going to be able to keep everyone happy but that open dialogue is something that the product side of things has been doing for longer than we have been doing, technically, and I don't quite know why we didn't pick up on it. I think it's probably, I don't know, developer arrogance, that 'We can just talk this out. We're smart enough to be able to pull this decision together ourselves.'
ALI: You said you have a small team - do you have any plans to grow it?
STEVE: I would like to. We're a bit restricted at the moment, I say euphemistically, but yeah, I think it would be, in the future I would like to. It's one of those things I would like to do slowly because it's another area of how do you bring someone on board? I feel it's quite a challenge when you have a team that is just focused on delivering, the person who comes on isn't necessarily going to get that nice ramp on that you might get with a big company. I don't know how that affects your side of things but I guess it's a similar kind of challenge.
ALI: Yeah. this is leading on to a question about hiring in general and what your practices are. For us, I’m having to think about a lot of that upfront, simply because I have some reasonably well defined plans about which direction this business is going in and how it's going to grow over this year and then next year. I know the team's going to hopefully double in size next year so I’m sort of gearing up to do that with a better defined hiring process and all the rest of it. I'm just interested to near what your hiring process is like, if you have one, and any pitfalls that you've found or things that you've learned that worked really well.
STEVE: So far - I experimented, basically. We had a bit of a drive for recruiting a year or so ago and it's difficult, I don't think I have a really good answer. I put a job ad out on Stack Overflow, got quite a lot of responses there. It's once you get into the interview process that I think it can be really tough. I have always found that sitting down and talking to someone more generally about how they approach development has been probably the most positive but I have had a few misfires where I haven't quite understood the technical skill of the person we're recruiting and they've turned out not to have the required skills.
ALI: In some cases guilty of talking a really good game during the interview but they're not necessarily having the skill or the motivation to back it up on the actual job. That's happened to me multiple times. people have said to me 'Ali, you interview really well, we want to give you this offer,' even if I’m like 'I'm not suited for the role,' so from the other side of that table, yeah, it's definitely the case that there are very dependable things you can say or patterns of conversation you can have in an interview that make you sound good verbally but then not have the technical skill to back that up.
STEVE: But on the flipside, I did a few things where I signed a paired coding project where I put together something that I thought was quite straightforward and the couple of people I tried it out on just completely froze in the interview and I was thinking what I was really interested in seeing was their approach to the problem, not the solution, and both people got so focused on the solution, on trying to get the solution right. I was interested in - and I tried to guide them on this as part of it - I see it as my misstep but it was interesting, seeing what their reaction was. I was expecting to see 'Do they approach this by trying to get more requirements about it? How do they use their editor? Are they competent with actually writing the code? Do they know how to look up a library documentation? Are they going to write a test?' those kind of things. That was what I was interested in seeing but they became so focused on the solution, I think, that they just completely froze. So it's hard, I don't know what the right answer is.
ALI: We went with the approach of, rather than just expecting people to know that those are the things we want, to just write those things down and say 'We want you to do this,' to the point where we hired a junior, well I say a junior, it was the first time she'd ever done any programming work for money, and what I was concerned about, because we had hired juniors a couple of times in the past, was that they would come on the job and they wouldn’t know what was expected of them, like what was the expectation for them to behave, and I think when you have a more senior developer you don't have to be as fine grained about it, but somebody who's just starting out, who doesn't really have much confidence, they want to know that they're doing a good job, so what I wanted to do was make it clear that if you follow this list of things to do, then as far as I’m concerned you're doing a good job, more so if I don't have to tell you to do those things. If you just do those things without me telling you to do so, you are doing a good job. And the list was the things you said - it was, firstly, for any task assigned to you, you are going to hound whoever assigned it to you with questions until you fully understand the requirements, then you are going to do a plan for the implementation that you are going to talk through with at least one senior developer, and if you don't have a plan, like if you have no idea where to start, then that planning session is really just you asking somebody for guidance and you sort of running with it, then you're going to implement it, you're going to do it with tests, you're going to do a pill request, you're going to work with any reviews and modifications, you're going to show it to production and then you're going to queue it to make sure it doesn't break the universe. Once we wrote that down on a Wiki page and said 'This is your job,' suddenly junior developers started becoming monstrously productive and it was great, so it worked in two instances so I don't know if it's generally applicable but that process has been quite good for us, for juniors. For seniors, we've just been very lucky in our hires so far so I don’t really know if there's any process we did to make that good. So you mentioned earlier that your day to day role is you do some programing but you do also do some management tasks, like sitting in meetings and, presumably, helping to find a roadmap. Is that transition into management something that you want to do, do you think, or is something that your current role requires of you?
STEVE: No, I don't want to do it at all, but I don't know that that's necessarily a bad thing.
ALI: That you don't want to do it?
STEVE: That's why I sort of classify myself as a reluctant manager.
STEVE: I think I’ve kind of accepted that that's what I’ll do because I find it hard being on the other side of it, not getting involved in those kind of things, because with the business background, with the understanding of that, it's very difficult for me to sit by and not get involved and try to help out on the technical business overlap, where it is.
ALI: I think that's actually a good thing. The part that's a good thing is that you're not a full time manager. The reason I say that is there are various duties you have to do as a manager but I honestly feel that, in my current situation, I’m a manager of basically everyone in the company but I also have 18 other what you might class as individual contributor roles, like all of the marketing, I do that, all of the sales, I do that, all the finance, I do that - I have a million things to do alongside management and I think that's a good thing because management is maybe one, perhaps two days a week of work, it's not a full time job and I think there's a lot of toxicity that comes out of people whose full time job is management for teams of this kind of size not having anything to do and so they just dick around all day with, I don't know, Jira or whatever it is, or new methods of servicing the productivity using some measurement thing, and I think that stuff can all just die in a fire - and it's good that we don't have time to just dick around doing that.
STEVE: Yeah, yeah. It was a conscious decision to say 'I am not going to manage the backlog. I'm going to input into it,' and I still obviously get involved in it but I’m not going to be going and communicating all the time to tell those people. I will have to do that at times but that's not like a part of the regular work, that's why we have the person, a guy here who is more involved in the education side and he actually takes more of that product ornery - I say ornery because it's not like a firm definition but he does a lot of communications with sales, a lot of communication with the CEO and stuff like that - and, yeah, I do see it as a good thing because I don't want to be detached, I would go crazy if I couldn't sit down and do programming for however long it is. At the moment I’m spending a large percentage of my time programming, sometimes it's not so much, but I feel like it wouldn't make me a very good manager - I feel - if I wasn't able to do that.
ALI: So I basically don't know programming at all, like my entire job is going into town and having coffee with people and trying to make sense of the financial reports and making sure clients pay invoices on time and stuff like that. I have no programming whatsoever, and the worry is that I’m going to lose touch with what, at the core face, programming is like, like I’m going to forget what that's like and therefore not be able to relate to the people who work for me anymore, so I am concerned about that a bit. I'm probably going to just do Rust or something in my free time just to keep myself programming, though I’m not sure how valuable that would be in the workplace.
STEVE: I think it's hard. Your position, I think, is difficult because you are the company and so the rules are different. I've got the opportunity to put myself in this position, of being able to say 'I'm going to choose, this is the technical side of it, this is how much management I feel comfortable doing,' so yeah, when you're running everything it is hard. You have delegated that down - when you said the people who work for you are able to be pretty self-contained and manage their own backlog of work.
ALI: For the most part, yeah.
STEVE: For the most part, yeah, that responsibility of technical oversight has been delegated down to them,
ALI: So I’m basically doing everything else that I didn't know was going to be involved when I started this business, yeah. I went to this conference last week called The Lead Dev, which was great. It had some surprisingly good talks at it. It was in London, which was also good. You should have gone; it would have been fun. Anyway, the whole conference was, to an extent, about the transition from a career as a programmer to one in management or leadership in some form or another and a lot of them were, like you mentioned, they're in positions where they still spend a lot of their time programing but then they have 20% or maybe 30% of their time focusing on these management issues and they were talking about how hard it is and how challenging it is and all the things they have to get over and when they were sort of whining about that I said 'You're only transitioning to one other career? I have like eight I’m doing now!' So I didn’t feel much sympathy for them.
STEVE: I'll just make it clear - mine is pure personal preference.
STEVE: I have been there, because when I ran the company I was technical director - well, CTO - of a small company, and the trouble, even if you have a co-founder, if your co-founder isn't technical, you end up having to be involved in everything because you don't have a big enough team to not have to program. In that position I was in, I had to do a large amount of the actual day to day programming as well, but then yeah, you can't get away from having to do sales meetings, because who's going to talk technical in that? You can't get away from doing the accounts, because who's going to make sure everyone gets paid, really? You’ve got to be involved in that. So, yeah, the idea that being in a technical leadership role, it's just a job. It's a job and it's whether or not you're happy to say 'Okay, I’m going to take the step up to be that technical overseer.' I think you can put it off - particularly if you're in a larger organisation. If you're spending your time going around different departments, talking to them about what they're doing, understanding the architecture of what's being built, even if you're not actually programing, specifically, day to day, having that deep technical understanding, especially if you came from a technical background, you don't have to become that person who's just drawing random omnigraphal diagrams that don't make any sense to anyone.
ALI: Oh my God, yeah, it's like PTSD being triggered! I've met people who are in that role and, yeah, wow.
STEVE: I've drawn my fair share of omnigraphal diagrams.
ALI: I'm not referring to my time at Aria. I don't think I saw any omnigraphal diagrams while I was there. Right, we're running short on time a little bit - do you have any picks that you would like to share?
STEVE: A couple of things, really. I was kind of struggling to think about this over the weekend and I don't know if I’m cheating on some things. One thing I wanted to kind of bring up - again, this isn't really a pick actually, this is more of the diversity angle of being in a management position, of being able to influence things for some greater good that you have - so one of the things I quite like about being a reasonably well-spoken white dude in a position of authority.
ALI: Good for you!
STEVE: I've done so well! Is being able to, obviously there's the hiring side of things, just being able to be more aware of making user you're putting feelers out to maybe groups of people that aren't just exactly like you, but also having influence over or being able to comment on things like when things come up in how a product's being built, being able to point out things like 'Did we consider people who can't hear so well or see so well?' or 'Are we being representative in illustrations that we're doing?' Those kind of things, I feel, are one of those things that, when you're in that position of authority, you can kind of speak up on, and those kind of things might not necessarily, it's not necessarily that people would be dismissive of it, but people who otherwise might have mentioned it maybe wouldn't because of where their positon is and the people who are maybe doing the work it just maybe wouldn’t have occurred to, so I guess that's a pick.
ALI: I'm sorry, what I should have said is do you want to lead the progression of the podcast for a little bit so, yeah, you go, let's talk.
STEVE: That's all I was going to say, really. I don't know if you have any thoughts on that side of things.
ALI: That's good to hear. Like you said, it's kind of annoying to be, what's the word I want to say here? The person on the team for whom that diversity issue, who would typically bring it up. It's kind of annoying to have to be that person. That somebody who is perhaps from a better represented background in tech, for them to speak up, yeah, that's a big deal, that's a huge deal and I think people are going to appreciate that.
STEVE: Yeah, and obviously it's a really fine line and you don't want to come off sounding... because you can sound kind of condescending and you might make missteps. I don't know, I kind of feel like it's one of those things that's worth risking sounding like a bit of a...
ALI: You've got to pick your battles, right? You really don't want to bring up whale meat with a Japanese audience, like that's not going to go well at all ever.
STEVE: Yeah. But in actual picks, so I came up with two things. One is very concrete in that there's a book that I love and recommend to everyone which is, I don't know if you've seen this, it's called 'Code: The Hidden Language of Computer Hardware and Software'.
ALI: Okay, yeah.
STEVE: I just love it as a book, and the thing is I haven't actually made it all the way through it yet but it starts off with like basic methods of communication that aren't necessarily written, like using Semaphore and Braille, those kind of things, but then it does a deep dive on basically building a computer from scratch, like how would you get a computer to the point where it can be booting software, so it takes you from logic gates all the way through to how a CPU, how memory works, that kind of thing.
ALI: And is it a book for the general population or is it a programming textbook kind of deal?
STEVE: It's not a programming textbook. I would say that at least a good portion of it is more hardware. It claims to be for the general public; I have found it hard going. I don't have a CS background and I think that if I did I might find it easier to get through it.
ALI: Yeah, I have a CS background - that's not true!
STEVE: Anyway, yeah, it's really well written and it kind of turns on all the lightbulbs for me and just picking up a lot of these things that maybe I didn't pick up because of the lack of formal education on these kind of things but, yeah, I recommend that.
ALI: That’s one.
STEVE: And the other one was history.
ALI: Just all of it? All of history, yeah, okay.
STEVE: To be specific, I would say on the technical front, I like looking back at the kind of things, the kind of challenges that we have now, looking at what people did, say, ten years ago, twenty years ago, for example things like large scale, big technical shifts and looking at the backgrounds of those kind of things, like, you know, say Apple starting with OSX, where they put a line in the sand and said 'Okay, this is what we're going to do, we're going to start building a new operating system,' and looking at understanding the decisions that led up to that, the background of Next, where all those things came from, I find super interesting, from a technical point of view, and it also gives you some perspective on what you might need to do in order to lay the groundwork for your future in the things that you're developing, because a lot of the thinking that we can have is really short term and that can be beneficial when you're trying to just get something out the door but countless times I can see things where people have tied themselves up in knots because they were just trying to rush it out five years ago and how you have something that is completely unmanageable and probably at the time everyone thought 'No, it's fine, we can just ship it and then we'll build another version,' but those kind of things don't always pan out. That's what I mean on the kind of technical history side of things. And on non-technical stuff...
ALI: Do you have any specific media you'd recommend or just Google the history of Apple?
STEVE: Yeah, I was struggling to find, I mean there are various books like 'Fire in the Valley' which is more early, I think sort of '80s to '90s, Apple, but yeah I was struggling to find something, I was trying to think about where I’d got the history from and I think it's probably from various podcasts over the years and listening to different things so it was hard to pick just one thing, but I think 'Fire in the Valley' is pretty good, it shows the creation of the Macintosh, I think it is.
ALI: Okay, and I think you were going to go into something else.
STEVE: Yeah, so on non-technical stuff I’m listening to two podcasts that I just wanted to mention because you told me to pick some picks but I’m listening to a podcast on the history of Japan and a podcast on the history of the Cold War, both of which I am finding super interesting, mainly because I had no idea about any of those things, and both of the people who present it are academics in the field of history, so they often present things and say 'Okay, here's what I’m going to do - I’m going to talk about the events as they run out on the timeline and then I’m going to talk about a couple of different interpretations of what led to those things.'
ALI: Right, okay, so it's not just one-sided political agenda or anything, it's acutely like somebody who's giving you various points of view and telling you that there are various interpretations of what happened.
STEVE: Exactly, and also saying 'I am going to try not to be biased in this,' but you can tell what their opinion is but the fact that they talk to you about, you know, firstly saying 'I'm going to try not to be biased about this but I’m also going to present you a number of different things and you'll have to go and read,' and then give you more reading materials to go and look at later. I think it's a good thing on a lot of fronts, of firstly understanding the history but firstly kind of exercising those critical thinking skills of, you know, don't trust everything you read.
ALI: Which, by the way, wouldn't it be great if we had more of in this country?
STEVE: Particularly now. I don't want to date your podcast or anything but it's particularly interesting for me right now. But at the same time, it's trying to put the kind of things that are happening right now into that historical framework.
ALI: It's kind of terrifying if you do that.
STEVE: It is a little bit because you feel like the sense of being one of those blobs on a timeline.
ALI: Yeah, exactly.
STEVE: It's kind of scary.
ALI: Excellent, well thank you very much for coming on the show and talking to us. I think we've covered a lot of ground in the 40-50 minutes that we've been talking and hopefully everybody listening will find this useful and we will record something like this again soon.
STEVE: Excellent. Thanks for having me.