Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Building a Successful Remote Culture at Scale with Strong Ownership

Building a Successful Remote Culture at Scale with Strong Ownership



Sushma Nallapeta talks about instilling ownership through delegation & goal setting and differentiating between accountability & ownership. She shares strategies and her experience at Apartment List, and talks about how they built a career ladder rubric to encourage ownership, how they created room for creativity called A-Time that helped build trust across teams, and many more lessons learnt.


Sushma Nallapeta is VP of engineering at Apartment List. She is excited about building a culture where people are constantly learning and growing, implementing and scaling Agile processes across remote teams and all levels of the organization, driving diversity/inclusion initiatives & building products that solve people problems.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


Nallapeta: Before I get into the actual content, I want to start off by telling a story. This is a story of how I learned about ownership in my career for the first time, and it was through a situation of bankruptcy – not of my own, but of the company that I worked for.

Ownership Through Bankruptcy

I think you all are familiar with Kodak. I used to work for a startup that was acquired by Kodak, called Ofoto. It was renamed Kodak Gallery. They were into photo-based products, so we made photo mugs, photo books. In December of 2011, Kodak filed for bankruptcy. We read the news online and found out. It was a very shocking moment. We didn't know what was going to happen. Were there going to be layoffs? Will the company be sold to someone else? We had no idea. Kodak definitely made a lot of memories but not money.

I was four months into my job as a first-time manager and I kept asking myself, what did I get myself into? The leadership got into a closed-door meeting at Kodak Gallery. We are expecting the worst to come out. We think they're going to tell us so many people would be laid off and here is the timeframe in which we'll be laid off. They come out and they say something very astounding. They said, "We are going to launch a brand new product and we're gonna launch it in two months. It's going to be the photo magnets." At that time, none of the competitors had photo fridge magnets. They said, "You have all the autonomy and ownership. Go figure out how do you execute this and how you want to get this done."

We didn't know if this was good news, bad news. We had no idea. We just said, "Ok. Let's go with excitement. Let's go focus on this and execute this." Everyone from product design to engineering were busy figuring out how to get this out to production. We were thinking about, "Should we build a responsive site? How do we overlay the photo on the magnet?" We just went into a full-on execution mode. While the company Kodak was trying to shop us off and trying to sell us off for peanuts, there we were trying to make a decision about how to wrap a thin film around a photo on a magnet to protect the photo. It was an incredible journey and an exciting moment of my career.

We launched exactly on time, a couple of months later. It was a huge success among our customers. They loved it. There was an outpour of messages. They said, "This is the best product ever." If only we had survived, maybe we would have become a profitable company. A month later, we got the news that Kodak has sold us off to Shutterfly, and the company was going to shut down. We didn't feel sad. We had actually got on through such an incredible journey that we built a strong bond. We had a strong sense of purpose. We had autonomy and we were all self-motivated. This was my story of how I learned ownership. This definitely was my Kodak moment.

I am Sue Nallapeta. I'm currently head engineering at Apartment List. When I joined Apartment List, we were a team of 25 engineers. Now, we are about 45, double the team in about a year. I have worked at startups as well as large companies and across different domains. The most exciting domain that I worked at was my previous job in a dating industry.

Reflecting on my story of ownership, one of the key ingredients to achieving ownership is having a clear goal. What happens in startups is that the distance between employee – that's me – and the goal is very short. You can easily connect yourself to the goal. Whereas as the companies become bigger and bigger, the distance increases because there are a lot of people in between and these people need to communicate and trickled down these goals to the larger org. It's very hard in larger companies for everyone to be actually communicating a goal clearly. A lot of times we go into an all-hands and we have to repeat the same thing over and over, and the fifth or sixth time, you repeat it, it really resonates with people. Then, how do you actually bridge the gap to employees and the goal? I have a story.

Is Remote Hard?

I had a team member who worked with me for two years. Meet Sam. He grew from an individual contributor to a manager, and then a director. He and his team launched several successful products. They were known to be highly productive team. Sam always communicated the goals very clearly. Whenever I had one on ones with people on his team, they said, "There's nothing that I can not tell Sam that I can tell you." That was the culture that Sam had built.

What did he look like? He looked like that. Yes, he was a remote employee. He used to dial in through a beam robot. It's already hard enough to communicate clear goals than you're co-located. It's even more harder to become a successful bridge by being remote. Today, remote has become a necessity because we are in a highly competitive market. We are competing against the Fangs, we are competing against the Unicorns. We are competing against the next big cool thing. Not everybody, and not everything is considered cool.

