Talking about Co-Living with Adam Gotterer

Adam Gotterer is the CTO at Common where he is helping to build a tech-enabled property manager. He has been responsible for scaling the engineering teams at many companies during their early stages.

Here is a transcript of the interview with him, edited for brevity.

Can you please introduce yourself to our readers

I'm Adam Gotterer, I started writing software when I was about 13 years old. I initially wanted to be a product manager, but it turns out nobody would hire me because of my experiences in programming. Back when I entered the industry everyone needed programmers (I guess little has changed), so that's what they sort of forced me to do.

My first job was as a consultant at a large cable and internet provider. It felt like a scene straight out of office space. Slow, political, and about as close as I ever wanted to get to creating TPS reports. I didn't last very long there. I ultimately said if I'm going to continue in this industry, I have to work somewhere fun.

I landed a job at CollegeHumor, which was probably the most fun I've ever had. Arguably, I had more fun there than I did in college. I joined as a software engineer and after two years I was promoted to Director of Backend Engineering and managed a team for the first time. My team was responsible for iterating and developing the backend of CollegeHumor.com, Bustedtees.com, TodaysBIGThing.com, Dorkly.com and SportsPickle.com. That was a great experience, a lot of fun, and I learned a lot about management and leadership.

After CollegeHumor I joined an early stage seed startup called Lot18 as their first technical hire and the third employee. Lot18 was trying to revolutionize the way people bought wine online. We launched our MVP with 6 employees around 4 months after I joined. Over the next 5 months we grew to over 35 employees. Over the following twelve months we raised an A, B, and C round, moved through 3 different offices, and grew to around 130 employees. I grew the engineering team from 0 to 15 engineers. The speed growth we experienced in both revenue and employees was wild. One lesson that sticks out to me, even today, was learning about the importance and challenge of scaling culture that fast. When the average tenure is measured in weeks to months, it’s likely the person sitting next to you also isn’t familiar with the culture.

During that time, I also learned a lot about the business and technical side of e-commerce and the challenges of dealing with data. One of the things that I kept seeing was that our business folks had a lot of questions about our data. So I left Lot18 to start a company called Shopalytic to try and scratch that itch. The idea was to see if we could create a solution that made e-commerce data more accessible to nontechnical people. I partnered up with a longtime friend / Lot18 co-worker. We built a BI engine that could take semi-structured questions and turn them into structured queries. It wasn't really free form, as this was a while ago, and there wasn’t as much open and shared knowledge around NLP or data science as there is today. Through a really clever UI we allowed users to use a series of contextual dropdowns to build out a question like, "Tell me about everybody who bought this product, used this coupon, and previously ordered 3 times in the last 12 months". We would take that question and determine the most relevant insights to share from the data. We bootstrapped the company and did everything we could to control burn and follow “startup best practices”. For example we went off and talked to customers before we wrote a line of code and received a lot of encouraging and helpful feedback. Then we went off to build our MVP. It turns out building the MVP for BI platform from scratch is hard. It took a few iterations and feedback cycles before we felt like we were heading in the right direction. By that time, we were pretty much out of money, and we were kind of tired. We started to shop around our assets in hopes of being acquired. While we weren’t able to find a buyer for the company, we did receive several compelling offers of employment, which we accepted. While we were winding down the company, we were introduced to a company that ended up buying all of our assets. It was a soft landing that helped cover some of what we invested in the company.

The company I ended up joining was called Nomi. They were essentially building Google Analytics for physical spaces. We manufactured and deployed beacons, cameras, and sensors around retail establishments. Our customers were big box retailers, shopping malls, supermarkets, and specialty retail. We provided retailers analytics and insights about in-store activity and performance. Such as how many people came into the store, how long they stayed, the path they took to walk around the store, and how often they came back to that store or a store in the chain. We overlaid the data we aggregated with cash registers and employee timesheets to determine things like conversion rate and the cost to service a customer. Next time you walk into a store look up above the door and see if there’s a camera pointing straight down at the door. That’s likely Nomi or one of its competitors. This was some of the coolest tech I had a chance to work on. It was a developers dream; big data, hardware, scaling challenges, and hard technical problems. I was initially hired as a Director of Engineering to oversee one of the three engineering teams. A month after I joined they asked me to be the CTO and to take over the whole engineering team.  

