Future Leaders: Adam Braimbridge, Senior Engineer
‘Future Leaders’ is a series of blog posts by the Financial Times in which we interview our team members and ask them how they got into technology, what they are working on and what they want to do in the future. Everyone has a different perspective, story and experience to share. This series will feature colleagues working in our Product & Technology teams. You can also connect with us on Twitter at @lifeatFT.
Hi Adam, what is your current role at the FT and what do you spend most of your time doing at work?
My job title is ‘Senior Engineer’. I’m in the ETG (Enabling Technologies Group) and I think of what we do as ‘developer experience’ — user experience for developers. There’s an overlap between making life better for developers and helping to stop FT.com & related apps from grinding to a halt, like how the previous version of FT.com (codenamed “Falcon”) did.
Does that involve a lot of monitoring? Or just when things go wrong you’re called in as the cavalry?
Part of it is the cavalry, or putting out fires, but I think that individual teams already do a fantastic job of that. Being able to help developers do their work easier is really what I’m aiming for. A lot of that is knowledge sharing and good documentation; and even things like “rubber-ducking” (talking out loud to understand a problem) are useful.
I’m trying to be a bit of an advocate for culture … a developer advocate, if you will. For example: One thing I find myself doing sometimes is to sort of play this character. I play a version of Adam that’s a little bit foolish and a tiny bit rebellious — and much more confident than I really am.
A subset of developers of all levels tend to have this thing called “imposter syndrome”, which can prevent them from contributing their ideas or objections. This is a huge waste of valuable brain power.
What I’m doing when I act this role is I’m setting the bar — within reason — to make it more comfortable for all developers to talk openly about whatever they want to talk about. Because no matter what they talk about, it’s not going to be as ridiculous / naive / contentious as whatever Adam just said.
Do you manage anyone right now?
Yes, I’m a line manager for two wonderful people. They make me look so good! Jennifer and Keran, I couldn’t ask for better reports. They came in as junior developers and they’re both mid-level now. We’re already building experience towards senior level. It’s great because I don’t have to push them; they’re driven, smart and so quick to learn. I really enjoy managing, it’s a rewarding challenge.
So, how did you get into the technology industry?
Oh boy, let’s see. When I was about thirteen, my Dad came home with a Commodore 64 and my brother and I played that. You’d power it on — it was plugged into a TV set, which I think was black and white. I remember turning it on and it flickers up and you could write programs in it, very basic ones. And if you wanted to run a game, it would say, “Press play on tape” and you’d literally put an audio tape into this player, hit play and then go do something outside for an hour. And then we’d come back inside and play this cricket game or whatever on the C64. From that early age I was sold. I thought that was the bees knees.
In high school I was doing quite well in computer studies, but in Year 11 they couldn’t find any programming teachers. At that time in Perth, there weren’t many high school teachers who knew how to program. I was told there’d be a programming teacher in Year 12, so I persevered, but when I started Year 12 there was still no teacher. That meant I couldn’t do my university entrance exams, so that really stuffed me around.
I went to the careers guidance counsellor and filled out a form for an apprenticeship. They gave me a booklet and asked me to pick three preferences. I picked computer technician and electrician but I couldn’t find a third one that was even close to programming. Now, the day before I’d watched a movie called “Death in Brunswick” which is about a chef, so I chose “chef” as my third choice. Sure enough I ended up doing a four-year chef apprenticeship, because of that movie. I stuck it through and finished it, then left Perth to travel around Australia for a couple of years as a travelling chef.
Although it was great for travelling, it wasn’t what I wanted. I went home, switched to cheffing part time and did a Diploma of Interactive Multimedia. I wanted a career in movies or games. To my surprise, I discovered a knack for programming. I had thought it was all maths and algorithms, but really it’s just thinking things through and finding the edge cases.
I taught myself a programming language called “Lingo”, which was the language for a popular thing at the time called Macromedia Director. I got good grades, which led to my first part time programming job in a company called “Fun Ed”, making educational games for kids.
After finishing the diploma, programming employment opportunities in Perth were scarce. So I built my own business called “Castledale Virtual Tours”, doing digital photography of houses (and oddly enough, luxury yachts). I developed a process for taking 360-degree photos, and wrote a “Flash” programme to download and view them online. Real estate agents would just give me their username and password for their business websites and I would upload the virtual tours for them.
That was great except I was working by myself, which got very lonely. I could have employed people but I didn’t have the confidence to tell someone else what to do.
One of my clients was called “Bam Creative”. They did websites & digital advertising for businesses in Perth. One time, I had a two-day contract to do some “Actionscript” programming (something of a specialty at the time). I remember this very well … it was my first time working in their office and the Syrian Army (or equivalent) hacked their servers! They were running around like headless chickens. The phone was ringing constantly. No one asked me to, but I just started picked up the phone and answering, “Hello, Bam Creative, Adam speaking. Yes, we’re currently undergoing technical difficulties, let me take your details and we’ll get back to you by the end of the day.” The owner was impressed enough with that to offer to buy my business and give me a fulltime job.
So I worked as a developer for Bam Creative for a number of years. During that time I had a one-year break in Vancouver, when I didn’t program at all. Arriving in Vancouver, I swapped my Macintosh laptop for a Kawasaki 440 LTD motorbike, borrowed a tent, and went off into the British Columbian forests with no plan but to see how far I’d get.
Were you trying to find yourself?
Thinking back on it now …yeah, I was trying to find myself.
Did you find yourself?
A little bit, but not as much as I wanted to. When I came back to Perth I was complaining to one of my friends about it, who was a nurse, and she said, “Adam, you’ve got depression. Classic depression. Go and talk to a doctor about it”.
That was when I was thirty. I went on antidepressants, and they changed my life. By the way, I’m on record at work saying that if anyone wants to talk about depression they can contact me. I’m happy to talk about it with anyone who needs to. I respect confidentiality and I’m good at forgetting stuff, so people feel safe talking to me.
Anyway, in 2010 I left Bam Creative and came to London, wanting to relaunch a career as a UX specialist. I even changed my Twitter handle to @uxtremist. I had three interviews lined up; the third was with a little company called “Assanka”, owned and run by Andrew Betts and Rob Shilston.
I was incredibly lucky to get that job. A few years after I joined Assanka, it became acquired by the FT and changed to “FT Labs”. I wanted an excuse to work from the FT home office, assuming that it was inevitable that we’ll all move across eventually, so I volunteered to join “Code Club”, teaching nearby primary school kids how to code. Because the school was near the head office, I worked from there one day a week.
Eventually I was there full-time, on the FT Blogs / Alphaville team. “Next FT” was less than a year old. One day I saw a big screen with user-data charts on it and was like, “This is amazing, this is awesome, this is what I’m talking about!”. Matt Chadburn (Technical Director of FT’s Internal Products team) walked by and said “Can I help you?” I said “Yeah, this is really interesting! What’s it all about and how does it work?”
Matt responded to my natural curiosity. One thing led to another, which led to a bootcamp with his team in Next FT. On my first day I made a chrome extension called “Mollydobbin”, to help developers add tracking data correctly. I think Matt was mildly impressed with that, because when I asked if I could join the Next FT team full time, I was allowed to. Thanks to Matt Chadburn, Matt Andrews, Rik Still and Michelle Shakes — and many other people — I’ve been very lucky at FT. I owe my success to all the really cool people in the Next FT team.
That’s so nice! What is the project you’ve worked on at the FT which you’re most proud of?
The thing I’m most proud of by far is mentoring students who’re learning how to code. It’s a long story, but I do a thing called “Big Kids’ Code Club”, where I tutor people from all parts of FT, helping them to develop the skills for working with tools, thinking things through, and figuring stuff out. Basically, how to google better. I like doing that, because personally I learn so much when I’m teaching; it makes me feel helpful; and I get great feedback. I even won an FT Culture Award for it! Flattery charges my battery. 😊
A personal project I’m proud of (and which I plug whenever I can) is an internal FT website called houston.ft.com. “If you have a problem, ask Houston.” The site is the result of me trying to make the most useful tool I can. It’s basically a hub, with an overview of everything, helpful search tools, a collection of useful internal links, and a reference to our publishing pipeline.
Now the biggest project I’m proud of is a group of tools that our team informally calls the “Sushi Suite”.
The story goes: When Amy Nicholson (who is so amazing by the way) was at the FT, she was instrumental in helping ETG find a new, better way to work. Amy and Sam Parkinson arranged an out-of-office away day to come up with a long term strategy, instead of just being tactical. Because “tactical is not practical!”
We decided to focus on improving the way we do code migrations. Instead of doing work for all the teams — which isn’t scalable — we would make tools to make it easier for teams to do their own migrations.
We started off thinking about our codebase. We have over three thousand GitHub repositories at the Financial Times. How do we know which ones FT.com is responsible for? You can have a spreadsheet or a list and keep that up to date manually, but no one wants to do that. So we made a tool called “Tako” (which means “octopus” in Japanese — the GitHub mascot is an “octo-cat”). It’s a single source of truth that we can trust to get a list of our repos. We can refine the Tako list using a sophisticated tool called “Ebi”, which means “Prawn”. If you’re a developer it’s worth looking that up.
Once you know which repositories to deal with, how do you automate a code change across them all? The answer used to be, you’d check them all out and then you manually copy and paste your code fixes. It takes a couple of days or even weeks to update everything. So as a team, but championed by Bren Brightwell, we made a tool called “Nori”. Nori wraps our tools into a command-line wizard, and was named because in Japanese, “Nori” is an edible seaweed that’s used for wrapping sushi.
So: We’ve got our list of repositories and we’re making changes to them all, but how do we know that we’re finished? Have all those changes have been rolled out? For that we’re using GitHub projects. You can manipulate GitHub issues and pull requests and stuff like that with a tool called “Asari” (or, “Clam”). It was a team effort of course, but personally the code I’m most proud of writing is in that tool.
That’s that — the Sushi Suite. By the way, a nice side-effect of this project is that I’ve been able to do tech presentations on it, for internal FT audiences, for the “London Web Performance” meet up, and at the Guardian office.
That’s really cool. What’s the biggest lessons you have learned in recent years?
That’s a tricky one. Three TED talks have been utterly transformative for me: Dan Ariely’s “Are we in control of our own decisions?”, Dan Pink’s “The Puzzle of Motivation” and Michael Shermer’s “Why People Believe Weird Things”.
Learning recently about “Glue Work” was an awakening. It’s the “less glamorous — and often less-promotable — work that needs to happen to make a team successful.” It’s pervasive and a worthwhile opportunity for improvement.
Aside from that, there’s been something brewing in my thoughts over the past few years that ties into just about everything. For some time I’ve known that everything comes down to respect and communication. They’re the most important part of being human. Now, on top of that, I’ve learned is that everything is on a sliding scale.
Whenever someone says “Oh, never do this” or “Always do that” or “All things are X” or “All things are Y”, I mentally convert that into a sliding scale where you’ve got nothing on one side and everything on the other. Then I kind of picture where that statement sits on that scale. It’s difficult to explain without concrete examples, but nothing is black and white. I’m very aware that everything’s relative; everything is on a sliding scale. Keen minds spot that “Everything is on a sliding scale” includes the word “everything”, which is a bit hypocritical, but I prefer to call it a paradox. 😁
By the way, this way of thinking sits well with OKRs (Objectives and Key Results), which I’m a volunteer “champion” for. It turns out that Key Results are not “the tasks you’re going to do”. They’re the ways you are going to measure the success of whatever it is you want to achieve (by doing those tasks). In other words, the Key Results are a sliding scale, and the work you do is measured along that scale.
So anyway, sliding scale is part one. Part two is: Almost every problem boils down to “signal vs noise”. What I mean is that communication is super important, and when you have problems with communication, it’s more often than not a problem of too much noise. There’s so much noise to deal with that it’s difficult to get a good signal. So when someone says something to you, because you don’t both share the same brain, the signal can get lost in the noise and you may misinterpret it.
When I’m faced with a problem or challenge I think “Ok, where’s the signal? Where’s the noise?” Because if you don’t acknowledge that up front, you are off on the wrong foot because you’re dealing with a noisy signal. The most important thing (which I’ll tell anyone who will listen to me), the first thing you should always do, is start with the problem. The trick is, if you understand the problem then you can come up with a better solution.
Which reminds me: Coming up with ideas for solutions is really easy, but understanding the fundamental problem is really difficult. As engineers or even as humans, we tend to ‘solutionize’; that is, we jump on the first solution we think of, rather than thinking through the problem and imagining a bunch of different possible solutions. One of my favourite quotes is cited by Steven Pinker: “Problems are inevitable. Problems are solvable. Solutions create new problems.”
Yeah, it’s better to fix something so that there’s not as many problems in the long run. That makes sense and is very philosophical. This leads nicely into the final question: What would you like to do in the future
Good question. I’m planning on staying with the FT and I want to continue improving the developer experience for everyone. I’m specifically interested in helping to bring the FT up to speed in one area: We’re currently lagging behind the rest of the technology industry in terms of remote working. I want to research what the competition is doing and see how we measure up.
I think the hardest part is figuring out how it will all work as a policy. At the moment it’s easier for people to just say “no, we don’t have a policy for working remotely” I would never presume to be responsible for writing an official remote-working policies for FT, but I think I can make it easier to share information and give clarity. I want to make a framework so that different departments in FT can publish compatible remote-working policies. I’m inspired by the recent “Engineering Principles” and “Engineering Checklist” projects.
Again — it comes back to signal vs noise and good communication, and everything’s a sliding scale. Obviously it’s ludicrous to say, “Yes, you can work from absolutely anywhere in the world!” but it’s just as ludicrous to say, “No, you can’t work from anywhere except the UK.” I want to slide the scale to the “good” end. Otherwise we’ll keep missing out on recruiting international talent, and losing our developers when they move to different countries.
The good news is that we already do remote working, for example we work with the teams in Sofia, Bulgaria. But we can’t work just anywhere. What I mean is, take Cyber Security for example. Some places you can’t enter the country without the government requiring to search your device and install software onto it. So there’s no way we should be allowed to take work devices in — and then of course we can’t do any work.
Other examples probably include not being able to work from certain countries for insurance and tax reasons. I don’t know the details, and that’s what I’m trying to find out.
Confession time: I do have an ulterior motive. I want to be a guinea pig and work in New York, even just for a week or so, still in the ETG for the London office. I think that could be something that is not ludicrous, but it’s a little bit … novel. It makes business sense in terms of proving that it can be done. As an experiment to see if it can be done, that would be great. Personally I would like to try living in New York for a while anyway.
Is there anything new you’d like to explore or learn about?
Oh yeah. plenty of things. I’m looking forward to learning a bunch of new stuff in the next project our team’s working on. We’re teaming up with the “Page Kit” team: Maggie Allen and Matt Hinchliffe. Kit means “something that generates” and Page means “web page”. So Page Kit is a project for modernising how we generate our web pages.
Also, there’s this new service called “Netlify” who are pushing this idea called the “Jam Stack”. I’d be rather interested in that. It’s something I’d like to spend a bit of time on to see if we can talk about doing procurement and using it in our stack.
Speaking of exploring, it’s been a while since I went out into the wilderness on a motorbike camping adventure. I wonder … *looks into the distance and strokes beard thoughtfully*
Ever the explorer! Thanks, Adam!
Interviewee: Adam Braimbridge
Interviewer: Georgina Murray
