This big John Olspau article is called "Being a Lead Engineer . " The first time I read it about four years ago, when I just started working for the current job, and it really influenced my ideas about this direction of my career.

Rereading it now, the really interesting thing there seems to be one thing, that empathy and helping the team is an important part of the work of the lady. Which, of course, is true!

But now I see that most or all of the leading engineers I know take on considerable help from other employees in addition to their personal programming work. Now it seems to me that my colleagues and I face not so much the problem “What ?? Need to TALK WITH PEOPLE ?? INCREDIBLE ", but with another problem:" How to balance all this leadership work with your individual contribution / programming? How much and what work should I do? ” Therefore, instead of talking about the signs of the seigneur from the Olspau article (with which I fully agree), I want to talk about the work we are doing.

What is this article about

“What does the lead engineer do?” Is a huge topic, and here is just a small article, so you should keep in mind:
')

• There is only one possible description of what a leading engineer can do. There are many approaches to work, and this should not become a dogma.
• I basically worked only in one company, so my experience and views are obviously rather limited.
• Obviously, there are many levels of "senor". This is about the P3 / P4 level in the Mozilla hierarchy (senior engineer / staff engineer), maybe a little closer to the "staff" level.

What are the responsibilities

These are things that I see more as the work of the lead engineer and less as the work of a manager (although managers definitely do some of the above, especially creating new projects and linking projects with business priorities).

Almost all of this work is essentially technical : helping someone to cope with a complex project is clearly human interaction, but the problems we will work on together will usually be technical! (“Maybe if we simplify the design, then we can cope faster!”).

• Write code (obviously).
• Make code review (obviously).
• Write and review design documentation . As with other reviews, a third-party look is likely to help improve the design.
• Help colleagues if they are stuck . Sometimes people get stuck on a project, and it's important to help them! I think about this not so much about “parachute from the sky and delivering your magical knowledge to people”, but rather about “working together to understand the problem and see if two brains can handle faster than one” :). It also means working together, not solving a problem instead of another person.
• Keep colleagues at a high level . For different people, “level” has a different meaning (for my team, this means reliability / safety / convenience of the product). If someone makes a decision that I don’t like, then either I know something that he doesn’t know, or he knows something that I don’t know! So no need to say, “Hey, you did it wrong, you need to do X instead,” or rather just give them additional information that they didn’t have, and often this solves the problem. And quite often it turns out that something was missing for me, and in fact their decision was quite reasonable! In the past, I have sometimes seen leading engineers try to enforce quality standards, repeating their opinions more and more loudly, because they think their opinion is correct. Personally, I have not found such an approach useful.
• Create new projects . The software development team is not a place with a zero amount! The best engineers I know do not keep the most interesting work for themselves, they create new interesting / important projects and create space for others to do this work. For example, someone from my team began to rewrite our deployment system. The project was super-successful, and now the whole team is working on new features that have become easier to implement!
• Plan the work of your projects . The point is to write down / communicate a roadmap for the projects you are working on and make sure that people understand the plan.
• Report project risks in advance . It is very important to recognize when something is not going very well, to inform other engineers / managers about this and decide what to do.
• Report success!
• Do third-party projects that benefit the team / company . I see that many seniors sometimes do small but important projects (for example, create development tools / help establish policies) that ultimately help many people to do their work much better.
• Be aware of how projects relate to business priorities.
• Decide when to stop a project . It turns out that it is surprisingly difficult to understand when it is necessary to stop / not to begin work on something. :)

In the first place I put "write code", because in reality this task easily slides down in the list of priorities. :)

The list is missing the item "to make estimates / forecasts." Here I am not very good yet, but I think that someday it is worth spending more time on it.

The list seems big. It seems that if you do all these things, they will absorb all your intellectual resources. I think that in general it makes sense to pick out some part and decide: “Right now I'm going to focus on X, Y and Z, I think my brain will explode if I try to make B and C”.

What is not the responsibility

It's a little more complicated here. I do not say that such things are categorically impossible to do. Most of the leading engineers I know spend a tremendous amount of time thinking about these issues, and work a little in that direction.

But it seems to me that it is useful to draw a certain border, because some people have a high sense of responsibility for the team and the company - and they are ready to take on everything, and as a result they will be overloaded with work and will not be able to make a technical contribution, which in fact is their main business. Therefore, the establishment of some boundaries helps to determine what issues it makes sense to ask for help when the situation becomes restless. Your real boundaries depend on you / your team. :)

Most of the following are the work of a manager. Disclaimer: managers do much more than what is listed here (for example, “create new projects”), and in some companies some of the above may actually be the work of a lead engineer (for example, sprint management).

• Ensure that each employee is rewarded according to merit for his work.
• Ensure that the work is fairly distributed.
• Make sure people work well together.
• Ensure team cohesion.
• Talk in private with each employee.
• To train new managers, to help them understand what is expected of them (although I think that leading programmers often really come to such an activity?).
• Manage third-party projects (I have the job of any engineer leading this project).
• Be a product manager.
• Conduct sprint-management sprint / determine the stages of work for each / conduct weekly rallies.

It is useful to set boundaries explicitly.

Recently, I was faced with an interesting situation when I discussed my responsibilities with the manager - and we realized that we look at them very differently! We clarified the situation, and now everything is in order, but it made me realize that it is very important to agree on expectations. :)

When I started as an engineer, the work was pretty simple — I wrote code, tried to invent projects that made sense, and everything was fine. My manager always had a clear view of my work, nothing too complicated. Now the situation has changed! Therefore, now I believe that I must determine the work that:

• I can do / long suited for me.
• I want to do / which is generally pleasant and meets my personal goals.
• It is valuable for the team / organization.

The exact wording will be different for different people (not everyone has the same interests and strengths, for example, I am not too good at code review!). I think for this reason it is even more important to discuss this topic and coordinate expectations.

Don't settle for work you can't / don't want to do.

I think it is very important to abandon work that I cannot do or which in the long run will not bring joy! It seems tempting to take on a lot of work, even if you don’t really like it (“Oh, that's good for the team!”, “Well, someone has to do it!”). Of course, sometimes I take on tasks only because they have to be completed, but I think that for the health of the team it’s actually very important that employees do what they like in general and what they can do in the long run.

Therefore, I will take small tasks that just need to be done, but it is important not to say: “Oh, of course, I will spend most of my time on what I’m doing poorly and what I don’t like, no problem” :). And if “someone” has to do this, perhaps it simply means that we need to hire / train someone new to fill the gap. :)

I still have a lot to learn!

Although I feel that I am beginning to understand what “lead engineer” is (already 7 years in my career), but I still feel that there is still much to be learned about it, and I would be interested to hear how other people define the boundaries your work!