The Daring Journey of a Staff Engineer: Part 1.

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.

The introduction of the Staff Engineer role is typically driven by a desire to offer Software Engineers paths for professional growth within the technical track, along with the opportunity to lead and mentor others. However, a debate persists: is aspiring to become a Staff Engineer the optimal choice for everyone?

While climbing this new career ladder is undoubtedly one path to professional development, it’s not the only one. That’s why it’s important to better understand the journey towards and in this position, so individuals can consciously decide if it aligns with their career goals, rather than defaulting to it.

My takeaways on Staff Engineering.

In my interactions with Staff Engineers at OpenClassrooms and discussions with counterparts in other companies, I’ve noticed that while their approaches, impacts, and scopes may vary based on their expertise, team dynamics, organizational structure, there are three fundamental traits consistently present in their work style.

They DARE:

• Drive a technical vision. This partly stems from their technical expertise. You can’t be a Staff Engineer if you do not have strong technical expertise. However, defining and driving a technical vision, adopted by the whole team and often going beyond your squad scope, represents an entirely different challenge, demanding significant leadership and additional soft skills.
• Get things done. Wherever and whatever it takes ! Showcasing creativity and persistence in overcoming obstacles, even when challenges seem insurmountable to others.
• Be empathetic. Empathy is not the first quality we think of when talking about Staff Software Engineer, but when we analyse the performance of those who succeed in this role, we understand that’s a huge driver and factor of their success. Empathy allows to establish a good connection with colleagues, users, stakeholders, and consequently better understand their needs and motivations. As a result empatethic Staff Engineer has higher chances to make an impact that matters for company on many levels.

Key element tying all these traits together is Daring. We often take the confidence and courage of technical leaders for granted, yet impostor syndrome is prevalent among them. Acknowledging its prevalence helps to destigmatize the experience. Once normalized, it becomes easier to make a plan for necessary self-work and actions to overcome it, thus paving the way for success in the Staff Engineering role. Overcoming impostor syndrome is vital for any position, but particularly for this role, which is relatively new, not always well-defined, and offers a high degree of autonomy.

In this article, Ahmed Lebbada and Dorian Milliere, Staff Software Engineers at OpenClassrooms, will share their insights gained from their personal journeys.

In this first part we will discuss mostly two first traits. The upcoming second part will focus more on relationships and the various connections inherent to the Staff Engineer role.

How you became a Staff Engineer.

Ahmed :

I had just taken on the role of Senior Backend Software Engineer in March 2019. Before that, I had around 9 years of experience, mostly in full stack initially, but later on, I shifted more towards backend.

I believe I was the first Senior member of the team at the time I joined OpenClassrooms. The challenge, in essence, was to prove yourself, gain enough trust to influence or change some aspects of the software architecture in place.

Becoming part of the Staff was a sort of byproduct of this effort.

I also think that my promotion to the Staff Engineer role was also related to daring to question things.

It’s not just about challenging things for the sake of it but understanding why things are done this way so you can improve it if needed.

I started learning to communicate more effectively after taking the Staff role, thanks to the guidance of my manager. Initially, I wasn’t great at communicating, I have a tendency to work in isolation.

I used to complain to my manager that despite doing cool things, nobody wanted to use them. That’s when I realized it’s not just about what you create; it’s about convincing people, explaining why it matters — it’s an ongoing process, involving a lot of communications and people management.

To summarize, obtaining the Staff role was initially based on technical prowess and daring, and only afterward, already being in the role, I learned other mandatory soft skills for Staff Engineer like communication.

Dorian :

For me, it was perhaps a bit different. I was heavily involved in architecture and such for a very long time. Even when I started as an intern at OpenClassrooms, I had already been working on these things, so it wasn’t like I suddenly switched to these responsibilities and missions from one day to the next.

When the Staff Engineer level was introduced I didn’t have it immediately, but I was consistently invited to meetings where all other Staff Engineers were present, and I was the only non-staff member in those meetings. Sometimes people even thought I was already a Staff Engineer.

Sometimes there were meetings of Staff Engineers where I was not included and I thought “They’re having a meeting where I might be the person best suited to lead it, and I’m not in it.” It frustrated me a bit, so I talked to my manager, and soon enough others agreed that it made sense for me to become Staff.

So, in summary, this role was attributed to me more because I already had this role implicitly. It was more of a natural progression rather than something I was actively looking for.

Creating a technical vision.

Anastasia :

Throughout our collaboration, both of you consistently held strong opinions on the directions the technical roadmap should take, demonstrating a clear technical vision.

What particularly stood out to me about your technical vision is that, you were consistently focusing on enhancing delivery speed and developer experience to bring the value to users and developers as soon as possible, rather than solely striving for long-term excellence, even if the latest was a part of your vision as well.

How have you cultivated this thought processes, which lead to a technical strategy inherently supportive of the product and faster time to market?

Dorian :

I think I have two kinds of triggers that lead me to technical vision.

Either it’s through observation because I see that the team has a weakness. For example, in the past we were understaffed in design, so I brought up the subject of using the library Material, which uncharged the designers from some work because we relied on Material UI. Or for example, in retrospectives everyone complained about Travis, so I implemented github action, and it greatly reduces the time waiting for the CI.

