Sam Phillips

Hello! What's your background and what do you do?

Today I'm CTO and Co-Founder at Residently, the startup that's helping renters unlock the freedom of renting: we want to become the world's home brand. I was a renter for 15 years and it amazed me that for the thing you spend the most on, there's a dreadful, analogue experience. Everybody knows it simply should be better – so we're trying to make that happen.

I've had a number of roles, mainly at startups and scaleups, but also at large companies. I've been lucky enough to be part of two big successes.

My first role after university was at an agency who had won a contract to build a travel website - this is 2005, so it was innovative at the time. I started the project from basically scratch, and it became On The Beach travel. From the outset, it was a huge success. I launched it at lunchtime on a Friday and took the afternoon off to submit my MA thesis... and immediately it took big bookings. I was still new to professional development work but had to quickly learn about scaling and building as our hardware and software quickly crumbled under the load. This was an amazing learning experience and before long I was the sole developer on a company valued at around $70m, which was a hell of a learning curve. I left in 2010; they IPO'd in 2015.

A while later, I took at role as Head of DevOps (later Head of Engineering) at Shutl, the original same day delivery company. I was interested in logistics and e-commerce, so it was a great fit. I had great fun building an amazing team, replatforming, launching in the US and integrating with eBay. The week after we integrated with eBay, they acquired us, and I worked for 2.5 years as a senior manager within eBay Local and Shipping.

I'm a self-taught coder, having started like lots of us looking at source code on websites and figuring out how to do it myself, on GeoCities, FrontPage etc. I started at 13 so at this point I've been coding for 25 years, always on web stuff.

I studied History (particularly Victorian mental health / psychiatry / suicide) at university, but coded the whole time on personal projects. I'm dreadful with numbers and maths so a technical degree was out of the question for me, but analytical, research, comprehension and writing skills that come from a history degree have turned out to be very useful!

How was your transition from software development to management like?

I worked as an individual contributor (IC) for about 2 years before adding leadership and people management work to my role. It's important to distinguish between management (by which I mean people management) and leadership... leadership is about building, setting the tone and making change happen, whereas people management specifically means to be a line manager of people, providing them with the coaching, feedback and mentorship that helps them grow.

Two years is a really short amount of time to have been an IC, but I was working at a fast-growing agency and we were in dire need of structure and process - I became a leader and manager basically by accident; the job needed doing and I thought I was best placed to step up. My first role as a leader was on the product management side - working out how to better structure our backlogs, daily meetings and scope, so that we could much better deliver for our clients.

My role later evolved to include more senior leadership aspects, as well as people manager, as I got to director level within that agency.

Remember: IC vs manager is not a one-way street: in later roles I worked as an agile coach, a principal engineer, a product manager and a business analyst, all with leadership responsibilities but no people management.

I learned management in a more formal way than I learned coding - I think this is important. I went on training courses (including Scrum Master training!), read lots of books and sought out mentors. Of course, I was learning on the job too, and made loads of mistakes, but the formal and structured part of the transition was very important, and something I always encourage others to do.

There are lots of courses available - and they don't need to be specific to a technical job. In fact, it's interesting to look for courses where you'll learn alongside folks from very different industries and job types. I started with basic introductions to team coaching, people management, performance management etc, provided by a local training provider.

Today, there are loads of great online resources available. Recently I've enjoyed LeadDev Together conference series, of which two of the standout speakers have their own courses: Lara Hogan's Complete Demystifying Management Program and Pat Kua's Tech Lead Academy. Pat's newsletter is great, too.

My most recommended books for those interested in engineering management and leadership are Camille Fournier's The Manager's Path, Rands' Managing Humans (there is also a great Rands Slack now), Julie Zhuo's The Making of a Manager and the Lister/DeMarco classic: Peopleware. I've given away so many copies of Peopleware over the years!

I moved to senior leadership after about 5 years in management, working at board level. Again, this was a mindful transition done with study, on-the-job training and mentoring.

What does your day-to-day work look like, and what motivates you to do it every day?

My day-to-day work is a mix of planning and meeting with team members. I do a weekly or fortnightly 45 minute 1:1 session with all of my direct reports, skip-level 1:1s with other team members (these are every 6-8 weeks), as well as catchups with peers and senior leaders. I'm also involved in various update meetings, plus I run my own staff meeting with my senior team members.

Our staff meeting is a critical part of how we work, run as a collective responsibility session. That means we are open and honest in that session about what's good and bad, but present a collective front to the rest of the team about decisions made. That's how we stay united as a leadership crew.

