#17 - How to do career ladders | Cat Miller, CTO at Flatiron Health
Real leaders improve their ladders
Hey friends! Welcome to issue #17 of our community newsletter, where we share in-depth guides from and for Engineering Leaders. We skipped last week to announce our acquisition by Coda. This acquisition comes from a shared vision to make engineering leadership a breeze through precise, actionable and helpful content and tools, as well as our love for thriving communities.
In the other important news, Elevate 2024’s lineup is finalized and you will soon be able to register to roundtables and workshops. Join us in San Francisco on June 5-6!
Today, we’ve invited Catherine Miller, CTO at Flatiron health to share her career ladder expertise with our community, more about that below 👇
Catherine Miller, from IC to CTO in 10 years
Flatiron Health is a company that helps doctors and researchers improve cancer treatment. They collect and organize real-world data from cancer patients' medical records. This information is then used to understand better how different treatments work in real-life settings, which can lead to more effective and personalized care for cancer patients.
Catherine Miller will celebrate her 10th work anniversary at Flatiron Health in about a month. She started as an Engineer in July 2014, when the company was only two years old. She climbed the ladder, step after step, holding several roles in her journey: Director of Engineering, VP, Evidence Engineering, and Head of Product (International). She grew into these leadership roles at the same pace the company grew: in 2018, it was acquired by Roche for $2B. The company now employs 2,500 people and since May 2022, Catherine has been their CTO.
As a company grows, its processes must evolve to reflect organizational changes, including career ladders. Having held several roles during her journey at Flatiron, it made sense for Cat to define a ladder that would fit the company’s needs — but it didn’t come without challenges. Learn more about Cat’s journey to the “perfect ladder” below!
You can follow Catherine Miller on LinkedIn.
How we do Career Ladders at Flatiron Health
Career ladders are crucial for any company that wants to nurture and retain talent. They are invaluable tools that can influence the behavior of a technical team, both positively and negatively. They tell an organization what is important and what isn’t, sometimes in subtle and unexpected ways.
I’ve been at Flatiron Health since 2014, as it grew from a tech team of eight to nearly 400. For the last two years, I’ve been CTO, in charge of software engineering, data science, security, and IT.
What is a Career Ladder?
“A career ladder is a structured and hierarchical progression path that involves a series of job titles or positions, each representing a different level of responsibility, expertise, and often compensation. “
Depending on whether you’ve worked at large companies, you may or may not be familiar with career ladders. Career ladders were new to me when I had worked only in startup environments.
A career ladder is a structured and hierarchical progression path that involves a series of job titles or positions, each representing a different level of responsibility, expertise, and often compensation. Career ladders vary in how they look from company to company, but in general, they look something like this:
On one axis, you have the level of progression (in this example the levels are called E2, E3, E4, and so on). On the other axis, you have the corresponding skills you expect people to demonstrate at that level. To make the ladder useable, those skills are typically bucketed into themes and reflect what is most important to the company.
Why do you need a Career Ladder?
A career ladder serves several key purposes within an organization:
It’s a tool to assess whether individuals meet expectations, used during performance evaluations.
It’s a document to guide individuals toward what career progression could look like for them.
It’s a way to establish levels and fair, equitable pay. Especially in larger organizations, they help ensure that individuals doing equivalent work are paid the same.
It’s an opportunity to define explicitly what work the organization values.
Common Challenges
Career ladders may look straightforward, but they’re notoriously difficult to get right.
At Flatiron, we have evolved our career ladder yearly since we first rolled it out in 2015. Here are some common issues and pitfalls I have heard of, or faced over the years.
1 - Incentivizing a Senior IC Path
A senior IC path is a career trajectory for technical individuals that does not involve management. Creating a career progression for such employees can be really hard to get right, especially at smaller companies. One reason is that it is very specific to technical teams: most other functions do not have the concept of becoming a subject matter expert. Establishing that pattern solely for your tech team can be challenging at the beginning of an organization.
Flatiron’s first ladder in 2015 had clearly written a whole bunch of senior levels, meant to signal to the team the IC path existed and was recognized as such:
E6 (Staff SWE): “independent engineer across systems”
E7 (Senior Staff SWE): “product initiative engineering leader”
E8 (Principal Engineer): “engineering leader across product initiatives”
E9 (Distinguished Engineer): “owns her/his job requirement”
There are a couple of challenges here, including the fact that almost no startup needs a Distinguished Engineer, but also in the language around being an “engineer across systems.” We’d have folks come up and say, “Well, I’m working on Jenkins and it touches every team and system in this company. So why am I not at Level E6?”
We iterated on these definitions for five years, and by 2020, we had a grand total of two individuals who had an IC level equivalent to that of a Director. One of them reveled in working across teams and figuring out common pain points. The other engineer was really good at grabbing a problem and accelerating the solution to make it happen quickly. Basically, get things done faster. We had a ladder that rewarded the first engineer very well, but caused the latter to struggle every performance review cycle because her impact was not across the entire organization; it wasn’t even across multiple teams sometimes.
We created a split track in the IC path, creating separate Principal and Architect paths.
Having two flavors of a level adds complexity, which as an engineer I abhor. But this change also made it very easy to get specific and direct about what each role should do, and how they contribute to the success of the technical organization and the company.
As leaders, we needed to be opinionated about where going deep or going wide is required
This also made it clear that as leadership, we needed to be opinionated about where going deep or going wide is required. When we realized that we had some gaps in our use of front-end technologies, we hired a Principal to level up that area of execution, specifically. Where we need to drive large architectural improvements, we have an Architect to drive that. We since have quadrupled the number of Principal/Architect individuals in the organization, and they are all driving important work.
To summarize, what helped clarify our senior IC path:
Embracing complexity and separating the tracks for depth versus breadth
Senior leadership being opinionated about where we need (and can afford) architects and principals.
Snowball effect. Once there were a couple of examples, the engineers in the organization could better understand what the path might look like for them.
2 - Unintended Consequences
In the engineering ladder, it’s generally pretty easy to define junior levels. The pathway for new grads progressing to the senior engineer level is straightforward: improve coding skills, learn to debug, and develop operational awareness.
At senior levels, the progression is not as easily defined. People start to specialize in different technical areas, and flex between working in code to system design depending on the business needs. You need people who can handle complicated technical tasks, and so it’s common to end up with ladder items like these from the early days of Flatiron.
“Designs new systems of high technical complexity or replaces existing technology with simpler and/or more robust alternatives.”
“Proven track record of designing a new complex product or system, or refactoring an existing complex system, while scoping work that several engineers might implement.”
These descriptions were intended to reward both handling complexity and creating simplicity. Did they work? In 2023 we surveyed senior engineers about the problems with our ladder, and here are the most common things they said:
We thought the ladder was clear, but what the organization interpreted was something different. A big part of the problem was prior expectations: some Big Tech companies are famous for rewarding new projects over maintenance, so we needed not just to be clear, but to counteract those assumptions actively.
We thought the ladder was clear, but what the organization interpreted was something different.
Over the years, we added line items to work against the assumption that folks would get rewarded for creating complexity.
“Good at identifying when there is no more return on investment and work should be wound down“
“Consistently makes production code and systems easier to understand, test, and maintain.”
“Changes to systems the team owns are consistently deployed without unexpected/unaccounted-for problems.”
We stripped out the language of complexity and added more specificity about behaviors that would add value to the organization. While still a work in progress, more engineers are proposing technical solutions that reduce complexity rather than add to it.
3 - Rapid-Fire Questions
There are many common questions I’ve been asked over the years, so here’s a rapid-fire set of answers to those frequently asked questions.
How do you avoid the ladder being a checkbox exercise for promotion expectations?
I think this is incredibly hard to avoid. Often at junior levels, it is a checkbox exercise: writing “clean, well-documented code” is an absolute requirement, not one of a menu of ways to hit the next level.
One way to approach this is to view a ladder as being necessary but not sufficient for promotion. Ladders typically talk about behaviors, but not necessarily outcomes. You can craft a promotion process that takes both into account, which reduces the possibility that someone will try to game the system without actually moving their objectives forward.
How many criteria are too many?
As a rule of thumb, if you’re spending a lot of time worrying about how many criteria you have, it might be time to cull some of them down.
How do we balance meeting expectations across all aspects of a ladder and excelling at one but not necessarily in some?
The T-shaped human is a classic problem, because at senior levels you actually want folks who have a specific technical spike, and ladders have a “peanut-butter” flavor typically–they treat all boxes as equal.
If you find yourself looking at someone who does have spikes and gaps, the fundamental question is: do those gaps affect this person’s ability to deliver value to the business? It can feel horrible not to reward an engineer who has deep technical expertise, but if their failure to be able to drive consensus means they are unable to get their ideas into production, how valuable is that technical skill to you?
If your ladder truly reflects the organization’s needs, then you may need to do the uncomfortable work of holding someone back because of gaps, despite excellence in other areas. Or, the exercise may help you discover that there are areas of your ladder that aren’t critically important.
How do you manage innovating and changing a ladder yearly with concerns of people saying you're moving the goalposts?
People are going to say you moved the goalposts because generally, people hate change of any kind. One way to smooth this is to roll out any changes immediately after a performance cycle, giving the organization at least six months with clear expectations before they get evaluated on the new criteria.
How do you use your ladder during performance reviews and promotions?
We’ve experimented over the years, from asking managers and peers to write feedback that specifically addresses every swimlane in the ladder, to a looser approach that only mentions the ladder where someone is excelling to the next level or has a gap at the current level. I prefer the less rigorous approach personally, and ensuring that we include the business value that an individual has delivered.
How do you de-bias your ladder? There are many different types of bias including extroverted behaviors being favored. Did those types of discussions happen?
Your ladder will favor some types of folks over others because that’s what your organization needs. Some places need deep technical thinkers who can go work on their own for weeks and come back with a 2-millisecond optimization. Other places need product-minded engineers who can learn a new business area in a couple of weeks.
That being said, two things are important:
Constantly ask the question “Is this individual driving business value?” and not just “Are they meeting the ladder criteria?” Where those two things don’t match, consider revamping the ladder.
Provide clear feedback and guidance on how to hit criteria, don’t ever assume that someone just knows what good looks like.
Wrapping it up
Career ladders are a constantly evolving document. No one should expect perfection on the first iteration, and even a well-oiled ladder might need to change when business circumstances evolve. There’s no substitute for listening to your organization and adjusting to ensure that your incentives are always pointing in the right direction.
And that’s a wrap! Thanks to Catherine Miller for her insights. We hope this guide will help you create the perfect career ladder at your company. See you next week for a new edition, or next month, for Elevate!
Cheers,
Quang & the team at Plato