These days I'm summing up my role as a TcL, after almost 3 years in the role (I am promoted to the group architect position), after additional 5 years as a server-side developer.
In this post, I will not deal with any technical aspects, I will share the way I see the role, some of my experiences and the ways I dealt with the role challenges, and what things you should try to gain in order to pursue this role.
~20 personnel product team, with ~10 developers (Back End, Front End, Mobile), including offshore. 3 Eng. managers were rotated during my time in the role, and two architects that were above me - site architect (11 teams) and Cheif Architect (30+ teams)
taking the load off the Eng. Manager
Dealing with big teams (10+ personnel) is a massive challenge - knowing the business, taking care of your employees, and delivering good features on time.
This team structure requires a technical authority, that will identify all the blindspots and future risks that the EM can not see - before the customers do, and take care of them:
Technical compromises & storytelling: making technical decisions, that the EM does not have any knowledge or experience with - measuring the value vs implementation effort, and picking the right story when 'selling' the solution (BTW the value can be - exposure to new technologies).
Damage assessment: I will divide this into two sections - A - issues that we found (i.e before the customers) - alerts, monitoring metrics etc.., - B - escalated user issues (or EUIs). During my time as TcL I used to evaluate/triage these issues. In my position, I mainly took ownership of infra issues (DB maintenance, queues, containers, AWS stuff etc..) since I am experienced with these aspects. Regarding other issues, I mainly triaged/helped the developers to shed some light on the issues, identify where the issue originated/point to the right team/person for support. Giving a hand in situations where devs needed assistance.
The On-call lie: on-call rotation is not enough, when I started my time on the team, alerts were rare since the alerting policy was sparse. Having an on-call rotation is not a magic pill for production issues, this is only the first step. The next step is embedding the culture of owning the system, meaning that every morning there is at least one pair of eyes on the logs/errors/APM, dealing with the problems before they reach the customer/wake up us late at night.
Security & Compliance: since we sell our products to customers who demand we will be aligned with proper security standards, we don't have any other way but to put the effort into this. The main posture that I like to suggest is - to be prepared ahead, meaning that your EM will be surprised with the level of readiness the product is at.
Your focus as TcL will be determined by the nature of the team: team dynamics, if there is an additional TcL in the team and EM background. bear in mind that this might change over time.
Personally, I started with an EM with Back End experience, where the challenge was to avoid stepping on each other toes and to get the best technical solutions while challenging each other. After this period of time, I had an EM without Back End experience, where in this situation - you are calling all the shots by yourself, but on the other hand - you own all the decisions, for good and worse.
I think that taking the technical load off the EM is the biggest challenge when done right. I would suggest asking the EM from time to time if there are other areas that you as a TcL can expand in order to better help the EM.
There are much more aspects to this, such as Capacity Planning, Design Reviews, and Rollout Plans which also vary between teams and companies.
excellence leads to frustration
Why is it so frustrating to be on top of your game (as a TcL)?
Making the right technical decisions does not make noise (besides if you save money). On the contrary - if you make a bad decision and fix it - you will be the hero of the day.
Everyone counts on you to be a go-to guy with any problem (at any time, even during weekends and holidays) on one hand, and on the other hand, delegating the work might take 10X to solve the issue in some cases.
EM will bring you into issues you think that others can deal with since he does not know the dev's capabilities well enough (or prefer to get it done ASAP).
What can we do about it?
Know your personal boundaries, and set them up as an iron wall (not that easy).
Talk with other TcLs/TcLs outside of your organization and ask for mentorship (might not be that effective)
Set the expectations with your EM, so you will deal with prod issues for X amount of time weekly (be careful with what you wish for)
setting up your own schedule and focus
One of the hardest aspects junior TcLs are required to deal with is - where should I put my efforts at. I think that this is an ongoing process where you should ask yourself - is the thing that I'm currently doing the most important thing that I can do right now?
Obviously this is a hard question since normally it's not prioritizing less important and more important things, it's prioritizing a few important things.
The best advice I can give you about this is - to keep a backlog of ongoing tasks, like security issues, and external dependencies (for instance you need something from an offshore team - don't wait for the team to respond, continue with something else etc..), so you can play with what you are currently doing, with minimum idle time.
I think that this is the fun part of the role, you get the chance of working with different people in your organization, working on different stacks and technologies, while staying in your own team
Communicating with external companies: I had the pleasure to communicate with about 10 external companies like AWS, Rookout, PDFReactor, Camunda, LaunchDarkly etc.. in context of POCs we had and knowledge enrichment, as well as support tickets for products that we use.
Cross-team impact: I had the chance of 3-4 designs that were crafted by me to be adopted by other teams. This normally happens sometime after the launch itself (i.e prod proof design)
Communicating with the architects: we have a forum where all the architects from our organization are taking place once a week. This gives me the opportunity to be exposed to different problems the org is facing, and to bring my value to the table.
Eventually what makes the difference between a developer and a TcL are two things:
schedule flexibility and focus flexibility
Given you have the technical knowledge, you should have the ability to deliver whatever you need to deliver, and have spare time to play with - mentoring/teaching/helping out the developers:
preparing for DRs, backing them up in decision making
helping out with bugs and prod issues
teaching them about different technologies that are not in use/maximizing current stacks
creating connections with developers from different teams that might help to gain knowledge
Most of the time during my role, it was not that easy to keep a good relationship with all the developers, all the time. There is no such option as saying - this is my authority, do something this way or another, i.e you are required to have a great set of arguments for every idea/decision you make.
how are TcLs measured?
It really depends on your EM relations and the way things work. I think it is easier to be measured by an EM that used to be a TcL or at least has some background in the stack that you used to own.
The key here is to set up measurable short-term goals. The requirement for short-term measurable goals should come up from you, and not from your EM (usually they won't do it otherwise). Base your growth plan on these goals (I would say that short-term is quarterly goals), and during your 1x1s you can talk about the goals and what minor changes are required during the following weeks in order to nail it.