Leadership stories are the best way to pick up the nuances of successful leadership.
Why?
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.
This post brings you leadership stories from legendary unicorns and accomplished leaders. They're collected from the Level-up Engineering Stories podcast series, hosted by Karolina Toth.
You'll find:
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!
Becoming an executive leader
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.
The story of Slack going down twice on the same day from a leadership POV
Arrival at Paradise
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.
The darkest day of Slack
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.
How much was your focus tactical vs strategic as VP of Product Engineering at Slack?
CTO vs VP of Engineering
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.
Putting out fires often turns into strategy
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.
A story of a random discussion turning into strategy
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.
Executives need to tell the truth - A leadership story from Slack
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.
About Michael Lopp
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.
Lloyd Moore, VP of Engineering at Blockdaemon, talks about building successful products and teams within the rapidly changing blockchain industry. He shares valuable insights on mindful hiring, flexible planning and getting a head start in the blockchain space.
Listen to the podcast for the full interview, or click here for more leadership stories from Blockdaemon!
How did you prepare to scale?
Establish company culture
Culture is one of the most important aspects of scaling. Without culture locked in from the beginning, it doesn’t matter what processes you have, you won’t have the right people. And the right people are essential for any team to win.
Hire for success
Building successful teams is based on good hiring. Our hiring philosophy is based on three pillars:
1. Culture
The main focus is to hire for cultural fit. Technical proficiency is important, but we put more emphasis on finding culturally aligned candidates. It’s a large part of our success, and it has allowed us to scale to where we are today.
Regardless of how good your processes are, if the people you hired can’t work together, you won’t succeed. Don’t rely on good luck; make a conscious effort to build the right culture, where everyone is a great fit and teams are aligned.
2. Interest
You must ask yourself whether your people actually want to be at your company. They might be a great cultural fit, but ideally, they’re also interested in your business—in this case, the blockchain space—and identify with your goals.
3. Brilliance
In the blockchain business, there are a lot of brilliant people, even as young as 15. However, brilliance on its own fades in importance if they don’t have the other 2 pillars or if they can’t work as part of a team.
Get to know your team
To get the most out of people’s talent, you need to get to know them on a personal level. The same approach won’t work with different people. Some of them want to be left alone to do their best, and some prefer to be micromanaged.
Identify what works for your employees, and use that as part of your leadership initiatives. It becomes easier to create well-functioning teams when you have this information.
How do you build your teams?
Get referrals
In the initial stage of growing your team, you should hire people who resonate with your employees to build team cohesion. This means asking for employee referrals and hiring people you’ve already worked with so you can build trust easily.
Consult recruiters
As the team grows, it becomes difficult to rely on references. At some point, you’ll run out of your local network, and you’ll need to consult in-house or third-party recruiters.
Find the right channels
You’ll need unique methods to find the right people within the blockchain community.
The people you want to hire don’t use LinkedIn. You need recruiters to go on Twitter and Discord servers.
Keep teams aligned
We’ve been a distributed team since the beginning. We have teams across the UK, Europe, US, India, Germany, and the APAC region. We need to make sure that the right amount of alignment and autonomy is established.
We make sure that teams can work independently but remain in alignment with the rest of the engineering organization through consensus. That allows us to keep our pace regardless of scale.
Circle of managerial trust
With the hierarchy we established, we can make sure that our teams around the world are in alignment with the rest of the organization. We’re experimenting with using a team API, where there’s a well-documented way of interacting with different teams.
With that, we can make sure people know who to reach out to and what their preferred method of communication is. We’re continuously learning and improving, but the fundamental elements remain the same: there are autonomous teams in alignment with the rest of the organization through consensus.
Limits
It’s important that we have limits and guidelines. For example, if one team decides to use a different programming language than what the rest of the organization uses, it’ll be difficult to run cross-functional programs. Using two different programming languages will hinder cross-functional collaboration.
Our preferred language is Go, but we also write a lot in Rust. For the front end, we use JavaScript and TypeScript.
What is your biggest challenge as VP of Engineering?
Getting a CTO
Due to our expansion, we recently got a CTO. In some organizations, you have a CTO from the beginning, and it’s usually a co-founder. For us, it was a higher priority to build up and scale the team first. We made sure that the retention rate was high. In engineering, it’s 95% over more than 4 years.
Once we established stable teams and went through hypergrowth, we realized that it was time to bring in the CTO. We had been planning it for a long time; the whole process took a year.
Our CTO, Chris Sharp, is a great win for Blockdaemon, especially for engineering. He was the director of Apple Pay, and he’s extremely knowledgeable. The challenge is to make the most out of our partnership and his talents.
Turning challenges into opportunities
The other challenge is planning for growth in our market. Some people would argue that we’re already in a recession. We focus on seeing the opportunities, so we can get a head start once this period is over.
What do you do to monitor your competitors and changes in the market?
Write your own story
I think that it would be naive to not share an interest in who our competitors are, but it's certainly not their story that drives our story. We have a roadmap that’s crafted as the world stands today. As we predict that roadmap over the next few years, the only changes that will come will be based on market forces, rather than whatever our nearest competitor at the time is going to do.
Have a flexible plan
Having a plan is better than no plan, even if there are some obstacles while executing it. Our plan was to be in a position where we could pivot depending on market needs.
We’ve always tried to make plans that enabled us to grow organically instead of creating a grand plan for the next few years. We’ve built some of our components knowing that we may or may not need them in the future, but they allowed us to react to market changes as they were happening.
We could react to changes in the NFT API space and solve issues regarding our institutional customers’ regional financial regulations. We also expanded our providers: we went from using one cloud provider to having 3, and we’ve also got bare metal systems globally.
React to market changes quickly
Today, it’s hard to find someone who hasn’t heard of NFTs.
They’ve been on our radar, but for a long time, we didn’t find it urgent to bring them further forward on our roadmap. Suddenly, there was a massive explosion of interest within NFTs. We had requests from institutional customers coming in.
Thanks to our amazing engineering leadership team, our methods have already been well-organized, so we were able to pivot on top of the architecture that we'd already built. Instead of creating an NFT API product that would normally take about a year to finish, we were able to produce something within 2 months.
About Lloyd Moore
Lloyd was a Royal Marines Commando for 12 years. During that time, he played professional rugby and was a 100-meter sprinter.
He became a hardware engineer after that, and then, he was a software contractor for a decade. He started out as Chief Architect at Blockdaemon in 2019, and five months later, he was promoted to VP of Engineering, his current position.
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!
The story of going from frontline management to leadership
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.
Give space to your teams
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.
Finding mentors and mentoring others in leadership
The role of mentors in leadership
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.
Finding mentors
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.
Leadership story about facing internal resistance
Resistance from Prezi’s leadership
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.
Resistance from Prezi’s engineering teams
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.
Leadership story about scaling Prezi's offices
Adapt as you scale up
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.
Virtual-first culture
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.
About Jose Roca
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!
How has the structure of Product Hunt evolved?
Contractors to full-time engineers
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.
Single-player mode to teamwork
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.
How have you made the transition from engineering to management?
It’s been a gradual process for me. Early on, we didn’t have engineering managers; it was just Andreas Klinger, the CTO.
I was helping my teammates and mentoring developers, as a senior engineer does. When I went from engineer to manager, I struggled with figuring out what my role should be as Head of Engineering.
Understanding the role of management
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:
- Reading a lot about management.
- Discussing my challenges with others in similar positions.
- Creating a circle of friends to discuss management issues with.
I’m still in the process of learning the handles.
From management to leadership
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.
How do you evaluate your progress as an engineering leader?
Build an autonomous team
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.
Manager journal
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.
Keep it to myself
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.
Keep it simple
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.
How do you make a fully remote organization work?
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.
Autonomy
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.
Communication
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.
Example from Product Hunt
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.
Accountability
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.
Story from Product Hunt
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.
About Radoslav Stankov
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.
Let's build awesome things together 🚀
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀
_ We’re a full-stack web development agency, building web applications from design to delivery with Angular, React, and Node.js
