Transcript
Gutierrez: How many of you were at Pat's talk just before this one? A few. I think it's great because we didn't do it together. Actually, our talks align a lot. I'm going to talk through a lot of the principles he talked through, and how we've implemented those ones over the last couple of years at Intercom, London.
Intercom London Experiment
A little bit over two years ago, my manager and VP of Engineering at Intercom, Darragh Curran, and our SVP of product, Paul Adams, decided to start an experiment. At the time, Intercom was a really fast growing SaaS startup. We were close to getting our last round of funding from our series D that resulted in a valuation of the business of over $1 billion. Some of you might have experienced our messenger before, when interacting with a business. It looks like this. Any Intercom users? A few. Our mission is making internet business personal. Our brand promise is that we can help you grow through enabling better relationships with your customers. We believe that you should do that through a messenger first experience. Intercom today, has five offices all over the world. At the time, two years ago, all product development was done from Dublin, where the founders were originally from, and where Darragh and Paul ran the product and engineering organizations.
The experiment was exploring building a new product and engineering team in London. This was a very quickly growing business. They wanted to really take advantage of larger talent pools. Another reason why they chose London is because of the close proximity with Dublin. It was going to be very easy for the existing team to be able to collaborate and set up the team here for success. They seated the team, pretty quickly, with a product manager and a senior engineer from Dublin. Then they hired the rest of the team in London, designer and multiple engineers. That's the first team in London, just formed, helping with the launch of one of our big releases that year, our messenger redesigned from our initial WeWork. A very small office in Shoreditch.
Hiring in London was very successful from the beginning. The close collaboration with the Dublin team was working very well. They decided that that chance had paid off. Paul and Darragh realized that they were into something and decided to commit to building a product and engineering office here in London. They hired engineers, product managers, engineering managers, designers, researchers, analysts. A few months later, we moved to our current office in Old Street. With bigger plans for London, they set out to find product and an engineering lead to grow and co-lead the site. That's where my product partner Jane and I come in the picture.
Background
I joined Intercom almost a year and a half ago and my goal was turning this successful experiment into a culturally aligned, very productive, self-sufficient, and thriving office with a big part to play in achieving Intercom's ambitious growth goals as a business. When I joined Intercom, I had been an engineer for almost 20 years. I had worked at different types of companies, public and private, really big and very small, co-located, very distributed. Some very successful. Some not so successful. For the previous 7 years before I joined, I had held senior leadership positions at very fast growing companies, and had experienced firsthand the challenges of building engineering organizations in that difficult context. I had seen the good and I had seen the ugly, from having to completely dismantle an engineering organization, to being part of a successful IPO, or later on acquisition with FreeAgent.
Progress, Improvement, and Belonging
During my career, I've learned to appreciate three things. One, the sense of progress and achievement that what I do really matters, and that it makes a difference. That's very important to me. The opportunity to learn and always challenge myself. A constant sense of improvement both as an engineer and later on in my career as a manager. Finally, the safety and fun of a healthy environment where I enjoy going to work every day, and where I truly feel that I belong. When those things come together, I feel is pretty magical. I get the best out of my work time.
Shipping Code Is the Company's Heartbeat
Joining Intercom to lead the London team was a great opportunity to put into practice what I had learned over the years, growing high-performing engineering teams, together with some best practices, building product that my peers in Dublin demonstrated. What they were doing felt pretty innovative and really resonated with me, and ultimately attracted me to the role. I wanted to see how we could mix my experience with what they had been doing. It was clear from the moment that I met my manager, my boss, that we shared a common bias for progress. At Intercom we believe that shipping is our company's heartbeat. That shipping brings to life our team, our product, and our customers. That shipping unlocks the feedback loop that confirms and challenges every assumption that we make when we're building software, and makes things actually possible. We ship a lot.
Great Companies Consist of People, Product, and Profit
That doesn't mean that it's just about the technical aspect of shipping code to production. When we talk about shipping at Intercom we talk about the quick evolution of our product. A great product is only possible, we believe, if it's built with a well-functioning group of people with common goals. It's not just about shipping for the sake of shipping. Des Traynor, who is one of our co-founders, and our strategy officers, says that great companies consists of three ingredients: people, product, and profit. If you get the people right, you'll get the product. If you can get the product, you will get, ultimately, the profit. The challenge for the new London team was to continue to grow very quickly. All that that implies is interviews, onboarding, team disruption, changing managers, while keeping that fast cadence of progress that Intercom was used to, and solving critical customer problems. Therefore, contributing to our revenue growth and our revenue commitments for the business. All that while being led by two brand new leaders that were just trying to figure out how everything worked at Intercom.
Where Intercom Is Going
I'm a very goal oriented person. If I've learned one thing over time, is that to achieve something, you really need to know what you are aiming for. Then point everyone you want to get there with you in that direction. To fulfill a goal, you need clarity around the mission that you're on. You can avoid misunderstandings, because if you have misunderstandings, you start wasting a lot of time and everybody is going in a different direction. It's important that you and your team gain a deep understanding of the mission of the business if you want to get anything done. Our mission is making internet business personal. Our brand promise is that we can help you grow through enabling better relationships with your customer. That alone tells us an awful lot about what we should or should not do when building solutions. We should steer clear of anything that might undermine that goal.
Mission, Vision, and Strategy Program
This is how we translate that mission and vision to our day-to-day work. From a clear mission and vision, we create a winning strategy with a time horizon of about two to three years. From that strategy, we identify a number of programs of work that are normally led by a specific leader and that normally involves multiple teams and different organizations that ultimately are going to do the work. Here in London, we drive one of those company-wide strategic programs, one of our top priorities for the next few years. Our teams in collaboration with other parts of the business are then involved in shaping and executing in that program strategy. Product, engineering, analytics, product marketing, biz ops, sales, we all get together to define what the product and the go-to market strategy for that specific body of work is going to be.
A clear strategy allows us very clearly to set priorities, to set focus, and ultimately agree on certain outcomes that we want to see. For example, what revenue we're aiming for, who is the target customer that we want to focus on. What problems are they facing that we ultimately want to solve? What specific problems of all the different problems we could solve, we really want to zoom in and target? We communicate those plans through accessible documentation to everybody in the company. Everything is very easy to find, read, and understand. We also do biweekly company all-hands and we share more specific information that is more relevant to a specific function or group of teams in site or function specific all-hands. The key here is that we are constantly reminding people what it is that we're doing and why we're doing, so that they don't lose track of what they're doing, day-to-day, from the bigger picture.
Things We Value
Before we get into translating that strategy into priorities, to plan, there are a few other critical aspects that we all need to align on. As important as understanding the direction we are going towards is understanding how we should behave during that journey. What values do we think we should demonstrate together? Your values, I believe, fuel your strategy. They really aid you in achieving your mission. If you optimize for a specific value, it should be because you really believe that it will ultimately make you more successful in achieving a specific goal. Values are very powerful, if lived and used by all every day. Disregarding values on the other side is pretty dangerous as well. It really undermines the credibility of the leaders that don't live them or enforce them. You need to be very careful. If you make a lot of noise about your values, you better live by them. They're super powerful, but they really come back fire if you don't use them wisely.
Guiding Principles
We have a great book at Intercom that explains clearly what they are. Everyone goes through a session on onboarding where we talk in detail about those values, when they join. We refer them all the time and look for evidence of alignment, both during our hiring process but also through our performance evaluations. If we really think it matters, we need to follow up on that in everything that involves our people. You also see our values represented in some of our execution guiding principles. Do you use principles in your companies to guide decisions? Principles are not as globally applicable as values. They are a way of encoding success. Normally, it's at a function level, for example. It helps you to repeat the behaviors that led to a positive outcome in the past. It helps you avoid previous behaviors that led to mistakes. It gives us, as a group, a common framework and language to understand how we should approach our work, for example product and engineering, as a wider organization. At Intercom, co-define our experience and lessons learned resulted in our shared principles and processes. As you face different constraints, as you grow as a business and you try to focus on different things, you might need to evolve them so that they fit with the actual strategy that you are shooting for. Values, on the other hand, tend to be a lot more permanent.
R&D Principles
These are our R&D principles. At Intercom, we talk about R&D as product and engineering. It's not a specific research and development function. R&D is the product and engineering organization, and that includes all our engineers, TPMs, product managers, researchers, designers, content designers. You will rarely find at Intercom anybody working in our organization in R&D, start working on something without having very clearly understood and concisely being able to explain the problem that they're solving. We always start with the problem. We think ambitiously, but aim for the smallest coherent solution that provides value. We always try to optimize for shipping as soon as possible. The sooner we ship, the sooner we get feedback, and we understand whether our assumptions were right or not.
We know that when we don't apply these principles, things don't tend to go so well for us. We ended up wasting time and effort on a solution that doesn't really solve a problem that is sometimes real or a priority, or that will necessarily move the needle. Or, we really miss the opportunity to understand a very critical dependency between the work that we're doing and maybe the wider system. Then when it comes to getting that into production, we realize that, actually, we are building a very disjointed user experience. We're building a platform, so it's very important that everything fits nicely together. When we don't think big before we start working on something, we miss that opportunity to identify those problems.
Our Role in Engineering
What is our role in engineering? This sounds a lot business, strategy. What happens? How do we apply those things in engineering? Why do we need 125 engineers across 3 locations, in our case? We built Intercom. I imagine, all your engineering teams in your organizations are responsible for building those products that make your business money. We were discussing the other day internally in one of our all-hands, very explicitly what it is that we're here for. We agreed that we do three things. We support and improve the health of our existing revenue lines, so our existing products. That might be, for example, we are protecting our availability. We address quality issues with our existing products. We might be reducing operating costs, because it's getting a little bit out of hand and it's not cost effective. We might be improving our purchase flow so that we get more customers into using our existing products. Or, we might be mitigating security risks.
We have different teams that focus on all those things. Some teams might be focusing on bringing in new revenue lines for our business by building new products and new functionality that we can sell for an added price. There's another group of people that focus on improving our ability to do the previous two things. This is tied to our principles or wanting to move fast and why we invest in this heavily. We call it protecting our ability to move fast. For us, it's as important as doing the other two things. We might build design systems, continuous deployment tools. Anything that will remove friction from the process of getting the work done, we will invest on. When we do it, we do it with a very clear goal in mind.
Without a clear understanding of those priorities, outcomes, and constraints, it's pretty difficult to execute effectively and efficiently, and make the right trade-offs. When, where, and at what level should we hire somebody? We need to have some indication of what we're trying to do before we make that decision. Or, should we optimize for cutting operational costs by actually optimizing for expansion? It might be a more important initiative than managing costs. If we have to make a decision that actually might be the right one. Should some teams prioritize addressing technical debt? Maybe not. Maybe if the most strategic projects coming out rely on those systems, we might actually need to make that a priority so we can move fast when we start doing work on that. Actually, some time just fixing some bugs that are causing churn are the most impactful. It's more or less everything that you can do to help the business at a given point in time. Without understanding that bigger picture, it's pretty hard to make the right call, for either leaders at the macro level, big initiatives, but also for any single engineer trying to make a trade-off between where they spend their time fixing a bug or trying to address an availability problem, or any other things that they might want to focus on.
Prioritizing Initiatives to Roadmaps
As the inputs and priorities are clearer, and we understand the problems better, we start prioritizing those initiatives to our roadmaps. We do that on a quarterly basis, so every three months. We build roadmaps that last for three months. There are four inputs that go into our roadmap rationale documents. What we use to inform what ultimately will make it to a team's roadmap. We consider any strategic input of where we want to go and see if there's any new products or anything we need to build to move us closer to that strategic goal. We might be focusing on addressing product gaps for either our existing customers or for potential new customers that are not signing up because we don't have those specific features. We might prioritize product health. Maybe we have a product available that is confusing to use, or that is very error prone, has incredible technical debt. We want to make sure that we make it more efficient so that teams don't have to spend as much time taking care of those problems. There might be a specific commercial success metric that we really need to figure out a way to impact and to move that lever. With a very clear understanding of all those four inputs, then teams get together to decide what they think is the right thing to focus on. They do that as a team. That's not the responsibility of the product manager. It is everybody's responsibility in the team to make sure that they have a clear understanding of the inputs, and that they make a case for what they think is the right thing for that team to focus on that will have the most impact in the business at that specific point in time.
We Consider Ourselves Product Engineers
An anti-pattern there will be an engineer coming to me after a product roadmap has been approved, and saying, "We never invest in technical debt, but we have these problems with these systems and we never get to work on that." If you're not working on that, it's because you haven't made a case that that is the right thing to focus on. If it's the right thing to focus on, your team will get behind you and will help you make sure that that gets prioritized. Everybody is equal when it comes to bringing those inputs into that roadmap. We just need to do our homework to make sure that we have a clear case to choose it. We consider ourselves product engineers. Before our engineers start to think about how to solve a problem, they are expected to first seek to identify, define, and understand that problem as per our R&D principle, start with the problem.
Shape the Solution
We have five further engineering specific principles that we use to decide how we go about building specific solutions. The first one is that we never blindly execute on requirements defined by order. We help define those solutions and help efficiently deliver them. That goes back to what I was saying about the roadmaps. Unless we also understand why we're doing the work, we should not start writing any code. That's something that we ask everybody to be very conscious of. That's why we organize ourselves into self-sufficient cross functional teams. We normally have a product manager, a product designer, an engineering manager. Something in between four to six engineers, depending on the team. Sometimes we also have researchers and analysts embedded in a team, if no, at least at the group level.
We work across disciplines and expect everyone to support each other and contribute to the solutions. Teams make commitments as a whole. If we need help with research, because that's what's blocking us from making progress and achieving our goals, an engineer will go and interview some customers with the guidance of our researcher to make sure that we're making the right progress. There's no such thing as this is not my job. Everybody's in it together. It's great for growing our skills. It's really good for us to unblock us, especially when the bottleneck is just one person in the team. The PM, the designer, the researchers tend to be the people that might be holding some of the work back. Engineers can change their heart and go and do a little bit of those things to get us moving forward.
Short-Lived Goals
To promote momentum, we break our roadmaps into various specific and short-lived goals. Through executing specific goals in our six week cycles, we call them our cycle goals. Those roadmaps that we've agreed with, with leadership, turn into outputs, so new features, and eventually outcomes of more revenue, or more activation, or more engagement in a specific part of the work. Then teams measure progress on a daily and weekly basis. They showcase that progress at a company-wide show and tell every Friday. As soon as we've got something that is ready to show, we put it in front of the whole company. Then we do what we need to get it into production. As we close the week, we get together to retrospect and plan the following week based on any of the learnings we've made. We take into account any new constraints and opportunity that we've learned over the week that might impact our plans.
Two-way Mission and Vision
This is a two-way road mission, vision. It just doesn't go all the way down. Mission and vision tend to be pretty static and is set by the exec team. It doesn't tend to change. Everything that we learn in the process goes back up the way so everybody can influence our strategy, our future programs, our goals for next week based on what we've learned. Actually, some of the biggest product releases that we've done recently, our Resolution Bot came from engineers, our ML team thinking out ways to productize some of the work that they were doing. It's actually turned into a great revenue line for us as a business. You always have to leave room. Ideas can come from anywhere in the business and you need to make sure you don't starve those and that you make the most of them.
How We Get Things Done
Knowing what to do, so setting goals every week is not enough. It is through agreed processes and principles that we are able to make those plans a reality, efficiently. If we're always reinventing the wheel, we might actually waste a lot of time. Our processes make sure that we stick to our principles. We've agreed on our principles, now we need processes that help us make sure that we're applying those principles successfully. They're there because of things that we've learned and help us truly operate according to our principles. More importantly, they help us operate autonomously as a team. That doesn't mean that we're operating in a vacuum. It's like we now have enough guardrails that we feel pretty safe to make decisions without having to involve every single leader in the company to tell us that we're going in the right direction, because we know we're sticking to a specific set of objectives and mission and vision. We have ways of doing things that aligns how the whole business understand we should be working on.
We are, at Intercom, very opinionated about our processes. We tend to stick to them. You might think processes might slow you down. We believe it's the opposite. A good process is there to speed you up, to help you avoid mistakes, and to move you through things quickly. If you have processes at your work that are slowing you down, they're not doing their job and you should be revisiting. We optimize for momentum. If there's something that is slowing us down, we surely are going to change it pretty quickly.
Set Up, Solve, and Close Out
Most projects will go through these three phases: the setup, the solve phase, and the close out. Then there's three stages within each phase. These may apply to very little projects, and you can go super quickly through those things, within a day or two. Sometimes you might take in a big project. Those are things that might take a little bit longer. During the setup phase, we make sure, no surprises here, that we really understand the problem. We build that one-page document that we call it the intermission. Everything at Intercom is called inter-something. It's a one-page document that very clearly states what we want to solve, and how we'll know we've been successful at doing that. We then understand the opportunities to solve it and how it impacts the rest of the system by focusing on our concept design. That's like, this little solution, how does it fit in the bigger picture? Do we need to think big here? Is there bigger opportunities that we're missing? Then we work with product marketing on the story. The story is how we're going to talk to our customers about this, once it's ready to ship. We need to make sure that we're building something that aligns with what our marketing team thinks our customers want. Because otherwise, you end up in a position that what we sell is very different from what we've actually built. It's important that we find that alignment from the very beginning.
Then we move into this solve phase. This is when we build the solution that we're trying to do. We agree on the minimum scope that we need to solve the problem. It's not the minimum thing you can do. It's the minimum thing that you are confident will solve that problem. That might be bigger, if it's a complex thing that needs quite a bit of work. You need to make sure you're always solving the problem, you're not partially addressing something. Then we design it, and we build it. We test our assumptions with real customers as soon as possible by putting that code into beta. We'll a lot of times start with Intercom. We use Intercom, so we'll test it ourselves. We have a lot of customers that are happy to test some of those solutions, especially if they've been asking for them, themselves.
Then finally, and more importantly, this is the part of projects that most companies and most places that I've worked at, always forget. We ship, we're done. Let's move into the next thing. Actually, the close out is as important. First, you get to full release. That might mean extra operational readiness. Changes, if you're going to build something that might create a lot of load in your system. Make sure that you can launch at scale. We then make it available to all our customers. We make sure we announce it. There's no point, you've put in something in front of customers, and nobody knows and nobody's going to use it. We work with product marketing to make sure they know about it. After an appropriate period of time, and that really might depend depending on the solution that you're building, we evaluate the impact. We track. Have we achieved the outcomes that we originally set out to do and hit? Have we solved the problems or not? At that point, we might find that we need to iterate further to provide a complete solution. We go back to understanding, what is the problem we're solving now? We go through this process all over again.
Be Technically Conservative
These phases might be done extremely quickly. Sometimes they just take longer for bigger problems. Engineers get involved in all of those phases, but they have a more driving role in the solve phase. Here is where we start introducing all of our other principles. Because we value speed, we stick to technologies that we know well, and that we can confidently operationally support effectively. That's a very deliberate decision that we make in favor of speed. When we hire people, we're very clear. If you are somebody that likes to play with multiple technologies, that might not be the place for you. We will use the right tool for the job. We will move to a new technology if we think it is the right thing. We always try to solve the problems with what we have before we attempt to introduce something new that is going to cost us a lot of time to get to the same level of operational readiness that we have with the technologies that we know well. There are big benefits to this. It really simplifies, dramatically, our systems. It allows us to do things, like our on-call rotation is done by volunteers. It's a paid rotation, and you volunteer. Nobody at Intercom is made to be part of out-of-hours support. You are on call with your team when you are in office hours, but out-of-hour support is volunteer basis. That's because the majority of engineers can very quickly get up to speed with all aspects of the system. We can afford to do that.
Build in Small Steps
As per our company values, we optimize for small and simple incremental improvements that we can control, and can confidently ship without much risk. Sometimes we will do that at the expense of other things like cost. Maybe doing a solution in a different way will be cheaper. Actually, if it's simpler, we might take that course in favor of simplicity, because we believe that our ability to move fast is greater than maybe the cost that we incur.
Build with Positivity and Pride
Finally, but most importantly, we value collaboration and good intent. That is very important for us. Why is it important? We value as a company, growth and improvement. Neither of those things are possible without trust and the opportunity to be vulnerable with others. How does that look like for an engineering team? This principle is critical for us to identify and address problems promptly. From getting quality day-to-day feedback on our code, in a pull request, peer reviews, to having successful incident response or incident reduce. Without that foundational culture of trust and collaboration and growth, it is impossible to do that effectively. If we don't do that effectively, it is going to cost the business a lot of money if we are no good at responding to problems quickly and identify what went wrong. If we get into the blaming game, if people are hiding information from us, we're toast.
Delivering Outputs
There is one more thing that you should really get right. We've talked about having a clear mission and goals to make sure that you are spending your time in the right things. That's very important. We've talked about values, principles, and processes to provide you and your team autonomy, whilst guaranteeing that alignment with what the business is trying to do. If you do the work, if you do all those things, you will for certain deliver some outputs. Hopefully, those outputs will achieve great outcomes for your business. Even if you haven't hit the mark, you will have learned something. Hopefully, you take those learnings and improve from there.
We Celebrate Great People and Great Work
When you do all those things, don't forget to celebrate. That is one of our company values as well. Take a minute to appreciate your own hard work and the hard work of those around you. When was the last time that you shared some unsolicited positive feedback with somebody? Pay special attention to those people that normally get overlooked by that. I encourage you all to be thinking about what went well, not just the business and the hard work that you've put. Celebrate team wins. We celebrate our many launches. This is the launch of Answer Bot, which has now turned into Resolution Bot. This is the launch of our multilingual support help center. We had two huge launches in London in the same day, multilingual help center and a big release for our custom bots. We couldn't decide which one we were going to go for. We did a mixture of celebrating our own nationalities or our robot of choice. This is how people were in the war room as they were making this public to all of our customers. We also celebrate big accomplishment. We also celebrate small, little milestones and accomplishments. It is important to remember those ones as well.
The first time that somebody pushes code to production in London normally is the first, second day that you join. Or, if it's me, it was about a year after I joined, I decided to do a tour with one of the teams. They get this little rocket that symbolizes, you're set up, ready to go. We want to celebrate that milestone. It passes from hand to hand as new people do it for the first time. It reinforces our values of shipping, and that it should be easy. It should not be a big deal. It's great fun to do that with everybody. We celebrate many occasions, the company birthday. You might think that we don't do anything because we're always celebrating. Actually, the more we do, the more we celebrate. Most importantly, we celebrate individuals. We used to have a cake per person, but that got a little bit out of hand. We do now have your zodiac sign cake. They've become super fancy. You want to be in the office on the day that we have our cake.
Making Business Personal
Our business mission is making business personal. We take that mission very seriously, believe me. We apply that internally as well every day by making time for each other and really making our day-to-day very personal. For example, we all have lunch together every single day. This is one of my favorite things of our setup in London. It feels like going back to school because you get your food and you sit in the first seat available. There's no choosing who you sit with. Everybody sits in the next seat that is empty. It really gives us an opportunity to really mix with everybody in the office and to get to know each other. It's been super helpful to build a sense of community in London. We've been growing fast. We've built many teams in a short period of time, which means every time we build a new team, we need to change other teams, because you're not going to build a team just with all brand new people. We're constantly changing the makeup of teams. Actually, having the sense of community and cohesion has really helped us to do that in a non-disruptive way. Because people are just used to being with each other. They don't mind working with different people, if that's the right thing for us to do.
Create an Environment Where People Can Be Themselves
I would really encourage you to do what we do, which is work really hard to create an environment where people can be themselves. We talked about that a little bit with our engineering principles, about positive intent. Fostering collaboration and celebrating differences and uniqueness is key if we want to have a diverse team and an inclusive culture. We can very much see the results in the work that we deliver. This is our special way of celebrating every employee's uniqueness at Intercom.
Intercomic
On our work anniversary, our manager and team members commission what we call an Intercomic. Remember the inter everything. That Intercomic represents our year at Intercom highlighting all the things that made it special and unique to you. This is just about you as an individual. It is probably the most exciting and worrying part of the job of a manager. I always freak out when I have to put one together because you just want to get it right. Everybody really wants to do a fantastic job. You can see the engagement from the team when a new briefing comes up and everybody starts sharing ideas. Some people have notebooks full of notes that they kept through the year of things that they want to highlight in that Intercomic. It really means a lot to us. It acknowledges us personally, our accomplishments, and the fact that people see us for who we are and what we contribute.
Where Is Intercom Today?
If you can get the people right, you'll get the product. If you can get the product right, you'll get the profit. Two years into this London experiment, a year and a half for me, where are we today? This approach, all those things that we've talked about, has really helped us to build what I truly believe is a very successful culture and team in a very short period of time. Believe me when I say that we have played a key part in delivering our revenue goals for the business this past financial year. We had strong commitments that were tied directly to the work that we were doing in London. We smashed those goals. We are now supporting, as well, core systems. Our inbox is now managed from London. We are creating new revenue opportunities through new products that we are building from London from scratch. We are also deeply contributing to the future strategy of the business like any of the other more established parts of the group. We're leading one of those main program initiatives.
If you take a look at Intercom product updates, we've maintained an incredible shipping cadence through the year. We've been part of multiple big product launches. Some of them require a lot of coordination with our offices in Dublin and San Francisco. We've also continued to iterate and deliver incremental product improvements to all of our existing solutions that we lead from London. Pretty much every single week, there's a new product update from one of the products that we lead in London.
Growing Teams with High Engagement
This is only possible through a highly engaged team that continues to get better every day, and that can move really fast. We're growing in numbers. We are over 50 now in London. As we grow, we continue to improve our diversity as well. We're not just growing in numbers. This journey has resulted in great career growth and progression opportunities for a lot of people in all of those teams. It has been two years of constant change. New teams, new managers, new problems to solve, new ways of working. We've been able to weather all those changes together, and kept an incredibly high level of engagement. We've done so through a strong support of our managers. We have great managers. A clear leadership, collaboration, and alignment with the goals of the business. Most importantly, we've really been acting promptly in what breaks. That result on action is super critical, because if people don't see that you are actually fixing those things that are going wrong and that you are not moving and taking into account what they need to be, then everything goes downhill. A lot of us in London have our own Intercomics. This is just a small example. Some folks actually have their second Intercomic, in the last few weeks. This is mine. This is my first one.
Questions and Answers
Participant 1: You mentioned that engineers take a really strong responsibility for looking at what the team should do in the roadmap, and for advocating for paying down technical debt. How do engineers who are new to Intercom, or maybe even new in their careers, learn to be effective within Intercom in doing that advocacy, so that you can, not only get alignment, but get alignment that comes from articulate signals coming up from above?
Gutierrez: For us, it's through learning by example. I'm a big believer that if you see those behaviors you quickly get, seeing with our way of working and talking. That's why inclusivity is super important as well. For us, we have engineers at all levels in each team. It's very important that regardless of your level, you also have a seat at the table and that you are able to provide ideas and answers. Actually, a lot of times what happens is more junior people will ask the question that is in everybody's mind, but nobody is willing to ask. They're just being curious. They want to understand better. Actually, it's by seeing what others do, and by feeling safe that you can actually ask questions and contribute regardless of your level of expertise. I think that's something that we really are very explicit about, and that we encourage. The best way to learn is by seeing other people and being a role model of those behaviors.
Participant 2: I just wonder, when you're hiring, particularly engineers, do you look for particular traits, or skills, or capabilities beyond just pure technical skill? If so, what things do you look for?
Gutierrez: Actually, from a technical point of view, we don't mind if people haven't used our technologies as long as they demonstrate an ability to think critically and to evolve solutions successfully. We are ok with that. We believe that you can learn those technologies. The part that is a little bit trickier is if you don't align with our principles and values. Actually, one of our stronger signal interviews is what we call culture add, is, are those people going to be able to operate in the way that we want to operate? Do they have a way to express how they've demonstrated those traits in the past? That that's the natural inclination. We put a lot of focus on interviewing for our values and for our principles.
The typical one is the fact that we don't use a lot of technologies, that we are conservative in our technologies choices. That's something you want to have a clear signal, if people are going to be ok with. Because the last thing you want is people coming in and being frustrated because they don't get to do the things that they really want to do. If they want to play with a very different technology that we don't use, Intercom is not the place for you. We should have that clarity from the very beginning. That's one of the reasons why we actually publish a lot of the things of how we work. You can go to our blog and see a lot of the things that I've been talking about, because we want to put it out there. We want the people that come to work with us to know what they're getting into, and that they self-select themselves into their way of working.
The engineering culture you build will be a direct result of the clarity you put into all aspects of the work. Be very intentional about what you focus on.
See more presentations with transcripts