Is remote hard? The good news is, it's only a 55% problem. What do I mean by it's a 55% problem? There's a famous psychology professor called Albert Mehrabian. He did a lot of research into what constitutes the perception of a person. He found that interestingly, 7% weight is given to the words that you use, 38% is given to the tone of your voice. How often haven't you been in a situation where someone appears fine when you have an in-person conversation but they appear rude on Slack or another platform? Tone of voice is important.

The biggest of them all, that carries the most weight is the body language. Body language carries 55% weight. It's one thing that does not exist in a remote setting because you only get to see a headshot of a person. How do you actually fix this problem? This is an engineering conference, and I'm an engineer. I love to talk about protocols. What better protocol than TCP? It only means trust, culture, and process. You need a combination of trust, you need to build the right culture, and you need to build a process that supports that culture to be able to succeed in scaling remote organizations.

Drake Equation

How do we build trust? It's very important to have a very clear goal and purpose, like my story at Kodak – we had a very strong purpose, and it was to launch a new product in two months. It's very important to communicate that goal and purpose. Then, it is very important to provide autonomy to people so they can execute on that goal. Let's talk about goal, and how we can articulate the goal, and how can we actually reduce the distance between goal and an employee.

Let's talk about Drake. Drake was an astronomer and an astrophysicist. He was very excited to work on identifying extraterrestrial lives outside of our galaxy, and also even within the Milky Way galaxy. Why am I telling you about aliens at an engineering conference? I have a reason. I took a general management course with Harrison Metal, and I found out that you can actually use this equation to articulate the goal clearly to the company. What Frank Drake did was he wanted to communicate the civilization to the other members at the city. He broke down and he found that this was a good way to start the discussion.

If I have to break down a Drake equation for my company at Kodak, I would break it down this way. What makes up the company's revenue? Number of new users times those who registered, times number of photos uploaded, etc. Having an equation at a large company level, and then the magic happens when you break it down into OKRs, objectives and key results for each part of this equation, and hand it off to each and every team at the company. This way, each and every team can relate to the larger vision and the larger equation, and understand what is the part that they play in making that equation come alive.

We did a similar exercise at Apartment List. We just launched our Drake equation. We are going to start using this in our quarterly planning moving forward to start planning out our goals. There is another problems that companies normally face. One, I think people don't know how to connect their work to the larger goal. Then also, it's important that people understand how the goals work with the rest of the teams in the org because when you increase one thing, you might actually be decreasing something else. How do you actually have that larger picture in your head and focus on executing your immediate goal? This technique definitely helps.


We talked about communication being a very important factor. It is. It's very important to get teams to not have emotional conflicts about personalities, and instead have decision or more decision-based conflicts – how I disagree with certain decision and I want to have a conversation about why. How do you get the teams to do that? One thing that we do at Apartment List is, as we started scaling and as we started adding more remote engineers, we started using this app called Donut. It is a Slack app. It connects to people every week or whatever setting you do. These two people either grab coffee or they get into a conference room and chat. This really helps because you need to connect with every individual on a personal level to be able to understand and make them be vulnerable.

The second thing is, the medium of communication is also very important. Some people love to communicate through visual representations, like on a board, like drawing big diagrams. Some people prefer words and explaining their architecture in the form of words. Some people are just feelers, they go with the gut feeling. These are the people who are huggers. How do you actually tailor your communication to resonate with different types of audiences is also very important as you start to think about building trust. One size does not fit all and you need to have a tailored approach to each of the type of people you have.


Next is the autonomy. How do you actually give people autonomy to execute towards the goal? One thing we did at Apartment List is, we have one day reserved for every two weeks, one day every sprint for engineers to work on an idea that they're really passionate about. It was somewhat similar to Google's 20% time but a little bit different. The rule is that the engineers have to work in groups, and the work that they do has to help the company in some form or another. This actually has been a huge success because you're letting engineers bring something to the table by giving them autonomy and saying, "This is your time. Go and build something and us, in product and design, we will support you to get that to production." We actually have shipped a couple of features to production with this approach. Some of them have even been metric movers, which has been great.

Trust is both a noun and a verb. Trust exists. I trust you. The more of the verb you do, the more of the noun you get.

Inclusive Environment

