How much technical discovery should the tech lead do while writing the ticket versus the engineer who picks up and works on the ticket?
Posted by Tiaan@reddit | ExperiencedDevs | View on Reddit | 18 comments
I'm a senior dev moving into a tech lead role. I've noticed something throughout my time in this role and am trying to understand what is normally expected regarding technical discovery.
Here's an example:
As a senior dev, I often get tickets with high level requirements eg "we want to achieve this, implement this feature, etc" so the goals are clear, but the exact steps required to get there may not be clear up front. When presented with these tickets, I considered the "technical discovery" portion to be part of my work to implement the ticket, and would work hard to work with engineers on other teams, product, stakeholders and others to flesh out these requirements and implement the change.
Now, as a tech lead, I've been trying my best to write tickets for the devs that are detailed with as many of the requirements fleshed out as possible, but they still either come to me often for "technical discovery" questions, or they just ignore any ambiguity and put something up in PR and rely on me to resolve the ambiguity as the PR reviewer - so what ends up happening is that I end up still spending a lot of time uncovering the technical requirements myself which seems to defeat the purpose of having devs work on these tickets in the first place, as then what's left is the easy part - plugging it into claude/AI to generate the code and put in a PR, and I can do that myself..
These are senior devs as well, not junior devs.
Is this how it normally works? Was I doing more than what was expected from a senior dev, or am I doing too much now as tech lead?
metaphorm@reddit
a lot. like twice as much as you think you need.
QuietSea@reddit
Do you mean like im the form of a timeboxed spike?
Maybe my shop has it backwards, but we had a tech lead that would spike every single feature they got and mamagement was getting frustrated by it so they tried to reduce it. To me that seems like more of a reflection of poorly defined stakeholder requirements...
Also, I think there's some value in letting juniors doing discovery once in a while with a close mentorship loop. They gotta learn that skill at some point to become senior.
SolarNachoes@reddit
There is no one size fits all. It will depend entirely on the project, the scope, the team, the business process, your history, your preferences, requirements, etc.
tizz66@reddit
We always aim to have the engineer who will be picking up the implementation be the one who does the technical discovery too. It's just easier to avoid context being lost. We always treat technical discovery as a separate task, not as part of an implementation task.
As tech lead I review discoveries and work with engineers to shape them to their final outcome, discuss discoveries with architectural teams etc.
sean9999@reddit
This is a great question. The answer will depend on non universals like what your culture is like and how much complexity goes into each ticket. I think devs should do their own discovery. You should provide high level requirements.
ugh_my_@reddit
Or you can just talk to people instead of reading/writing tickets
Isogash@reddit
Ever the question.
The way I sway is towards whatever creates the most effective team. To me, that is to build engineers up to a state where they are taking initiative in fast iteration and getting a good result (not just "a" result) as soon as they can, and not wasting time in discovery if it would be quicker to just do the real work and ask questions when you need them. So in my view, you were doing the right thing as a senior dev, and as a tech lead your goal should be to guide your team to operating on that level.
To do that, you'll need to challenge team members to take that ownership of discovery, but also protect them from the increased risk of failure that increased ownership brings. In practice, that means you lead by example, you're attentive to ensuring they follow that example, and you build trust that you'll back them up if they make decisions.
How inidividual people will respond to being pushed to "level up" is highly variable, so understanding their motivations and personality first can help a lot. Generally, you need to be attentive and listen to what they need. When people feel heard, they trust, and when they trust, they listen.
You can't win with everyone though, some people will just resist for reasons you won't be able to change.
PsychologicalCell928@reddit
Hmmm…. Does it make you wonder why you’re moving into the tech lead role and they are not?
Simple truth: there are people who care about doing things in the best way possible. They tend to do things carefully and completely at the beginning.
There are people who are a combination of think-and-do. They opt to think a bit, then build a bit, then refine their thinking, ….
There are also people that like crisp lines between requirements gathering and documentation and coding. That is, if it’s not specified in the requirements - it isn’t going to be added.
Programmers and engineers come in all variety of personalities and are shaped by their experiences.
I’ve seen new hires fresh from college who are exuberant get hired by places with very firm fixed lines of responsibility. You can see the enthusiasm being trained out of them by comments like ‘stay in your lane’ and/or ‘write your thoughts in a memo or a ticket’.
The best tech leads steer the engineer towards what seems like a good solution while recognizing that the engineer upon further investigation may spot flaws requiring a different approach.
Often the best approach is a verbal whiteboard discussion early on in the process. Early on in’s important because people quickly become vested in their approaches once they start implementing.
NeckBeard137@reddit
I aim to remove ay unknowns. If it's an unknown and I can't/don't have time to look into it, it gets a spike ticket.
The tickets are formatted to be fed to agents.
vansterdam_city@reddit
As a tech lead my goal is to make sure the desired outcomes are clearly defined. I want it to be clear what the output should do.
Technical requirements and implementation details I try to leave something for the engineer doing the task to figure out. If it’s complex enough I will make one of the tasks be a TDD.
You want folks to “read back” their understanding somehow, to make sure they have internalized it. I think most engineers also enjoy some space to be autonomous. Super detailed requirements inside tickets rob them of opportunity for both.
kalexmills@reddit
Can confirm this. Receiving a dictated solution, it feels like I'm being asked to own a particular solution rather than own the problem the solution solves. If that solution doesn't end up working out, I end up going back to the engineer who proposed it to make sure I'm not missing something. This just wastes both parties time, so delivering a clear understanding of the problem is best for all involved.
symbiatch@reddit
I would say it depends on the task and situation. Not everything should be ready chewed in my eyes, but if there’s known things they should be presented. Like if they need to use a specific service, take into account some future feature, anything like that it should be said.
But if it’s more of regular work then it’s up to the dev taking the ticket to decide. They should know how things work there and make correct decisions. Of course they can also ask if there’s something unclear or larger things, but usually shouldn’t be necessary.
We get by just fine with not a lot in tickets usually, except these specific cases which I mentioned.
Pleasant-Memory-6530@reddit
There's a few things to unpack here:
Assuming the answer is "yes" to both of those, then the other thing I'd say is that this kind of proactivity /ownership massively varies between developers (including developers at the same level).
Pre-LLMs I think this was probably a good thing. It could be helpful to have a few people on the team who were happy to just plod through well defined requirements, and were experienced enough to do so competently.
I'm not sure the industry has really confronted yet what happens to these non-proactive devs now LLMs are so effective...
SqueegyX@reddit
I think it really depends on the task and the trust level you have in the implementer. A junior (or a contractor) will require more explicit guidance than a senior who knows the system and has been here for 3 years.
Also if I have a strong opinion about the data model of a thing that may not be obvious, for instance, it may be worth calling that out but leaving a lot of other implementation details unsaid.
I think about it like: write as little as possible that ensures the correct outcome. And for what you don’t say, let them be smart, if you can trust them to indeed be smart.
x-jhp-x@reddit
they still either come to me often for "technical discovery" questions, or they just ignore any ambiguity ... so what ends up happening is that I end up still spending a lot of time ... myself which seems to defeat the purpose of having devs work on these tickets in the first place
You are right on target with most of your thoughts. The engineers are making you do more work. I don't know why, I would consider most of them to not being doing their jobs, but you'll need to find out more. Have you laid out role expectations with a manager? Have you talked to your manager about better task separation? This needs to be an internal discussion with your manager and team, not just about what role the other devs are doing, but what your role is as well.
I think one thing to be careful of is that your role is also to help grow your engineers, and have them take over the tasks you are doing, so if you can, give them room (with guidance) on implementation, and allow them to architect some solutions. Your team is obviously not there yet, but one thing I've seen tech leads struggle with has been getting input & growing other team members into taking over a tech lead position themselves.
SqueegyX@reddit
I think it really depends on the task and the trust level you have in the implementer. A junior (or a contractor) will require more explicit guidance than a senior who knows the system and has been here for 3 years.
Also if I have a strong opinion about the data model of a thing that may not be obvious, for instance, it may be worth calling that out but leaving a lot of other implementation details unsaid.
I think about it like: write as little as possible that ensures the correct outcome. And for what you don’t say, let them be smart, if you can trust them to indeed be smart.
Gxorgxo@reddit
Why don't you do the discovery phase with the developers and the other stakeholders?
SafeEnvironment3584@reddit
Well, you need to triage the questions and push back some of the responsibility. You might ask them what they have tried, what were their thoughts or where they tried to look for information. Ideally you shouldn't be an asshole, but there should be a clear expectation on the engineers to do some work before coming to you with questions.
Of course if they are new grad or junior, then it makes sense to give more detailed tickets