Product Management Confabulation
What Product Managers are talking about.
Have you ever wondered why your Agile practice feels a bit uninspiring? Or why your engineers have become a bit jaded with all this Scrum stuff? Did you know that you might be the reason for this? Something that both fascinates and frustrates me is how the discussions about Agile have flipped from being embraced [...]
The post Why we Need to Rethink Product Management in an Agile Practice appeared first on Mind the Product.
To move quickly towards a mission, the core attributes of product teams –strategy, design and engineering – need to be well aligned.
But how do you achieve that alignment and what happens when you don’t? I gave a talk at Building Intercom on alignment as a key quality of a great product team. You can watch the video above or read on for a lightly edited transcript.
Startups, they’re a bit crazy, right? What really drew me towards startups as a place to work was just how intense and exciting they can be.
They’re exciting to me, because when your company is as small as a startup, the scope of ownership that you have and the scale of your responsibility is going to be so much larger than they would be elsewhere. Individually then, the impact that you can have towards the success of your company can be huge.
What makes it intense though, is that your time is short. That time that you have to build a really great product that’s either compelling to consumers or investors is really limited. If you don’t manage to build a great product in that time, it’s game over for you and your company.
Early on, you have to be able to move with so much momentum, just to have a shot at success. It can absolutely feel like you’re just figuring out where the track should go as you’re hurtling down it. Especially in this startup world where individuals can have so much impact, one of the things that you need to get right is ensuring that you have good alignment.
Now, half of you are probably thinking right now, “Alignment, what a buzzword,” and sometimes I’d agree, but what do I really mean by it? To me, it simply means knowing what is it that’s important in what we’re building. What does it mean to be building the right product for our customers?
“There are three core pillars that good product is built upon: engineering, design and strategy”
I’ve been an engineer at Intercom for about three and a half years now. To put a little color on how we’ve changed over that time, when I started at Intercom, it was this itty bitty startup, and now we’re a company that puts on engineering events at Vicar Street.
We’ve obviously grown a lot, and we’ve changed a lot. But, over that time and throughout all that change, I’ve thought a lot about the great product teams that I’ve worked with and the consistent qualities that they have. To me, alignment is one of those qualities, and I want to give my take on how that works.
When I think about product, I think that there are three core pillars that it’s built upon: engineering, design and strategy. I think of these as the dimensions of products. A really great product will be strong in each dimension. It’ll have a smart strategy, it’ll be well built and it’ll be easy to use and understand.
To give a concrete example of that, I think the original iPhone is a really good product that was strong in each dimension. It was well built. You couldn’t just put in a blank password and log in. It was so easy to use that my grandmother could use it. Apple really nailed the strategy at the time.
While their competitors were focusing on making things like business email in your pocket easier, Apple came along and put a platform in your pocket and just let you do what you wanted. Maybe had this not happened, Gavin Joyce’s demo would have been us sinking polyphonic ringtones in our Blackberries. But, it covered the entire spectrum, every dimension of product.
At Intercom, we structure our product teams to try and capture each of these dimensions, too. Typically, a product manager will take on team strategy, a designer will take on UX and ensuring that the whole system fits together and engineers will build, run and maintain our systems. But, we all work together in unison to try and make this product.
It’s interesting to think of product in this way, as something that exists in this space, something that isn’t just one dimensional, that appears as an icon on an app store or as a website in your browser. But, maybe what’s more interesting to think about is how do you actually get a team that’s capable of building a product that’s strong on each front. Because, for every original iPhone team, there have been thousands of teams that have just crashed and burned along the way.
Well, maybe a good place to start is with you, the individual on a team, and the skill sets that you bring to your team. As an engineer, you’re naturally going to be more focused on those engineering problems such as making sure it’s scalable, making sure your product is fast and making sure it’s well tested. But, you’re not completely one dimensional. Regardless of what your core discipline is, you’re still going to have some knowledge of the workings of the other dimensions.
Does anyone remember Top Trumps, that amazing game you used to play as a kid? It’s kind of like that. You’ve a range of skills. You’re not just one dimensional. Top Trumps would have been terrible if it was just a single number on a card.
Thinking of individuals in this way and the skills that they bring to the teams kind of opened up this chain of thought in my mind, that teams are like vectors. I can look around, and some of you are probably having Vietnam-style flashbacks to your Leaving Cert maths classes where you didn’t really understand what a vector was. But, I was bad at maths too, so I’m going to walk you through what it is.
“Each individual on a team has influence and bias”
A vector is simply a quantity that has a magnitude and a direction that it moves in. But, the interesting thing about them is, if you have multiple vectors and you combine them together, the overall output of that function is the individual magnitudes, the individual directions of each vector put together.
That’s interesting, because I think that maps really well to teams. Specifically, I think it maps really well to the different functions of teams coming together to try and build a product. Just like a vector has magnitude and direction, I think that each individual on a team has influence and bias.
What do I mean by that? Well, influence is just the pull someone has over another person. It’s a common property of any human relationship, really. It’s that person’s ability to really push for change in a group of people.
Why is this an interesting one, though? People hear that word and they think, “Bias. Who’s biased? I’m not biased.” We are all biased. But, I don’t mean it in a negative way.
In a sense of building products, your bias is just that area that you’ll naturally give more focus because of the skill sets that you have. Again, as an engineer, I’m obviously going to be more focused on a scaling problem than some UX problem that my designer’s looking at, regardless of the overall priority and impact that it has on the product that we’re building.
“It doesn’t matter how fast you’re moving if you’re building the wrong thing”
If you take each individual then and you look at their biases, the skill sets that they bring to the table and the levels of influence that they have, that is typically what determines our levels of ownership in a team, that kind of slice of the product that they will really fight for and think about. If you take each of those individuals and you put them together, just like we did with the vectors earlier, that is what will determine the direction your team will take and the momentum it will have. Remember, early on, we need to move at such momentum just to have a shot at success.
Your team’s direction is interesting, though. Because, if you get that wrong, it doesn’t matter how fast you’re moving because you’re kind of screwed anyway. You’re building the wrong thing.
Great teams are well balanced. They’ll have strong owners in every dimension. They’ll know what it is that’s important to their customers because they cover it from every dimension. In poorly aligned teams with unbalanced people, they’ll be trying to pull the team in all different ways. They’ll build the wrong thing in the wrong way.
Let’s imagine for a second that you’ve just started a new company or a new team within the business that you work in, and you’ve built this team, you’re really confident that you have the skill sets needed to build a great product. You can kind of get almost this map to success in your head.
“Really great product teams are constantly tuning and iterating on the direction that they’re moving”
Unfortunately, our road maps in work don’t actually look like maps. I kind of wish they did, though. But, it’s easy to get this map to success, right? There’s this X that marks the spot. It’s that perfect product that you want to build. It’s a straight line down the road, right? I have a great plan, I have a great team. Everything’s going to go perfectly. Real life is never, ever that simple. There’s always going to be unforeseen challenges along the way.
Imagine I’m the engineer on this team, and somewhere down this road I see a problem that we’re all intimately familiar with. It’s that scary mountain of technical debt. As a team, we were originally moving in the correct direction, with good momentum, but if we don’t change what we’re doing now, we’re going to hit this first mountain.
It’s my responsibility, as the owner of that engineering dimension of the product that we’re building, to pull my team around this mountain. But, the only way that can work is if the other functions on the team trust that I am doing the right thing. Because, remember, they’re going to be biased as well. They will have a vision of where they think the team should be going. I need them to trust me that I’m doing the right thing and pulling the team in the right way.
Sometimes you need to repaint the picture of what you think is true
The direction of your team needs to be fluid, organic and reactive to what life is throwing at you. Really great product teams are constantly tuning and iterating on the direction that they’re moving. David Lynch put it in a really nice way. He said that sometimes you need to repaint the picture of what you think is true.
It’s that diversity in your team, that diversity of skill sets, that gives you vision to see that problems are about to occur. But, just having vision isn’t good enough if you can’t actually react to them. It’s that ability in you and your teammates to be able to realign and compromise on where you think the team should be going that actually lets you react.
If you look at any successful project, you’ll see that you’ll have weaved and bobbed through loads of challenges along the way. Passive teams, the teams that never changed how they worked, they’ll still be stuck on that first mountain.
We really value this kind of iteration at Intercom, this tuning of direction. It’s something that we really try and do every day. But, we’re human, and we’ve absolutely gotten it wrong. I want to go through an example. It’s a feature that we built almost two years ago now. It’s called Smart Campaigns. It’s essentially a feature that would intelligently deliver the best message to the best people at the best times. Sounds good, right?
The first version of Campaigns that we launched, on the face of it, was successful. It solved some major requirements of our customers, it made Intercom a much more powerful messaging platform and shockingly for this industry, it launched almost on time.
Internally, though, it was a scaling nightmare. It kept engineers awake at night. It cost us a lot of money to run, far more money that we’d ever hope in making in profit from it. In fact, simply running it was a danger to the overall availability of our product. And fuck me, I led that project. How did we get to this point? But, I want to go through it, I want to touch on it, because, to me, Campaigns is the perfect example of alignment in a team gone wrong.
See, when we started building Campaigns, we thought that there was this strategic need to build this huge feature set for our customers to use. We thought that because we had customers using an older version of our messaging system, and we wanted them to move to Campaigns.
However, there is an upfront time cost associated with them actually doing that, and we wanted to make the choice as compelling as possible. Serena Fritsch talked about having empathy with your customers, and this was us very much trying to tick all the boxes.
“Misalignment in a team compounds on itself. The longer you leave it, the harder it is to get back on track”
As engineers, we could see that there were going to be scaling problems down the line, but we were so strategically aligned to this vision that we needed this huge product breadth, that we just kind of hoped that we could buy more AWS instances and buy more Mongo capacity. All right, that’s going to be cool.
Real life doesn’t work that way. Just like the straight line down to the X on the map, it’s never that simple. I think maybe Serena said that it took her 6 weeks to rebuild Snooze. It took us 7 months to get Campaigns to a place where it was stable.
You know what? Retrospectively, we looked back at the feature set that we built, and we realized we didn’t need all of this stuff. We were all so blinded by this strategic vision that we never fought for that engineering side. There was absolutely a smaller set of features that we could have shipped, that we would have nailed on all of these dimensions.
My key takeaway from that was we were misaligned from the start. But, misalignment in a team compounds on itself. The longer you leave it, the harder it is to get back on track. I should have fought for my engineering ownership earlier and brought us back on track.
But, it’s a learning process, right? Getting this alignment right is hard. You have to be able to constantly tune where your team is going.
I talked about the benefits of alignment to a team and how it helps your momentum early on, and we’ve also shown what happens when it goes wrong. I’ve also talked about this concept of being able to fight for your area of ownership, or being able to compromise when someone else is fighting for theirs. But, those are kind of opposing points, right? How do you actually get the skillset to know when you do that? What do you look for in a really great product engineer, or just a great teammate in general?
There’s a lot of talk about T-shaped people in the tech industry, and certainly when I was a manager, these were the kind of people that we really wanted on the team. For those of you who aren’t familiar with what a T-shaped person is, it’s simply a person who has great depth of knowledge in a single area, but great breadth of knowledge in many others. It’s that breadth of knowledge that let’s them know how to approach problems outside of their domain. They’re curious people. You tend to be able to throw them in the deep end, and they’ll figure out how to swim.
“Great product engineers should have insight into things like product strategy or the UX system that we’re using”
Now, in a great team, each individual should understand the high level function and concerns of the other functions on the team. That might be me, as an engineer, understanding why getting something to market now is more important than fixing some issue that’s been really annoying me for the last week.
If you go back to this original T-shape, and you zoom out across roles, you’ll see that it remains true. Great product engineers should have insight into things like product strategy or the UX system that we’re using. You don’t have to be the expert, and I’m not saying that you have to be at all. Just having that overview can give you this amazingly useful empathy with the people that you work with.
Everyone has a mental model of product development, it’s how they think about the process. It’s two different sides of the same thing sometimes. When you gain this broader context, you start learning the mental model of the people that you work with. You start learning how they think.
“Teams are all about balance between individuals, what their vision of the team should be and what’s actually good for your customers”
When you learn how someone thinks, you learn how to communicate with them incredibly effectively. You learn how to say when you are fighting for something that’s critical to you, and you learn when they’re fighting for something that’s critical to them. It gives you this overall empathy and trust with the people that you work with, and it’s those two skills that give you the ability to know when to compromise and when you should fight for you area of ownership.
At the end of the day, teams are all about balance. Balance between individuals, what their vision of the team should be and what’s actually overall good for your customers. Your team direction needs to be fluid to be able to move around the obstacles that life throws at you.
Sometimes, it’s really hard to see the forest from the trees, and you need to be aware of the influence you have over others and the biases that you’re bringing to the table. To do that, you need to grow yourself, but you need to grow yourself outside of your core domain.
“If you want to grow a great team, you have constantly tune and iterate on the direction and build empathy and trust with the people you work with”
Waheed El Miladi talked about how he didn’t understand the problem he was trying to solve until he worked with product and until he worked with design, it was only then did he realize what he needed to do to build the right product for his customers.
Ultimately, your job as an engineer is not just to write code. It’s to help build a business. The best way that you can do that is to help your team build the right products.
If you want to grow a really great team, you have to be comfortable with constantly tuning and iterating on your direction. You have to build that empathy and trust with the people that you work with. When you do, you will build better products.
The post Alignment on great product teams appeared first on Inside Intercom.
On day one as Reddit’s new VP of Engineering, Nick Caldwell faced a dilemma. He had just spent 13 years at Microsoft, most recently as the head of 300 engineers. At Reddit, he led a team of 35 – none of whom knew how to manage other engineers.
He had to quickly determine which team members displayed a potential for leadership and teach them the fundamentals of management so they could make new hires and scale – without ruining the culture.
I hosted Nick on the podcast, where we discussed the differences between management and leadership, fostering diversity in tech, and more. If you enjoy the conversation, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice.
What follows is a lightly edited transcript of the conversation. Short on time? Here are five quick takeaways:
Nick Caldwell: I’m VP of engineering at Reddit. I’ve been there for about two years, and my primary responsibility has been growing the engineering team from around 35 engineers to the 177 we have today and building tons and tons of interesting stuff. The biggest project I’m working on is the website redesign, but I also created a machine-learning data science, data engineering organization, and an ad platform. Before that, I was a general manager at Microsoft. I had a 13-year career at Microsoft, where I started as an intern working on video games, if you can believe it. I then went into natural language processing, machine learning, and ended working on business intelligence through a product called Power BI, which I became the general manager for.
I got into engineering through my father. When was a little kid – 3 or 4 years old – he brought home a Tandy 1000 to replace his typewriter, and I thought the thing was fascinating. I used to sit on his lap and type random stuff into the keyboard. That got me fascinated by computing early on. And then when I was around 10 years old, my dad bought me a book called Learn C++ in 12 Easy Lessons, which was not an accurate title by any means. From there, it just snowballed. I became fascinated with computers and decided that was going to be my career.
Leaders are people who take responsibility for what happens next
I got into engineering leadership as a manager about three and a half or four years into my career. Part of it was that I had good relationships with some sponsors who saw a lot of potential in me, and part of it was that I don’t like being told what to do. A couple of years later, I got into a real leadership position. Managers and leaders are different. Leaders are people who take responsibility for what happens next. I got my first real leadership opportunity about five years into my career when one of the teams I was on was struggling with the product roadmap. Rather than complaining to my manager, I decided I would step up and take responsibility for figuring out the product roadmap. That project led to my first cross-functional team. It also led to winning a Microsoft internal prize, and it was really the first time I could call myself a leader instead of a manager.
Darragh: You mentioned that you became a manager because you didn’t like being told what to do. Presumably you’ve got about 177 people who don’t like being told what to do on your team right now, right?
Nick: I was being a bit tongue-in-cheek. Our 170 engineers at Reddit are great. What was missing for me early on – and why I make that joke – is that we needed direction. I do think one thing that’s a leader’s responsibility, whether or not you’re a manager or not, is that you have to provide a compelling vision for people to follow and believe in. At that early point in my career, I was frustrated and had to step up because no one was providing that vision. At Reddit, we don’t really have that problem; if anything, we’ve got too much stuff to do. And sometimes it’s challenge to keep all the balls in the air at the same time, but there’s no shortage of vision. That translates into missions that we carry out day to day.
Darragh: You wrote a blog post recently about the impact of having sponsors during your time at Microsoft. How do you see the difference between mentorship and sponsorship, and why do you advocate so much for the latter?
Nick: Sponsorship versus mentorship is a piece of advice I give to pretty much every person within my organization. Most people know what mentoring is: you find a leader, someone you respect, you grab coffee with them every so often, you unload your problems on them, and they give you some coaching and advice, which is useful. It’s good for building a network. It’s good for getting advice. Sponsorship is where – instead of going to someone and getting advice – you go to them, and they give you an opportunity. Sponsors are typically high-level people in the organization who are aware of opportunities. And in meetings and conversations where those opportunities are being discussed, a sponsor makes sure your name pops up, and they’re maybe pushing those opportunities your way.
A sponsor makes sure your name pops up, and they’re maybe pushing those opportunities your way
In my career, most of the major leaps I’ve taken came through sponsorship: people who were in a room when an opportunity was being discussed and said, “Hey, Nick would be a great person to try that out.” There’s another key difference when you’re being sponsored, you actually have to follow through. In a mentor/mentee relationship, you can even expect that your mentee isn’t always going to take your advice because they’re talking to multiple people and they want to get multiple perspectives. In a sponsor relationship, there’s a clearer back and forth. If a person sponsors you, it’s not only your reputation on the line but also the reputation of whoever sponsored you. You have a heavier more burden to carry through and make sure you deliver.
Darragh: Do you think sponsorship is implicit in a manager relationship?
Nick: No, I don’t think that’s the case. Great managers look out for you and want to make sure your career interests are being considered, but managers aren’t always fully aware of all the opportunities a company might have. A manager is certainly aware of what they want you to do, but your sponsor is going to come from the broader network of other managers, directors or executives. There’s a whole ocean of opportunity out there if you just go look for it, and if you limit your opportunity window to what your manager’s giving you, you’re going to be missing out on a lot of things.
Darragh: What’s your advice for people who don’t yet have someone they identify as their sponsor?
Nick: Getting a sponsor is difficult. It’s more challenging to get than a mentor. You start by getting a sponsor by simply doing great work. No one will sponsor you if they aren’t willing to take a bet on you. Step one: make sure your work is rock solid, and put a lot of energy into high quality results. Step two: gain sponsors through networking. When I was at Microsoft, I made a conscious effort to spend some percentage of my week meeting people who weren’t within my organization. Finally, you have to be patient and wait for your opportunity.
The value of my network outweighs most other investments I made in terms of my career advancement
When you’re networking, the value of your network is always immediately apparent. But in looking back over my career, it’s clear that the value of my network outweighs most other investments I made in terms of my career advancement. Find people who would be willing to sponsor you, that have a continuous stream of opportunities that they look at, impress them and then be patient and when the opportunity arises, don’t be afraid to jump. If you want to advance in your career, you have to get uncomfortable and be ready to try new thing. When that opportunity presents itself, jump at it and go.
Darragh: Was this a formal thing at Microsoft or is there a sponsor program?
Nick: There was not like a formal sponsor program until late in my Microsoft career because over time, people wanted to normalize sponsoring and they saw the value in it. Early on it was simply me putting in the legwork myself. Later on, there was formal sponsoring for a good reason, which was to promote diversity and inclusion. /dev/color is a charity I’m a board member of, and one of its goals is to promote leadership – particularly getting people of color into leadership positions. If you want to make real tangible progress there, sponsorship is a great method.
Darragh: What was it like when you walked in on day one at Reddit? What were some of the unexpected challenges that appeared? What needed to change or improve right away? And what did you pull from your time at Microsoft?
Nick: When I left Microsoft, my team was around 300 people. When I joined Reddit, it was 35 people and my mandate was to grow it rapidly to about 100 engineers. I would describe that first day as a 35-person team being run with the tools you would see in a five-person team. A lot of the engineering processes were missing; there were one or two (but almost zero) managers, and there were a lot of people calling themselves “tech leads,” but there were no managers. One other thing that was frustrating on that first week was that there was a video game setup with Smash Brothers right in front of where the executives sat, and people were just playing Smash Brothers all day. You can’t really execute if people aren’t motivated and excited about the company mission.
Those were three things I wanted to jump on. I said: “We have to get some managers in here if we want to scale. We have to figure out how we’re going to run our engineering processes in a way that’s going to grow with 100 people instead of using a five-person process. Then critically, if you can’t come up with a vision or mission that’s more interesting than Smash Brothers, then you’ve got a big problem.” We spent some of those early days crystallizing what we wanted people to be working on and why it was exciting.
Darragh: What game did you replace Smash Brothers with?
Nick: Well, the game playing really died out. If you walk in the office now, it’s people just cranking away. But after hours, there’s this game called Killer Queen. I’ve never played it myself; it’s a 10-player simultaneous video game that I’m told is the most fun thing ever.
Darragh: You went from running a 300-person team to one 10 percent of that size. Were you sensitive to the idea of applying what worked for Microsoft in a different context?
Nick: Your natural assumption is to take whatever works in your previous roles and use it as a template for what’s next. I view process more as a set of tools I carry around with me, and I decide which tools are going to be deployed based on the situation. I immediately knew that trying to deploy tools from a big company like Microsoft on day one would not work at Reddit. If you’re coming into an organization, big or small, and you’re in a leadership position, you need to spend the first couple weeks just listening to the problems people on the team present to you. Then, you can dig around in your process tool bag, figure out the right tool for the job, and adapt that tool to fit the situation.
You want people to tell you what they need, and then you come up with the correct solution rather than assuming you have the solution from the start
At Reddit, the biggest immediate change I had to make was getting managers in place in a company that really didn’t have a formal management career track. But I didn’t just jump in and say: “You’re a manager! You’re a manager! You’re not!” I took time to talk about what management was, my philosophy on what it meant and the value it would add to the organization. Then over time, I just listened to the tech leads describe their problems day to day and said, “Hey, if we had a manager this problem would go away.” Over time, you get an inception where people realize that having this management layer is going to solve the problems for them. And that took about a month and a half from start to finish. Then, the pattern repeats. You want people to tell you what they need, and then you come up with the correct solution rather than assuming you have the solution from the start. That’s a great way to piss people off: to just land a ton of process on them that they’ve never been exposed to.
Darragh: Earlier you said one of the major focuses for your team the past year has been to make Reddit more welcoming. What does that mean in practice, and what the role of engineering is in helping accomplish that?
Nick: Making Reddit more welcoming was a theme for all of 2017 and most of 2018. From a user experience perspective, Reddit hadn’t been updated for about eight to 10 years, and it’s well known for being a site that was anchored in the past. The challenge, though, is that meant new users to the site were having a bad experience. They couldn’t figure out how to use the product, and it looked really dated. So they’d come in and think, “I don’t get this.” Then they’d turn right back around and leave, which is unfortunate because there’s lots of great content and communities on Reddit. If it were easier for people to understand and connect with, the site would grow, and that’s what we really want to have happen.
Over the last year or so, we’ve been redoing Reddit’s entire user interface, so it looks much cleaner right now. If you go to new.reddit.com, you’ll see the new version of Reddit, which has some cool features like infinite scroll and a card view that’s easier to consume. The challenge with this, of course, is we already have a ton of existing Redditors, so we have to make sure their old experiences translate well into this new experience. We had to redo the entire front-end architecture.
For me personally, another really fun set of things that we’re doing is using data to easily connect people with communities that might be interesting to them. We’re trying to understand: Can we group communities by topic? When someone onboards to Reddit, can we give them recommendations? As they use the home feed, can we make it more personalized and customized to their interests? From an engineering perspective, we have a data engineering team, a data science team, a machine-learning team, and a search and relevance team, which has all been really fun to create from the ground up.
Darragh: I love when you can get your purpose clear enough that all those things make sense, rather than bringing all those types of teams to the table without knowing exactly what you want to achieve. With such a large org, how do you build a sense of connection and empathy for your users?
Nick: There are two approaches. The first is the quantitative approach. In any product you’re building, you want to make sure telemetry and monitoring are baked in from the start so that you understand which aspects of your product are actually getting used. Then, you can either double down on those or decide whether or not they’re the right things to focus on. The second thing is more qualitative: developing customer empathy often times requires you to get down on their level and experience what they’re experiencing. At Reddit, we do that in a couple different ways. On a small scale, we invite people to the office, and we do user interviews.
On a larger scale, Reddit already has this gigantic community of moderators. Reddit is a network of communities, and each of these communities is run by teams of moderators. We’ve created communities where we can engage at a high frequency rate with those moderators to get feedback on any new product or feature we build. Every time we create a feature, we make a post announcing what that feature is, how to use it, and how to test it. We’ll put it into the moderator community, and almost instantly they’ll give us feedback on how well we’ve done so we can adjust as needed. Our moderators are not shy. You can really see that with the redesign. If you go to the r/redesign community on Reddit, you’ll see announcements for what we’re shipping, along with feedback both positive and negative about some of the features that we’ve created all the way back since we started the redesign. And we just keep revving that as fast as we can until hopefully people are 100 percent happy. Well, maybe 90 percent.
Darragh: What advice would you give engineering leaders who are moving roles or companies and taking responsibility they’re not yet familiar with? How do you build the trust you need to lead that team into the future?
Nick: Whenever you take over a team, the first thing you have to do is decide that you’re not going to just exert your willpower immediately. Nothing beats listening, at least for the first few days, to get a lay of the land and a sense of what matters to the people on the team. Listening is 90 percent if what you should be doing for that first week. Some engineering leaders there will tell you “Hey, it’s the first 30 days.” But I work in startups. 30 days is a long time at a startup, so I would dispute that you should wait and do nothing for 30 days. In a startup environment, the clock’s is ticking.
So, I would say listen for about a week. Make sure you understand what matter. You’re going to bucket what you hear into two distinct groups. First: things on fire that you need a bucket of water to put out immediately. Second: things that aren’t on fire that you should build a fire department to address in a more systematic fashion. For the things that are on fire, work with the key leaders who told you about them to come up with immediate solutions. This is a great one-two punch: it helps you actually solve a problem quickly, and you can build trust through actually doing things. For the second class of problems, take your time and use your normal approaches to toward getting buy-in with key stakeholders. Let the new systems roll out slowly over time.
Another thing is that you do have to identify people who are going to be supportive. The tricky thing is you also want to identify people who aren’t going to be supportive. With any organization, particularly one that’s going to scale quickly, sometimes you find people who fundamentally don’t like scale. There are plenty of folks out there who love that small-startup, 30-person feel, and they aren’t necessarily going to make it to the 300- to 500-person engineering organization. But corresponding to that, there’s also a bunch of people who are super excited to see that growth is about to happen. Find people who are going to be supportive, use them as advocates and guinea pigs for any new processes you want to roll out, and grow that way.
Darragh: With the people who are comfortable in that small 30-person company, do you think that that’s a changeable mindset?
The best managers understand that it’s about aligning people’s passion with what the business needs
Nick: Totally. People can change over time, right? So, if someone is only used to only working at small startups, they can learn over time how to operate with more processes and more dependencies. Those are totally trainable and if you have good managers and directors, they’ll bring people along for the ride. But I’ll always caution: sometimes people are just good in their particular lane, and you want to be careful as a manager not to force people out of their lane unnecessarily. If someone’s really strong at a particular skill or in a particular team size, there’s always a risk to pull them out of that. I would strongly advise you to make sure that people’s interests and passion are lined up with what you are trying to get them to do as a manager. If you can get that intersection, then you get the maximum output. If you’re always trying to pull people away from what they’re naturally inclined to do, or push them toward things they don’t want to learn, you’re going to be fighting an uphill battle. As a manager, you have to recognize that it might be better for that person to find a different opportunity. It would be better for them, and it would be better for your team. The best managers understand that it’s about aligning people’s passion with what the business needs.
Darragh: When you joined Reddit, there was basically no engineering management practice there. You introduced that, but you did so by balancing both hiring and growing folks internally. I’d love to understand your thought process and approach there.
Nick: Whenever you’re building an organization, it’s always best to look within, before you bring in folks who from the outside. You want to preserve the company culture, and every time you bring in a new leader from outside, you’re going to change the culture up a little bit. Even though we had 35 engineers at Reddit, there weren’t a lot of managers. But it was clear to me that there were a lot of people who exhibited leadership and could be guided toward a management track. There are also a lot of folks who wanted to be individual contributors and maybe go up an architect track. So I introduced the concept that you could climb the ranks in one of those two roles. Within the first couple of weeks, I did one-on-ones with all these folks and tried to figure out what their career aspirations were. For engineering managers, I look for people who like to ship on a predictable schedule, people who enjoy coaching, mentoring, and investing their time in others. Then, you can identify architects as folks who are interested in the long-term health of the code base. They may talk your ear off about Kubernetes or some Erlang or a niche technical project. I tried to tease these folks apart, and for the folks I identified as being more managerial in nature, I started with one-on-one training at first and then group training later, teaching what I thought were the basics and fundamental requirements of being a good manager.
On the execution side, you need to be able to deliver high quality software on a predictable schedule. On the people side, you have to attract, retain, and develop strong talent. Those are the fundamentals of management. With the architects, I talked talked about how to manage and monitor tech debt, how to develop technical strategy in terms of scaling. So that gave me the first group of people. I had to train all these folks to try and hire more engineers – if you ever find yourself in a situation where you need to scale this rapidly, you do eventually have to hire external folks. But I only did that after we had a great system of execution in place and I also felt that the company culture would sustain bringing in more people from the outside.
Darragh: Your line of questioning to help explore is interesting. Do you get many people who want to do both?
Nick: Early on, everyone is in that situation. Most companies have a role called “Tech Lead,” which if we’re being honest, is a proto-position where you have some management responsibilities and some architectural responsibilities. You’re halfway between two worlds. We had that at Microsoft, and it seems to be really common. Rather leaving people in that limbo state, though, I prefer to track they want to experiment with as quickly as possible. If it works, great. If not, you can always switch. You can make a lot of different bets on yourself, particularly in Silicon Valley.
Darragh: Speaking of bets, I understand that a big part of Reddit’s engineering culture is around freedom and experimentation and a particular ritual called “snooze days.” Can you explain what those are and most interesting things that have come out of them?
Nick: Snooze Day was actually started by the original Reddit CTO, Marty Weiner, and the idea was to give Reddit employees some creative freedom. They could literally explore any engineering or non-engineering topic they wanted for one day every couple weeks. When I joined, I saw this bi-weekly ritual and I thought it was great culturally because allowed people to take a lot of creative risks. But because I like to put process on things, I decided one day didn’t really give people enough time to take a full swing at some of these ideas. So Marty and I worked together to modify Snooze Day, by making it a few days longer, adding themes, and adding prizes. Now, it’s become an institution, and it’s actually a whole week long. One’s coming up next week, and we’ve got five different prizes. Nowadays, the projects that come out of Snooze Week will get shipped into full production, so we get a lot of great value out of that. Last time around, the theme was “quality.” This time, the theme will be “efficiency,” so hopefully we’ll get some great cost-saving projects.
The intent of Snooze Week is really creative freedom
Here are some examples: We were talking about Killer Queen a while back. Reddit really loves this game, and they were asking us to buy one for the office. It turns out this game costs like $15,000 dollars, and we weren’t willing to spend 15 grand on it, so during one of the Snooze Weeks, the team got together and made a game called “Killer Snoop.” It’s basically a clone of Killer Queen with all of the characters replaced by Steve Huffman the CEO, co-founder Alexis Ohanian, and a bunch of different Reddit. It’s really awesome. There are practical ones, as well: we had someone add performance monitoring to our continuous integration, continuous delivery pipeline. That shipped to production. There’s a good one called “Reddit Rabbit Hole,” where the idea was that essentially for any given post you would see on Reddit, we would find the next most addicting post so you would just fall into Reddit and never get out of the rabbit hole. That one is in experimentation now and might ship.
The idea here is that if you give a couple hundred people free reign to come up with any idea they want, sometimes you’ll get games, and sometimes you’ll get things that add immediate value to our end users. But the intent is really creative freedom. We’ve had people use it for things that weren’t even really code, like a pie baking contest and a gardening club, so that creative culture lends itself to a lot of different outcomes.
Darragh: You’ve also recently created a scholarship program called “Color Code,” and as you mentioned you’re on the board of /dev/color. Can you tell our listeners what those initiatives are about?
Nick: To give some quick backstory, I’d been at Microsoft for 13 years. And I was one of the few black engineers I would see day to day. You’d really see few other people of color on campus, and that was frustrating. The whole time I was there, I don’t remember seeing any other black Tech Execs. Which was really frustrating. I had been trying at Microsoft for so long to change the numbers, both in terms of people of color and women in tech. We made progress with women in tech, but trying to get people of color up into Seattle was always a challenge.
Within the first two weeks of moving to San Francisco, though, I was invited to /dev/color. It’s a non-profit group whose purpose is to promote leadership for people of color in the tech industry. I attended one of their first events, and there were 300 other black people in one room, all in tech, from all age ranges, from entry level all the way up to senior executives. I was just blown away by this; I’d never seen anything like it in my career and it really gave me hope that I could really make a difference if I put my time in. In San Francisco, at least, there were enough people in the area with enough motivation to hustle and learn, that I could really help make a difference.
So, to answer your question, Color Code is a scholarship my wife and I started about a year and a half ago. It’s a small fund; it comes out of just our own money and our small donations. We pick a leader who we think has a lot of potential, and we’ll put them through training courses or give them mentoring. We’ve done that with a few people over the last year. /dev/color is much larger, though, and I highly encourage people to look at this organization if they’re interested in finding ways to promote leadership for people of color. I joined the board a few months back because as the organization scales, they want people who have run larger organizations. When I joined, it was 300 people; they’ve since broken through the 500-person barrier and now are expanding to multiple cities. /dev/color is different from other boot camps that you might have heard about in that it’s just not a boot camp. Boot camps are about getting people in at the ground floor. And /dev/color is really about getting them into positions of leadership, which is a key evolution in diversity and inclusion.
Darragh: What are some ways for folks who to get involved and help that initiative?
If you talk about diversity issues in a safe environment, you’ll make more progress
Nick: Start at devcolor.org. They do sign-ups every three to four months, so you can join anytime. If you want to join you do have to have some initiative, and there’s what I call a “lean-in circle.” The first experience you’ll have in /dev/color is joining a squad of other people who will tell you what goals they have for their careers, and your responsibility is to meet with them once a month to talk about progress toward those goals. That’s like the entry requirement for getting into /dev/color to show that you’re willing to put the time and commitment in to help others as well as yourself.
If you would like to sponsor, just shoot me an email and hit me on LinkedIn. If you sponsor /dev/color, you will obviously get to have folks in your company join the organization, but we also have training programs for folks who maybe aren’t people of color but just want to learn about how they can make a difference. If you talk about these issues in a safe environment, you’ll make more progress. Companies can be afraid to talk about their diversity initiatives publicly and honestly. And with /dev/color we have a closed-door environment where you can come and bring your honest questions and concerns, meet with other leaders who are trying to promote diversity and inclusion in their organizations, and talk about what works and what doesn’t without worrying about your initiatives showing up on Business Insider or TechCrunch or something like that. Talking about these things is a great way to continue making forward progress.
The post Reddit’s Nick Caldwell on engineering leadership appeared first on Inside Intercom.
As up and coming engineers in Silicon Valley, Jean Hsu and Edmond Lau long sought more influence and impact in their respective positions – but they couldn’t shake the feeling of being stuck.
Their story isn’t uncommon. Many engineers feel like they must make a jump into management to lead. But as Jean and Edmond will now tell you, following years of engineering leadership at Quip, Quora, Medium and more, that simply isn’t the case.
They’ve now started a company together, Co Leadership, to help pave the road for engineers to become leaders. After coaching 100+ tech leads, managers, directors, VPs, and CTOs, Jean and Edmond are distilling their most valuable lessons into workshops and online courses.
I hosted Jean and Edmond on our podcast to get their take on the difference between leadership and management, the power of positive feedback, and why trust is the foundation of the most effective engineering teams. If you want more insights from Edmond and Jean, they’ve actually put together a free guide for Inside Intercom listeners, which is all about designing better working relationships.
What follows is a lightly edited transcript of our conversation. Short on time? Here are five quick takeaways.
Louis Bennett: Jean and Edmond, welcome to Inside Intercom. Can you give us a feel for what led you both to Co Leadership and explain your mission there?
Jean Hsu: We both spent about a decade in various engineering roles including IC, TechLead, and other leadership positions. Both of us had this experience where we felt stuck. We wanted to have more influence and impact than we were having, but we were trying all these things and we couldn’t figure out how to do it.
Once we both moved into engineering leaders, we saw this was a pretty common pattern. We really want to help people bridge that gap, make it an easier transition (into leadership) and help people live the lives and careers they dream about.
Edmond Lau: There were times earlier in my career where I wanted more leadership roles and I would do things like ask my manager to become a manager. I would be waiting for leadership and authority to be handed to me. When that didn’t happen, I just felt like, “What do I do now?”
It’s very easy for people to feel stuck and wait for opportunities to come. A lot of our work at Co Leadership is helping people feel empowered – to actually start leading from where they are.
Louis: How do you define leadership?
Edmond: Leadership is having some sense of the impact and the influence that you want, and then feeling empowered to take steps toward moving towards that direction.
Jean: Leadership is really about your mindset. A lot of times people will wait for a leadership role to be granted to them or their potential to be recognized and then given this title. Then what they often hear is, “You need to display leadership before you can have the role.” They just don’t know what that means. I didn’t know what that meant and I tried a bunch of things without much success. Leadership is more about the mindset of taking initiative and being responsible for the changes you want to see.
Edmond: An implication of that mindset is that everyone really can be a leader. It’s not something that has to be attached to a title or a role. It’s something that you can decide and choose to take on. Then if you’re given the right tools, you can be more effective at doing that.
Leadership is not something that has to be attached to a title or a role.
Jean: Especially with engineering teams. If you think of leadership just as management, there aren’t that many spots. As a result, you see a lot of people moving into roles like mid or senior level IC, a tech lead or tech lead manager. All these roles change very quickly. They’re not super well defined, so we really want to equip people with the skills to have leadership in these types of roles that aren’t as explicit as, “Your role is an engineering manager.”
Louis: There’s a certain kind of inherent tension to engineering management. Someone will have developed their skill set in one walk of life – computer science, for example – and then there’s so much organizational gravity pulling people towards a management role, which is a totally different discipline. But leadership is something you can show to be a senior individual contributor across all those things. It fits into that gap and can provide a strong foundation to switch from one to the other.
Edmond: There are a lot of different problems that exist in organizations where there are gaps that exist. Really anyone who builds awareness around that gap and takes initiative toward it can step up and be a leader, even without following those default patterns of what it means to be a manager or what it means to be a tech lead.
Louis: Co Leadership offers training for people across a lot of different companies as well as deeper training sessions with specific companies as well. What do you think the most impactful things or the most surprising things have been that you personally have learned from the attendees of your courses?
Jean: For our independent events we have people come in pairs, such as an engineering manager and a product manager who have been working together for some time. We teach them some skills around how to discover what’s important to the other person. Then we send them off to have a five-minute conversation using these skills, asking open-ended questions and really listening. They’ll come back and say something like, “I just discovered more about what motivates this person. I didn’t even know that and we’ve working together for a year and a half.” That’s so rewarding for us to hear that we’re actually having that impact on people who work together all the time.
Edmond: It’s super motivating because if we can really spread the work that we’re doing at scale and teach a lot of these foundational, trust-building, relationship-building skills to more people, so many more teams would be able to achieve higher levels of success. If you’re able to really understand what’s important to all the stakeholders around you and people you work with, and you’re able to design much more fulfilling relationships at work, people would get so much more done and be way more efficient too.
Louis: It’s amazing how much of getting work done is just getting people to actually trust each other to work well together, to find areas where motivations are aligned or not aligned in order to help get stuff done versus just doubling down on, “We need to do this thing. Why aren’t we doing this thing?” It’s really about, “How do we actually work together to have shared accomplishments?”
It’s amazing how much of getting work done is just getting people to actually trust each other.
Jean: That’s one of the reasons why this is a gap. As engineers we’re so focused on the how, the problem solving around a particular problem. It’s easy to focus on the tactical elements of something rather than taking a step back and investing in trust-building and discovering what’s important to people.
Louis: I’ve always approached this from the simple fact that I can’t read people’s mind. If something is important to someone, they’ll need to tell me that. I can infer, but the likelihood that I’ll get that wrong is also very high. If I say, “I think you’d be great at this,” they’ll need to tell me, “That sounds horrible. I don’t want to do that.” None of us will be right all the time in that way and so finding ways for people to effectively communicate, is empowering – whether it’s an EM and PM, peers or manager and direct reports.
Edmond: When we realize that we can’t read people’s mind it means both that we not only have to share what’s important to us, but we also have to ask people what’s important to them. It becomes this two-way, discovery conversation where you put what’s important on the table so you can actually start to make decisions around it.
Louis: When you think about teams, beyond 1:1 conversations, have you found any frameworks that work well for teams to talk about things like this?
Edmond: That reminds me of the workshop we ran a while back with members of the engineering team from Medium. It was actually the reason why we started doing pairs at our workshops. There’s all this shared context from people who all work on the same team, but oftentimes what’s important to this group of people isn’t made explicit.
One of the workshop prompts was, “What are gaps that you notice in the organization or on the team?” We created this shared context of what gaps everyone saw and what they wanted their team to be. People were able to share a lot of things and build a confidence that, the gap they see on the team is something that everyone else sees too. They’re the one putting the words to it in this group, but there’s actually a lot of buy-in, alignment and support if they were to take initiative and tackle it.
Jean: Without that level of alignment it’s easy to think, “I’m the only person this is bothering. No one else is having this problem because no one’s bringing it up.” Then everyone’s sitting with this thing thinking, “I shouldn’t bring it up. I don’t want to be the one complaining.”
Edmond: That’s a broader limiting belief that we see among a lot of engineering teams – people think that they’re alone with this problem or that someone else will fix it. The impact of either of those beliefs is such that I feel less empowered to take leadership. Those end up being two of the beliefs that we work towards equipping people with the tools to overcome in these leadership experiences that we run.
Louis: It feels like there’s some crossover with ideas like blameless post-mortems and things like that, of people being able to have shared vulnerability to say, “Here is exactly what happened. Let’s not talk about the who, but let’s talk about the circumstances that created this,” and really encouraging people to name the obvious to generate more insightful conversation that way.
One thing we do at Intercom that is very effective in promoting the greater good is helping people understand it’s not necessarily a people problem. Maybe it has to do with the circumstances of the problem or something we haven’t prioritized or some other extenuating circumstance. Those frameworks work best when people can build upon an existing strong relationships as well as a place to be safe.
When I think about your work, I think a lot about the research that’s been done about people performing better when they have psychological safety, and that vulnerability and psychological safety go hand-in-hand as well. Have you seen any direct or indirect experience that would confirm or refute that?
Jean: In one of the Medium workshops, we also had people go around and hear the impact that they’ve had on other people. We had everyone else in the group talk about the impact that person had on them. When we talk about blameless post-mortems, we usually think about when something’s gone wrong; a lot of my and Edmond’s work is focused on what’s going well, which does build psychological safety. Hearing 10 people say, “When you do this, it makes me feel inspired to do my work,” or when we do our post-mortems it’s mostly positive.
Edmond: We go through lessons learned, assessment of progress, and then gratitudes.
Jean: It’s focused on what’s going really well, and that builds up psychological safety. Then when we do have to give each other feedback in the moment we have this trust that we both really enjoy working with each other and are doing really meaningful work.
If people don’t know the impact they’re having with all their positive actions, they might stop.
Louis: Do you find that certain personalities get that better than others? If I speak for myself, I’ve gone through performance reviews before where you hear, “Everything’s going well,” and I’m sitting on the edge of my chair waiting to hear about the things I could do better. I’m not saying I don’t listen, but that’s not the feedback I’m craving in some ways. Oftentimes people don’t provide enough or give enough credence to positive reinforcement feedback that way.
Edmond: It’s a very strong engineering bias. When we do code reviews we look for what’s wrong. It’s oftentimes very rare for people to say, “What’s going right?” in a piece of code, and we end up applying that same mentality to people. If 80% of the time things are going well, maybe 80% of the retrospective should be spent on celebrating what’s going right.
Jean: …Or figuring out how to do more of what’s going right, rather than focusing on the small percentage of things that are not going well.
Edmond: There’s a risk of not focusing on what’s going right: if people don’t know the impact they’re having with all their positive actions, they might stop doing it.
Jean: That’s an important point. When people share positive feedback, they often don’t talk about the impact of the positive things you’re doing. They’ll just say, “You did a good job,” or something that just seems vague and positive. They don’t say, “Because you did this, now so-and-so can really be unblocked,” or, “This person feels much better about their work.” A lot of times when you don’t have the impact shared, especially as engineers, we tend to just focus on, “What are the things I can change?”
Louis: If I think of every post-mortem I’ve done, if it’s divided into things that went well, things that went better, and things to change, the “things that go well” column is always given short shrift. It’s three or four different things and it’s nothing about the root cause of why things are going well. It’s more digging into, “Why didn’t that happen? What was the sequence?” From a healthy culture perspective you want to make sure you don’t end up messing up the good stuff while you’re trying to fix some of the things that could be going better too.
Edmond: There’s so much research in the field of positive psychology around how happiness leads to more success and better performance. Celebrating what’s going right can also just create a much happier team and also lead to better performance and success for the team too.
Louis: One thing that’s different at Intercom versus other companies I’ve worked for is the geographical distribution of the employee base. We’re in five different offices in four different countries, so being able to effectively work together across continents is predicated on trust and being able to say, “There’s an aspect of happiness within that.” Basically you, until you physically meet people in-person, are two dimensional in that space. You don’t necessarily get that character of, “This is who this this person is. This is how they feel about these things,” and the off-hand conversations that help build trust over time. I need to remember that if I have an urgent question for someone in part of the world that’s done at the office, I’m taking him or her away from their family. Just acknowledging that, or if they’re calling me at 5:00am, acknowledging that I might be waking up, makes it easier to work together too.
Jean: Remote or geographical distribution is a forcing function to make sure that you have explicit conversations that build trust. A lot of times teams rely or fall back on being able to see each other. You can get a sense of, “Is this person doing okay?” just by seeing them at their desk. The absence of that actually forces you to have these conversations more explicitly.
Edmond: One of the issues with remote teams is when the meetings are focused on making sure the logistics work as opposed to spending time getting to know one another – understanding what people’s core motivations are, what’s important to them and what makes them happy at their job.
There’s also a piece I think that would accelerate building trust: whenever issues do arise, clear up the stories that can get in the way. One of the researchers who really influenced our leadership experience work is Brene Brown. She does a lot of research into vulnerability, and how oftentimes the stories we make of people that we don’t know too well hold us back from stronger working relationships.
When there is conflict in remote working relationships, and there isn’t a way of clearing up these narratives that we make of other people, that’s when trust becomes harder to build. Spending time clearing up those stories helps build that trust a lot.
Jean: You can definitely get pretty imaginative with stories when you don’t see the person in the office. It’s like, what did that person mean when they said this on Slack? What did that email or code review comment really mean?
Louis: I think we’re all our own worst enemies when it comes to interpreting what other people said, either in the sense of giving people too much credit for what they’re saying and missing something nefarious. The much more common case is there’s some off-hand comment that we’re mentally chewing on for hours that doesn’t match the intention of what that comment was at all.
Jean: Meanwhile they were just trying to get through 20 pull requests and they were tired.
Louis: I’ve worked with a lot of engineers going through the transition into some variety of leadership role. There’s this sense of people waiting to dip their toes into it and there’s a chicken egg scenario of becoming a leader before you can become a leader. One of the things that I’ve done is recommend books that are helpful to me. What books and reading has been interesting to you to help people understand what engineering leadership and management means?
Jean: One of my favorites is Five Dysfunctions of a Team, which ties this conversation about trust. The author talks about these five dysfunctions that you really need to address in sequence. The basic one is lack of trust and building trust and how that can be the foundation for everything else. It’s written as a fable so it’s really easy to read.
Edmond: Another book that I really like that’s less focused on management is Extreme Ownership by Jocko Willink. He was a former Navy SEAL and ran the team in Iraq. A lot of that book is around this mindset he calls, “Extreme ownership.” Taking ownership of the outcomes.
Oftentimes we disempower ourselves when we believe it’s someone else’s responsibility.
He talks about one training exercise where he broke his squad into a bunch of different sub-groups. They were running these races and they took the leader from the winning group and swapped them with the leader from the losing group, and the losing group was able to win. This person had embodied what it meant to take ownership over that group and was able to motivate everyone in that group to actually do well.
That book sticks with me because it has this mindset of, “You are in charge of the results that you want to see. It is not someone else’s responsibility.” Oftentimes we disempower ourselves when we believe it’s someone else’s responsibility.
Jean: It reminds me of another book that I found really influential, Turn the Ship Around. The author runs a nuclear submarine, and he changed the entire model from leader-follower model where there was a hierarchy of, “Do this,” and then that person would tell someone else what to do, to a leader-leader model. By the end he would be wandering around the submarine and people would come up to him and say, “This is the context. I’m going to make this decision. What do you think?” He’d go around approving things and everyone would come to him with the information he needed to make the decision. I thought, “If this guy can do it with a nuclear submarine, we can definitely do it with the internet and software.”
Louis: It puts it in context. Sometimes it feels like there’s no idea sharing in the way that software engineers do management, where we think about, “How do you break things into component parts and have distributed systems that talk to each other?” Management tends to be this talked down, orchestrated thing that has fewer of those components. That’s why I always like hearing about books that have ostensibly nothing to do with software engineering because it brings in new ideas.
Edmond: Translating some of these concepts that are well known in other industries into language that maybe engineers can better resonate with is something that makes us very excited about our work. How do we use our engineering careers and everything we’ve learned about abstractions or investments and infrastructure, and apply them to relationships?
Jean: Every engineer understands that when the technical debt gets bad you need to chip away at it. You need to invest in it. You need to create projects around it. The same is true for relational debt. If you invest in it upfront, then you can set yourself up for a better relationship down the road, but sometimes relational debt gets pretty bad and then you have to really invest a lot of time to make that working relationship better.
Edmond: We know that we definitely should design our software if we want it to achieve our desired goals, but we don’t apply that same mindset to our relationships. If we want our relationship to turn out a certain way, it would be helpful if we explicitly designed them.
Louis: Is there a point where it becomes awkward? Where you’re talking so much about your relationship and how you measure successes of relationships among teammates that it makes it a little impersonal in your experience?
Jean: Right now what we’re seeing an under-investment in talking about how people want to work together. I think we’re pretty far off from over-investing in there, and at least for us working together we definitely invest a lot of time in conversations just around what is and isn’t going well. It’s always surprising to me how well it’s paid off and made everything else easier.
Edmond: Any sense of awkwardness comes from using a new muscle that you just haven’t exercised before. It can be little uncomfortable when you don’t quite know how to do it correctly, and a lot of our day-long events are teaching people the language they can use to ease into these discovery conversations or design their relationships better.
Jean: Embrace that it’s going to be different from what you’re doing day-to-day. A lot of times people read communication books and they understand intellectually that this could work. Then, they go to work and they don’t use any of the things the book says to do because you don’t get the stepping stone of practicing in a safe environment and then transferring it to work.
Louis: As you both look forward, what’s next for Co Leadership? Are there any things you’d want Inside Intercom readers and listeners to know about?
Edmond: We’ve actually put together a guide for Inside Intercom listeners on how to design your relationships as alliances. It’s a tool that we put together to get a sample of some of the things that we teach in our leadership experiences as well as our leadership programs with companies. You’ll learn how to ease into a conversation where you actually have an explicit discovery phase of understanding what’s important to the other person, and then how to build alignment around that.
We’re trying to take a lot of these leadership experiences that we’ve been running in the Bay Area and broaden the reach to people all over the world. We’re starting to launch our online courses and build longer multi-week programs where people can learn some about investing in relationships, building trust, building effective teams, and we’re doing that across videos as well as experiential practice sessions that we do online.
Jean: We’re also running in-person events outside the Bay Area and doing some travel as well.
Louis: I’m super excited to see two people that are so competent attacking this for a lot of different companies and really helping them open their eyes to their potential. Thank you both for taking the time to talk with us. It’s been great.
The post Edmond Lau and Jean Hsu on engineering more leaders and better working relationships appeared first on Inside Intercom.
There is something unique about the joy of being on a high-functioning, high-achieving team – and that goes as much for a sporting team as a professional one.
We borrow a lot of the words and concepts we use to describe our engineering teams from the world of sports – from huddles and scrums to sprints and even goals, the terminology resonates from the pitch to the office.
However, we rarely stop to think about the deeper parallels between the two spheres.
I play rugby where I’ve seen exactly what it takes to build up a team out of individuals – the preparation, the analysis, the commitment, the growth of camaraderie and trust between teammates. My time as an engineering manager at Intercom has reinforced for me the parallels between team sports and being part of a successful engineering team.
When you think of being part of a sports team, you instinctively think about the thrill of the match, the excitement of clashing with opponents in a competitive environment. But in reality, most of your time is spent practicing, preparing for the games ahead and analyzing the challenge posed by your rivals.
The preparation and analysis is critical to ensuring you build the best possible products
It’s all that unglamorous time on the training pitch that builds the sense of being a team, which culminates in those performances in competitive games.
That process has some parallels to the day-to-day routine in an engineering organization – the preparation and analysis is critical to ensuring you build the best possible products.
The incentives for me to join a rugby club and the joy I get from my engineering work are driven by the same things – a desire for continuous growth and learning, acting on meaningful feedback, being proud of my work and iterating towards success.
When at training, I put my heart and soul into every drill. I get up after every tackle determined to go harder, listen to any advice from coaches or teammates, and practice, practice, practice. The same goes at work, where I commit to taking on constructive feedback, always focusing on the goal, knowing where I need to improve, and yes, more practice, practice, practice.
One of the things about sport is the way it exposes weaknesses and highlights strengths – your legs can only run so fast, you can only kick so far, you can only tackle so hard, and that will all get found out on the pitch in the heat of a match.
It is that balance that helps us achieve more as a team than we could accomplish as individuals
This is where the dreaded imposter syndrome can become a real problem, especially when joining a new team. It can be a very vulnerable time – you don’t know the organization or your teammates well, you can feel like a drain on teammates because you are relying so heavily on their support, and your fear of failure is particularly acute as you feel the weight of fresh expectations.
But being part of team means building on our collective strengths to minimize our individual weaknesses, and great teammates will quickly see your strengths. It’s about achieving a balance between the different members of the unit. On the rugby field, I would love to be a speedy winger able to run an amazing line and score a try, but my legs just don’t have that speed. Instead, I can put all my effort into doing what I’m good at and enabling others to make those runs.
That sense of complementarity is also evident in the best engineering teams – we rely on each other for the skills we may not have so we can form a truly functional team. It is that balance that helps us achieve more as a team than we could accomplish as individuals.
That unique sense of collective achievement is what is so rewarding about being on a highly functioning team. Because not only can you achieve more as part of a team, there are some things you can only achieve as part of a team.
It’s often
easy to underappreciate just how special team spirit
can be
Central to all amazing teams is collaboration, trust and passion. This means a team will be able to grow together in the knowledge that everyone is trying their best, trying to help one another and putting their passion into everything the team is trying to achieve.
There’s no better time to see this team spirit than when a deadline is looming and the team pulls together, having frank and open conversations on struggles and potential strategies on next steps. This contributes to great decision making, team alignment and collaboration. The learning and support never ends, instead it adapts as the team grows and matures.
When we discuss team spirit, it’s often easy to underappreciate just how special it can be. Whether it’s on the pitch or in the office, being a part of a team gives you the feeling that you are contributing to something greater than the sum of its parts, that you are realizing your potential in ways that you couldn’t do alone. In sport and in work, achieving your goals may be the result, but it’s the journey that builds up to those goals that brings the ultimate satisfaction.
If you’re interested in joining the engineering team to help build Intercom, check out our current openings here 
The post Smells like team spirit – what sports and engineering teams have in common appeared first on Inside Intercom.
There is something unique about the joy of being on a high-functioning, high-achieving team – and that goes as much for a sporting team as a professional one.
We borrow a lot of the words and concepts we use to describe our engineering teams from the world of sports – from huddles and scrums to sprints and even goals, the terminology resonates from the pitch to the office.
However, we rarely stop to think about the deeper parallels between the two spheres.
I play rugby where I’ve seen exactly what it takes to build up a team out of individuals – the preparation, the analysis, the commitment, the growth of camaraderie and trust between teammates. My time as an engineering manager at Intercom has reinforced for me the parallels between team sports and being part of a successful engineering team.
When you think of being part of a sports team, you instinctively think about the thrill of the match, the excitement of clashing with opponents in a competitive environment. But in reality, most of your time is spent practicing, preparing for the games ahead and analyzing the challenge posed by your rivals.
The preparation and analysis is critical to ensuring you build the best possible products
It’s all that unglamorous time on the training pitch that builds the sense of being a team, which culminates in those performances in competitive games.
That process has some parallels to the day-to-day routine in an engineering organization – the preparation and analysis is critical to ensuring you build the best possible products.
The incentives for me to join a rugby club and the joy I get from my engineering work are driven by the same things – a desire for continuous growth and learning, acting on meaningful feedback, being proud of my work and iterating towards success.
When at training, I put my heart and soul into every drill. I get up after every tackle determined to go harder, listen to any advice from coaches or teammates, and practice, practice, practice. The same goes at work, where I commit to taking on constructive feedback, always focusing on the goal, knowing where I need to improve, and yes, more practice, practice, practice.
One of the things about sport is the way it exposes weaknesses and highlights strengths – your legs can only run so fast, you can only kick so far, you can only tackle so hard, and that will all get found out on the pitch in the heat of a match.
It is that balance that helps us achieve more as a team than we could accomplish as individuals
This is where the dreaded imposter syndrome can become a real problem, especially when joining a new team. It can be a very vulnerable time – you don’t know the organization or your teammates well, you can feel like a drain on teammates because you are relying so heavily on their support, and your fear of failure is particularly acute as you feel the weight of fresh expectations.
But being part of team means building on our collective strengths to minimize our individual weaknesses, and great teammates will quickly see your strengths. It’s about achieving a balance between the different members of the unit. On the rugby field, I would love to be a speedy winger able to run an amazing line and score a try, but my legs just don’t have that speed. Instead, I can put all my effort into doing what I’m good at and enabling others to make those runs.
That sense of complementarity is also evident in the best engineering teams – we rely on each other for the skills we may not have so we can form a truly functional team. It is that balance that helps us achieve more as a team than we could accomplish as individuals.
That unique sense of collective achievement is what is so rewarding about being on a highly functioning team. Because not only can you achieve more as part of a team, there are some things you can only achieve as part of a team.
It’s often
easy to underappreciate just how special team spirit
can be
Central to all amazing teams is collaboration, trust and passion. This means a team will be able to grow together in the knowledge that everyone is trying their best, trying to help one another and putting their passion into everything the team is trying to achieve.
There’s no better time to see this team spirit than when a deadline is looming and the team pulls together, having frank and open conversations on struggles and potential strategies on next steps. This contributes to great decision making, team alignment and collaboration. The learning and support never ends, instead it adapts as the team grows and matures.
When we discuss team spirit, it’s often easy to underappreciate just how special it can be. Whether it’s on the pitch or in the office, being a part of a team gives you the feeling that you are contributing to something greater than the sum of its parts, that you are realizing your potential in ways that you couldn’t do alone. In sport and in work, achieving your goals may be the result, but it’s the journey that builds up to those goals that brings the ultimate satisfaction.
If you’re interested in joining the engineering team to help build Intercom, check out our current openings here
The post Smells like team spirit – what sports and engineering teams have in common appeared first on Inside Intercom.