Next, how do we build culture? I think the key part of building a culture is to build a very inclusive environment. What does inclusive environment even mean? I used to work for a company that did payments and gift cards, and we had a remote team across a 12-hour time zone difference. I had three engineers here and I had four engineers in India. I wanted to operate this team as one single Scrum team. I brought the whole team together. We started discussing what the goals for the team are going to be, who's going to be the product manager or the product owner, and what are the different roles each team is expected to provide.

Then we got into the discussion of how can we actually organize our meetings that needs to happen. We were using Scrum. What the team did is, they discussed and they decided if they have meetings either early morning or late evening, it's inconvenient for both parties, and you cannot have those meetings in between the day because it's just off hours. They decided to compromise. They said, "Two days a week, the U.S. team will have stand-ups at 7:00 AM, so in morning and two days a week the team will have standups in the evening." We did the same thing with grooming. We said, one day every sprint we will have groomings in the mornings and in the next sprint we'll have grooming in the evening. This way we split out the meetings and there was a balance of power. This really helped get everybody's voice heard and then also made people feel that they're on an equal plane and equal ground.

This was a very high performing team. I worked with this team for about two years, and they really developed the respect for one another. It's not enough to just talk about building an inclusive environment here, to find creative ways on how can you get people voice their opinions, voice their ideas, and what forum as leaders are we creating to make that happen.

Career Growth

Let's talk about career growth. This is a topic that's very close to my heart because I don't believe in performance reviews because it feels like a reflection in the past. I do believe that we need to be professionally developing people and be looking ahead. At Apartment List, when we started thinking about developing a career ladder, one thing we decided was that it's very important for a ladder to match our values and what we want from people. We were no longer a engineering team of 25. We were going to be doubling and the way we operate today was not going to be enough.

We came up with this funnel approach. Think of it like a marketing funnel, where you have more audience on the top and then the conversion is lower at the bottom. When engineers are early in their career, they focus on mastery. They're focusing on mastering a particular technology, particular code base, or even a product feature. As they become more seasoned, they start to focus on ownership, either ownership of a codebase, ownership of a feature. It could be executing on a feature end to end collaborating with product. As they become even more senior engineers, they should not only focus on their work but also that of the team, and ensure it's the team success so they move towards leadership. Leadership is a very important aspect even among individual contributors because there is so much that you can do and you have a lot of power in your hands. We focus on things like mentoring other engineers. Also feedback is a very important key aspect, you need to be able to see feedback at this level and even provide feedback. It's not just the responsibility of the manager. Then we move towards impact. You create an impact not just at the team level or the company level, but also across the whole company interfacing with all the other teams.

This split up our career ladder into these levels. We have six levels. Two levels focus on each of these different parts of the funnel. If you can see the colors at each level, they're always trying to either touch upon the next level or master it. Having this approach really helped us because, one, the engineers were super excited. Two, it defined something that goes beyond just your technical skills. It talks about soft skills and what's important at each of the levels. We also define anti-patterns, what not to do at each level, not getting your code reviewed and not taking feedback from code reviews is a big no-no at SE1 level. Whereas, a senior engineer, you should be able to build consensus across the team, whether if it's an architecture decision or a very complex technical problem.


Recognition is a very key important aspect as well. There are a lot of companies tackling the problem of recognition. There are companies that are just built around incentivizing employees to recognize one another. I used to actually work for a company that did that, where you hand out points. Every employee is given a set of points and then you just hand it out to people that you really enjoy working with.

One other thing that we did at Apartment List is, our Scrum teams do something called [inaudible 00:20:07]. In the team retrospective, every sprint, they take five minutes to recognize each other for the work that they did. Recently one of the engineers said, "I'm going to [inaudible 00:20:20] Aden because he was very helpful to me in getting this feature completed and he helped me do the good code reviews on time." It's very important at every step of the way to recognize people for the work that they do and you're building their career along the way as opposed to the reflecting in the past.

It's even more important to sit down and have a conversation with employees as they're developing and say, "These are the things that you're doing that are really great and I want you to get to this level. These are some more things that I want you to do and I can help you get there. I'm going to put you in this position so you have more visibility to prove what you can do at each level."


Next, how do we build process? I think, as you start to build remote teams, it's very important that you look at a strategy across the board in terms of your hiring, in terms of your architecture, and your dependencies. We had to tailor our hiring process to match the needs of a remote team. Not everyone can work remotely. Not everyone is good at expressing themselves and expressing their ideas when there is not a lot of feedback loop. You need people who are very self-motivated. You need people who can actually be ok with silence on the other end and take that initiative for the first time.

