In reality, there is no single formula to be a great tech lead. It’s a demanding position. It requires both sides of one’s capability: the heart, and the mind. Sometimes, heavier on one side than the other, and sometimes the other way round. It is situational, applied differently to different people.
Clippings Posts
For those who aspire to call themselves SREs, or are concerned that others may disagree with their characterization of themselves as SREs, perhaps these opinions can assuage some of that existential dread.
Whilst setting targets might work in some organisations, it’s worth considering whether they provide the signal you expect, and whether the implications of doing so have been properly considered.
Two reasons why building teams in high growth is difficult: can’t assume stable teams, can’t rely on cultural osmosis.
No one would claim that we have things like engineering roles, levels, and career progression locked down, but it all looks quite mature and well-understood compared to the Wild Wild West that is engineering management.
An SRE team is responsible for building software that improves the resiliency of systems, implementing fixes, responding to incidents, and automating processes whenever possible.
So what does it mean to always be quitting? It means “making yourself replaceable”; “deprecating yourself”; “automating yourself out of your job”. You might have heard these more-popular names (which you’ll need to do your own research) and they hint at how to act.
Incidents and outages caused by animals highlight the importance of flexibility and out-of-the-box thinking when it comes to SRE.
I think clarity of communication is one of the most underrated skills as a developer. If the ratio of reading code to writing code is 10:11 then the ratio of talking about code to writing code must be 100:1, especially the more senior you get. Being able to define a problem or explain a scenario clearly, precisely and unambiguously should be something that, in my opinion, every developer strives to nurture.
I am sure you are familiar with the following scenario: a user is reporting to your Support team that something is not working for him as expected. Your Support team investigates the issue and agrees that there is a bug in the system. They open a JIRA bug to the R&D department with all the information they have collected, as expected from them. But then… a furious argument begins on the ticket. Support is saying that they think R&D should solve this bug within a week. The Customer Success Manager is saying this is a critical customer just before renewal. Therefore we need to make all of the effort to solve it within 48 hours, but R&D doesn’t see this as an urgent matter and thinks the bug should be solved within 30 days. Who is right?!