August 29, 2024
Editor’s Note: This article first appeared in The Current, Jellyfish’s LinkedIn newsletter. You can subscribe for monthly updates and articles like this one here.
My first adventure into engineering management was, to put it simply, chaos. A small group of technologists with mismatched priorities and skills supporting an online music school, broken into at least two groups of engineers in completely different tech stacks who didn’t want to work together, or even speak to each other, at times. One team decided to “do agile”, another decided that tickets were fine, and Post-Its on a manager’s wall would be sufficient.
Just getting anything done was a miracle. But we were small, and I could keep most of the projects in my head at any given time, and solve a lot of problems by just walking around and chatting with folks until we found our way. I learned a lot, and we did some work I’m still proud of to this day, but I knew it wouldn’t scale beyond my own ability to spin plates and talk fast (and friend, I can talk fast).
So I moved on. I wanted to do it again but…harder. I moved into a Large Company with a very mature product org, with Product Managers (PMs) embedded with each engineering team. I hadn’t experienced such close collaboration or input into the software lifecycle before. Other people had opinions about how well we were working, and I was eager to impress them all and help the team improve. To get my bearings, I did the first, most obvious thing: I interviewed every product person I could find and asked them “what do you want from engineering?”
Here’s, roughly, what they told me:
- We need to ship things at a reasonable rate (and we’d like that rate to be “fast”, whatever that means). Just get the work done.
- We’d like to know how long those things will take, so we can prioritize and plan well.
- We’d like those things to not suck.
- We’d like the team to give a damn about the outcome, and participate in the mission, not just the typing.
Eventually, I boiled those down to slightly more work-friendly categories:
- Velocity
- Predictability
- Quality
- Engagement
These four categories of feedback, or pillars, gave me a great start at helping to improve the engineering team, and building trust with our cross functional partners.
I’ve used them with every team I’ve joined since.
It’s easy to understand the pillars, but it’s hard to know how we’re actually doing for each of them. How will we know if we improve in any of those areas? Are we keeping score? Do we have goals? Do we think there is potential for improvement on the team? What does it mean for this team to be the best team ever?
There are lots of ways to run a team, but whether you’re a certified Level 26 Scrum Wizard or staring at a wall full of Post-Its in columns, these pillars can be signals you should keep an eye on to keep that engine healthy.
So let’s go deeper into each area:
1. Velocity
There’s no one right answer to “How fast should my team be,” of course, but we have to pay attention to how much work we get done. Otherwise, how can we improve it, or know when or why it’s changing over time? What is it, beyond a person’s ability to type code at a normal rate, that makes a team more productive?
One way people try to speed up a team is by adding headcount. Let’s say you add one person to a five-person engineering team, that’s a 20% increase in capacity for the team, all else being equal. But how long does it take for you to onboard them and for your team to actually show a 20% uptick in output? Or maybe you only get 10% more output because of the added communication overhead? Watching changes in your team’s velocity can give you signals about the health of your team, the effectiveness of your processes, and whether other investments you make in developer tooling, training, or technical debt are making an impact.
LEVELING UP: Not all velocity metrics are created equal! I prefer measuring Epic completion because that speaks to actual projects being finished and value delivered, and I really really don’t want to argue about story points. Think about what you can measure that maps to your teams delivering value to your customers, and worry less about metrics that indicate “busyness.”
2. Predictability
Software is just done when it’s done, right? Who knows what weird complications, scope changes, or setbacks we’ll encounter on our way? But also, we plan on doing these three projects in the next quarter, and you should totally believe us when we say we’ll be able to finish all three.
Predictability can be scary to talk about, but it’s worth investing in, and there are ways to improve it. It’s important for the best engineering team ever to understand that the goal of talking about predictability is NOT to a) set ourselves up for long nights and weekends struggling to finish something we’re overcommitted to, or b) to pad out estimates twice as long as we need so we don’t risk looking bad to “management.”
The goals of predictability are to empower good planning and prioritization (if you could only finish two of the three projects, which would you pick?) and to keep the team focused on delivering value consistently. It’s important to balance ambition with realism.
LEVELING UP: Predictability can be notoriously difficult to measure at the project level where it counts most. Are your projects shipping within a week or two of targets? When you need to make changes to your estimates, it’s better to communicate those changes a month out from a deadline rather than the day before you miss one. Is your team getting more accurate in their estimates over time?
3. Quality
If you’re posting content to a website daily, the cost of fixing a small typo is pretty low. If you’re landing a robot on Mars, an errant keystroke here or there can have catastrophic and expensive consequences. Like velocity, nobody else can tell you what the “right” number of bugs is going to be for your team. For most of us, it’s not zero, and the only way to ship zero bugs is to s l o w e v e r y t h i n g d o w n. We have all heard “good, fast, cheap: pick two,” but obviously there’s room for balance between our speed and our quality. Also, not every bug occurs because one of your developers let their cat get too close to the keyboard as they were saving a file. We need to understand where our bugs come from, what impact they have on our customers, and how much of our time and attention we’re losing to quality problems. And those are things we can measure!
LEVELING UP: Counting bug tickets in your backlog is not enough. Think about the difference between an engineer in a hurry, shipping untested changes that break for some customers, and code that has been working in production for six months that fails because something else in the universe has changed. Not to mention bugs that aren’t actually code issues, but are areas of confusion for customers that make your product seem flawed in some ways. Bring a little nuance into your bug data and get better insight into the quality of your daily work compared to the health of your system and the customer experience.
4. Culture and Engagement
Nobody is going to tell their friends about how great their team is if they don’t feel like they belong, and are valued. A team that is afraid to challenge themselves and pick ambitious, but achievable goals may also not be around for too long in a competitive industry. We need psychological safety and healthy ambition, and both of those things take work. Luckily, your engineering team has you.
LEVELING UP: Aren’t these things just…feelings? Doesn’t culture mean different things to different people? How can we know what’s going to work for our specific team? How do we make it better? The answers to these questions, and more, are already within your team. Ask everyone on your team what it means to have a great team culture, and you might be surprised at the variety of answers.
Building the best team ever can take time so I recommend picking one of these pillars per quarter to go deep, refine your measurement, target some improvements and normalize tracking. And from there you can improve.
Looking for more insights like these? Follow Luke on TikTok or subscribe to The Current from Jellyfish on LinkedIn to explore the trends and technologies shaping engineering organizations.
