Leadership stories are the best way to pick up the nuances of successful leadership.
You can’t simply take a textbook, and learn a handful of rules that will make you a great leader. Everything depends on the context. The best way to build a real understanding about leadership - except for making the mistakes yourself - is to look at leadership stories.
The more context you get, the deeper your understanding will go, and the more likely you'll be able to utilize the knowledge.
Michael Lopp, a.k.a. Rands takes us back to his time as VP of Product Engineering at Slack. He takes a deep dive into stories about becoming an executive, the need to tell the truth and he allows a sneak peek behind the scenes into the darkest day of Slack.
Listen to the podcast for the full interview, or click here for more leadership stories from Slack!
I only really figured out how to be an executive about three years into the role, which was a year after I joined Slack as VP of Engineering. I was in an executive role at Pinterest for two years before, adding up to three years combined.
We humans tend to be hard on ourselves when we get into a new role. The roles are often significantly different, whether it’s going from junior to senior engineer, transitioning to management, or managing managers for the first time.
I’ve recently come up with this phrase: you’re aspirationally qualified.
This means you believe you can deal with the new role and you’re excited about it. That’s essential, but it doesn’t actually qualify you for the role. Realistically, new managers aren’t qualified to be managers when they’re promoted. This is just the way it is.
It took me three years to figure out my executive role, and it’s probably true for most roles. No one wants to hear this. When you’re starting in a role, your previous experiences are built around using a different set of skills, and it takes time to adapt to your new role.
I wish I knew this earlier. My role at my current company is different. I’m about a year and four months in, and I’ve got it about 50% figured out.
You also need to learn about the culture and the rules. The unspoken rules are especially important, because no one writes them down, but everyone expects you to follow them. You need to watch carefully and ask around to figure out the expectations and why they’re a part of the culture.
When I arrived at Slack, any engineer could push anything to production at any time. We were releasing Slack 100 times a day.
Slack was proud of the fact that whenever a customer complained about a bug, a person from customer service would go to engineering and have it fixed in a matter of hours. The customers were happy about bugs being fixed too.
This seemed like a dream.
The downside kicked in because Slack was in hypergrowth and went from 60 software engineers to 600.
Setting up staging areas, regression, pre-submission testing, chaos testing, monkey testing, and a long list of things took a lot of work. Unfortunately, we only learned this when we already needed them.
On the darkest day of Slack, we were down twice on the same day. I told the team, “If Slack’s down, the New York Times isn’t going to publish.” I’m sure the NYT was fine, I just wanted to get their attention. I needed to make the point that our service isn’t just nice to have, but it’s mission critical.
Many people are blocked at work when we’re down, so we needed to take this seriously. It was caused by too many releases, so we went from releasing 100 times a day to 3-6 daily rollouts. Saying it like that makes it sound easy, but it took two years to dig ourselves out of the technical debt in the infrastructure and all around.
The CTO at Slack, Cal Henderson, sent me a text that day saying this but with stronger wording, “We’re not going to release anything until we figure this out.” I said, “Got it,” and I gathered everyone in a conference room, and let them know, “We’re not going to release anything until we change this,” so a many-hours-long whiteboard remediation commenced.
It took us getting to a dire place to change the release process. We managed to fix it; it’s no mistake you don’t hear about Slack going down anymore. This happened years ago, and it made us go through a lot of hard work and learn lessons the hard way.
Let’s start with the difference between a CTO and a VP of Engineering. In this scenario, the CTO, Cal, built the machine, and my job as VP of Engineering was to run the machine. This includes all the humans who work on Slack.
My specialty is the people side of the equation. Cal had written a lot of the code, and he knew the tech stack incredibly well. This meant that I got to focus on the process, the people, and the product in my day-to-day work.
My focus often shifted between strategy and tactics depending on where we were in the product cycle. At times, I focused on the tactical level to help push a big feature across the line. Other times I was working with the other VPs to plan out the next 6-12 months and to make decisions about the product, the people, and the technology.
Another important part of the job is dealing with the unexpected stuff. The things that land on your plate have usually passed through your ICs, their managers, their leaders, and everyone else to get to you. These things are often on fire, because if anyone else along the way could have handled these, they would have.
You spend about 25% of any day dealing with unexpected things that show up randomly. These often turn into strategies, as you start looking into what caused the fire. You may have a leadership issue on a team, or someone not doing their job because that turned into a disaster.
In this case, you tactically navigate through the problem, then turn it into a long-term strategy to stop the same from happening again.
It often happens that people talk to you about one thing, but their real problem is something else entirely. This happened to me literally this morning. I can’t go into details, so I’ll keep it abstract.
A person tells me about one of their reports being cranky about topic X. When I hear that, I instantly get the impression it’s not the real problem, so I ask, “What about A, B, and C?” They tell me, “A is a thing, but B or C is not a problem.”
This tells me it’s all about A, which is completely different from X, which we started talking about originally. At this point, I need to figure out how to teach this person to recognize these situations and to focus on the important part. It’s part of the job.
It’s a real problem I need to spend hours dealing with out of the blue. The solution won’t be as obvious as writing a test. I need to teach this person a lesson, and make sure they learn it.
I suggest executives in growing companies tell the truth as quickly as possible.
It’s great advice, but this story is about how it backfires. Really, this was a failure on my part as a senior leader, and it flowed from this approach. If I get a question, I answer it. If you ask, “How are we doing on hiring women in engineering?” I’ll say, “Here’s the answer and here’s the data.”
At Slack, we had a lot of data come in about hiring in a big spreadsheet. It’s data like the number of people hired, diversity in recruiting, and so on.
My admin asked me, “Someone asked for this data. How are we going to share this information?” While literally running from one meeting to another, I answered, “Just send it to them.”
This was a terrible idea.
It was just a spreadsheet with numbers, including no personal data. What could go wrong?
Someone should have gone through that data to gather what we can learn from it and frame it right. When you give raw data to a person who doesn’t have context, they’re likely to read the worst possible story out of it.
I learned this lesson an hour later.
Someone came to me and told me, “We’re not doing X, because the spreadsheet says…” I was very surprised, so I started to put it in context, “That’s not what it says. You’re reading one row out of 27 rows, and…”
I use a phrase that came out of this situation: don’t YOLO communication. Senior leaders have an added burden about what they say and how they're saying it.
I still advise executives to tell the truth as quickly as possible. I’d also remind them that they need to be thoughtful about everything they say, and it needs to stand up to scrutiny. They need to explain well, especially when it comes to complex concepts like diversity, hiring, or engineering culture.
This may go against the part of doing it fast, but just do it as quickly as possible. Sometimes I just say, “That’s a great question. I need to gather the data and put it in context for you, and that’s going to take some time.” I need to be able to tell the story, explain the strategy, and say why we succeeded or failed clearly so it makes sense and doesn’t create confusion.
In this instance, I created confusion. Once we got everyone together and I explained what we could learn from the data and how they all go together, everyone realized it was not a disaster. I didn’t give them the framing.
Michael’s passion is engineering leadership. When he became an engineering manager at Netscape, he couldn’t find useful literature for engineers to develop leadership skills. This is why he started talking to other leaders. He wrote down the ideas he found and turned them into a blog.
Some people consider him famous or “valley famous,” but he thinks of himself as just a guy who writes about engineering leadership and has been recognized for it. He’s built a leadership Slack community over the past 5 years. He enjoys the collective learning aspect and helping others develop.
He has worked as VP of Product Engineering at Slack, Head of Engineering at Pinterest, and occupied engineering leadership positions at other notable companies.
Jose Roca, VP of Product and Engineering at Prezi tells stories about him going from shy kid to great engineering leader, building and scaling Prezi's platform teams, and throws in lots of exciting details to make it more fun and emphasize what he's learned along the way.
Listen to the podcast for the full interview, or click here for more leadership stories from Prezi!
My biggest challenge has been scaling myself. It was especially difficult when I went from managing ICs in one team to managing managers across multiple teams. I needed to delegate on a different level, and put it in my mindset that the issues I’m used to dealing with now belong to my reports.
There’s an old but great article covering this topic called “Who’s got the monkey?” It helps you learn that sometimes solving certain problems isn't your responsibility. You can build self-managed teams on this principle.
My biggest mistake was trying to be involved in too many things. It didn’t come out of a desire to micromanage, but out of a wish to contribute as much as I can. When I’m surrounded by good people, I want to stick with them and help out.
This is what stopped me from scaling myself. Focusing too much on any one team took my attention away from the others.
When I was working too closely with a team, the people in there didn’t grow as much as they could have because they didn’t have enough space. Leaders can solve issues themselves, but often it’s better to provide space for their teams, let them figure it out, and grow in the process.
My mentors helped me overcome this. It’s great to talk to a person who can point out the consequences of your actions and connect the dots in ways you may not consider.
I’ve improved at giving space for my teams. This gives them space to grow, and it also gives me space to focus on higher-level leadership work, so I can grow as well.
I haven’t just learned about management by reading books and listening to podcasts. I’ve been building a network around myself and found my mentors along the way.
Mentorship is about getting feedback from a person you trust. It can speed up your growth and help you avoid some mistakes along the way. This has been essential to my growth.
My mentors helped me on my path when I wasn’t sure whether I was going in the right direction. Other times, they helped me realize that I was going in the wrong direction and helped me find a better course.
They have opened doors for me and trusted me to do my best. It’s important that leaders do this for others, because if you focus on the growth of the people around you, you can go further together. On the other hand, if you don't provide your reports space to grow, the best ones are going to leave.
You can learn from your peers within your company, and you can also find mentors outside your company. Most of my mentorships are internal to Prezi, but I also reach out to other people. When somebody reaches out to me, I’m always happy to have a conversation about whether I can help them.
I often send cold emails or messages over LinkedIn. I usually open with something like this: “I’ve seen you do this, and I love it. Do you have time for a chat?” At times, these don’t go anywhere, but sometimes it leads to an engaging conversation, and I even found some of my mentors this way.
For example, I’ve had great conversations with people from Spotify’s leadership. We reached out, they were happy to talk, and it turned out we were facing similar challenges. They were ahead on some of them and Prezi was ahead on others, so we could compare notes.
Currently, I’m mentoring staff engineers within the company. I also regularly talk to leaders outside the company. I mostly function as a sounding board for them, and we mutually learn from each other.
I enjoy reciprocal mentorships, as I’m the type of person who feeds off others. If someone brings good energy, I push it back, and turn it into a cycle between us. I use support as encouragement to push myself further.
Prezi has gone through different phases. When I joined, the company was centered around engineering, so it was easy to push through engineering initiatives.
As the company grew, we needed to scale up the platform teams. In time, it became comparable in size to the product teams, and the product oriented people were questioning whether it was worth the investment.
This taught me about communicating metrics and outcomes. When most of the company revolved around engineering, everyone in leadership knew the value of the platform team’s work. As focus shifted towards the product, I had to start communicating outcomes, metrics, impact on the company, and the value we provide because these weren’t obvious for everyone.
My most controversial move was adding the first full-time product manager to an infrastructure team. The resistance mostly came from the engineers. They didn’t understand what the product manager was going to do, or they didn't think they needed that type of help.
I explained everything step by step. We went through everyone’s roles and responsibilities, but the infrastructure engineers have been working without product help for so long, I couldn’t convince them it was going to be helpful. On the other side, I worked closely with the first product manager to make sure he fit into the team, and in time, the engineers started seeing the value of his work.
Today, our platform teams always work with product managers and they like it, because they understand what tasks they take off the table, so the engineers can focus more on writing code. Some of the platform engineers enjoy doing interviews with product engineers, but most of them are relieved that the product managers take care of it.
This initiative was challenged by both leadership and the teams, but focusing on the outcomes, the metrics and the impact led us to where we are today.
When I joined the company, we were in a building with two floors. This gave us all the sense that everyone in the company was approachable.
Eventually, we moved to the bigger building with four floors. While we all fit on the first floor, it was just as great as the old building. As we scaled and started using the entire building, we distributed the teams too much, and we started losing this sense.
This happens to every company in hypergrowth. We realized this along the way, and we started proactively designing where we wanted to move teams in the office and how we wanted them to interact. This made the teams more cohesive and improved their productivity, but it took a while to get right.
Prezi has switched to a virtual-first policy, but we still use the office as a hub. Since the pandemic, we haven’t opened every floor, only the first one.
The intent is to create one space where people may actually meet each other and interact, so we don’t want to spread everyone out. Some people were hired during the lockdown, so they haven’t met their colleagues yet, while others just haven’t come to the office for a while.
We intend to create hubs like this across different countries. Currently, we have a hub in Budapest, Hungary; a hub in Berlin, Germany; another one in Riga, Latvia; and one in San Francisco. Dropbox is using a similar system for hubs.
We’re not forcing anybody to work from the hub. We’re a virtual-first company, and our employees can work from anywhere. We use hubs to improve collaborative processes, and for any additional thing that comes up from time to time.
Jose Roca is currently VP of Product and Engineering at Prezi. He became interested in technology at a young age while playing around with a Mac SE. He fell in love with the internet, so he started his career as a system admin.
At Prezi, he joined the infrastructure team, which evolved into a platform engineering team over time. Currently, he runs the site reliability team, the developer experience team, the security compliance team, the data infrastructure team, and the growth platform team.
His mission is to serve both internal customers (Prezi’s developers) and external customers (the users). He has been utilizing a product mindset to achieve his goals. He introduced technical product management at Prezi, which landed him in a dual leadership role.
Radoslav Stankov walks us through his time at Product Hunt where he went from software engineer to Head of Engineering. He tells stories about his personal development, his leadership tricks, how he's been leading the company in hypergrowth.
Listen to the podcast for the full interview, or click here for more leadership stories from Product Hunt!
Early on, the engineering part of Product Hunt was built on contractors. As we grew and the product proved to be viable, we started to hire full-time software engineers. My main focus currently is building a layer of engineering managers and splitting the work between the teams.
We used to call the way we worked single-player mode. We handed a feature to one engineer, and only that one person worked on it.
We’ve developed this into a collaborative single-player mode. As you grow, you have to move from individuals to cross-functional teams. My current challenge is to keep the good parts of single-player mode, but update it to serve our current needs.
We doubled our size during the pandemic and went from 20 to around 40 people. We also have contractors in DevOps and QA.
It’s been a gradual process for me. Early on, we didn’t have engineering managers; it was just Andreas Klinger, the CTO.
I needed to realize that management is a separate career from software engineering. Not everybody needs to become an engineering manager; you can remain an individual contributor and have the same impact.
Early on, time management was difficult, as reducing the time I spent writing code hurt on the technical side, and I had to balance that with learning about management. Here’s what I’ve been doing to make myself a better manager:
I’m still in the process of learning the handles.
Currently, I’m moving away from working directly with engineers and starting to focus more on working with a team of engineering managers. There are significant differences between leading vs. managing.
I trust my team, so I don’t want to keep tabs on them. Getting the amount of freedom I give my teams has always been tough to nail for me. You want to set standards, but it’s not obvious how much you need to stick to them or when they may stop working.
You need different skills in management, so make sure to improve yourself every day.
It’s my goal as a leader to build self-managed teams, and to make my presence unnecessary.
The company has seen phases of hypergrowth, which keeps me busy and forces me to move the frontline work lower on my priority list. When this happens, I try to delegate some of my work. I look at my list of tasks and ask myself why I’m the only person who can make this decision, and how I may change that.
I have a technique that I call my manager journal. I write a log of everything that happens every week.
This includes the general things, like what I was doing or what core events happened to our system. I also use it to keep track of what I’m worried about that week. For example, there might have been an outage, or an argument in my team, or some of my points didn’t go through.
For example, my concern right now is the design system we’re building. My main concern was balancing its flexibility with performance. I write these in my journal every week and check back every month to track how my concerns have changed and to see whether they’d been resolved.
I also write a personal journal for myself, but my major journal is still too personal to share. I try to be as honest as I can when writing it, so the thoughts in it are too raw. They’re meant only for me.
Sometimes I overreact in a situation, and the journal gives me a better perspective. Sometimes I think I did something and it was a huge success, but looking back on it a week later, I realize it isn’t such a big deal.
I use the journal to share some of my concerns, either if I have a solution, or if I need help from a team or from leadership, but I don’t directly share the journal. There is a lot of raw information that comes to me; I put a big chunk of it into the journal, and I don’t want to overwhelm people with it.
For some reason, I write my journal in English, even though it’s not my first language.
I’ve been changing the format, but the point is to write your thoughts, no matter the format. I used to write a blog, but most recently, I created a note on my desktop called weekly journal, and I write in it every day as a cold storage. I tend not to use any fancy software; I keep it in a simple text file.
The point is to move the information out of my head and into a document that I can look at and manipulate. Recognizing the problem is the first step towards a solution, and this helps me recognize problems.
I sit down every Sunday for about 30 minutes to plan my next workweek. I read through the journal, consider my goals for the week and plan what I need to do.
I use these tricks to keep myself in check.
Managing remote teams used to be easier before the pandemic. COVID made everyone stressed. It made it difficult to optimize everyone’s work environments, because their families are there as well, and it complicates things. Everyone faced these issues.
In-person meetups stopped happening, and I’d like them to start back up. We used to hold meetups two-three times a year in Bulgaria, and often up to five people from my team attended them. These were great opportunities to meet in person and get to know each other.
We use a concept we call single-player mode to provide autonomy for our engineers. We want to empower everybody to be able to execute without depending on others. I consider dependency the worst thing on both the people and the technology side.
For example, we hire full-stack engineers because I don’t want to force front-end and back-end developers to have to sync up continuously. One person can execute alone, and their engineering manager has to enable this by providing standards, tools, and guidance.
Autonomous employees make decisions on their own.
You need the ability to write to your colleagues as clearly as you write code. Software engineers aim to write concise code, but when you look at comments in the code or the code reviews, you often see long comments that aren’t formatted well. They often don’t put the same effort into writing clear comments as they put into writing clean code.
I’ve found that communication styles differ between nations.
Engineers in the US prefer to start with the problem, go straight to the solution, and then go through the thought process that leads to the solution. The thought process comes last, because if they don’t agree with the solution, they don’t bother reading the rest.
People from Central Europe work the other way around. They want to see the thought process, and the solution itself is less important for them. A leader needs to balance these preferences.
I prefer not to measure the time spent with work. In a remote environment, I think it’s better to measure the output of each engineer. It’s difficult because engineers are often blocked by other engineers or designers.
In order to get accountability from people, you have to give them a clear line where they can execute from the beginning to the end with a clear goal. Set clear expectations for them, and make sure they know who to reach out to if they have any issue. Not hitting a deadline is okay, but you need to understand why it happened.
At some point, an engineer on my team told me that he couldn’t hit a deadline, because it was too much to build in such a short time. I went through his tasks with him, and we realized that half of the features he was supposed to build were useless.
We adjusted his tasks accordingly, and he ended up delivering early.
Radoslav is from Bulgaria, and he started his career in tech around the age of 15. He’s been at it for over 20 years, and he's currently Head of Engineering at Product Hunt.
Before the pandemic, he used to do public speaking and organize conferences in Bulgaria. Recently, he’s been giving talks online.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.