Jernej Virag explains how to become a Senior Developer

In Meaningful work interviews I talk to people about their area of work and expertise to better understand what they do and why it matters to them.

Jernej Virag (LinkedIn) is a Technical Lead / Manager at Google. We discussed how mid-level developers can become Senior developers and how to ensure that you can deliver what you promised as a technical lead.

How do others introduce you?

They usually introduce me by explaining how my name is pronounced 🙂 My current role is what they call a TLM – Technical Lead / Manager. It’s an informal role that was created because Google tends to have a lack of engineering managers on the engineering track and engineers tend to now also take up a mantle of managing smaller teams.

I’m currently one of the technical leads on the Android Google Assistant project. I’m responsible for the core architecture of the Androids, Phone Assistant, together with about ten other senior engineers and architects. We form a kind of council, do design reviews, work on basic architecture, support our teams and ensure that our product works on your Android phone.

What kind of seniority levels would you see in a team?

The usual team size at Google right now is around 10 to 15 people. About three or four are Senior Engineers, one or two Staff or higher. The rest are about half mid-level Engineers and half Junior engineers. The distribution between teams varies, but it is rare to see a team composed of mostly senior engineers.

How would you define a Senior Engineer?

At Google, we think about seniority in terms of responsibility. You are an individual contributor when you get a task that you work on yourself. It could be a big task like owning a whole piece of User Interface or a library.

The requirement for the Senior Engineer role is to be a go-to person for something. You need to be a person that other engineers ask for advice and to make technical decisions. To be successful at this, you need to think in terms of “Why are we doing this?” and also be able to clearly communicate the reasoning behind decisions to others in your team. You also need the authority and technical knowledge for people to trust you. And that trust is critical – most senior engineers aren’t managers of the teams they lead, so people won’t listen to them if they don’t have enough trust in the team.

You need to prove three things to get to the Senior engineering level. What I just talked about is Leadership – gaining trust and being able to influence other people to follow your designs.

Another aspect is Impact. To demonstrate impact, you need to show that your work is useful and helps the overall company bottom line. It’s a measure of how useful your work is to the company and others. The company needs to understand why it’s paying you. And a senior engineer needs to demonstrate that their work impacts more than just their team in a measurable way. This has unfortunate side effects of the infamous launch-centric promotion progress process. It’s easier to measure the impact of newly launched features than justify and explain future usefulness of cleaning technical debt or improving infrastructure.

The third one is Technical Complexity, where you need to show that your work is sufficiently complex to be worth the senior engineer title. This means that your work is more than just putting some buttons on the screen or running simple CRON batch jobs.

From a practical perspective, to get promoted, your manager needs to give you a chance to work on a project where you’ll be able to clearly demonstrate those three aspects. After that, it’s all on you.

What’s at the core of being a Senior Engineer?

It’s about always asking one question – why? Why are we doing what we’re doing? Does this product, technology, approach, business strategy, architecture, library choice, language choice or any other decision make sense?

If you keep asking yourself why and writing down the pros and cons, you will usually end up with good decisions, especially if you give it to other people to scrutinize and to contribute their ideas. Then you iterate on feedback with fresh eyes until you’re able to make an informed decision.
The main development I see with junior and mid-level engineers is that they’re cargo culting and not thinking their solution through to understand what they’re trying to accomplish. They’ll decide on a technology and architecture based on an emotional hunch, “easiness” of implementation and their limited skillset.

Growing to senior engineer is where you go from I’m taking Docker because everyone is using it to I’m taking Docker because of these upsides which outweigh these downsides. When you can adapt to this mindset, everything else follows. 

They say “a good engineer has to be lazy”. But a good engineer needs to be lazy in the right way. There’s workplace laziness where you’re always trying to find ways to minimize the amount of work to reach your goals. If you’ve saved three months of work, your team will get better results than if you’d worked for three months. That’s the good kind of laziness.

But what’s not acceptable at a Senior level (or any other level really) is to be intellectually lazy – where you decided because it emotionally felt like the right thing, not because you’ve spent time thinking it through.

