This is another topic that I often get asked about when I advise companies. It often comes packaged in the format “what do I need to do to attract more senior engineers?” but the core of it is the same: how do you work with senior engineers? As an engineer myself and having worked throughout the years with some great engineers, I have decided to synthesize the answers into this post.
If you are at that inflection point where you need thinkers not just doers and you are looking to hire senior talent then this post should help.

Let them tell you what to do

One of the main traits of a senior engineer is experience, pretty much by definition. And if you want to benefit from a senior engineer you have to find a way to leverage that experience. Steve Jobs famously said: “we don’t hire smart people to tell them what to do, we hire smart people to tell US what to do “.

And the same applies to senior engineer: the best way to benefit from that seniority is to listen to their advise. The best way to make use of their seniority and experience is to let them use it and surface ideas and solutions for your problems. Junior engineers need your attention and your guidance and your suggestions at each step, with senior engineers the roles are swapped: you need to check in with them about how something can be achieved rather than tell them.

Bigger picture

Another aspect you have to understand about senior engineers is they are always looking at the bigger picture and always looking at the horizon. They design and build solutions for tomorrow and for the bigger picture.

This can lead sometimes to conflicting views and ideas to the ones the leadership team has. This is normally caused by one of the 2:

• They don’t have full context: perhaps when presented with the problem they have to solve, certain aspects have been missed out; it could be that there is a fixed timeline to this, or it could be that some components are outside of your team (or company) control, or the budget has certain restrictions and so on.
• You yourself haven’t thought it deeply enough but they did! It’s very easy to get stuck on an idea sometimes and miss out the big picture; this is where the senior engineers help as they are very good at looking at large systems and big picture.

If it is the latter, as a leader, this tells you 2 things:

• Delegation: step away from trying to suggest solutions in the future, and let your senior engineers take care of this — since that’s why you hired them
• Let the voices be heard and learn from being challenged: senior engineers strive for the best solution, they are not challenging your authority, but rather help you reach the best technical outcome. Silencing their voices when they have different ideas than you it’s the worst thing that you can do as it drastically restricts the areas and the ways they can help you.

Curiosity

When you work with junior engineers you will have to spend a lot of time breaking down roadmaps into stories and stories into tasks and even tasks into smaller subtasks and assign small pieces of work to them and work closely with them throughout these so they can execute as well as learn. If you present a junior engineer with a task like “we need to implement a caching layer” they will be overwhelmed on one hand (and demoralized because of the size of the task) as well as not be in a position to make a good decision: when you are junior you don’t know what you don’t know and often you work on (wrong) assumptions and interpretation. And that interpretation is only through the prism of what you know, which again, as a junior, is not too much!

Senior engineers on the other hand, when confronted with a task like the one I just described (“we need to implement a caching layer”) start first by digging deep – and in doing so they end up sounding like my 5-years-old and confront you with a number of “why?”’s :

– We need to implement a caching layer.
– Why?
– Because our platform is slow.
– Why?
– Because we make a lot of queries to the database and those are slow.
– Why?
– Because we do a lot of joins AND our database is slow.
– Why do we do a lot of joins?
– Because of the way our entities have been designed
– Why?
– I don’t know, that’s the way we inherited the system / it’s just the way we designed our entities
– And why is the database slow?
– I don’t know, we just noticed certain queries are extremely slow, that’s why we want to cache them.

Based on a discussion like this your senior engineers will probably go quiet for a bit then come back with a new entities and database structure, a new configuration (be it hardware or software or both) for your database and a proposal to achieve this. Their solution in fact might not be anything to do with the caching layer you asked for!

Institutional knowledge doesn’t mean seniority

This aspect in itself deserves a post of its own I think, but it is worth mentioning here too: a senior engineer is not senior because they learned code and architecture for your product inside out, that is in fact “institutional knowledge”. Knowing where to change some configuration or how to restart a service in your infrastructure is not engineering knowledge, it cannot be transferred to another company or another product. Even more so, anyone who joins a team can pick up the institutional knowledge in a matter of days or weeks, depending on the complexity — this does not mean that your junior engineer has become now senior having absorbed all this institutional knowledge.

