Having been an engineering manager myself for a few years now, I’m fascinated with the topic and becoming the best EM I can possibly be. So, following a tip from my previous guest, I jumped at the opportunity to chat with James Stanier. After all, he’s not only the driving force behind theengineeringmanager.com, he also recently wrote what will certainly become a classic book on engineering management, Become an Effective Software Engineering Manager. When he’s not busy writing great content (or maybe it’s the other way around), James is an SVP Engineering at Brandwatch, currently leading and supporting multiple managers and their respective teams.
We look at the usual aspects of team building and product development, but I also particularly enjoyed hearing James’ views on broader topics, such as how we can manage our own psychology at work or how the deluge of online content these days is both a blessing and a curse.
Without further ado, please enjoy this wide-ranging conversation with James Stanier.
James, it says on your LinkedIn, “I like seeing new ideas popping into existence, then poking and prodding them until they're good enough to become great software that our users love.” This sounds like a good jumping off point for the first question. In your organization, how do you decide what to build?
About two years ago we acquired our biggest competitor, so we spent a lot of time less on delivering lots of new value and more on trying to integrate the two products (side note: we did it successfully!). But then a bit less than a year ago we wanted to also get away from the whole feature factory thing, which we felt we were defaulting to as we got bigger. It was just becoming too hard and uncomfortable to do things the old way.
So we’ve been trying to have company level outcomes which then trickle down to R&D outcomes. And within those, we then have squads working on them. For example, for a desired outcome of improving net revenue retention, we then trickle that down to various pain points in workflows in the UI that are annoying users, or maybe hindering the speed they get insights from the platform. What this means is that squads can be much more autonomous in how they do their work, as we pretty much delegate to the PMs on those squads to work on the day-to-day with the engineers towards those objectives.
The challenge is that you’ve built an org chart around some kind of inherent feeling of top-down control. But with this you kind of invert control, which is good for the teams, making their work more autonomous and enjoyable. What we’re working on now is trying to make sure that the reporting of all the work is visible to the rest of the company, within a general bi-weekly cadence.
Speaking of visibility, how do you enable it? How do you proactively surface what’s getting done, and uncover roadblocks and issues?
That company-wide visibility I was just talking about is in a better shape now. That wasn’t always the case. There’s a recorded R&D update that goes out to the whole company, where we have every squad contribute a slide as to what they’re working on and have links off to demos and any relevant documentation. Our CTO, Chief Design Officer and Chief Product Officer take turns in doing the narration and recording of that video. And then we also have Slack channels where, when that goes out, anyone in the company can come in and ask questions, give feedback and so on.
One thing that’s been a challenge is that being outcomes-based means we’re less focused on deadlines than we used to be. So we’re in the middle of a cultural shift for the company where it used to be like “what are you building and when is it done?” to more of a “Look, trust us, stuff is coming out every 2 weeks” mindset.
As for me, I work with my direct reports in helping them surface anything that’s important. We have some delivery managers in the org as well and we do health checks with the teams, on where things are going -- any blockers or problems that come down the road, any resourcing problems. So it’s kind of a combination of top down (the reporting cadence) and the bottom up surfacing of issues. And I’m sort of in between trying to make it all work.
You lead a sizeable team of teams, over a dozen in number. How do you maintain some sort of coherence and alignment, and avoid wasting time reinventing different wheels?
Yeah, that’s a good question. We’re still trying to figure things out as we go but one thing is we formed guilds around various different areas. An example at the moment is that we have some parts of the UI that are really modern and some that are fairly old. So in the background there’s this modernization effort happening whilst still contributing new features. The guilds act as a sort of “sync group” -- the various ICs or lead managers in those areas meet on a regular cadence, talk about what they’re working on, and raise issues to each other.
In the end it’s really about just connecting people all the time. And I feel a lot of the job is just like “hey, you need to talk to this person” or “we should talk about this once a week, let’s put that in.” It’s a lot of broadcasting information around.
The Engineering Manager role, much like the Product Manager, is ambiguous, hard to define, and varies wildly from company to company. In your experience, how should organizations think about and define the role?
Usually, in the early days, you start off and you just have the CTO and a whole bunch of engineers. But I think as you get bigger, there are various other forcing functions that make it attractive to have that role. It's less about wanting to control people or tell them what to do… I believe that's just a side effect. It’s more about the need to think about everyone's career development, everyone's growth, put people in the right roles and then step back out of the way. And the sooner you're able to really think about your individual contributor track alongside your management track, the sooner you’ll open up doors for people. It’s also a framework in which you can think about performance, compensation and just help people get an idea of where they can and want to grow.
I would also treat those tracks differently because often ICs who reluctantly become managers, once they get people reporting to them, they don't enjoy it and the people that report to them don't enjoy it either. So being able to really identify it as a separate role is key. You could still contribute code, for example, but you have an actual role and responsibility for people's development and for their success. And I think the sooner you accept that, the better it is for everyone
Speaking of people development, I personally believe that one of the biggest levers of success is fostering a practical culture of continuous improvement. What are your thoughts on how to bring that about?
When I first started learning the ropes, I read High Output Management, Andy Grove’s book, which is just so good. And there’s this equation in it that I always go back to which reads “the output of a manager is the output of their team plus the output of the organization they influence”. And that is always in my brain. It makes you question how you are spending your time and ask yourself whether what you’re doing is making the team better. But also, whether you’re working with other people and collaborating with them in order to make everything else more efficient and impactful. So if you’re not doing either one of those two things you should probably re-examine how you spend your time.
The same way engineers are always looking for ways to reuse code, to abstract things away so others can build on top of it, I think the same totally applies for organizations. You can identify two teams tackling almost the same problem and get them to collaborate on building a common framework that works for both. That’s the sort of thing that can save you six months in the future. So, for an engineering manager, it’s good to look at your team and what needs to be done, but having really good connections with your peers and the rest of the org is just as important.
We have been talking about managing others. Let’s shift to how we manage ourselves. In what must certainly be a high-pressure environment at times, how do you manage yourself, and how has your capacity to do so change or evolve over time?
I think you eventually realize what your flaws are, and get the opportunity to think about how to use them in a positive and motivational way. For example, I know I’m really bad at multitasking, I can’t do multiple things at once. I’m just awful at that. So I learned over time that I really need to invest time in structuring my day, making sure I block out my week so that I actually progress things. Otherwise I’ll just feel really frustrated.
One other thing that comes to mind is that I feel like I am now being myself in my job. In a way, the distance between the role and me is very small. Whereas in the beginning, when I first started as an engineering manager, I felt that was almost like a role I had to play, which created a big distance between me and the job. And that distance caused tension and stress because you are being someone that isn’t actually you. “Oh yeah, I have to be like this manager persona. And really be in control.” I think with time I realized I should just be myself. After all, you wouldn’t have a job in the first place if you weren’t capable. So you don’t need to pretend to be anybody you’re not. You can goof around and have fun as well as contributing. There’s no need to be super serious all the time.
That’s a great point. I recently realized something that, on the surface, goes in the opposite direction but aiming at peace of mind just the same: detaching yourself from the job, so as to not confuse your identity with the job itself, while still caring deeply about the people around you and the success of what you do.
Yeah, you’re right. That reminds me a lot of the Stoic philosophy and how there’s things you just can’t control and attempting to do so is just wasted effort. It makes you feel bad. There is this sort of summary book on Stoicism by an author called William B. Irvine, A Guide to the Good Life, where he gives some good examples. Say, a tennis player can only do their best, right? You can get injured, someone else may just play better, but you can’t do anything about that. You can only control what you do.
I think it’s similar for engineering managers, or even just work in general. You can’t control your customers, you can’t control the market, you can’t control the economy, as we’ve particularly seen this year. So all you can really do is set goals that are internal about how you perform, and simply do your best.
Coach John Wooden famously said that “success is being at your best when your best is needed.” It served him well, as the ruthless focus on the things he and his team could control (practice, rest, nutrition) gave him 10 college basketball championships in 12 years. There's also this book called The Courage To Be Disliked and the concept of “my tasks” and “someone else’s tasks”. For example, if I’m giving feedback to someone, I can control what I say it, how timely and actionable it is, how kindly I give it, and so on. That’s my task. But how it’s received and what is done with it, it’s the other person’s task. I can’t control any of that, therefore I shouldn’t fret or worry about it.
It’s all, like, the fundamental truths of being human, connecting us together, right?
Absolutely. It’s funny this conversation started with how we decide what to build and how to align teams and such. And now here we are talking about these things.
Because it’s the important stuff, isn’t it?
It sure is. One last question, James. You having written a book, I’m particularly keen to know what book or books do you recommend most to others.
I’m actually less of an avid reader than I used to be. I found that when I started writing, bringing too many other people into my headspace “polluted” my output somewhat. I guess it’s like when musicians are recording an album they kind of stop listening to other people’s stuff for a while.
Anyway, High Output Management I still think is fantastic not just because of the content, but also how Andy Grove was effectively an ex-engineer CEO. It’s really interesting to see all that content from an engineer’s brain applied to something at that scale. I also really enjoyed Never Split The Difference, the book by Chris Voss about negotiation. And we already talked about A Guide To The Good Life earlier.
Outside of the business sphere, I really enjoyed reading Jon Kabat-Zinn, who’s a mindfulness professor and has written loads of books. I’m not someone who meditates but I run every day and that’s my meditation. I just really enjoy that perspective on things. Because -- and I don’t know what you think -- but unfortunately I find that a lot of the “industry stuff” these days in terms of what people are broadcasting on Twitter and LinkedIn, while some of it is important, it’s all just so overwhelming. It’s not very human and it’s sometimes too “hustle-y”. So I really just started to sort of turn off from it in some way. The technical stuff is still great, like a tech conference, for example. But outside of it, it’s a bit too much of people advertising themselves rather than the content, and it gets harder to connect.
If you enjoyed this content, you will probably enjoy The Weekly Hagakure, a weekly newsletter to help tech leaders build better teams and more humane workplaces.
You can also find me on Twitter @prla. Join the conversation!