Our hiring process included bringing all these candidates to different Slack channels with a group of engineers, and we would give them an assignment, and basically tell them, "Go ahead and execute this, and you can ask whatever questions you have. You can ask all these engineers on the channel." When we started this process, we didn't get any questions because people were just quiet and awkward. They didn't know what to do. We were questioning ourselves, "Is this process even going to work? Are we like looking for the right things?" Then they started finding people who had a lot of questions, who really collaborated with engineers, who started having architectural discussions among engineers. That proved that we really need to hire people who can really work remotely well and that's very hard to find.

We also did another thing in our architecture interviews. We told people, "You'll be tested on architecture. You can decide what medium you use to communicate your architectural decisions and choices." Some people wrote it on a piece of paper and held it up to the camera. Some people just used words and described it really well. People actually brought up the camera to a whiteboard that they had and then they started drawing on it. There are different ways of doing this. No one's way is better than the other, but you need to find people who can engage on their own.


The second thing is about architecture. Imagine having a monolith and having a distributed team across the globe, and expecting them to deliver on that monolith. It's going to be a nightmare. We need to evolve our architecture as our team structure changes as well because you need to make people successful. The way that you can make people successful is like providing them with ownership and autonomy. That's not going to work if you don't have a scalable architecture to support it. That's another key aspect.


Then managing dependencies. When I joined the company, we were functionally operating teams. We had a web team, we had a native team, we had an API team because that is what was needed at that stage of the company, because we were just building out these platforms from scratch. As we started growing, we really needed to structure ourselves in the form of cross-functional teams. We started structuring into product-based teams. Now, that's not enough either because we are working on a lot more strategic initiatives and going after new areas of business. Now, we are moving towards mission-driven teams. I think the point there is, the team structure will evolve as the company evolves. You implement the process, don't get stuck to it. Just know that you have to change it in six months or one year. I think knowing to reset yourself constantly will really help guide your progression.

I get a lot of questions about, do you go remote-friendly? Do you go remote first? What culture works best? Just for everyone in the room, remote only is where all your employees are distributed. There is no headquarters and you just all operate in that fashion. Remote first is, you could have employees in headquarters and you might have some remote engineers, but you operate with the mindset that it doesn't matter where I am, but I'm going to use the same processes as I would when I'm remote. Then remote-friendly is, you primarily work out of headquarters. You start adding few engineers or a few employees, and then you start to figure out how to bring them in and include them into your process.

Definitely, there's an argument that remote-first is a better culture than remote-friendly, but here's a food for thought. If you just had two employees who are remote, do you actually want to go through and implement a whole bunch of processes to accommodate two people? Is there another way to actually build the right level of processes for the team that they're part of so that they can feel included?

According to me, this is a cycle because companies keep changing and evolving, there could be an MNA that happens. We could be merging with another company and acquiring a new line of business. We might be actually just creating a new office. It doesn't matter what it is, it's a vicious cycle where you will end up in one of these scenarios, at some point of the life cycle of the company. You just have to remember to always reset and adapt to the new processes Trust, culture, and process will guide you through that journey.

I was reading a book by Annie Duke called "Thinking in bets." One of the things that she talks about is that facts are not final, facts evolve over a period of time. If I asked my 91-year-old grandmother six years ago how many planets there were in the solar system, she would say nine. Now, if I asked the same question to my four-year-old, she'll say eight. Both of them are not wrong. It's just important to know that the facts will change over a period of time. Then, if facts themselves can change, why can't companies change? Why can't people and their mindset change when needed?

Facts evolve overtime, problems change over time. We have to remember to reset often and reset our mindset. Otherwise, we will not be able to scale to the level of the company. In my going back and finishing thoughts about my first story about ownership, ownership is about taking an initiative and also seeing it through. It's very important to be that initiator. I think a lot of people are ICs and managers in this room. Some of you are on the initiator side and some of you are on the executor side. Regardless of where you are, you need to figure out, "I need goals. I need a purpose. I need autonomy." Those will bring self-motivation. That's how I can operate.

Questions and Answers

Participant 1: I wanted to emphasize the recognition part that you mentioned. For example, one team is in headquarters and of the others are the remote. Fom my experience, it's a challenge for remote teams to have access, because most of top managers, senior engineers are in their headquarters. For the people in the remote section, it's harder to access them and it's going to be harder for them to be promoted or to get more challenging projects. In the headquarters, they can meet over the coffee or something, they can talk. Then they have easy access to the top managers and senior engineers. How you can actually mitigate this issue or, is there a way to actually handle these kinds of scenarios?

