The three fundamental stages of an Engineering career

This article is aimed at engineers who need a clear path to guide their career, and at managers who need a clear mental model to identify good candidates and help the engineers they are responsible for grow faster.

This three-stages framework allows you to place people on a scale in less than five minutes of interview and sets a pretty realistic expectation for that person in the workplace.

Context and background

I feel like to be fair to the reader, I need to introduce myself and give some context of how I came up with this framework. Feel free to skip this section if you want to go straight to the core of the idea!

I had a steady linear path in my “engineering” career: I started at a pretty young age with static webpages built with Microsoft FrontPage, then moved to freelancing during my studies, worked for a few different companies, and finally ended up at one of the first french unicorns: Blablacar.

At the time I have always been the dumbest person in the room, comfortably learning from my much more experienced peers, and feeling great about making progress. That very comfortable situation suddenly shattered about four years ago when I decided to start Equify as a founder. I was all of a sudden the smartest person in the room (a room with only me to be fair) and had to deploy quite some energy to get outside advice, something I was not used to doing. As the company grew, I had to slowly transition from a full-time contributor to a more managerial role. And one of the things I was terrible at was evaluating people, evaluating their potential impact on the company, and helping them grow as they deserved. With that in mind, I started to reflect on my own situation, read books, talked to peers, and analyzed what worked and what did not at Equify. This article is a summary of that reflection.

The dogmatic stage

We begin with the dogmatic stage. All people I have met have begun their journey here, I certainly did. From the most gifted to the less talented, this is where we all meet. A person in the dogmatic stage has a few strong principles in which they believe (hence the name), and more often than not thinks that those principles are a one-size-fits-all type of solution. Such principles mostly come from books or blog posts the person has read, or from a mentor sharing their wisdom.

You can easily spot a person in this stage by the topics they bring up during an interview:

“I believe OOP is old school, everyone should be doing functional programming by now”

“I always try to obey the DRY principle in every project I work on”

“NoSQL is definitely the future of data storage, I started migrating from Postgres to Mongo for all my side projects”

What do all those quotes have in common? The belief in a strong principle, and a universal solution mentality. There is nothing wrong with the principles themselves, in fact, they often come from very intelligent people, but you have to keep in mind that people in that stage are mostly driven by what they read or hear rather than by the situation they are trying to solve.

As a person currently in the dogmatic stage, the best attitude to adopt is to first realize that you are in this stage, and to then listen and follow trusted mentors that might deviate you from your principles. It will feel counter-intuitive, but following this process will help you move faster through this phase. A good way to calm the feeling of doing something “off-track” is to ask questions until you understand the motivations of your mentor. If it ever boils down to a question of opinions that cannot be resolved with arguments, it most likely means that the mentor is not yet capable of articulating a convincing argument (still in their intuitive stage). In this situation, you need to help your mentor understand their own reasoning by asking more questions and you need to stay very humble with your own convictions.

Out of all the people I had the chance to hire, the ones that I saw move out of this stage the faster were the ones asking a lot of questions, and the ones genuinely interested in the answers. On the other hand, the ones that performed the least were the ones focused on getting their code merged, and the ones taking feedback negatively as a proxy for their personal performance.

What has helped me the most in shifting people from the second mindset to the first was to explicitly set a clear and honest feedback culture within the company (see the book Radical Candor from Kim Scott), and to explain to them the “dogmatic stage” I thought they were in and what I expected of them: asking questions and learning a lot, not shipping code fast or introducing that new hot design pattern to the company. With clear expectations and goals, people tend to perform better and start transitioning to the next stage.

The intuitive stage

Once you start to detach from your early principles, you end up relying more and more on your so-called “instinct”, sometimes without even realizing it. It is your brain operating in auto-pilot (see the book Thinking fast and slow by Daniel Kahneman). This intuitive judgment is built upon the years of experience you have had and the accumulation of problems that you faced.

A person in that stage has the right answers to questions like “how would you solve X” but is not able to clearly communicate why its solution is better and is having a hard time convincing their peers. This is precisely how you identify them:

“Trust me, I’ve been through this, we should definitely do X and not Y”

“As the tech leader of this team I think we should go with solution A, it sounds much better than solution B”

“In my previous experience it was hard to push my ideas, they often chose a less elegant solution”