After Nomi, I joined Knotch as the eighth employee and their second CTO. We were in the business of helping marketers measure and better understand their branded content marketing efforts. If you’ve ever seen an article on a publishers site that says, “Paid for by '' or “Sponsored by”, that’s branded content. Turns out there’s a whole industry built around measuring things like banner ads, email marketing, search marketing, etc. But millions of dollars were blindly being spent on sponsored content without any understanding of performance. Knotch partnered with all the big publishers and became an independent measurement company to collect data about sponsored content. We built an analytics and insight engine that we sold to large brands.

I was having a lot of fun at Knotch and the business was doing well, but I had grown a little fatigued of the data and analytics space after all of those years. I had an opportunity to join a larger and more mature startup in an industry which is heavily regulated and relatively untouched by technology. It's been a year and a half since I joined Common as their CTO. Common is a residential brand and operator that designs, leases, and manages multifamily properties. We are working on solutions to the shortage and affordability of housing in urban environments though smart design and tech-enabled operations. We are most well-known for our co-living apartments. Common has been growing incredibly quickly. Over the last year we’ve doubled from 100 to 200 employees and our real estate pipeline includes over 14,000 signed beds that will open across 14 new markets. The business and technical challenges are really fascinating and I’ve enjoyed building out our product and engineering teams.

Multiple times you started at companies and had to ramp the engineering teams immediately. How were you able to do this & what was the secret behind the success?

There was no secret to that. It's a grind, honestly.

I think having a well defined hiring process plays a vital role. We've done an excellent job hiring here at Common. One key ingredient is having a strong pipeline of candidates. I work with a couple of recruiters I like and trust, and they help to fill the pipeline. We also do some of our own direct outreach and work with companies like BuiltInNYC to help with industry exposure. What makes everything run smoothly is our well-defined interview process. We’ve built out a rubric for every one of our interview sessions. We train our team on how to run those interview sessions, and have done everything we can to remove biases from the process and have a solid baseline against.

Our interview process has a track for every open role type, for example we have one for frontend engineers and another one for backend engineers, overall they're very similar. In all cases we start with a 45 minute phone screen with me or one of my hiring managers. For some reason tech interviewing has become a sort of interrogation of the candidate and feels very one-sided. In reality it's a two-sided interview. They're interviewing us to see if they want to work here and I’m interviewing them to determine whether I want them  to work here. I actually spend the first half of the conversation pitching them our mission and vision, which can be dangerous and expensive. Most people don't do that. A lot of companies jump right into the interrogation so that they can get off the phone quickly if the candidate isn’t the right fit. In my case if they're not the right candidate, there is no good way off the phone because I've already invested a lot of time into the call. I do this because I want to get them excited about what we're doing here, and I want them to tailor their story to what they know about my business and needs. I can’t tell you how many people have thanked me for giving them the full pitch up front, or how many people end up being even more excited than they initially were.

If they pass the phone screen, we follow up within 24 hours to schedule a technical phone screen. You need to move fast because the best candidates are in demand. Depending on the interview track, candidates will either have a 1-hour technical phone screen or a choice of the phone screen or a 4-hour take-home project. We offer a choice so that candidates have the chance to interview the way they feel most comfortable. Some people just don’t perform well in a live shared coderpad which isn’t their standard development environment. We also don't ask any algorithm questions in our interview processes. That's not something we believe is a strong indicator of a good programmer. We care more about strong fundamentals, being able to break down requirements, debug issues, iterate through a solution, and communicate intentions. For all of our interview tracks it’s always the same questions.

We have developed a rubric for all of these interview sessions. One axis is the levels of our career ladder and the other axis are the skills / traits we are evaluating. The intersection contains the expectations of that skill at the specified level. The rubrics helps us determine what to expect from the candidate and to slot potential hires into the appropriate title and compensation range based on their performance during the interview.

