The main aim of this post is to give an overview to engineers about what they need to learn and how to grow themselves to be able to move to the senior level.

One good way to think about it is looking for a teammate or an engineer in the company that is rocking at the senior level, and try to learn from their actions.

The Senior Software Engineer

This is a level for strong engineers. From this level on, it is not only about engineering skills, but also having a bigger vision of the product and helping other engineers around to also improve and grow.

What you should be able to do in this role

You can take complex requirements for projects with multiple stakeholders and dependencies on other teams, do research, put together technical design documents, create Epics with Stories and Task breakdowns and lead other engineers to implement the solutions. You are able to work with outside stakeholders and dependencies and clearly communicate technical solutions, plans and deadlines.

Your work touches your peers and your team more than before. You bring solutions and proposals to the table that affects coding style, workflows, planning, grooming, scoping or anything else that the team does. Your work starts to more and more elevate the whole team, instead of just elevating you as an individual contributor.

You are able to lead other engineers and challenge all parts of the product development progress like:

Challenging the product requirements

• Do we really need to build this?
  It is ok to challenge the product decision and if it is something that is needed to be built it should be very easy to explain.
• Are we making simple things complex?
  With every development, the goal should be improvement of the product and adding value to the customer. If while being introduces the next development you understand it will not do any of those, it is your job to challenge and point it out.
• Does the effort versus the created value make sense?
  Are we building something that has a ton of complexity and needs a lot of effort and the outcome would be minimal? When the effort seems high compared to added value, it is crucial to look for clear ways to cut corners and make the effort and the value match more.

Design

• Does the UX make sense?
  The classical explain it to me like I’m 5 years old. Building UX that is smooth and easy should be the goal, making things complex, crowded or just cryptic will not benefit anybody.
• Is it technically reasonable to add complexity that the UI/UX demands?
  Designers are well, designers and sometimes they want to build very beautiful and delightful experiences, while we should not discourage them from this path to greatness we should balance the reasonable effort and the idealistic vision somewhere in the middle.
• Can we reuse something we have done before?
  The smartest work is the work not done. If you can have big wins by using components and solutions created in the past, you should always try to do it. It, of course, helps if you build things to be reusable in the first place.

Release plan

• Can we split the solution into multiple parts and release them separately?
  Iterative releases are great, allow having more focused development with isolated solutions and give more feelings of success as a part is shipped. Big chunks are hard to understand, hard to review, hard to test, so whenever possible chop bigger things to pieces and take them on one piece at a time.
• Can we extract essential things and ship them fast and work on fine-tuning later?
  MVPs and follow-ups is how I call it. Make the most important and essential concept work and give it to the customers or a set of customers. Get feedback and track the usage. In many cases, this feedback will make you change the direction and you will build something different from the initial big idea.
• Should we deploy with targeting, A/B test or push to everybody at once?
  Depending on the expectations for the feature, different logic may apply. If it’s about choosing direction then you need A/B tests, if it’s something that is already proven you could do full release etc.

Technical

• Do we have something in the pipeline that would already solve the problem we are trying to solve?
  There is no reason to put in effort to build something if you know that you have a refactor waiting in a few months. Having the full picture and understanding of the technical direction is a must.
• Does the proposed solution make sense and is it optimal, clean, matches our code style?
  With time the style and direction of solutions will be more clear and when building new things using the already proven solutions is always more stable.
• Are we creating similar components to the ones that are already present, should we make the component universal?
  You need to understand if the service or solution you are building is unique enough to be its own special solution, or if it is generic enough to be universal. Even if the solution is pretty universal, you need to take into account to keep different domains separate so it is easier to maintain and build on top of them.

You should ask questions a lot to challenge both product and technical solutions and direct attention to missing pieces in discussions. You should always be able to think ahead and see how the current specific change will affect future developments.

Let us illustrate the expectations of this position with a story

Story of Average and Beyond

A certain farmer had become old and ready to pass his farm down to one of his two sons. When he brought his sons together to speak about it, he told them: The farm will go to the younger son.

The older son was furious! “What are you talking about?!” he fumed.

The father sat patiently, thinking.

“Okay,” the father said, “I need you to do something for me. We need more stocks. Will you go to Cibi’s farm and see if he has any cows for sale?”

The older son shortly returned and reported, “Father, Cibi has 6 cows for sale.”

The father graciously thanked the older son for his work. He then turned to the younger son and said, “I need you to do something for me. We need more stocks. Will you go to Cibi’s farm and see if he has any cows for sale?”

The younger son did as he was asked. A short while later, he returned and reported, “Father, Cibi has 6 cows for sale. Each cow will cost 2,000 rupees. If we are thinking about buying more than 6 cows, Cibi said he would be willing to reduce the price 100 rupees. Cibi also said they are getting special jersey cows next week if we aren’t in a hurry, it may be good to wait. However, if we need the cows urgently, Cibi said he could deliver the cows tomorrow.”

The father graciously thanked the younger son for his work. He then turned to the older son and said, “That’s why your younger brother is getting the farm.”

At the senior level, it is expected that the engineer looks further than the immediate task before them and asks questions to challenge and improve the initial task description to find smarter, more valuable solutions. Senior people usually have enough knowledge and drive that they want to create their own work. This means that when working on a task, they understand the needed follow-ups or further developments and create and plan these after the initial development ends.