This week, the Range team was in attendance at Plato’s 2019 Elevate Summit, a 1-day summit for engineering and product leaders held here in San Francisco. We joined a number of great sponsors in the booth area—we got new shirts for the occasion—we hosted two interactive workshops, and I even managed to find a bit of time to attend the morning sessions.
I learned a lot during each of the keynotes and discussion panels, and I wanted to capture and share some of those learnings with anyone who wasn’t able to attend. So, here are some of the key takeaways I gleaned from this morning at Elevate.
1. The most common challenges facing engineering and product leaders today
Opening remarks by Plato CEO Quang Hoang
The backstory on Plato
Just after receiving funding to develop a product on expense reports, Plato lost three engineers on the same day. Why? Because of their managers. People don’t leave their companies. People leave their managers.
We were crappy managers. We did everything wrong. We didn’t do 1:1s. We didn’t have an explicit mission. We were micromanaging.”
Plato wasn’t functioning like a team, they had no plan, and they felt completely lost. And at this point the advice they received was to hire a bunch of people.
They were about to go down that road, but then they realized that they didn’t care about expense reports. They wanted to create the future, but more importantly they wanted to build a future that they cared about. They wanted to solve their own problem—and one many other people struggle with—and become better leaders.
A framework for finding the best advice for you
These 5 pillars will help you find advice that will change your life.
- Find the advice from a person you trust — For them, it was Michael Seibel from Twitch.
- Seek advice for decisions that have high leverage — Do not seek advice for every single decision.
- Get actionable advice — Following advice should have a concrete set of actions.
- Advice must be timely — If you have to wait 4 weeks, you might have to make a decision by then.
- Own the advice — The advice we received was to find something we cared about. We had to own that, and figure out what we cared about. And that’s Plato.
2. Ways to manage during growth and change
Keynote from Reddit CTO Chris Slowe
Surviving rapid growth
Chris was the first employee at Reddit. Reddit was that rare, beautiful product market fit that allowed growth to double every 3 months. The first couple of years it was just about keeping the wheels on and managing that growth.
Employee team growth changed dramatically. For a long time it was just 5 engineers; they didn’t have any product managers or designers at first. And they were constantly fighting fires. 🔥 The mission was very clear: just keep the site running!
Now the company has over 500 employees. One of the first challenges was to clearly define the difference in role between the VP of Engineering and the CTO. Both jobs are about people.
As a manager, think of yourself as a meta-engineer.
The T in CTO stands for “Therapy,” which is something I spend most of my time on.
Shaping values
As you set up processes that are consistent, you will affect the way that things are done, and that leads to changes in the company culture. Any process you put in place will be imperfect, and you will need to iterate.
The purpose of management is that you’re connectors, and cutting down the number of hops.
Values are incredibly important. Just like software is a living document, values should also be a living document. And values fit in three classes:
- Implicit values — You don’t have to say them. Example: “We don’t steal.”
- Explicit values that are immutable — Tied to your mission. Example: “Remember the human.”
- Explicit values that will change — More about execution. Example: “Everyone does the dishes.”
One of Reddit’s values is “Fail fast and iterate,” which many people misunderstand. It’s not that you want a bad solution, but that you when you aim for the 80% solution, the last 20% is probably another 80% to get done.
Practice “MVP” (minimum viable process). Find the simplest process that will solve the problem and move you forward.
No one is really an individual contributor (IC) after a certain part in your career. At the staff level, you have to work with people.
Meetings are very very expensive. So be sure to clearly state the purpose of the meeting you’re having. As a manager, it’s helpful for you to stay informed, but be aware of the communication tax you’re putting on your team.
Values are about investment. They need to be broadcast, which is why they should be covered in all-hands meetings.
3. How to build teams and cultivate leaders
Panel with Stitch Fix CTO Cathy Polinsky and Zume CTO Chris Satchell
One journey on the road to becoming a CTO
Cathy started programming early, with LOGO on the Apple II. She was interested in computers, but had no idea what a career in engineering would be. Her first job was doing UNIX system administration, and then she moved into software engineering. After many jumps, she ended up in leadership and executive roles and is now the CTO of Stitch Fix.
Different types of CTOs
There’s aspects to being a CTO that have changed over the last decade. There’s an idea that the CTO should be the most technical person on the team. But there’s another idea that the CTO is the person you send out to do all your sales calls. It’s a more outward-facing role, in enterprises.
How to get smart on customer needs
[As leaders,] we don’t deliver code, we deliver value.
Chris shared that as a leader you have to understand the customer deeply and own the journey you’re delivering to that customer. You can’t delegate that. In the end, as a CTO you need to understand that. Design and product and engineering are so intertwined. He thinks of it as a continuum.
You need to mix product, engineering, and design.
There are a lot of ways to approach learning about your customers. You can read about your industry, talk to your customers, and listen to your business partners. Don’t get distracted by what you feel they need today. Think about where they’re going to be tomorrow.
How engineering relates to other departments
Per Chris, for CTOs, you’re expected to understand the worlds of the rest of the executive team. But they will often not reciprocate. They may not be interested in the details of how engineering is done. And that means it’s easy to fall into being treated as vendor, which is dangerous. It’s more work to understand the whole company, but it’s thrilling to be involved in everything.
On hyper-growth and prioritizing diversity
Stitch Fix has a very diverse leadership team and board. They’re developing a service that can benefit everyone around the world. And they realized that they needed to build a diverse team in order to do that—benefit everyone.
They spent a lot of time making sure candidates for specific roles and similar levels of experience, and a level playing field in the interview process. And they didn’t have any quotas.
Cathy believes that referrals are good because they help you pull in your network. But if you do all of your hiring based on your referral network, you’re only going to get more people that look like the people already in the room.
Stitch Fix also spent time talking about their values publicly. That improved the diversity of the people applying to roles and helped the organization understand why diversity is important. When you have a team that’s not diverse, you make silly mistakes. For example, the Facebook feed issue where the year in review shows relatives that may have passed away.
Building and managing remote teams
Zume started in the south bay. They would talk to a lot of engineers, but they lost them because of the commute. Eventually, they realized they needed to be in San Francisco. (They already had a Seattle office at the time.)
What you find is that really good people don’t have to move. So you better go where they are. And you have to be prepared to work on a distributed environment.
You have to ask, how much do you want a feeling of one team across the whole company? Or are you okay with diversity in how teams operate? And the same thing happens with the engineering architecture, and even your collaboration tools.
Stitch Fix has a distributed team. For three years it was about 50% in SF and 50% remote. It’s been a challenge for Cathy to make sure everyone is aligned. To help with this, they have two summits a year. And on the off-quarters she encourages teams to go wherever they want to connect with their distributed colleagues.
4. Surviving the challenge of fast scaling
Panel with Lyft EVP of Engineering & Product Luc Vincent, Asana Head of Engineering Prashant Pandey, and GitHub VP of Engineering Dana Lawson
5 quotes on scaling engineering and product teams
1. You need to set objectives around scaling your team, aligning them, and building culture.
To be successful, you really have to think about your culture. One of the biggest challenges is forming interpersonal connections. —Dana Lawson
2. It’s important to think about “Why” are we scaling fast.
If you’re spending all your time on hiring, then you’re not building product. —Prashant Pandey
You need to have scaling built into your on-boarding process, and help people get productive sooner.
3. Onboarding is everybody’s job. Every engineer and manager needs to contribute to helping people be productive in their first week.
Make it very clear that recruiting is a top priority for people. —Luc Vincent
4. When you’re onboarding with GitHub, no matter where you live in the world, they’ll fly you to headquarters to get started.
Remote work is the way of the future. With today’s toolset, there’s no reason you can’t have a distributed team. If you’re building a global product, you need to have a global team. —Dana Lawson
5. No matter what you do, being at startup versus a 1,000-person company is a very different job. Every job changes dramatically at every different stage.
As you grow as a company, every role changes. —Prashant Pandey
As a leader, ask yourself, are you really enjoying this job? Even when it’s changed. And ask yourself, do I have the skills for the job?
The best advice you’ve ever had
- Luc: Surround yourself with people you trust.
- Dana: Be yourself.
- Prashant: We spend most of our lives worrying about things that will never happen. As an engineering leader, it’s your job to look out for problems before they happen. But you can’t spend all of your life worrying. There’s a difference between planning for the future and being lost in worry.
5. Understanding “The Product Triangle”
Keynote from Slack VP of Product Engineering Michael Lopp
Accountability is key at Slack
Accountability is in the bloodstream of Slack right now. When people hear that word they sometimes think “If you don’t do this, then you’ll be in trouble.” But that’s not what the word means.
Accountability is an amazing word. It simply means you’re expected to justify your actions and decisions. It means, “to account for a thing.” It’s not about a mandate but about knowing why you’re doing what it is you’re doing. It’s a joyful word!
Michael noted that while at Apple there were no product managers. So they had a lot of conversations about what they were building and why. There weren’t any product specs. Then, there were two constituencies there: Engineering and Design. And there was a third role: TPM - Technical Program Management.
The Product Triangle includes:
- Engineering - The how you build it.
- PM — The what and the way you build it. The voice of the customer and articulating the business value
- TPM — The when you build it. If you don’t have these people, it’s work that’s happening anyway.
The challenge of growing a team is the confusing gray areas between the teams. That’s where there’s the most miscommunication. It’s the biggest challenge as a leader.
Michael suggests we consider a simple question: Who is responsible for a feature? Is it engineering? Is it program management?
The old guard has a vast amount of knowledge about who’s responsible for what. They are culture carriers. They often don’t write anything down. And they have a disproportionate amount of power in the organization. But they don’t scale.
So you need the new guard. They are the people who join your team and need to figure out how everything will work. At around 150 people—the Dunbar Number—it gets really confusing.
Here’s what a good leader does at this time:
- For yourself: Write down the things you’re responsible for.
- For your peers: Ask them to write down what they’re responsible for.
- Together: Make a contract. Define a protocol for the gray areas and who’s responsible for what.
6. How to build alignment between engineering and product
Panel with Airbnb Head of B2B Product Clara Liang, Robinhood VP of Product Josh Elman, and Workday Senior Director of Engineering Madhura Dudhgaonkar
5 words of advice from the panelists
- The role of product management. It’s slightly different at every company. The core is that you’re building products that your customers love. Your product is the process of how your team works together, as much as it is the bits you ship. (Clara)
- Don’t forget that as an engineer your job is shipping value in the most cost-effective manner, with the fastest time to market. (Madhura)
- Great ideas come from anywhere. Prioritization comes from your customers, and your mission. Robinhood puts all ideas into a rubric of whether they’ll help us meet our customers needs and help us become a sustainable business. (Josh). We talk to so many customers through our research. We don’t have to guess ourselves with our options. We don’t try to A/B test every idea. We have the research and really get to know them.
- Having a north star is important. Imagine a 2-3 year bet, charting that north start, and then let teams be flexible about how they’re going to get there. You take bets that are short-term, mid-term, and long-term. But all of those bets should ladder up to that north star. (Clara)
- You need to define, once you get where you are going, what will success look like. It helps everyone stay on the same page about where we’re heading. (Madhura)
3 pieces of advice for setting the product roadmap
- Engineering can’t sit on the sidelines and look to product to decide what to build. As technologists, you’re the only ones who can help the team think beyond what they think is possible to what is actually possible. You can shape how much more delightful the product can be. (Madhura)
- Bring the people from all the teams into a room. Give them all the same research. Help them understand where you’re going and let the team come together to figure out the most important things you could do. Open it up to debate to refine your decisions. That creates a pretty good roadmap. Hire really good people, have these conversations and debates, and you can trust the outcome. (Josh)
- As companies get larger, it can constrain innovation unless you give people bigger boxes to think within. Workday created a team that didn’t have any product charter. We are aware of the overall context about what our business is about but are also allowed to venture outside of that box and experiment. We made the investment knowing that many things they try might fail. And this year, something amazing came out of this team. (Madhura)
What’s the best piece of career or life advice you’ve gotten?
- Madhura: Not saying no to new experiences, however uncomfortable it makes you. The more uncomfortable it makes you, do it.
- Josh: Stop taking calls and start making calls. Find the things you really want to do, and go make it happen.
- Clara: If the job doesn’t scare the living daylight out of you, don’t take it.
Continue with Google
Continue with Slack
Continue with Microsoft