Senior engineers have normally a rich and diverse background, and their experience does not come from knowing where a certain file is in a system; but rather how to develop a system so it does what it is supposed to do, it can scale easily and be maintained and deployed easily. More often than not, in fact, senior engineers prefer NOT to build institutional knowledge, in favor of building a system that is easy to comprehend and doesn’t require too much of this “knowledge”. They know that the lower the institutional knowledge required to understand a system the easier it is for anyone to come on board and understand and help with such a system — which lowers the entry barrier for any new member of the team.

Open to collaboration and mentorship

Most senior engineers I have managed or worked with have a very open attitude to the code and architecture they are working on and in most cases constantly look for collaboration opportunities. Ask a senior engineer a question about what they are working on and why made a certain decision and they will start showing you code, tests they ran, industry articles and so on and more than likely ask for your opinion.

This is extremely useful when you have a mix of junior and senior engineers in the team, as the junior folks can benefit an learn a lot from this attitude, as they get to experience the thought and learning process a senior engineer applies. As a leader of an engineering group, this also has the nice effect of reducing the need for you to be involved at every step in mentoring and helping develop your junior engineers: assuming your junior engineers have a curious nature and are looking to learn, being next to a senior engineer opens a world of opportunities for learning for them.

As I mentioned before, senior engineers normally look at the bigger picture — and often talk to other teams to build the mental bigger picture. If you are a leader fortunate enough to work with senior engineers, it is your job to foster and develop this collaboration, connect them with other teams so they can learn, introduce them to other departments, architects, engineers, leaders: working with these other teams will help them get a better context around the overall platform and this categorically leads to them being able to make solid decisions.

Show them the direction, let them tell you the path

Probably the most important aspect, and a symbiosis of all of the above: when working with senior engineers you just have to tell them what your destination is, they are the ones who will craft the path. Give them full context and let them help you carve out the path.

The quickest way to demoralize a senior engineer and cancel out their seniority is to give them small tasks without a clear vision as to why those are needed. You are effectively transforming them into doers and not benefiting from the thinking part, which is where they excel. You can of course use a senior engineer as a doer, as an executioner — and they understand that part of the job is doing that too! — but not using their full skills and experience means often that you have made the wrong decision in hiring them. (What is worse they quickly realize that and walk away — and there goes a lot of effort time and money you put into hiring them and you find yourself back to square 1.)

Watch out for motivation

I recall a particular case where a senior engineer who I know has been asked to work with a team which was in need I was told of senior help. The individual jumps right away at the opportunity to get involved in this work but quickly becomes demotivated to the point of nearly leaving not just the team but the company. (In fact it is at this point I got asked to help which was nearly too late.)

When talking to the team and the individual a few things jumped to my attention right away: the leader of that team was very junior and not too knowledgeable about how to manage the workload of the team or how to manage the engineers. Also, all of the engineers in that group were juniors — which justified of course their asking for senior help.

The problem was that the senior engineer started asking question right away about what does this component do? Why is this working like this? Why are we doing this report? — effectively “What is the bigger picture?”. The manager, used to distribute small tasks to junior engineers felt immediately insecure and threatened by this; even more so, the manager was used to judging performance by the number of such small tasks each member of the team would complete in a week/month; but in this case the senior engineer did what any senior engineer would do: build the mental picture of the overall system, so the immediate output was way slower than the other team members.

The manager of course decided to talk to the engineer and inform them their performance is not what they would expect; with no way to get his questions answered , no visibility into the future, a manager who feels threatened and his moves restricted, the engineer I mentioned was as I said on the verge of leaving the company when I got asked to help.

The solution: have the manager spend some time to provide context, talk about some of the team long term goals and this opened up a few avenues for the engineer being able to employ his skills and work on some of the long term needs. (And of course, had to advise for some coaching for the inexperienced manager also.)

Conclusion

It is quite easy (especially for inexperienced managers) to treat a senior engineer as another simple cog in the machinery and dish out small pieces of work same as with all the other team members. This however means you are not benefiting from everything a senior engineer can offer, and often leads to very poor retention. If you decide to hire senior engineers or you want to attract them, you must build a culture of empowerment and be prepared to listen to the voice of experience.