Nallapeta: When you have people who are in headquarters and remote, I think us as managers, it's our responsibility to make sure that you create the right team structure for people to function really well. You mentioned, how do we even recognize people who are remote? What if there is a conversation that happens by the water cooler that ends up resulting in a project? That happens more often than you think. You have to expect it to happen, and figure out what's the best way that you can push other people towards those opportunities.

One thing that I have done that has worked out for me is, when these water cooler conversations happen, and if someone's suggesting, "Can I get this engineer to work on this? This person did a great job and I really want this person to work on my next project," I sometimes question back and I say "Tell me what outcome you want and tell me what the goal of the project is and what type of seniority do you need, and I will figure out who will be on as part of your team." I think you need to actually figure out how to push your team towards opportunities because opportunities will not push themselves towards your team.

You'll have to find a way to blend your team into the process. It's afterthought a lot of times people are not in the visibility, they're not visible because they are remote and then they become an afterthought for a lot of people. You just have to find a way to engage them. We use Slack. One of the ways that we do is, constantly we have a shout outs channel so we give shout outs to people who did something. We are always giving shout outs to someone for something incredible that they did. They're always on people's mind that, "This person actually did a great job, so I maybe I want to talk to this person on how to do this." Once you start doing that, you will shift the culture to actually start thinking about remote employees as well.

Participant 2: This is a question about the other side of that spectrum. At the beginning of the talk, you mentioned Sam, who was able to rise from the IC to the director and a couple of years. Are there specific strategies that were effective for Sam, especially as a manager and a director to work remotely, and be effective?

Nallapeta: In that situation, Sam was the only manager in the company who worked remotely. There was one other engineer who was remote, but we only had two people who were remote. Some of the things that Sam did go back to my three techniques in the protocol trust, culture, and process. He did it in a way that was very implicit. He would actually call people, use 15 minutes of his time and call one member of his team every day of the week, just to get to know them and figure out what are some of the struggles that they have, just to establish that relationship. Every day, maybe during commute time or in the evening when they have some time, he would always try to establish that relationship. That was one thing that he did.

The second thing he also did was any communication from leadership, he always found a way to translate that back to his team. If there were things that were sensitive, he would ask the leaders, "I want to be able to communicate this in some form or another to my team because they need to know and they need to be prepared for it as well. How can you enable me as a leader to communicate this?" Then people actually start asking those questions and try to push for transparency. You will really start thinking about, "How can we be more transparent across the board?" That was another thing that he was really good at doing, taking what he heard from the top and translating it all the way to the bottom. I think that goes back to the example that I gave. Anytime I had a skip level one-on-one with the members of his team, the response I always got was, "There's nothing I have to tell you that I can't already discuss with Sam." I think that's a validation for his capabilities to provide that forum.

Participant 3: We had a team where we only have one remote. Any guidelines on knowing whether that team member wasn't cut out for working remote versus that our team wasn't helping him out or accepting him? Do you have any strategies for drawing that line?

Nallapeta: Let me repeat your question. Is your question, one person was remote and the rest of the team was co-located, how did they include that one person to be part of the team?

Participant 2: More like it didn't end up working out and he went away. I'm wondering whether it was us that we didn't help him. He just didn't seem to kind of go out and grab our attention. Then again, we didn't go out of our way to include him either. Any strategies to know where that line is, either it's not this person's cut out for it or it's the team's deficit.

Nallapeta: I think it's a bit of both. I think the person can only reach out and connect to what the person can see and witness. If there is a Slack conversation, there's an email, then the person at least knows this is happening and can engage. Otherwise, it is the team's responsibility to engage that person. It's even more important for the manager to make that person be included. Let's say the team decides they want to start talking about some architecture problem. They just go into a room and then start whiteboarding. The first thing that they think of is saying, "Sam is remote and I need to include him in this discussion." They reel him in into the conversation because otherwise, nobody will know what will happen if that conversation even happened. Now, if it does occur people might just turn to each other and have a conversation, we need to have a process where people document decisions somewhere so the larger team can see it. I think this goes back to building the right kind of documentation, at least trickling information the right way to people. It could be even in your demos, sprint demos that you talk about certain decisions that were made during the sprint, even architecture, product decisions. At least the whole team come


See more presentations with transcripts


Recorded at:

Jan 22, 2020