My favorite example of this is when you’re building a new product, and you know that you will need to internationalize (i18n) at some point. What I see junior engineers do is just ignore the requirement “because we don’t need to think about it yet”. Then one year later, you find out that your libraries don’t support i18n. Now their team is losing to their competitors because they need to rewrite large parts of your technology stack instead of adding user value. 

Instead, they should think about how to be prepared for i18n in the planning phase. Ensure that when they pick libraries, they support i18n and architect the backend with this in mind. Add i18n as an item to the checklist when evaluating different solutions. It doesn’t mean they should actually add the i18n support, but they should think about it. Don’t do “manual” work but still do “thinking” work.  And this is a tough mindset to have, and I even see our teams struggling with it. Think first and then build.

How do you build this culture of asking why?

Trust, I think, is the only answer here, and that’s why it’s so hard. When it comes to trust, business needs to trust engineers, and engineers need to trust business, UX, and everyone else.

It’s really, really hard to assemble good teams. This is where big corporations have the most significant problems. When you get a direction from high-level leadership it propagates down the hierarchy. At every level, people are trusted to drive the initiative forward and document their thinking. The issue is if they have the trust of their peers.

One of the significant improvements we made in our teams was to have regular design review sessions with senior engineers across our organizations. Engineers come to show their design and then we talk about it. Depending on the tone of the conversation, you either gain or lose trust. If you’re a senior person and start your feedback with “Hey, why are you building your feature like this? This is stupid; how could you do something like that?” – it will result in people not coming to you and asking for yout opinion. You lose trust and those engineers aren’t going to learn from you. We both know developers that behave like this. Behave like programming is some kind of ego competition where you need to win; behave like they always know better and they need to constantly prove it. There’s also a different way of discussing: “Hey, you kind of forgot this, this and this. We used your proposed design already in product X and there we hit this issue, there’s the post mortem document for a production outage.” 

Just by changing the tone and getting your ego out of the way, people are more likely to listen to you and more likely to come to you and say,” I don’t know this. This doesn’t look great to me, but it’s the best way I know how to implement this. Can you help?”.

The above mindset continues into a culture of blameless post mortem. If you actually reach that point, you have people who can openly discuss everything they did wrong. The end result isn’t people inflating their egos by tearing down all the things you did wrong. It’s a conversation in a different tone: “These six things we did are the cause of a 16 million user outage. We need to work together on this to fix it across four teams.”

It’s tough because as soon as teams grow, it’s so easy to lose the personal connection with the people on the other side. Especially when working remotely, where the other person is just a face (or even worse, an avatar) on the other side of a video call. You stop seeing them as your allies but as people slowing down your path to project launch product launch, causing you to do extra work during weekends.

Can you introduce the practice of asking why from the bottom-up, or does it need to originate in management?

I think a good engineer can start this practice as long as they’re the communication firewall between their team and the outside. A single team manager can trash trust, basically, within weeks, if they do it wrong.

I think you can do it in a small team where you can cultivate trust. There needs to be a clear communication firewall where the lead needs to step in and protect the team from outside influences. 

At this point, it becomes a question of larger organizations’ style. Google is not a top-down organization, so it’s up to teams to decide how they want to work. In a more top-down organization, your team practices can help propagate these ideas to management.

How can a junior developer become better at the practice of asking why and related skills?

Just… ask yourself “Why?” in the context of the tools you are using. Think about why you chose Python? Why did you choose your library? More importantly, read other peoples code and think about what decisions they made. In my field, level up by having Android engineers go and look at Android source. For some reason, that’s a very scary proposition for most people, although it’s all there – a single click away.

When you find something broken, you can ask yourself – “why is this built like this?” or you can go to the original code author and ask them, “why was this built this way?” Most of the time, you’ll learn something new. If you’re lucky, it’s not going to be just the technical part but also the organizational part. The latter is important as well. You’ll hear stories of how the organization approaches different risks, past failures, and how they try to mitigate that. You’ve now learned important things about the culture, and you can prepare your projects better. 

