This big article by John Olspau is called "Being a Lead Engineer" . The first time I read it was about four years ago, when I first switched to my current job, and it really influenced 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 are an important part of the work of the lady. Which, of course, is true!
 
 
But now I see that most or all of the lead 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 Signs Senora from the Olspau article (with whom I fully agree), I want to talk about 3r3-3120. Work 3r3121. which we do.
 
Mozilla hierarchies (senior engineer /staff engineer), maybe a little closer to the "staff" level. 3r3208.  
 

What is the responsibility of

 
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 3r3121. : 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!”).
 
 
3r-33199.  
[b] Write code (obviously). 3r3208.  
Make code review (obviously). 3r3208.  
Write and review design documentation . As with other reviews, a third-party look is likely to help improve the design. 3r3208.  
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. 3r3208.  
Maintain high-level colleagues . 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 this often 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 sometimes saw leading engineers trying to enforce quality standards, repeating their opinions more and more loudly, because they thought their opinion was correct. Personally, I have not found such an approach useful. 3r3208.  
Create new projects 3r3121. . 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! 3r3208.  
[b] Plan the work of their projects 3-3-3121. . The point is to write down /communicate a roadmap for the projects you are working on and make sure that people understand the plan. 3r3208.  
[b] Report in advance project risks . 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. 3r3208.  
Report success! 3r3208.  
Do third-party projects that benefit the team /company 3r3121. . 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. 3r3208.  
[b] Be aware of how projects are related to business priorities. 3r3208.  
[b] Decide when to end the project 3r3r1121. . It turns out that it is surprisingly difficult to understand when it is necessary to stop /not to begin work on something. :) 3r3208.  
 
I put “write code” in the first place, because in reality this task easily slides down in the list of priorities. :)
 
 
The list is missing the item “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 of

 
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 boundary, 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 the technical contribution 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).
 
 
3r-33199.  
Ensure that each employee is rewarded according to merit for his work. 3r3208.  
Ensure that the work is fairly distributed. 3r3208.  
Make sure people work well together. 3r3208.  
Ensure team cohesion. 3r3208.  
Talk in private with each employee. 3r3208.  
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?). 3r3208.  
Manage third-party projects (I have a job at work of any engineer leading the project). 3r3208.  
Be a product manager. 3r3208.  
Conduct sprint management sprint /determine the stages of work for each /conduct weekly rallies. 3r3208.  
 

It is useful to explicitly define the boundaries of

 
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 out 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 define the work, which:
 
 
3r-33199.  
I can do /long-term fit for me. 3r3208.  
I want to do /which is generally pleasant and meets my personal goals. 3r3208.  
It is valuable for the team /organization. 3r3208.  
 
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 3r33232.
 
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, this is good for the team!”, “Well, Someone Should 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! 3r33232.
 
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 this, and I would be interested to hear how other people define the boundaries your work!