It’s really simple: if we observe something that doesn’t work and people regularly complain about it, we just take the ownership of this subject, and not discard it just because it’s not something our Squad naturally addresses.

The second trigger is to make people happy ! For instance, I developed a tool to facilitate testing with multiple accounts, and I thought I would make people happy by implementing it because it would improve everyone’s daily life.

And don’t hesitate to go beyond the scope, for example, if it requires the work you are not usually used to do, if you are front-end and it requires back-end work, don’t hesitate to do it anyway.

Sometimes, precisely because it’s beyond their scope, no one takes it on, but at some point, someone with a somewhat multidisciplinary skill set has to take on the subject that spans devops, frontend, and backend, to get things done.

For example, migrating from Travis to GitHub Actions involved devops, frontend and backend, so I had to step out of my frontend scope to do it.

For me, it does not necessarily mean stepping out of my comfort zone, but it can be for some things, in any case.

Ahmed :

From my side, I would say it’s actually a series of experiences that progressively changed my perspective. I would mention the first two significant experiences I had before. They were meaningful in shaping my way of thinking.

The first one was actually in a very small web agency. The company was struggling to survive, and there was fierce competition in the market where projects were usually awarded to the lowest bidder who could demonstrate certain standards or quality. Working there was very stressful and challenging because you couldn’t afford to go six months without a project; otherwise, the company wouldn’t survive.

You always have to find ways to optimize your work, to work faster than the competitor, to achieve something valuable quickly. That’s where you really learn pragmatism, what works, why it works, what problems you often encounter, and how to adapt.

I think I worked on about six or seven different projects while I was there, if not more, so it helps you see a lot of different issues.

For my second experience, I joined a company that had just one product, but with different challenges. When you have a product that has been around for, I don’t know, 15 years or so, with over half of the codebase being over 10 years old, it’s a different problem. It’s about the size and complexity of the codebase, maintaining quality.

You have to be very careful, especially when there are real-time systems that generate revenue. That developed a kind of anxiety in me, and what a better way to ease it than focusing on quality ?

That’s where I came across OpenClassrooms, where I saw that unit testing was common practice, there was a focus on quality, and architecture was important. So, I joined the team, and there I encountered a third problem I had never seen before.

It was the complete opposite of the previous experiences: there was too much focus on quality (with time, we’ve fortunately found the right balance). But back then we sometimes spent a week before releasing a feature. In my first agency, we couldn’t survive at such a pace.

I thought there must be a way to do much better, and why was I so confident about it? Because I’ve experienced it before. I knew for sure there’s a way to do much better. Now, how to do it while adhering to the principles we follow, without changing everything, while maintaining the level of quality required, that’s the challenge.

I had to learn even more, but in reality, when I arrived at OpenClassrooms my technical vision was already shaped by my previous experiences.

The rest is how you think about the problem.

I’ve read a lot about software architecture and design patterns, Uncle Bob, Martin Fowler and so on.

But in my vision, when I started in company, I knew that it’s not black and white to balance quality and productivity. I also learned that quality doesn’t mean slow, often the contrary when really understood.

There are many layers in the books about architecture — confirmation layers, selection layers. You have to be very careful when reading opinionated architecture books because with these books, you you can fall victim to the barnum effect: you see what you want to see. In some cases you can even become dogmatic about some practices.

Think about the problem, as Elon Musk says, in terms of “first principles”. Basically, you have to break down the problem, understand the basics, and what you’re trying to solve. If you don’t start with that, you’ll never solve the problem, you’ll just apply a solution to a problem you don’t understand, and you’ll over-engineer it.

Proof of concepts and experimentation.

Anastasia :

One of your favorite tools to convince the stakeholders and teams was doing proofs of concept (POC) and experimentation.

It could not be always obvious, because we can imagine that some POCs are hands on work that takes a lot of time so you have less time on the projects that should be delivered to the production, on the system design or coordination.

What advantages and challenges do you see in this approach, and how do you make the choice to do the POC, delegate it or choose another way or paving path to your vision?

Dorian :

The need to do a POC arises when the subject is too big, not on the roadmap, but still, we’d like to explore it because it has potential. However, we can’t invest too much into it. Essentially, it’s a way to test an idea that has potential without spending too many resources, and quickly determine if it’s worth pursuing. If it’s worthwhile, we add it to the roadmap, if not, we don’t.

A POC is simply a way to save money and time because it’s much quicker to execute.

As for the challenges, it comes with growth. It’s easy to do POC in a small company, but in a large company, like with over 200 employees, it’s difficult because there’s a lot of validation required, and the processes aren’t necessarily suited for doing POCs.

There are legal validations, security validations, SRE, scope validations, and even politics — like, “You shouldn’t have touched that, it’s not your scope,”. All these are obstacles to doing POCs.

The biggest challenges in large companies are the heavy processes not suited for POC quick win.

Ahmed :

I agree that the biggest challenge is often the process.