Sooner or later, you’re also going to be the person that knows how to build things as well. The more knowledge you have, the more you need to learn how to communicate it. The reality is that most of this needs to be written, so you need to practice and develop this skill. It also tends to be in a format of answering different whys – why did we choose these things and the other options we considered. Practice writing and explaining your whys. As you get better at it, you start using this skill automatically in your emails. You explain things better, and that leads to increased trust. 

What should someone who is currently working in a small company and can see themselves not growing as an engineer anymore, do? 

The easiest way is to go work in a team where you’re not the smartest person in the room. It’s tough to grow if you’re not challenged. It gets even harder if you’re on a team that doesn’t need to change because you’re wholly dependent on outside sources. The Internet is full of blog posts written by people with two years of experience who never lived with their decisions. The sad part is, to become an excellent senior engineer, you need to live with your decisions for the next few years. It also helps to join a team where you need to live with someone else’s decisions from five years ago and see all the ways that they can break.

You can always write code and deploy it, and it will work for the first year. And then the second year, probably as well. And the third year, your startup will fail because it can’t change your codebase to follow the market. You need to have these kinds of experiences to grow as an engineer.

If your team doesn’t challenge you to grow, read books, watch lectures, follow blogs. Conferences are starting to be a thing again and they’re full of talks where people explain what they learned. Find people on the web that are smarter than you and can tell you what you’re doing wrong. Read other peoples code and look at the massive open source library of software as an inspiration.

How do you know that the engineering team you’re planning to join will challenge you to grow?

My tactic is to go and talk with the prospective future team members. Longer lunch works well, or even a virtual meet the team. You can quickly see, within an hour, if new team members are actually interested in growing, if you can have a good technical debate with them, and how they approach working on their project. I’m also checking if they can answer the “whys.” My favorite questions are usually around the things that went wrong and what they learned from that.

It’s also not the end of the world if you join a more junior team. You can use this opportunity to level yourself up in leadership skills and create a framework that will level up the other people on the team. It will be challenging because you don’t know what you don’t know and what you’re doing wrong. You will need to get into a feedback loop of improving yourself and the team. You will spend a lot of time practicing your explanation skills to explain things to other people to make them better. You’re not going to grow fast as an engineer, but you’ll still grow.

As a team lead – what kind of things are you saying no to?

One of the significant mindset shifts that I had to do when I came to the team lead position was protecting my team’s time. At this level, you start saying no to everything that doesn’t fit your team’s direction or vision. You don’t want to take unplanned maintenance of a project you are not responsible for. Your team will not get rewarded, grow, and you’ll look bad because you won’t deliver on your core responsibilities.

In a startup or a small company, that means not doing projects and features that are not valuable—not doing rewrites into a new library stack or adding features that only a handful of users want. These kinds of things won’t bring in more money, and they’ll eat away your time.

When I get a request from my team, I ask for a meeting, and we start talking about how it makes sense for my team. What’s the core part of it that will make sense in terms of metrics, goals, and promotions for my team and a good product.

I first need to understand the scope of what the other team wants us to do. This makes it easier for me to go to Leadership and request additional resources and changes to OKRs. I want to make sure we don’t work on unrelated things.

What are some books or resources that you recommend to people on your team?

Well, I need to start with our own books which explain lessons learned on how to approach good software engineering:

Software Engineering at Google – Lessons Learned – Describes lessons learned from the software engineering process at Google.

Google SRE Books – Books describing the processes Googles SRE use to make sure that services run stabily and meet the quality bar.

The Architecture of Open Source Applications – A series of books talking about how popular open source software actually works under the hood. Useful for bite-sized reading.

The Manager’s Path – Essential pre-reading for anytone thinking about switching to the Engineering Manager career and what that entails.

Spring Into Technical Writing for Engineers and Scientists – A great beginners book for technical writing.

Working Effectively with Legacy Code – Sorry engineers, legacy code is the default state of things in software and you’ll need to handle it well.

Great Conference Talks:

Architecture: The Stuff That’s Hard to Change – Dylan Beattie – How to approach and architect good systems.

Expecting Professionalism – Robert C. Martin – A good summary on how a professional team should approach solving problems. No, it’s not Clean Code related, put away pitchforks please.

Simple Made Easy – Creating simple things is impossibly hard and this talk makes it a bit… easier.