If they pass the technical interview, we invite candidates to come onsite. Our interview process includes session for architecture and design, culture and values, and a pair programming session. The architecture session is focused on architecting and designing a solution around some requirements we provide. For the backend that includes using the whiteboard to design an API, database schema, and defining how it all ties together. For the frontend its more about defining the screens, the UI/UX, and how it will create and consume data from an API. Our culture session is the same for everyone and is part behavioral and part values alignment. We ask every candidate to teach us something technical for 5 minutes. We ask that they don’t come with any slide and are merely prepared to talk about the topic and answer questions. Knowledge sharing and mentoring is important to us, so teaching something helps to demonstrate that skill. The pair programming session is our longest session, its scheduled for two hours. Similar to the technical phone interview we want to see how candidates break down requirements, debug a problem, iterate through a solution, and communicate intentions. Candidates do this on their own laptop in whatever environment they feel comfortable in. They are allowed to use Google. We also don’t hover over their shoulder and instead have them share their screen with us and we watch from across the table. Our in person sessions are done in pairs, so in this case one of us act as the PM and the other as a pairing partner. We both end up asking questions and steering the problem. But the whole session is generally meant to be pretty collaborative. Our whole interview takes about 5.5 hours. It’s a long day, so halfway through the day we take them out for lunch. It gives the candidate a break and a chance to get to know the team. It’s also a more social extension of the culture interview.

Interviewing shouldn’t be treated as an integration. Too many people go in with the mindset of trying to stump the candidate and that a candidate should prove that they deserve to be there. We go in with the mindset of trying to make them successful. We want them to pass so that we can hire them. That’s why we don’t ask quiz-bang questions, expect them to remember some arcane method definition, or some philosophical idea from the comp sci class they took 10 years ago. Even when an interview isn’t going well and it’s clear that they likely won’t be a fit, we try to guide them through the problem so that they have a good interview experience and maybe walk away learning something.

Something I do with my hiring managers from time to time is re-review resumes of people who get cut at the phone screen or tech screen stage. We use this as an opportunity to re-calibrate, ensure that we are getting the right people into the hiring pipeline, and identify any lessons if there are any.

What are the qualities that one should possess to be a great engineering leader?

Empathy is one, being empathetic not only for your users but also for your team and co-workers. We do something interesting at Common which I've never done at any other company. Every week we have a meeting that we call "team catch up". We start with 2 minutes of silent reflection / retrospection. Then we go around in a circle and everyone has 90 seconds to say whatever they want. It can be personal or professional. During that time no one is allowed to comment or react. Everyone is just quiet, with the occasional chuckle or head nod where appropriate. People share all kinds of stuff, sometimes it’s deeply personal like an issue with family and other times it’s about their weekend adventures. It’s their time and they can get whatever they want off their chest. Attending the session is optional and participation is optional as well. What I've taken away from this ritual as a leader is a reminder that people also have a life outside of work. At times the boundaries of work and life crossover and impact each other. You have to remember that these people are human and that they're not machines. Sometimes they are going to do amazing work and other times things are going to be down and out because they have something going on in their personal life. Be empathetic.

Another quality great leaders have is the ability to inspire. You have to be able to get people excited about a vision and mission. If you can't pitch a compelling vision or sell a meaningful mission, no one's going to follow you into the depths and hell to execute against it. You’ll also need that skill to get buy-in from other departments or to sell prospective hires, business partners, or investors.

One of our core values at Common is being transparent. When I interview a candidate, I try to be as honest as I can about what it will be like to work here. When I ask a candidate, "what are you looking to do next?", and they say, "I want to work on big data or massive scaling problems affecting millions of people." I'll just be honest without any spin and just tell them, "we don't have those problems. But here are the interesting problems that we are trying to solve in this massive and complex space. I'd hate for you to come here and work under false pretenses and end up working on things that you didn't expect to work on." So being honest and upfront might save you some churn or unhappy employees sometime down the line.

We truly care about developing people's careers. It’s important to employees and it’s important for our company’s growth. Caring about that growth is a crucial part of being a manager. In addition to weekly one on one’s, my managers do a monthly check-in with each employee to benchmark their growth against our career ladder and to set expectations or areas for improvement. The career ladder isn’t designed to be a checklist. We don’t just go down the list and say check, check, check, congrats here’s a promotion. The ladder is more of a guiding framework for what is expected from an employee at each level. The actual promotion is still subjective. We expect people to already be performing at the new role before they are promoted to it. The actual promotion just commiserates what has already been achieved.

I generally try to keep my managers out of the engineering critical path. If you're running a small team of 2-3 engineers, then I think it's okay to be hands-on. But there's certainly a point where you should not be hands-on, and your focus should shift to people management, removing roadblocks for the team, hiring, aligning people, project managing, and all the other stuff managers should be

