4 Engineering Leadership Screw-Ups by the Best in the Business (And What We Learned From Them)

Leadership in engineering can be challenging to get right. Even the most successful acknowledge that it took time to hone their skills. Just like with software issues, it’s important to take stock and gain wisdom from engineering mistakes to strengthen your organization and accelerate its growth.

We spoke with four engineering leaders who shared humorous of their professional screw-ups—with takeaways that you can apply to your professional development.

Lesson 1: Always Double-Check

The Leader: Daniel Marashlian, now the Co-founder and CTO of Drata

Early in his career, Daniel helped build the learning management system for a community college. After about a month on the job, he began to earn their trust and was granted access to more resources.

While helping a customer out and in the database, he saw an error and issued a delete statement. But a semicolon was missing—because it wiped out the entire student database. Luckily, senior members of the team rallied to help him fix the issue.

Only for Daniel to take everything down again.

Don't just take my word for it; take Daniel's from the video above—you should always double-check. This advice may seem simple, but following it will save you a lot of headaches in the long run.

Lesson 2: Know When To Automate

The Leader: Luca Rossi, now the Founder of Refactoring.fm

Luca's previous startup offered a way for people to shop around and reserve travel at the best available rates. In the past, they worked with the meta-search approach. Eventually, they decided to close the funnel within their website by allowing people to pay and book tickets on their platform.

However, since they felt it would also be a very intensive engineering activity, they decided to carry it out in a lean way. To start with, even though they integrated a payment gateway so that customers could pay for their tickets on the site, staff members still had to manually book the tickets on the transport company’s site when a booking came in. I'm sure you can guess what happened—as soon as they saw any sort of scale, their lives became a hell of booking 'shifts' with customers potentially showing up at any moment and team members on call to book them on the back end.

They made the mistake of not planning for what would come next. After deciding to release their solution as fast as possible, they failed to prepare for the challenges it would create for them.

There are always new problems to face in a rapidly growing company. It’s best to deal with them when they’re still small. If not, it might be too late. Something you don't automate at a small scale will only continue to grow in magnitude having untold impacts on efficiency and employer morale.

Lesson 3: Organize Teams Around Solving Problems

The Leader: Shweta Saraf, now Director of Platform Engineering at Netflix

Shweta shared with me an experience where she managed an eight-person team of engineers with extensive knowledge and inherited another team that excelled in the front-end and user experience. She had to think about how the teams could best cooperate to increase productivity and speed up the process of getting things done. So, they decided to reorg to a full-stack team: they took a couple of people from the back end, with domain expertise, and people with front-end knowledge and put them into a team.

However, the team bombed because they were too focused on fixing things in the back end. When the front-end specialists on a full-stack team complained that there weren’t enough stories to work on, it was a sign that they saw learning to code in the stack as too daunting.

From this, Shweta realized the importance of knowing the why behind any design or reorg you undertake as a leader. Full-stack teams may be successful in some contexts, but it doesn’t indicate they’ll be effective in others. It's important to take a 'people-first' approach and understand the needs and behaviors of your team members as well as provide a sense of ownership over the outcomes of their work.

Lesson 4: Understand Which Metric Measures Success

The Leader: Chris Downard, now the Vice President of Engineering at GigSmart

Being in a leadership position in engineering is challenging since you often have to roll out new projects while introducing your team to new tools. Chris joined GigSmart when the company was employing various platforms to pull stats and fine-tune its metrics. However, the amount of data was overwhelming team members who couldn't easily see a distillation of key points of emphasis.

Data is great, but it doesn’t help people make the best decisions until it’s put into context and presented as information. For instance, one developer had anxiety over their commits since they could see their commit activity. That’s the metric they zeroed in on for how well they were performing. This developer believed that the number of commits they pushed each day indicated their level of activity and productivity. But it really wasn’t. A high commit volume does not translate to a high acceptance and low rejection count.

As Chris shares in his video, GigSmart learned the lesson of what not to do when rolling out tools internally. Too many tools create the wrong kind of motivation—you need to align your platform to not just monitor vital metrics but to equip team members and managers with the knowledge they need to identify what's important. To solve this, Chris implemented software delivery management platform LinearB to shift how they show engineering metrics to the team; now, everyone has access to the information they need, but they can be intentional about what they’re looking at.

Moving on from mistakes

Nearly every great leader believes in continuous improvement for themselves and for their team. You can't have improvement unless you acknowledge—like these amazing leaders—that there are things to improve!

If you're looking for a surefire place to start improving your engineering team, dive deeper into another pitfall too many engineering leaders face with my Dev Interrupted co-host Dan Lines' blog: How to run a data-driven dev team—without being a performance tyrant.