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!
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.
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, or transitioning to engineering management 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.
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!
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.
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.
🚀 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.