What does an Engineering Manager do? Q&A with Tillo's Joe Barber

We recently sat down with Joe Barber, Engineering Manager at Tillo to find out what’s involved in his role, how he got here, and much more! 

Joe has been at Tillo since the early days and has really evolved during his time here, as he’s progressed into his role as Engineering Manager. He’s been instrumental in delivering key Tillo features and releases, has over 1,000 tickets to his name, and has onboarded 100s of brands into the platform. And on top of all his accomplishments, you couldn’t meet a nicer guy. 

Read on to hear Joe’s thoughts on management, mentorship and why he likes working at Tillo. 

Thanks for joining me today, Joe. Please, can you start by telling me a bit about your career path? 

Most of my career has been in the programming software development field. I went into it a bit unplanned - I went to university to study architecture, which involved cutting out bits of balsa wood to make models at crazy hours in the morning. But it turned out that I wasn't very good; it was a lot more arty rather than engineering based. And programming wasn't really something I'd done at school, but just being at university with a few people who are doing it, I thought that that would be something equally creative and technical to get into. So I joined that course, and I very quickly enjoyed it. 

I did the degree and then did a placement year. I just enjoyed everything about software development. Especially the fact that you can come up with an idea, and make it happen, and build it if you can first break it down into a series of logical steps. So that was a good fit. Except, it was actually slightly unplanned in terms of what I was initially setting out to do.

And how did you come to work at Tillo? What previous experience did you have before joining?

I suppose before joining Tillo, I’d been working for about 10 years before that. I moved to Brighton to work for Amex for a couple of years, on their mainframe systems, at the same time as I was doing a Master's at Sussex Uni in software engineering. And so that got me interested in working with PHP, which is the language I've pretty much worked in my whole career in various flavours. 

I really enjoyed the whole concept of building data driven websites, where you're pulling in data from various places. For example, I worked on personal projects to pull in feeds of ticket data for gigs, making sure that there was a website people could sign up to and be alerted when their favourite band was in town, that kind of thing. I didn’t make a huge amount of money on it, but I just liked the concept that you could have the idea, and you can make it happen - that’s quite powerful. 

I spent about five years in the travel industry - again, pulling in data from various places such as flights, hotels, companies, and processing them to make package holidays for websites. I worked in elearning before I came to Tillo, making training websites and training portals. So quite a wide range of experience.  

But then, I originally had an interview with Alex, Gareth, and Martyn at Tillo in 2017. And I think the big thing that sold it to me, I remember at the interview being shown this great big diagram of all the connections between the various components - how brands will connect to us, how partners will connect to us. It was basically a big old diagram with boxes and arrows. And that pretty much just sold it to me because my main interest in engineering is making systems talk to each other.

If you can get data pulling through from one place into your bit of software, and you process that, you make that available to other people. That kind of “Eureka moment” when you can make systems talk to each other. That's the most interesting bit of development to me and I quickly saw from that diagram that it's just gonna be all about those connections and about working with APIs to define those. So I joined and I haven't been disappointed at all - the whole company is built around those connections. So that’s pretty much what sold me on Tillo in a nutshell. 

That's really interesting. And what does a typical day in your role as Engineering Manager look like? 

On a typical day, I generally spend the first hour of any morning planning what's going to happen that day - both my own priorities, and what I think the priorities for the team should be. 

We have a daily standup at half nine every day with the team. So that's a chance for everyone to go through what they're working on today, and if there are any blockers at that point. I'd share what I think the priorities would be, we'd have a chat about it, and maybe after that, if anything's come out of that stand up or if anyone's blocked or isn't able to progress on their task, I’ll try and work with them to make sure they can get going on it. 

And then I think pretty much every day's got either an element of defining a new ticket or one that’s not been started yet. But as an engineering manager I’m just working with the various teams to make sure it's ready for someone to pick up, or checking in with engineers about work in progress, how they're getting on with it. And then also, when an engineer has finished the task, they'll raise what’s called a pull request so everyone within the team can review it. But at least a fair bit of almost every day is spent reviewing work that an engineer has completed so we can give it the green light as a team!  

Testing is a very important part of making sure it's fit for purpose So you've always got your testing hat on: 

• Does it do what it's supposed to do? 
• Or does it do what it's supposed to do, but inadvertently break something else that was working? 
• Is it fully complete? 
• Although the code might be done, is it well documented? 
• Do we have everything we need to put it live? 

So the engineering manager role is a kind of combination of those things, depending on where we are in our current sprints (these are the fortnightly blocks of work that we do). If we're at the start of the sprint, we’d generally spend more time making sure that the work is ready to be picked up. And if it's the end of the sprint, we'll be working more with QA and the other engineers to make sure it's going through its testing cycles, and that it's ready to go live.

That makes sense. So how many other members of the team do you manage? 

So I’m directly line managing five engineers, which is all fairly new to me - I went into this role four months ago in September. Each engineer, and in fact everyone in the company, has their PDPs (Personal Development Plans). So we'll be working with those engineers to find out what they're interested in achieving for the next year, in terms of how they want their career to progress. 

And, as well as directly managing them, I’m currently scheduling the workload for the core team - that's nine engineers in total. I work with Greg, our Scrum Master, and the product team to effectively define what people are working on during those fortnightly sprints as well as making sure everyone's got enough work, and that people can get the work done. 

In the engineering manager role you've got a very broad overview of a lot of things. I think that the change from being an engineer to an engineering manager is that you're less focused on one or a few particular things. So it's a bit of a change in mindset; you’re more focused on the big picture. 

What kinds of projects are you responsible for? 

In terms of the kinds of projects we work on, it can really be a range of different things. 

