Drive agility with empathy, not process

Fahim ul Haq is the co-founder and CEO of Educative, the world's leading upskilling platform for and by developers. He is a former software engineer at Microsoft and Facebook with a deep passion for creating better, more efficient ways for developers to master in-demand skills.

You are cruising at 80 mph on a straight, clear road when suddenly a deer appears out of nowhere. You have to immediately apply brakes, and every passenger in the car is shaken up.

That’s sort of what happened at Facebook.

In 2013, Facebook was still in its growth phase, and its IPO the prior year had generated a large influx of cash to enable scaling their headcount. Hundreds of engineers were working on growth tweaks.

Then Gmail launched Tabbled inbox and started pushing every Facebook email to the “Social” tab. Facebook’s growth strategy was heavily tied to sending emails. For example, whenever a user would send a message, you would get an email, your friend suggestions would be sent to you in the email, etc. Facebook’s email open rates dropped by over 50%, and their product roadmap and growth plan needed to be completely rewritten overnight. 

So What?

The world of software development is about change. This isn’t new information, but as someone who has sat at both sides of the table – leadership driving change and the engineer whose work has been scrapped – it wasn’t until more recently that I realized how much change is uncontrollable.

Change is, of course, inevitable. It happens at both startups and mega-corporations. There’s the Facebook and Google example above, but how do you think Uber responded when Lyft rolled out ride-sharing instead of just hailing black cars?

Engineers are usually excited about the change. We like to solve problems, write code, and drive processes as users adopt our solutions. This is really a function of control: we like things we can fix. So when all our work on a product is retasked, it becomes a struggle to regain control.

When change becomes disruptive, it can be stressful and even demotivating, especially for junior developers. This is where a good engineering manager leads not with technical expertise, but with people skills and business understanding.

External Change

Google pushes an update to Gmail; Facebook reacts with an updated growth plan and reallocated engineering hours. Lyft introduces ride-sharing, and Uber adds Uberpool. These are changes that come from outside the company.

An acquisition is yet another event that could cause a shift in the engineering roadmap. I imagine a lot of projects at Slack were changed when the messaging app was acquired by Salesforce, as the product was fit into a roadmap that leveraged Salesforce’s entire enablement portfolio.

Usually, the acquisition decision is a closely guarded secret, and most engineering managers hear about the news of the acquisition along with the rest of the world. Unfortunately, they have to react quickly and their teams are anxious to know what happens next. Imagine the chaos in the Facebook Messenger team where they were focused on creating a competitive product to beat WhatsApp and suddenly Facebook announced that they’ve acquired WhatsApp (no need to compete, we are all friends here now).

How can a manager ensure these drastic changes do not devalue dev work? By understanding the external changes from a business perspective, and then connecting those product imperatives to the team’s technical interests. Managers must communicate the why that drives a change in scope, and assure the team that the change is meant to empower their work to be even more valuable, more effective.

Frame a strategy change around the business need. A good manager can’t just retask developers; they also need to reorient developers to a meaningful destination. No one wants to keep working without growing, without a finish line, or without the gratification that comes with shipping great products.

Secondly, provide the opportunity for developer growth within these changes. During the now-scrapped (or significantly changed) project, one of your developers might have shown himself to be a great project manager, checking in with the team to ensure his dependencies were aligned. Another developer might have shown that she was a truly good designer, contributing at system design meetings and suggesting meaningful API improvements or connections. Take these developers and find ways to help grow their interest and skillset based on this new data.

Internal Change

Even an internal change that scraps months' worth of work is a learning opportunity. For the developers, reflecting on the strengths and weaknesses of different technologies is a continuous growth area. We often set out with a project plan based on the best technology available, only to discover that the best technology doesn’t quite fit our use case.

We’ve all had the product manager come to us and say we need to start over or that the company is going in a different direction. Whether it comes a week before launch or six months after countless hours sunk into developing the roadmap and maintaining our production environment, having your product scrapped can feel personal.

We sometimes hear how artists “pour themselves” into their work, that a painting is a part of them. I think the same is also true for engineers, who spend time designing solutions, researching and collaborating with their team, GitHub, and Stack Overflow, all for a task they’re interested in and a skill they’re talented at, and a job they love.

I’ll tell you a practical example: at Educative, we’ve been developing a mobile application. When we first started, we didn’t think mobile was practical for learning software engineering, as coding environments are much richer on desktop. But our users asked.

So this is an internal project spurred by external feedback. That’s already an external change that we had to navigate. We want to be able to support all developers, so we need to develop something cross-platform. Enter Flutter.

We scaled up production for literally a few months, and the app worked great. Internal testing and functionality were highly reliable. Our engineering did great work.

The app isn’t released yet. Why? Because we scrapped it. We had to tell these engineers that their work wasn’t coming out; it’s not something to be fixed and rewritten. We were starting over.

Though all external use cases were considered, we ran headlong into a technology mismatch internally. The Educative web application is written in React. The mobile app and the website couldn’t keep up with each other, and given that we have over one million website users and a content library of over 400 courses, it was clear which got our priority.

We’re still developing a mobile application, but we had to start over with React Native. This was driven internally, as we found that our existing tech (Flutter) wasn’t able to scale rapidly enough to meet our needs and uses. Maintaining twin codebases became impractical from a DevOps perspective, and engineering couldn’t easily be cross-applied. This was a lesson learned. We could have kept pushing Flutter for the mobile app, kicking the can down the road because it was almost done. Or we could have sat in endless debates about which direction to go, pausing development for who knows how long.

Good leaders jump into a situation and make decisions. Amazon calls this fail fast - we ran, we saw the problem, we recognized it as a failure, and we made a quick choice to build a robust React application. We cannot be frozen by analysis paralysis – and we had to communicate that to all of our teams.

Final thoughts

As an engineer-turned-cofounder, I’ve always wanted to be agile. Every engineering manager I know wants to be agile, but the purpose of agility is to provide stability to their team.

One of the things about being a cofounder is that as your product scales, your vision has to evolve. From my place as a software engineer, that changing vision and market was often foreign to me. As a leader, it is frequently the only thing I see.

Now, I understand those changes both external and internal to a software engineering team.  Engineering management exists to maintain the general direction of the team, not to dictate the day-to-day. Managers cannot prevent change, but they do need to mitigate the sharp turns.

To use a metaphor: we are driving toward a north star. Our product has a purpose. And as we’re steering this ship of an engineering team, our job is to avoid the big icebergs, the doldrums where we’re all stagnating, and the storms that can toss us about. To stay fixed on a goal, the crew needs to understand.

How to keep steering toward that north star? How do software engineers maintain their sea legs and agility? It’s not through the process; it’s through communication. Drive agility with empathy, not frameworks.

Being an engaged leader requires connecting with your team and telling the story of their growth – that their technical contributions are valuable, and that they will continue delivering on this shift. Helping your team maintain their motivation can mitigate future disruption.

A technical manager can make the necessary changes to deliver a robust product, but a good people manager can maintain or even improve job satisfaction for their developers. To be a complete engineering manager requires both.