Boundaries of tech lead responsibilities
Posted by Lonemagic@reddit | ExperiencedDevs | View on Reddit | 22 comments
Just curious how this varies in other orgs.
For us, I see our design reviews get bogged down from questions like: 1. Who does ops call when this functionality goes wrong? 2. How will we maintain and test this component? 3. What will be the release and upgrade process?
These are totally fair and valid concerns, but I feel like, as a tech lead, I have to present all of these to my manager and are out of my control. These are process related, not specific to the tech, which I'm heads down on. It also distracts from the design review itself, which always seems to take a backseat to these process issues.
What do you think? Is this a tech lead's responsibility? Or is what I'm feeling a result of lack of management support?
outpiay@reddit
These are pretty basic questions for deploying any new application lmao. How are you a tech lead and unable to answer these questions? I would be instantly demoted if I ever told my manager, not my problem on these fundamental questions.
JimDabell@reddit
Who do you think is responsible for answering these questions, if not the tech lead? It seems like you’re waiting for somebody else to step up.
morosis1982@reddit
These are all things that while it may not be totally under your control, you should definitely have some input on.
For example, in my org we have an ops team but they don't know anything about the applications (there are many). Typically they'll get involved if it's something like infra that's got a problem, say the database server is not responding.
The thing about a system is that it's a system. All the tech that goes into making it work, as well as observability and alerting, is part of the technical design.
The good thing is that the latter should have a standard way of doing things so you don't have to reinvent the wheel, but the wording you used begs a question...
How do we maintain and test? What is the release and upgrade process? Who does ops call?
It should be the team that owns the product that answers all of those questions. If that's your team, then that's up to you as the lead. If you have a team lead that is separate to yourself then the who should be up to them.
svenz@reddit
Concur with others, these are exactly the kind of things you should be thinking about in a design review, and as a TL have answers for. Code is just one piece of any production feature.
serial_crusher@reddit
It strikes me as weird that individual projects would get dragged down by these questions. You should establish a standard answer for all of those that applies to as many projects as possible. "who does the ops call" -> either the dedicated ops team (and you have established standards around knowledge sharing, runbooks, etc), or the developers do an on-call rotation. "how will we maintain and test it" -> tests will run as part of the same CI/CD build that all our other features run through, and/or designated manual QA people follow the same basic checklist. "what's the release and upgrade process" -> again, the same process you use everywhere else unless there's a specific reason to change it.
It makes sense if you need to block introduction of a new technology because the roadmap doesn't set aside time to work it into the deployment pipeline, but situations where that happens should be few and far between, and the conversation about adding that scope should be straightforward once the need is identified.
Building the standard takes time, but can probably be done in parallel. i.e. if supporting your current product is some wild west of finger pointing and desperate phone calls to the one tech lead who knows how it works in the middle of the night... you're signing up for more of that on the new project.
If that's going to be hell, you're not blocking the new project because you lack answers to those questions. You're blocking the new project because you have bad answers to those questions. Slow down feature development and invest time into fixing your processes, but to the extent that you still have to do some feature work, keep doing it the way you have been.
Drugba@reddit
This is a really weird question, IMO, but I'll give you my answers before going into detail.
The team proposing the design owns responding to when things go wrong. It's their feature or service. Unless there's something special about what you're building that requires a special process it should be treated the same way anything else you own is treated in terms of ops.
This is what design review is for. Who ever is writing the doc needs to have an answer for this in the review document.to have an answer for this in the review document.
Same as #2. Ideally you already have a process for other services/features that can be applied to the new thing you're building.
Getting back to my first point about the question being weird, your whole question is framed with an individual mentality, which is bad, IMO. Ideally, people shouldn't own things because people can randomly leave, teams should own things because a business has control over when a team is created and destroyed.
A tech lead is responsible for the tech of a team. If your team is proposing a design then, as a tech lead, yes, at some level you are responsible. That doesn't mean you have to answer these questions for every design document your team does, but you are responsible for ensuring that every design document your team does has adequate answers to these questions.
In an ideal world, all of these questions have defined processes in place and your responsibility to your team as a tech lead is just ensuring that anything anyone on your team is proposing follows those existing processes. It sounds like you don't currently live in that world though and it seems like your manager has recognized that. Everything being asked is a fair question and part of building decent quality software. Your team (and by extension, you) need to have answers to these questions.
DeterminedQuokka@reddit
I would consider if these should be in your wheelhouse.
Process is part of the code. 90% of the time ops doesn’t need to even be part of a function breaking the owner of that function should.
Releases and upgrades should be owned by the people who understand the product. How would a random ops guy know if upgrading a package broke something.
Maintaining and testing your code is clearly you.
I don’t understand what job is even left without these things.
Antique-Echidna-1600@reddit
As tech lead, you should be informing your boss of the possible solutions not the issues. The only time they care about the issue is when it's described in a problem space statement in your recommendations. Always assume your boss does not know or understand any process or technology. Their only concern is the people in the PPT triage.
Also, if you're head down working on something. You're not delegating or planning properly.
DingBat99999@reddit
A few thoughts:
Lonemagic@reddit (OP)
sayqm@reddit
you're the tech lead though, you should have an answer
SwitchOrganic@reddit
Yeah, as the lead the buck stops with me.
sayqm@reddit
Putting those process in place are a tech lead responsibility IMO
Lonemagic@reddit (OP)
Yeah consensus is pretty clear, thanks!
obscuresecurity@reddit
If you can't answer those questions, you aren't doing your job as a tech lead.
Seriously, those are HUGE business concerns you should know the answer to.
And a HUGE hint: They shouldn't change much project to project. Your manager is dropping you a big ass hint.
riplikash@reddit
It just depends on the company in culture.
Don't think it really matters THAT much in the end. If you're a lead, you make sure things get done and that process is figured out. You're not "responsible" for it, you're just...responsible.
Sometimes you have weak managers. Sometimes managers are purely administrative. Sometimes managers are overloaded.
Leads just make sure things get done.
casualfinderbot@reddit
For (2) and (3), why are you reinventing the wheel for every design review? Just create a team wide approach that you use for everything
Is this a tech leads responsibility? It’s an important technical decision so obviously you should be making these decisions. Managers absolutely should not be making these decisions if they’re non technical.
Wtf does a tech lead even do if not answer the above questions
krywen@reddit
I feel that:
I believe tech lead duties comprises non only to design an architecture and making technical decisions, but also doing so keeping in mind maintainability, (how easy is to hire or replace eng in a specific skill/lib?), releases and upgrades (perhaps you need support from a SRE/DevOps team?), fixed and ongoing costs.
Side note: the fact that you think these might not be part of tech lead responsibilities suggests (I might be wrong) that your management has NOT been effective at explaining these responsibilities and perhaps are not organising work well.
Lonemagic@reddit (OP)
Fair enough, thanks for the responce.
couchjitsu@reddit
I think, depending on other variables in the cutlure, those could be fine tech lead responsibilities. When I think back to my time as a TL they don't surprise me. As I think about my time as a manager, they're things that I think my TL could handle now. I might have to help out a little from time to time.
That said, I think the bigger issue is that these are brought up every time. Why hasn't a support process been defined? Why are there questions about testing & maintenance? Why does work need custom release steps?
I think if your company established a process for each of those 3 things that'd go a long way. As a manager, if you came in with recommendations that would be greatly appreciated, but not strictly required.
But if I'm answering the same question over and over, I'm looking for ways to never have to answer that question again.
fnbr@reddit
It depends on the organization. I have been at orgs where the tech lead was responsible for this, and I have been at orgs where this was a VP/Director level question. What does your manager say about this?
fortunatefaileur@reddit
these are all pre-existing problems that you have failed to address - the answer should have been written down in advance or at most be a “team X or Y” binary question at some early stage.