Your job as an engineering manager is to destroy your own job

Your job as an engineering manager is to destroy your own job

Jacek Migdal is a Director of Engineering at SumoLogic who created Warsaw office from scratch. I sat down with him to get his thoughts on what engineering is like today vs. a few years back, how to hire, and why culture is critical to mission success.

 

Short on time? Here are 3 key takeaways from Jacek on the role of the Engineering Manager:

  • Solve problems fast. When issues arise - and they will - nip them in the bud early on, but try not to get in the way of your people.
  • Prioritize communication with remote teams. If you have devs split across timezones and offices, you need to put extra effort to connect with your remote team. 
  • Make solving the hardest problems fun. Establish a reward-based system where players are rewarded for solving complex problems. 

What follows is a long form write up of the key topics we discussed in our interview. 

_______

My parents were into software engineering. 

I created my first game around 6 or 7 years old. It was a simple game in Visual Basic, but it was inspiring. When I was a kid, programming in Poland was mostly about algorithmic contests/challenges, but I loved it.

"You can say geek is in my blood"

My time at Facebook was crazy. I was there early on, we were shipping to production and then going live within two days. It blew my mind how fast we could iterate a change. At the time, we had a lot of interns to help us implement those changes, though. I think it was a 7/10 ratio. Seven interns for every ten developers. Today there needs to be a lot of support to make anything work, especially for a company as monolithic as Facebook. If you’re not giving teams enough support, the concepts just won’t work.

We move fast and break things. We were scared we were going to screw up. There were so many people adopting Facebook. The numbers were through the roof. There were fires to put out every day, it was non-stop. Especially as we were developing the chat capabilities. Everyone has to pay their dues.

The biggest thing I remember was testing so many ideas. We’d sacrifice a lot of projects, even the important ones to make sure the right stuff got through. We tested different databases, we tested the speed of releases, reaction times, everything. We pushed a lot of code in those days. Young Facebook was scrappy, but we managed to do a lot and on a fast turnaround.

"I learned a lot about myself during that time and one of the biggest things I learned: it's ok to sleep, and it's ok to ask for time for yourself. We all need a break and should ask for it regularly."

Working at Facebook taught me that I loved working with early-stage companies. Getting in with a company in its infancy gives you the best chance to leave your mark on the product. After seeing how fast Facebook moved on ideas, while a lot was left on the cutting room floor, I wanted to start somewhere where I could control a little more of what was being focused on, rather than see good projects get swept aside. 

When I left Facebook, I took a sigh of relief.

I started with a young company analyzing data and eventually developing a tool for data science. I moved from the swanky office with the crazy benefits, to an office in a house. I learned quickly that my work mattered, that I could launch anything quickly. At startup, the most essential thing is growth, but later it’s more about unit economy (in SF if you’re not growing 100% a year, it’s stagnation) one has to learn what’s realistic in the startup world vs. what’s perceived, it’ll make the job a lot easier in the long run.

I believe in gamification. By establishing a reward-based system where players are rewarded for solving complex problems, we’re untangling a lot of issues that would otherwise get pushed aside. People love chasing a prize, and by rewarding handsomely, it not only strengthens the bond between those who did the work, it obviously helps the company but also doesn’t burn people out through boredom. 

Do first and chase hierarchy later. If you start doing things because it makes the flow of the work more manageable, and then realize you deserve a promotion for your efforts, we’ll talk about it. We believe in the team dynamic, but also self-starting.

My team is comprised of 32 people, 3 managers. The total amount for the company is 150 worldwide and spread across 3 offices.

"Our philosophy: we run a service. People should own the problems that we're solving, along with the issues that arise."

We believe in Full Stack Ownership. Building ownership is hard because it’s a part of the culture, which is something you can’t force because once you become heavy-handed, it can ruin everything. It’s common in Poland that as a dev you’re seen as some kind of special ops that are called when there is a problem that needs to be solved - but it’s reactive. Startup-minded people love having a broader scope, people coming from “older” companies not so much, and they need to adapt to the mindset.

Software development is a jungle.

Most of the time, you’re gardening and pruning, but you can’t predict a meltdown, so accept that you can’t control it, but you have to manage it. You’re not growing trees, you’re managing the forest.

Sumo Logic creates software for engineers, so we can never forget our core audience. Educating people from the start – even before hiring them, is critical to how we do things. We have Product Managers (also, mini PMs for micro-services) who define, design, implement and maintain features, but the ideal state as a manager is to not to have to do anything. A well-oiled machine is the dream. 

We strive for visibility across all channels. From software to how we solve problems, we’re building products for people like us, other software engineers. We champion culture above all because we need to stay focused on keeping who our core audience is and what they want from us as a product, but also a company as we scale into different areas.

"We maintain that hiring for the right fit is more critical than someone with hard skills. We've passed on some top-notch engineers because they weren't a fit."

A good manager doesn’t get in the way of their people. We need to keep an eye on solving problems, handling escalations, but also if things are going wrong, be the gardener early on - don’t let problems grow. Never postpone. Weeds grow, and it’ll only get worse. 

Hackathons are essential. We hold two every year, and they last a week. It’s enough time to develop something not only on developers level but on teams level too, we tried shorter hackathons, and there wasn’t enough time for teams. We look for positive black swans - but do not let chaos affect clear KPIs (cost estimations etc.).

Your first few hires define the culture of the office and the company. You should know 20 people you’d love to come join you, that you already know who you’d like to work with.

After working with remote teams for a while now, I’ve learned a few things: You need to prioritize work from remote workers higher than locals because those in the office are easier to connect with, even it’s just for a Coke and quick check-in. You need to have a system. How do you handle working within different time zones?

Team-to-team relations are easier to maintain than individual-to-individual when talking about distributed teams. There are a lot of tools out there like Slack, Trello, and Confluence that make collaborating straightforward. We’re split between the US and Poland, so we need systems everyone can embrace.

"Working across the world has taught me to be more organized with my thoughts."

How I interact with someone who’s hours behind. We both need to accomplish our goals, so when we talk, it needs to be meaningful. Sometimes you need to stay longer and sacrifice dinner at home to connect with people. You need to understand the interactions, join the discussion early on when something is developing or needs to be fixed ASAP.

Keep Reading

Everything you do should tie back to minimizing risk and surprises

Give engineers the power to solve problems they know actually exist.

Shortening feedback loops can turn programming noobs into evolutionists