So, we might be developing a new page on our hubs - where brands and partners will log in to view their sales, their relationships, top up their monies, that kind of thing. Or we might be making a page within the hubs for our internal staff to use. We did one fairly recently, around being able to support requests by partners for brands. Some brands will require sign off before they accept the partners. So beforehand, this was just done with a lot of email back and forth, but we've now got one central place in the hubs where that can be managed. And our account managers and customer success team can track the progress of those and set them live.

We might be adding a new feature to our API; we worked on one recently where we made it easier for partners to manage their float money. They’ll have a pot of money for every time they buy a gift card - and they need to make sure that’s topped up otherwise they won't be able to buy gift cards. Although they can do that through the hubs, if we make it available on our API's, and other companies can write software to automatically top up, then it allows them a lot more flexibility in managing their floats. 

We're always adding to and maintaining our API so that our partners who write software to integrate to us, can work more efficiently. And sometimes they'll request certain things from us, and then that will go into our roadmap. And we'll build that out. 

We also have your internal projects to help, say, the finance team or the sales team do things more efficiently. And again, we'll build software tools to help them. And then from a purely technical perspective, we'll need to upgrade our systems to the latest versions of software just to make sure that they are bug free and that they're supported by the wider communities who build these packages. 

What kind of other teams do you interact with, across the business? 

I genuinely feel it's almost everyone, to some extent. The engineering team itself is now quite large; we've got over 20 of us, so although that's split into sub-teams, and different disciplines, most projects involve interaction between them all. We split developers between back-end and front-end developers; back-end being often PHP or Python (the logic side) and the front end will be quite design focused.

There's always interactions between them: we’ll interact with Pete in QA, who's always testing the work and sort of championing it, and with Damir and his team around the DevOps data side of it, just to make sure that what we're doing code-wise will perform well and at scale when it goes live. Day-to-day the different functions within the engineering team are always working together. 

Obviously, we're always working with the product and design team, for any new feature - just making sure that the requirements make sense; they're checking in to see that what we're building is what they wanted, whether it meets those requirements. And then we also work closely with the operations team in a couple of different areas. On the service desk channel, we'll always have two engineers routed on to help the ops team with any support queries they have. Sometimes, there'll be things that a partner or a brand will request that can only be really fixed by a developer. The ops team will also manage the partner and the brand onboarding, and I also work closely with the ops team to prioritise what's going to go into any kind of release.

And then even teams that you'd think maybe wouldn't have too much common ground with the engineering teams such as finance and sales, we’re quite often building and improving the tools in the hubs that they use. So it's always important that we spend time with finance and sales to make sure we understand how they're using the tools and changing them to help them do their jobs better. So I think really, pretty much everyone!

You've now been working at Tillo for over four and a half years; what's the best part of working at Tillo so far?

Yeah it has been quite a while! I joined as a software engineer, progressed to a senior software engineer, and then more recently, to engineering manager. And it's been great to see how much has changed over that time. I think there were about 11 people at Tillo when I joined - and we’re now at over 60 people. 

But I think that although we've grown a lot, the culture has always been good. 

There have always been open and honest discussions - and although there’s a lot of expertise within the company, people are willing to be challenged. They’re not necessarily going into meetings with a strong point of view and sticking to it. There’s always been good, constructive, light discussions and sometimes your viewpoint will change based on what other people say.

So in general, I think we’ve always hired the right people. I’ve consistently enjoyed working with the people we hire, so I think there must be some kind of common quality to that. 

For my career development, and in particular stepping into the engineering manager role, I think I've been really fortunate to have two really strong role models in both Martyn and Michael in the tech team - I’ve worked closely with them from day one. I really don't think I could have asked for any better role models to sort of progress in my career, they've always been available for help. And just by seeing how they interact, how they communicate within the team and externally to clients, I've learnt a lot from them. And I’ve also been given increasingly challenging projects, just to gain experience in doing those kinds of things, and every step of the way they've been there to help me progress. 

Final question for you: what advice would you give to someone that's just starting out in this kind of engineering role? 

From my point of view, it’s about making that transition where it's less about what you're doing individually as an engineer to a manager, where it's more about what you enable the team to do. So that takes a bit of getting used to. It's difficult when you're used to just jumping into the coding and thinking “okay, I can fix this, I can pick that up.” It's not really the best use of your time to do that. It's also not giving the people in your team the ability to pick that up, and gain experience and progress. It’s having the confidence to be able to delegate tasks. 

It’s important to check in and offer support to your team. And when they have questions, it’s not always something I'm going to know the answer to myself, either. So sometimes support will be pointing someone in the right direction and saying, “If I was doing it, I'd maybe ask these people. I'd have a look at that. Or maybe there's two or three different options we can go down. Maybe try that one.” I try to allow people to be confident and let them know that they're not getting things wrong because this is all part of the discovery, whether you're quite a senior experienced developer, or whether it's your first job in development. The answer isn't always clear cut. Sometimes this is very challenging work. 

There’s always a lot of things that you could be working on in this role so it’s just learning how to prioritise your time and where you can be most effective. It’s important to make sure you’re got time to think and plan your day a bit - without that you’d always be quite reactive (although there’s always an unavoidable element of that). I think if you can just take the time to think, and plan, and prioritise things in your head - then even if things do change, you can see where they are in the bigger picture. 

And also, becoming an engineering manager, you need to be conscious that you're becoming a mentor and a first point of contact for a lot of people. So be conscious of what you're signalling, just try to be positive, try to be approachable. Try to keep the motivation levels good in your team, and make time to listen to what people want, and help them progress in their careers. 

You’re trying to head off any problems that there could be in your team to make sure that people are happy with what they're working on, that they’re confident, and that they feel valued. Because ultimately, you want to make sure that you can retain engineers in your team. We're always looking to recruit! 

Tillo is currently hiring for the role of Engineering Manager - please apply if this role sounds like a good fit!