What are your expectations from a lead developer?
Posted by dartungar@reddit | ExperiencedDevs | View on Reddit | 29 comments
I am a senior SE (7yoe), doing backend almost exclusively nowadays.
I've been with my current company for \~10 months now and quite enjoying it - it's a bit hectic with tight deadlines and a lot of legacy, but there are a lot of fun challenges and the company's product (dating site which tries to be wholesome, as contradictory as it sounds) is a lot of fun.
The work is organized in several streams (we currently have 3). Every stream is doing one or two major features at a time, and has a mix of FE and BE engineers and couple of QAs, totalling at about 7-10 people and changing shapes depending on what feature we are doing. No sprints, thankfully (but deadlines are quite tight).
Each of these streams has a "lead". I wouldn't call this position a "team lead" (although it might be?); lead's function is to coordinate work, answer "streammate's" questions, and generally try to maintain momentum. For most of organizational and "business-y" stuff we have a PM who is cross-team.
Recently I was offered a "trial run" of one of the streams and agreed; doing this for 2 months now. It's quite fun - I love helping people and the feeling of responsibility, having a (moderate) say at the decisions made regarding the feature we create, trying to keep momentum while not micromanaging, and communicating with PM and business to try steeammates' lives easier.
This is my first time doing this and I wonder - what does this role look like to you guys (and gals)? Is it a team lead, lead SE, or something else entirely? What do you expect of someone in this position? Do you have any advice on what mistakes to avoid?
Cheers!
Eligriv@reddit
Lead level is about team efficiency : treat your team's work as a flow and lead continuous improvement initiatives.
Common problems are : rework, passivity, dependencies, local optimizations, entropy.
I would say a lot of tools and answers can be found in extreme programming practices (agile before cooptation by consulting firms for the young faces)
Own-Dot1807@reddit
Utilizing a methodology like Agile do help on the day to day activity. Unfortunately most teams never read or understand the agile manifesto or the chain of thought behind these methodologies. Most teams start wasting time on the seremonies but dont get the benefits since they dont actually apply the philosophy. It takes experience to really feel why people and interaction is greater than processes and tools…
Own-Dot1807@reddit
Sometimes it helps inversing the question: How can I be a really bad lead dev?
Not providing psycological safety so that the team mates get burnt out and quit.
Not utilizing the teams potential by failing to delegate.
Not communicating with the team or the other stakeholders sorounding the team so that the work gets missaligned in regards to expetations etc.
Responsible_Sir_7423@reddit
Expectation that often gets missed: the lead should be the person who makes ambiguity smaller, not the person who escalates it.
When something is unclear, the IC’s job is to surface it. The lead’s job is to either resolve it directly or make a decision about who resolves it and by when. The shift from “here’s the problem” to “here’s the problem and here’s what I’m doing about it” is most of the transition.
nkondratyk93@reddit
honestly the expectation that they should be the top coder is a trap. I've seen that pattern fail a lot - the lead spends all their time coding, no one's setting quality standards, team just drifts. the actual job is making the team's output consistent. that means reviews, patterns, unblocking people. not necessarily the best PR.
rupayanc@reddit
the thing that separates a lead from a strong senior IC in practice is that a lead has to make decisions stick across a team, not just locally in their own code. i've worked under leads who were brilliant coders but terrible at this because they couldn't explain their reasoning in a way that convinced anyone. my one expectation: you should be able to draw the system on a whiteboard, explain why it's shaped that way, and tell me which parts you're least confident about. the "least confident" part matters most because it shows real awareness of technical risk.
SZeroSeven@reddit
My expectations from a technical lead are just that: they lead on the technical decisions for the team and being the person that can filter the technical jargon and shit that others might try to bamboozle PM's into thinking they need to bring work in (when they 99.9% of the time don't need to).
My expectations from a team lead are closer to what I'd expect a traditional engineering/line manager: 121's, holiday approvals, filtering the shit coming down from above etc.
throwaway_0x90@reddit
The main difference between a "Senior" Engineer and a "Lead" Engineer, is that a "Lead" mentors and uplifts teammates to help them reach high quality and velocity.
mexican_restaurant@reddit
Disagree. Part of being a senior is mentoring and leading by example and making others around you better. Especially above senior 1, I’d argue a lot of the job is leading and functioning in a way that helps unlock everyone else… unblocking others in any way possible technically, being a big part of technical design and architecture, ultimately making the important technical decisions as direction to the less senior folks on the team. If you’re sitting in your chair not talking to anyone all day, especially just churning out features that have been pre spec’d out for you, that ain’t senior
leetcode_and_joe@reddit
you had me at clear requirements
Teh_Original@reddit
Isn't a lead typically a role on a team though? And only one person is a lead on a time at a time?
throwaway_0x90@reddit
I would say similar to college, some students may be more comfortable with certain things and help their fellow students but none of those students replace the teacher.
AtWitsEnd1974@reddit
I’ve been trying to coach the younger devs in my org about this.
They constantly issue stop works or block if there is any perceivable ambiguity in a ticket (e.g. missing tooltip text, no font recommendation on button text, no clear checklist on regression to validate after making a change). They want perfect waterfall requirements, and they seem terrified to use any discretion or make any decisions.
At a certain point, if you are unwilling to solve problems and only want to be a rote code translator for precise solutions…you could be absorbed by a capable sr with Claude code in a heartbeat.
Teh_Original@reddit
Leadership should empower them to do so. I've literally been told "You aren't leadership, so STFU." before.
ConspicuousPineapple@reddit
I mean it's fine to refuse discretion, but then you need to be proactive in seeking answers to your questions, ideally with proposals of your own.
AtWitsEnd1974@reddit
I’ve seen a few too many devs that refuse discretion, then make no effort to seek clarification. They just stop or go play Xbox until someone notices they are stuck.
ConspicuousPineapple@reddit
Yeah well that's just a bad dev then. They're first in line to lose their job security. Not that I wish that upon them but that's where we're going.
throwaway_0x90@reddit
While this is true, since this post is about OP asking what a "Lead" is. Having failing team-members kinda reflects badly on the Lead. You want to help those IC SWEs understand when they're stuck and to ask for help or something.
ConspicuousPineapple@reddit
Sure, having unproductive members isn't a good look, at least not if it's not acted on and reported if need be. It's also the job of the lead to be proactive in general in seeking information on task advancement and potential blockers so yeah, we agree.
But at some point you can just have bad teammates and you need to flag them as such.
ImSoCul@reddit
Don't think that's true at all for senior. Of course, varies by company, but on most places I have heard, there is still requirement for a leadership component
throwaway_0x90@reddit
Definitely, the line between "Senior" and "Lead" can be very fuzzy and arbitrary depending on company. I'm just saying a "Senior" could, in theory, get away with just focusing on getting their own work done and not worry too much about other people. Some companies will allow this and some won't. But a
*Lead*can never get away with that anywhere.zaibuf@reddit
So what you are saying is that the BA and Stakeholders sill just use AI to build the app and integrate with the 20 year old spaghetti systems? I will fold my camping chair and bring popcorn.
ConspicuousPineapple@reddit
No. What they're saying is that the developers with the soft skills of an actual lead will be able to produce all that without the help of any "code-only" senior dev.
AtWitsEnd1974@reddit
The issue is not AI replacing all developers.
The issue IS AI replacing weak developers by making the capable ones way more efficient.
Also, in startups, integrating with ancient systems may not be an immediate problem for at least a while.
circalight@reddit
"Lead"and "Senior" have a lost all meaning. They're completely subjective to what the company needs at any given moment.
LuckyWriter1292@reddit
I've just become a lead and am exceeding expectations, my manager told me the following
Being self managed
Showing initiative
Producing a roadmap and self implementing for the next 3 years
Providing updates in a timely manner (every week)
Updating tickets and system documentation in a timely manner
Presenting to the wider audience to show the work we are doing
Not needing my hand held, self managing and planning for the next 3 years
Mentoring, helping and uplifting others in the team
Working across departments and providing good service
Realising it's not just about you, it's about the team and driving the organisation forward towards a common goal.
ConspicuousPineapple@reddit
An actual lead, to me, has more than a "moderate" say on how the project gets specified and done. They're involved from its inception and take ownership (and accountability) of the technical decisions.
Bricktop72@reddit
Don't go heads down on a problem. Always pull someone in.
Antique-Stand-4920@reddit
Leads have to pay attention to both engineering and team dynamics. Their job is not to let things fall through the cracks for the team (within the scope of their role, of course). This doesn't mean they do everything, but they are expected to be aware of more things and address issues when they see them. This includes involving the right people when needed.
As for advice, mistakes are a given...and they aren't always "bad." It sounds cliche, but they can reveal opportunities to strengthen the team. The main thing is to avoid catastrophe. This can be done by going with proven and "boring" approaches most of the time and picking the right situations to do something more risky with a big payoff. This applies to both the engineering and how you work with people.