There’s another technique that I’ve used before, which is using data before proposing a project. Sometimes, you can’t just propose something; you’re required to back it up with data.

For instance, if you want to change some code architecture, people have a belief that this architecture is often used because the problem is always framed in a certain way, and the architecture is the best response to this problem. Consequently, the debate is quickly closed.

It is where you need to work on the data and really understand the problem.

When there’s a change in methodology, it’s harder to just do a POC. You can do one, but it’s rarely sufficient because it’s a way of seeing things that needs to be challenged.

This ties back to what I mentioned earlier about biases. Without experimentation or at least data, we can’t guard against biases, we’re not sure we’re proposing the right solution.

Even having data sometimes isn’t enough because the way we format our data insights can introduce biases.

It’s more about the quest for the right solution.

Sometimes in this quest there could be debates considered sterile, more about opinions. Doing POC helps avoid these kinds of unconstructive debates.

Getting things done to have impact.

Anastasia :

You often mentioned taking initiatives and questioning things. It could be not easy, but get things done to have real impact and change is sometimes even more difficult.

It’s like new year resolutions, we initiate things, but then we lack time, courage, motivation or something else to pursue and finalise our initiatives.

Because even when something is almost completed, like being coded or delivered, you often need to persuade people to use it or contribute to it to achieve the desired impact.

What do you think is necessary here to get things done, especially the last mile: discipline, persistence, and communication to push through moments of fatigue and organizational conservatism?

Dorian :

To respond to “how to get it done,” I think you need to dive into the mess very quickly, avoid overthinking and trying to anticipate everything.

You need to start it quickly, a bit like Spotify’s slogan “fail fast”.

If the last mile becomes complicated, i.e. you’ve done everything and there is a last validation missing, if necessary, work around the process. A saying I like is

Ask for forgiveness rather than permission.

If it’s just one identified person blocking things, you need to go talk to them, to unblock the situation. And if they still won’t budge, try talking to other people, maybe their colleagues or their supervisor, but never give up. That’s how we can solve the last-mile problem.

Ahmed :

I have a story supporting Dorian’s thesis. On the backend side I wanted to push forward OpenAPI for validation and routing. Initially, when I proposed it, I did a proof of concept, but at the end of the POC, nobody took it seriously. There were opinions like “we don’t think it will work”, and that’s where I think I didn’t respect the process. Despite the fact the majority of the opinions were against it, I put it into production and proved that it worked once in production. And it changed people’s opinions.

Nevertheless I don’t want to recommend this approach, because the problem with it is that you have to be really sure of yourself because the risk is high if you do something outside of the process, and in the end, if your thing doesn’t work, well, I think you’ll pay a higher price than if you had respected the process.

Dorian :

I think you have a very important point here: if it also puts the company in a mess, if the risk is too significant, obviously, you have to advise against it. If the risk is just administrative paperwork or arbitrary processes that objectively aren’t very relevant, go ahead and do it if they’re not very serious matters. If the risk is breaking production, then definitely don’t do it, indeed.

Ahmed :

It’s true that even breaking the PR itself, you might think, “Oh, I can rollback and we’re good”, but if you rollback and there’s data corruption, then you’re not good.

Overall in a company, you should calculate the risks and dare to take action in all cases.

I think to come back to Anastasia’s question, it’s complicated. I’ve been thinking about it for a while now, but I can’t figure it out besides persisting, just persisting isn’t enough. Saying you just need discipline, I’m not sure if that’s really a good answer.

Anastasia :

Here are my two hypotheses.

The first is passion, being truly passionate about this project, so regardless of barriers you will go ahead to finish it and bring it to life.

And the second one is empathy. Because, as you mentioned earlier, it makes you happy when people are satisfied by using the tool. So, the fact that you’re doing something useful, that people can genuinely appreciate, helps you dare things, because you do not do it only to prove you are right but to help people.

Ahmed :

I think you’ve hit the nail on the head, I believe it’s more about empathy. I’ve even seen it in the language of some individuals who are able to put themselves in the shoes of our end users, students.

I think it’s empathy towards the students, the clients, and also empathy towards the developers we work with that often drives the whole thing. I couldn’t find it, but now that you’ve mentioned it, it seems obvious to me because often, at least in my case,

When I develop some project or push for it, it always starts with a belief about the value it will bring.

Behind what I imagine in the outcome are happy students, satisfied developer colleagues, but also, I expect a bit of recognition. I think there’s a mix of both.

Wrap-up.

As Ahmed and Dorian reflect on their journeys, it’s clear that technical expertise is necessary but alone isn’t enough for success in the Staff Engineer’s role.

Ahmed’s journey highlights the importance of pragmatism and independent thinking, emphasizing the need to be mindful of biases. Dorian’s path highlights a continuous pursuit of organizational improvement through observation and caring. Both stress the importance of daring (in taking initiatives beyond the usual scope, asking uncomfortable questions, sometimes even breaking rules and processes !) and genuine empathy in their work.

In the upcoming second part of this interview, we’ll discuss the impact of the Staff Engineer’s role on team dynamics and the evolution of their interactions with different stakeholders.

Watercolor illustrations by marinaboby