In those situations an argument from authority is used, the chosen solution might be the best regarding the situation, people might accept that decision, but they will not be convinced and will not learn much from that interaction. I clearly recall discussions I had where I was the one using an argument from authority, and I can guarantee that it did not feel good. I felt I had the right solution but the part of my brain responsible for communication had no access to why I thought this was the right solution at the time.

When you realize you are at the intuitive stage, the only sane thing to do is to take time to reflect and understand your thought process. I found it to be a very hard thing to do at first, but this is one of those things where practice makes perfect. Talk to peers from outside your company, discuss with your mentors about the situation, and listen to their arguments, not just their conclusions. Then do your best to explain and convince your teammates and don’t settle for the easy way out: practice makes perfect.

It is a very long and iterative phase, and it takes a lot of practice to nail consistently. I think we found a very good framework that helped us move forward in that stage: make everyone (including you) list all the advantages and drawbacks of the solutions they propose. This exercise alone should make everyone grow by being more confident in their good ideas, and more inclined to drop bad ones. At first, you end up with a list of very precise items:

• Pros: we will be able to refactor X without touching Y
• Cons: we have to compute X before computing Y
• Pros: we have a better abstraction layer that hides X and Y

Then you can dig deeper and ask “why does it matter?” for every item until it boils down to very simple concepts:

• Pros: better maintainability
• Cons: worst performance
• Pros: onboard juniors faster

With practice, it became very natural to move from the big idea to the detailed example and vice versa. From now on the question is no longer “what is the best solution?”, but “what are we optimizing for?” This takes all the egos out of the equation and focuses on the goal. This exercise has allowed me and my team to never pull the “team lead” card and has forced us to justify our choices and gain insight into our reasoning.

Pairing a person in the intuitive stage with a person in the dogmatic stage can work if both parties are dedicated to helping each other move up, otherwise, this particular combo will probably slow down both individuals and be detrimental to the team. That is at least the experience I had with hiring engineers at Equify. This is a very rich process, and with time it becomes easier and more natural to articulate concise arguments. This is a sign that you are transitioning to stage 3.

The mentoring stage

Whether you decide to go the expert route or the management route, you inevitably end up in the mentor stage if you can successfully go through the intuitive stage first. In that stage, you have a great understanding of the problems at hand and you become responsible for delivering that understanding to the rest of the team. People in the mentor stage are perfectly aware of the reasoning behind their opinions and its implications. They can now focus almost exclusively on communicating as simply as possible with others.

I found that people in this stage almost always start discussions with a high-level overview:

“In my previous experience, we optimized for maintainability and readability rather than performance because we were still trying a lot of things, I now want to focus on more stable projects”

When you start looking for this type of cues, it becomes much easier to identify such profiles during the first 5–10 minutes of an interview. Those people are a great addition to any team and can have a very positive impact on the growth of their teammates.

People in the mentoring stage will not necessarily have a huge impact on production (although they might), but will definitely save you and your team a substantial amount of time by helping others move up stages 1 and 2. I feel like accepting and internalizing this has made me a better manager. Realizing that the biggest impact I can have on my company is to build and grow my team did not make me a selfless altruist person, but more of a logical and cartesian manager.

This last section is not as detailed and action-oriented as the first two as I am still exploring it, so any feedback or story you can share that might enrich this topic is welcomed!

Conclusion

If you have not read the “Context and background” section maybe now is the time before you take this article as fact. While I feel this approach is broad enough to apply to most software engineers, I would be cautious trying to apply it outside of the field.

I strongly believe that this article will be most useful for people in stages 1 and 2, providing them with a clear way to auto-evaluate and a simple actionable goal to focus on. With this framework in mind, knowing what you need, you will also be able to help your manager help you and greatly improve your experience in the workplace.

Young managers like me might also find this article helpful to internalize things they already “feel” but cannot yet express, a necessary step towards helping people reach their potential. Being able to recognize those patterns in the people you are responsible for will greatly improve your ability to act accordingly and build a more efficient team with the people you already have.

As a last piece of advice to anyone wanting to apply this framework, this is not a “get-rich-quick” scheme, you cannot take shortcuts. You cannot apply advice from stage 2 if you are still in stage 1, I believe that you have to let yourself slowly move through each stage in order.

Feel free to reach out in the comments or on Twitter and share your view!