So, it's a lot of conversations... and it can be exhausting, especially remotely, but I believe it's critical to understanding what's going on, coaching and mentoring. My intention in the future, as we move to a more distributed model, is to do as much work as possible asynchronously and not in-person, but for these conversations I think that video/in-person really does make the difference. My evolving belief on distributed/remote working is that it'll be important to use the right communication style for the job at hand - many meetings could be emails, but 1:1 sessions I think will always need to be synchronous.

Outside of chats, I spend a good deal of time planning – looking ahead at roadmap, strategy, tactics for the weeks and months ahead, and working out what we need to do with our team structure as we grow. I try to take at least half a day a week on this.

I very seldom code. I love to code and am a builder, but I know that I can add maximum value by letting others do technical work - I ask questions on plans to probe them for robustness, and coach folks on how to come up with tactical approaches. My motivation is to get the best possible result for the end customer (at Residently, that's the resident), and I can do this best by staying out of the coding. Put bluntly, I simply don't have the large blocks of time to dedicate to coding, so I'm a rubbish pair and can't pick up anything that's critical. I do pick up a few small jobs here and there, just to keep my hand in.

If and when you should give up coding is definitely context-dependent: for me the tipping point was when I felt I could be more useful by letting others do it and spending my time on making sure my team was supported, unblocked, had a backlog ready and we were hiring at the right pace. Trying to mix the combination of coding and hiring is particularly difficult! Bottom line: you may be doing your team a disservice if you are spending the majority of your time doing the work that they too can do, rather than the things only you can do.

What are the biggest challenges you've faced so far? What did you do to overcome them?

For sure the challenge of management is achieving with and through others. You build the machine that builds the machine, rather than building your own product or your own capabilities. But this isn't a downside: it's the way that management differs from being an individual contributor... it's the essence of the work.

Some folks who are new to management, or are looking to their manager to "fix problems", find the pace of change frustrating. If you're used to a red/green/recycle cadence and working with computers, working with people is very different - and you can't treat a person like a computer! Working with people to develop them, coach them and help them grow is much slower. It's much more rewarding, but the work isn't so binary: it's never done, it's never finished. It's about tiny increments, small questions and gentle suggestions. It takes time.

What has been the biggest surprise so far? Something you didn't expect?

One thing that I'm frequently surprised by is how little training new managers are often given in organisations - this could be formal training, informal coaching or just general guidance on how to work. I love to help people move into people management, but I take the work incredibly seriously: blending formal learning with reading and a gradual introduction to the role.

Still though, a lot of technical people are managed by people who don't understand management as a profession, a skill to be learned and honed over time. I think leadership and management are roles that have enormous potential to do a lot of good in the world - to create the inclusive, productive environments we need to build great products - and so it's worth doing well.

What's the best advice you've received about being a manager?

That almost everybody wants feedback, even if it's very direct and not the best news. If somebody has a personal hygiene problem, they are desperate for you to tell them, however embarrassing it may feel. If somebody is underperforming badly, then often they know it - but you recognising it, getting it out in the open and talking about what we're going to do about it is often a huge, huge sense of relief for them. An underperformer who has the stress of believing they have to hide their issues is under a lot of strain - and it compounds the problem.

For sure there are better and worse ways of delivering feedback, and I've done my fair share of very poor delivery - but it's almost always better to give the feedback than not.

The other great piece of advice I try to remember is that I never know what I've said until I hear the reply. Communication is not about intent and what you think you said is irrelevant; it's about what the other side heard and understood. So, it's critical to ask for feedback and responses... and most of all to listen.

What do you tell developers who are considering making the switch or new to the role?

For sure I say to give it a shot! It's not a one-way street and it's possible to try the roles out for size before committing. For example, it's possible to be a leader without having an official title: it's often possible to suggest a change to the way your team works, gather consensus and drive the plan forward. Now you're thinking beyond just your own code and your own deliverables: you're thinking about the whole team.

When it comes to people management, it's also possible to try this out: ask for feedback from a peer, or offer some feedback yourself - the feedback you'd usually give via a manager. This gives you a taste of the work of people management.

It's also possible to go "back" to being an IC - as many people do throughout their careers as roles change. You're not going to forget your technical kills overnight and being a manager, even temporarily, gives you a great insight into what your manager needs from you - so it makes you a better team member.

Final call to action! Where can we go to learn more about you?

I love to help others learn about leadership and management! I tweet at https://twitter.com/samsworldofno and you can sign up for my fortnightly letter on product, teams, engineering and leadership at https://samsworldofno.com.