Overview
This is the third installment of documenting my journey as a software engineer.
The previous two posts are:
- The Untraditional Dev
- Transitioning from a Junior / Mid Level Software Engineer to a Senior Software Engineer
In this article, I want to talk about growing from a senior engineer to a tech lead / staff / architect / principal level engineer. Note: Some companies have different levels for the above roles, but in this post, I will lump them together.
Document, Document, Document
As you progress in your career, you will find more and more that you are doing much less of the implementation details of features. Rather, you will start to drive patterns on how a feature should be implemented. This sometimes means to build out a few initial features to follow the pattern, but soon becomes a task of getting team buy-in. And to get buy-in, the patterns need to be documented in a way that is easily consumable by the team. It also needs to be discoverable. If your team does not know where to find the documentation for the new pattern, getting them to follow you on the journey will be a tough road.
Get Good at Presenting
You undoubtably be asked to present the patterns you want to implement in your new role. In order to do this, you should get good (and comfortable) with speaking in front of both people on your team AND not directly on your team.
One suggestion is to write an article (or documentation) on what you want to present first. This organizes your thoughts and serves as a good rough sketch of your presentation.
Another suggestion is to present to your team before presenting to a bigger audience. You know your teammates and will be more comfortable with them as you get valuable practice time.
Also, know your audience. Do you want your presentation from a 10,000 foot, 5,000 foot, or 500 foot view? If you are talking to a more business focused audience, you probably want to stick to benefits to the business. Even if you are talking to a highly technical group, they could still have technical expertise that is not in the category that you will be presenting. In this case, you want to be technical but not in the same detail level as when you present to an audience that is more comfortable working in the same space as the item you are presenting.
Soft skills Are Paramount
When you become a leader, whether it is in software, sports, or really anything else, you need to get your teammates come along with you. To accomplish this, you must be someone that does not rub people the wrong way. Sometimes the best engineers are not necessarily the best leaders because of this. You can churn out line after line of code but if you are constantly telling others on your team how good you are and how bad their PRs are, you will have a tough time getting them to come with you.
To get your team to the final destination, you first need everyone to face the same direction. And the more distributed the team, the harder it is to accomplish this. This means that communication is imperative. One suggestion is to use the collaboration tools (Slack, MS Teams, WebEx, etc) to get a pulse on all of the different teams. Know what they are working on and provide constructive feedback when you see something BOTH good AND bad. I tend to look at PRs occasionally even if they are not assigned to me. I will provide feedback and sometimes send a small PR to illustrate my suggestions.
Also listen to your team and the suggestions they make. Being a leader does not mean you make unilateral decisions but instead you facilitate discussions on the road ahead. Acknowledge when you have made a mistake, praise the team on wins, and bear the load on losses. I have found this helps get you respect from the team and respected leaders get more followers.
I hope this has been helpful. Happy Coding!
Top comments (0)