Tech teams with no team lead.
Posted by Brilliant_Anybody_38@reddit | ExperiencedDevs | View on Reddit | 41 comments
Feels like an absolute joke this methodology. Decisions become soooo much harder. So much more mentally draining. If you want to achieve any change instead of convincing one person you need to convince the whole team.
Also, much harder to do responsibility assignment. Like who does what and when ?
Absolutely hate it and the orgs which do it to save money. Also, no obvious career growth.
What do you think about it ?
onceunpopularideas@reddit
Better than a thin skinned talentless team lead. It also depends how big the team is, and many other factors. On a small team this could work well. But what tends to happen in these situations is that someone emerges as the natural lead.
jaypeejay@reddit
Agreed, and unfortunate that the naturally emerging leader (assuming competency) isn’t explicitly rewarded
Ambitious-Toe8970@reddit
Yea had I bad team leads in past, and it is better to don't have tl. In our comp we don't have cto so no one can specify what the team lead does so it ends up he'll for him
SoggyGrayDuck@reddit
Welcome to tech debt hell
ellerbrr@reddit
AI will fix it. Just agree within your team to ask AI to make the decisions and roll with that. Your bosses will be impressed.
Note this is a joke post. /s
Kaimito1@reddit
Dont forget to tell AI to not make mistakes /s
FantasticVanilla5464@reddit
This is pretty much how both my current team and last team operated and I personally love it.
The dev owning the specific project is the decision maker. No need to have one team leads overly opinionated perspective driving everything. This way the whole team can contribute their individual perspectives and have equal weight to their suggestions and concerns.
It also helps reduce bus factor around one teammate, and drive good tribal knowledge spread throughout the team.
thevoid__@reddit
I joined a company as an EM to managed two teams that have been operating like that. What a nightmare, feature driven teams with gigantic infrastructure and architectur issues, regular incidents, you name it.
We managed to structure and clean things up but has been a journey
bluemage-loves-tacos@reddit
We work like this, and it's .... actually not bad. I would say though, with other personalities it wouldn't work so well. We have 5 teams, and if there's disagreement in the team on what to do, then we figure out what the options are, try and understand each others worries about a particular approach, see what we can do to mitigate them, and then, well, if all else fails we vote. We've only done that last part once in the 2.5 years I've been in the team.
Decisions don't take a lot of time, but we work in small iterations, so decisions are usually small to begin with, and we can always change our minds if we start and it doesn't seem to be panning out the way we thought it would.
A different data point: I worked in a team many years ago, that *technically* had a lead, but the lead was ineffectual. Myself and one other took over, which was a disaster, as we both had very different styles, so decisions *did* take a long time.
I feel like it's a setup that can work really well, but it needs people who are able to let their opinions get out of the way. Strong opinions weakly held and all that.
dethswatch@reddit
antiPattern- the nerds need a deciderer or it ends up in a constant battle
DualActiveBridgeLLC@reddit
It's astounding how many organizations have terrible decision making structures. My current company has the "Stage-Gate' process. Any effort above 300 man-hours is supposed to go through it. Essentially you have to create multiple meetings where you have to get the thumbs up from the 'executive committee' which is 7 high ranking members of the organization. But realistically the vote of the owner/CTO is the only one that matters. It is the textbook definition of dilution of responsibility and clearly highlights the distrust of the engineers you employ to make decisions. I have had to start doing that trick where you put together a great plan but intentionally mix some stupid ideas into the presentation so that the executive committee can 'fix' some problems they see. One of the senior engineers who had never done Stage-Gate saw me do it and I had to tell him 'trust me, we want this in the plan, you'll see'. Afterwards he congratulated me on how perfectly I orchestrated it because they spent all their 'debate time' on my distraction and we got our thumbs up for the project that was already 50% completed.
F1B3R0PT1C@reddit
Usually whoever is product owner ends up being the lead in these situations. They’ll be the one dictating priority if nobody else tries to own that. I used to work on a team like this and it really sucked.
Now I work the complete opposite. I ended up being the tech lead and now I have to convince other teams and management that our changes are needed. Honestly only marginally better for me hahaha
TopSwagCode@reddit
"product owner ends up being the lead in these situations" - Nope :D What happened on this team, was everyone just refined their own task and worked on whatever they wanted. Product died and everyone was reassigned to new teams.
binarycow@reddit
I feel attacked.
Okay, my situation isn't exactly the same.
Our primary application is a self-hosted web app. There are like five or six teams, all with a team lead. We have a director in charge of all of it. We have a product owner. Etc.
But I work on a desktop app that is "part of" the web app. It's basically a standalone desktop app that is used to gather files that are intended to be imported into the web app. The idea is that sometimes, you can't use the web app, so you use the desktop app.
Hell, the application exists because I got bored one day, and chose to write the initial version.
taznado@reddit
You do not need leads, you need to hire non toxic people.
martinbean@reddit
Doesn’t work if you then have people with differences of opinion, and a simple decision like “should methods have docblocks or not?” never get agreed on, and you then have people in the “no” camp rejecting PRs that include them, and people in the “yes” camp rejecting PRs that omitted them. I say this as a genuine example, and was the final straw for me and made me hand my notice in.
blissone@reddit
Well should they?
StefonAlfaro3PLDev@reddit
Well who is turning the Business Requirements into tasks?
I don't understand how the setup you're describing is even possible.
retroroar86@reddit
In practice that happens where I work.
throwaway0134hdj@reddit
If it’s anything like my experience, it’s someone non-technology give vague high-level requests . The stuff of nightmares…
just_looking_aroun@reddit
You just described my team. Oh the number of wrong features that were delivered over the last 3 months…
Whitchorence@reddit
Why is this exclusively the work of one person and not the entire engineering team though
midasgoldentouch@reddit
For a given project there should be one person doing it, even if the specific person rotates across the team from project to project.
Whitchorence@reddit
But there may be several projects ongoing at any given time. Sure, in some sense one or two people will likely be "leading" each one. But that's a different thing than necessarily having a "team lead" who is the top dog in the entire team.
midasgoldentouch@reddit
That’s fair. I do think there should be a team lead as the technical expert who is responsible for ensuring that the system as a whole is reliable and cohesively designed (to the extent possible).
Whitchorence@reddit
In some sense yeah I guess you want someone to be accountable for any given system, but that may not be at the individual team level.
morosis1982@reddit
This sounds like a great way to have endless meetings discussing which tasks should come from the requirements.
You need one person (doesn't have to be the same person for each new feature/requirement) to break it down into logical parts, then you can have the team debate on when and how those fit together, what the details are, dependencies, etc.
Have done the one where you break it down as a team, unless there's a strong lead (in which case why didn't they just do it first solo) it becomes design by committee.
Whitchorence@reddit
The way it's worked on teams I've been on is that any team member is capable of creating these tickets and then in grooming we'll get to firming it up if it's unclear and then estimating and all of that.
crazy0ne@reddit
In my experience this has happens when we have two teams, with a time difference, working to implement overlapping features and no domain boundaries on the same product.
The product owners have this notion that it is easier to track new features and estimate time of delivery. However this approach more echos the sentiment on teaching:
"Lectures are a great way to teach and a horrible way to learn".
The outcome is tons of meeting, needing to talk over points again and again that have been/should have been covered, missed requirements and tons of shuffling in scope of work from planning to delivery.
At the end of the day, push comes to shove and something gets delieverd, but it could be done better if planning was done upfront and domain boundaries were drawn before product owners engage the engineering teams.
But that is just an idealistic world to leadership, who will then will turn around and ask if we can go faster with Ai. 🤦♂️
retroroar86@reddit
We have this where I work. No one in charge and no senior developers that has the role de facto.
I have been in my current job for four years and now have the «authority»/respect to be the leader in practice.
The thing is, many developers either don’t care, or they don’t the «instinct» of good design/architecture.
One of my colleagues have been at the job 3-4 years longer than me, but he produces complicated code, and I tip him by «just do it this way» instead.
Just last week he created a complicated setup and I showed him to get the same effect in just two lines of code. I spent 2 minutes and he probably spent 2 hours.
Luckily they don’t have any egos around being shown a better way, so it’s never a struggle at least
I have shown this to my manager and pushed for clear roles and position changes, but the company is stupid and slow. My manager sees the benefit, but the system itself is insane.
I have told my manager that I expect these changes for me and to have it be official. I didn’t threaten to quit or anything like that, but I have made my demands and worded them strongly.
No leadership with tech debt makes for chaos in the long run. I have found some many stupid decisions in the code base, like dynamically referring to image base on client name (working on a white label app) so that any changes in the client name broke certain image references.
This was completely unnecessary because we never had namespace pollution for references because client apps are all independent. That no one thought of this while creating the setup shows me the lack of critical thinking by previous contributors.
oiimn@reddit
Not every team needs a tech lead IMO and those are the best teams to work in. But that’s a very rare situation
Tech lead is also a different role at every company.
However if you think a tech lead is a necessity for your team why don’t you propose voting on one internally? Then the issues that a tech lead solves should be fine (vetoing on a decision when colleagues have a disagreement).
Gareth8080@reddit
What methodology is this because no methodology I know of says don’t have someone who can overall technical decisions. You should at minimum have someone who owns the product from a commercial point of view (scope, requirements) and someone who owns the technical vision. Consensus is great and always desirable but not always possible 100% of the time.
TopSwagCode@reddit
Haha :D Been there done that. Also been on teams with Tech leads, who didn't do their actual job and just said they didn't care.
Had manager's say they didn't believe in tech leads, but rather that whole team had their different areas. So what essentially should be a basic decision, would always be a vote, which lead to meetings, which lead to bringing in architects.
So much wasted time on this :D
Foreign_Addition2844@reddit
All teams need a lead who is atleast breaking dead locks or helping make quick decisions. Its not about money - they can assign someone this responsibility for the same salary.
It sounds like a bad work environment if tech management does not understand the need for jt.
graph-crawler@reddit
There's no project lead too in our place. The decisions and repo setup is made by junior with claude.
No backend frontend contract nor typesafety, it's claude doing the integration. Nobody knows if there's an api response drift or anything.
No semantic styling either, it's all glued by claude. No unit testing, it's all manual testing.
mattbillenstein@reddit
Sorta the experience of my first startup - they had a bunch of smart guys, but the way they did stuff is to chop the problem in to N pieces and then each go in a separate room and code for six months. I came in after that process into the "pull it all together" phase which was predictably a mess.
They'd have been better off and saved a lot of time if there were one or two architects responsible for the over-arching architecture, data format, coding guidelikes, etc.
Whitchorence@reddit
I think it is fine.
throwaway0134hdj@reddit
This is crap company. Sorry but you should have seen the red flags before you joined.
Comfortable_Job8847@reddit
You are integrating humans and software development. It is similar to integrating software and software. Find the necessary points of interaction and agreement. Allow the rest to become someone else’s problem. Your organization is not operating in a standard fashion and so results may vary. Standardization enables consistency which supports the business. It is preferable but not required to succeed. It is often more difficult without standardization.
Ilookouttrainwindow@reddit
What is worse, this or claim of lead while actually this?
HK-65@reddit
How did that even happen? Is this a new management fad or the pencil was drawing too thick at the last layoffs?