There are a lot of things to keep in mind when running the heart of your engineering team, whether to build a good buddy system, removing friction from local dev environments, keeping documentation updated, to more external ones such as designing with and for customers. No matter how we deal with unique problems, team leaders are always at the mercy of their engineering philosophies, the ‘whys’ and ‘hows’ of leading the company in achieving their goals successfully, which is always not easy regardless of company size.
Tell Us More About You and Your Role.
I am Anjuan Simmons and I am an engineering coach at Help Scout. Coach is the term we have for managers. Because we have what we call ‘players’ in a coaching model, and we believe that the best managers are people who are hands‑on developers. This is why we try to make sure that we take our experience as individual contributors or IC, and guide others or other IC’s in their careers.
We are helping them understand the work that they're doing, and that how can we as a company help the people who work here meet their goals which may include things that are outside of Help Scout. So while we hire people to help us serve our customers, we also try to have ways for people to meet their goals, whether that helps our customers, Help Scout, or just themselves.
Share A Little More About What Engineering Philosophy Means To You.
Engineering philosophy to me means having a framework on how to create a high‑performing team with a high‑performing impact. And by that, you have a philosophy for the software that you want to build and for the people who you want to help you build that software. It also means that you are thinking about the experiences of the people that you want your developers to work with.
I've worked with engineers, and every day we work on getting some kind of product or product increment out to our customers and put a lot of thought Into how we create that product. But in many ways as a coach, the product that I create is the experience of the engineers that I'm very fortunate to work with and to support.
A lot of my engineering philosophy is around how can I make sure that the team at Help Scout and the engineers who I manage get a great developer experience. The way that we think about our work is structured and adheres to a couple of frameworks. But more than that, it also means that we are thinking about the impact that you want your engineering teams to have on the world, and being able to think about what we want the world to have because we exist in it, and what are some of the benefits that we will leave behind because one day we're all going to probably move on to something else. What things did we make true? What good things did we make true because of the company and what we can do? These are very much the aspects of my engineering philosophy.
You talked about the ideal, real sort of developer experience that you can cultivate for your engineers on your team. What is that developer experience? What do your developers on your team want out of work?
The primary part of the developer experience, something I've heard from my players over and over again, is them wanting to be able to come to work and have a set of things to get done. It sounds simple, but there are often so many roadblocks, so many friction points that keep engineers from doing that. A development environment has aspects of production, so you have to have a lot of the tools and a lot of the systems that we use to run any software. (We've come a long way in making that remix experience or that local different apartment better, but we are still working to make it the way that we wanted to be).
A large part of the developer experience also is reducing those friction points, improving the local dev environment experience, and providing ways for engineers - that when there’s change, they can deploy that change into production. That they can see and share changes with QA or someone from design to gather feedback, re-push it, then do it all again seamlessly.
In your team where you have players and you have are the coach, how do you think about hiring and onboarding those players?
Hiring and onboarding are essential at Help Scout. We tend to have a lengthy hiring process as we believe that no hire is better than a fast hire. That’s why we take our time to fill our roles. It also means that we are intentional in our hiring process. We want that person to be able to stick around for a very long time. I've read that there are roughly 3.5 million software engineers in the United States but finding the one who has the skills and the background can add to the company's culture. And that I believe why hiring and onboarding processes should be unique and made smartly.
How do you think about the terms ‘culture-fit’ and ‘culture-at’ in your teams?
At Help Scout, we don't try to hire for ‘culture fit’ because there are lots of negative connotations to that. Cultures can be often very homogenous in a lot of ways. We do think about value, about what this new person adds to what we're doing. Though we know our culture isn't perfect, we think our culture is very rich, strong, and ever evolving, as a result of always looking for people who can bring in different backgrounds and different experiences to what we do.
There are two people involved in the success of everyone new at Help Scout: A mentor, being someone who has probably done the job that you were just hired to do who can give you those sp called cheat codes, shortcuts, or power-ups to help you get to up‑skilled and productive faster; and second is a work best friend. They may not be someone who knows how to do your job, but there's someone friendly, a phase two, who can be there to help you navigate the company and become integrated into it (since this is most difficult for fully remote globally distributed companies of any size).
Like you said, one day when we transition out of this role, what do we want to leave behind? What do you think about the relationship between a high‑performing team and that mission?
I think high‑performing teams when they have a mission that is beyond just having more revenue, more profitability, or making the company more valuable to the stakeholders, get a sense that the work that we're doing transcends over the lines of code that we're writing. And having a mission that is bigger than the people who work at Help Scout is motivating.
High‑performing teams have that big sense of mission, as trying to achieve something great. One of the north stars of Help Scout is that we want to be the leader of small and mid‑sized businesses. This market in our industry means that we want to be the de facto tool. We have to understand the market better than anyone else, we have to be able to create solutions for that market better than anyone else. And so whenever we're unsure of ourselves or every time we encounter adversity, we can always go back to that mission and have the determination to get past an obstacle because we're trying to accomplish this great thing.
Help Scout is also a very conscious company in terms of our commitment to inclusion and diversity, and also in terms of the kind of impact that we want to have on the world. All of that wraps into having an experience where whenever we're trying to do something hard, by just knowing who we are and more importantly who we want to be, that motivates us to get past those hard experiences. And then we keep going until we get to the successes we want. So if I could summarize it, one benefit of having a high mission is that you develop the grit that you need to get there.
Lastly, If you had a piece of advice to give to engineering managers, perhaps future engineering coaches that want to build better teams, what would you give them?
There are a lot of things I would as it's hard to find one answer, but when it comes to building a team, we're lucky in that there's a great book titled Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, which took years of research into software engineering teams and what makes these teams high‑performing. High‑performing engineering teams work on ideas into production, can deploy those productions, can quickly revert production deployments, and can fix production problems quickly when they do occur.
On top of that, thinking about psychological safety is a more subjective thing to consider, but it's so important. All that psychological safety means is that engineers can do their work without fear. that they won't get yelled at if they make a mistake, that they won't have to worry about punishments, that they can do risky things, things that have never been done before. Having a safe environment for doing that work is important.
The amount of dignity and respect of the manager towards the team is also crucial. When problems happen, try to figure out what went wrong, what can we learn from that? Let's construct a timeline to see how we got there while taking everything as a learning experience. You'll get better results because your folks are more determined to solve it together hand-in-hand than leaving all burden to you as a result of having no psychological safety with what they do. And I believe this is what I want managers to take.
An engineering team’s success is greatly influenced by the leadership of engineering managers. And with the help of engineering coaches, tools, and resources, we are closer to seeing dev teams operate seamlessly with no friction.