responsible for. Being a manager is hard and it’s different than software engineering. It’s really hard to do both well at the same time.

I try to build teams that can be autonomous and be given a project or task that they can go off and execute on without management being a bottleneck. We avoid micromanagement by asking the team to be proactive about bubbling up information to the appropriate people at the appropriate time. When we interview people, we screen for things like their ability to communicate, lead, and be self-motivated. For each major project or initiative we spin up and down a new team. We don’t have tech leads and have found that if you put a bunch of smart and motivated people together and provide them the autonomy and resources to execute that they will figure out the best way forward. We’ve seen people with different skills, experience, and backgrounds step up to lead where appropriate. This has also resulted in high quality collaboration / teamwork and an increased sense of ownership and pride.

During my one-on-one’s I try to focus on career development and talking about whatever the employee wants to talk about. I consider this time to be the employees time, so I ask them to come prepared with some topics to discuss. I do skip level one-on-one’s once a month with anyone who doesn’t report directly to me. Our company uses Lattice for status updates so that we don’t need to talk about status in a one-on-one. We talk about project status from time to time, but I try to encourage people to communicate status outside our one-on-ones and only raise project discussion because they want to talk about it, not because I asked about it. I'm more interested in using the time answering questions about the business / vision, removing blockers, or providing thought partnership.

One thing that I've done that I really like, and which has been adopted by managers across the organization is this idea of a Managers README. I learned about it on Rand Leadership Slack, which is a great network of technical and product leaders. My Managers README is public and available on my Github. I share it with all new hires on their first day. It’s meant to be a jump start guide to how I think, how I work, and some of my expectations and philosophies. It includes things like the hours I work, my communication style, some of my quirks, and a little about my life outside work. It’s not meant to be a replacement for actually getting to know someone. I’ve received good feedback on the README and I try to revisit and update it every few months as my principles and philosophies evolve and change.

How do you see Co-Living in the next five years?

For the last 50 or so years the cost of housing has been outpacing the growth of household income. This is playing a critical part in the shortage of houses and is making it unaffordable and inaccessible for people to live in major urban cities. Common is working on creating solutions to this problem.

Co-living is not a well-known term yet. We hope to help spread the word and help define what co-living is. Over the next five years, I think you'll see new constructions that are tailored to co-living and some case studies that demonstrate why co-living is a good investment for developers and why the offering is good for tenants.

One of the keys to success is that we’ve invested heavily in building technology for operating our buildings and business. Over time we expect other operators will notice that we are leveraging technology to operate buildings more efficiently and will start to invest in technology of their own.

Co-living isn’t going anywhere, it’s a growing asset class that is starting to get a lot of attention. There’s significant activity and money moving in the space.

What is Common doing to change the Co-Living space?

Common didn’t invent roommates, we just tried to simplify it and make the experience better. We provide people an opportunity to be able to rent a place they can afford, is well designed, and offers flexibility. Common provides flexible lease terms from 3-12+ months and the ability to transfer to other Common buildings. For example, you can live in a Common building in New York and then decide to move to a different Common building in California. Assuming we have availability, we’ll let you transfer to that building.

Common is a tech enabled property manager and we operate all of our buildings in-house. We are focused on improving the tenant experience and operating buildings more efficiently than the real estate industry has historically done so.

Our goal is to build one of the largest residential brands in the world. In the same way that when you travel you know the reputation and what to expect at a major hotel chain, we want to do that in residential. When you are moving to a city for the first time or moving within a city Common will be a destination you go to find your next home.

What are your current challenges at Common?

My team is trying to keep up with the pace of growth we are currently experiencing. Today we have 200 employees, of which about 12 are engineers. I inherited this department and have hired nearly everyone on the current team. We are playing a little bit of catch up to the rest of the company’s growth. The business is growing really fast, and our company has a deep real estate pipeline. Today we manage about 1,500 beds and we will end the year with 6,500 beds, and have over 14,000 beds in our signed deal pipeline. That number will continue to grow as we close new deals.

I like to joke that we are 5% of the way through the tech that we need to build. I don’t know what the actual percentage is, but the point is that we still have a lot of work to do to fully realize the vision and be able to operate this business at scale we intend to grow to. That's what I spend a lot of my brain cycles thinking about.

---