What do responsibilities look like in a team of only senior engineers?
Posted by Present_Passion_1126@reddit | ExperiencedDevs | View on Reddit | 53 comments
Does everyone work on their own project? Are engineers a tech lead on one project while being more of a pure code on another?
Or is it just that everyone is expected to contribute to the design of each project? I guess I’m just really used to *one* person ultimately drafting up the whole initial design and being the final decision maker.
random314@reddit
A lot more doing. But also a like more knowledge silo as seniors tend to bury their head and work.
Having juniors tend to force seniors to cross research, give presentations, update documentations... Etc.
obelix_dogmatix@reddit
Knowledge sharing is immense, but collaboration is pretty much non existent. Everyone is self sufficient and on cruise mode. Meetings are to the point. Yes, more often than not everyone owns different projects.
Creative_Badger6027@reddit
Grab tickets and finish them?
Valuable_Ad9554@reddit
This lol, same as a team of only juniors really
Unlucky_Data4569@reddit
No mentorship expectations is only difference
Federal-Garbage-8629@reddit
Yeah That's how it goes at my company. 😃
Shazvox@reddit
This, but senior-like. Y'know. Add a lot of ascii art and leet speak to the commits.
joseconsuervo@reddit
foo bar poot
GuyWithLag@reddit
That's a mid-level engineer at best - seniors should be writing the tickets.
trele_morele@reddit
PMs and all levels of engineers should be writing tickets
Creative_Badger6027@reddit
And then who does the actual work? The janitor? Refinment is refinment regardless of seniority.
GuyWithLag@reddit
My bad, I wanted to say that if you only "Grab tickets and finish them", you're likely a junior engineer, or an engineer with 5 times 2 years of experience.
Salink@reddit
Everyone is just expected to self organize around different responsibilities based on who likes doing what. My manager sets high level priorities and trusts us to prioritize smaller tasks appropriately and keep him in the loop during stand up and jira. My coworkers and I talk to each other regularly get help from each other or pass off taks when needed. Larger architecture decisions are half dictated by the primary coder in that area and half by vote between all the SWEs. Almost all of these decisions have multiple good options, so we just go with what feels right until other constraints force us to refactoring later.
PM_ME_DPRK_CANDIDS@reddit
streets are calling this communism
Salink@reddit
Idk I read a lot of posts here and I wonder why they spend time posting here instead of talking to someone real for a couple minutes.
PM_ME_DPRK_CANDIDS@reddit
seems like dysfunctional workplaces mostly.
thinkandexe@reddit
Worked on a senior-only team for about 18 months. A few things that were different:
- Design ownership is distributed. Nobody waits to be assigned architecture decisions, they just happen in Slack/PRs/Notion organically. Can be chaotic without clear norms.
- Coordination load shifts to everyone. When there's no one "figuring out" the work, all the invisible coordination work (sequencing, dependency tracking, stakeholder updates) gets absorbed by whoever cares most. That person burns out.
- Conflict is more sophisticated but also more entrenched. Senior engineers argue from first principles, which is great until it isn't.
The thing that actually made it work was having a manager who was genuinely good at making the invisible work visible — not directing it, just surfacing it so the team could self-correct.
libre_office_warlock@reddit
I'm on a tiny senior-only team at the moment and it's my favorite situation I've ever been in.
For us, basically yeah: everyone has their own project or at least their own work stream. Someone might own the ticketing or 'big questions answering' of a project but product/design still makes the larger calls and we can push back/brainstorm/iterate with them.
As an extreme introvert I relish in not having to directly mentor anyone right now. We just get cool stuff done together; I have my domain (backend); the others have theirs; sometimes we try new stuff but we have the experience to figure it out on our own and learn via code reviews.
asapbones0114@reddit
Complete independence. Everyone architects, sets up their own meeting, their own instrumentation and their own solutions.
RabbitWithADHD@reddit
My current org is pretty much all senior, and my team is only senior engineers and up. We’re given a lot of autonomy and are expected to have a high level of ownership. This means that certain engineers are likely to lead one of the various projects running in parallel, but the way we’ve structured it is that everyone is aware (at least at a surface technical/product level) of all of the projects on the team, so any of us can chip into any of the projects when needed.
phouchg0@reddit
I was once on a team with all staff engineers, we all reported to the same director. Strange thing was, though we were all on the same "team", we did not work together on Dev projects. Each one of us had our own area of business and system expertise, there were separate dev teams for each of those areas, sometimes more than one dev team for a business area.
95% of the work we did was with what we considered "our" own development teams, not with each other. The Dev teams had their own managers, we did not report to them, we only answered to our own manager. It was more like a partnership with the Dev manager. Many of the dev team managers at this time were not very technical.
On this team, we were the ones that years ago had taken a good long look at the leadership career path and said "that's no fun at all, I am staying technical." By the time this team was formed, we had all known each other for years and were promoted up around the same times. It was sort of like we all grew up together.
We had some very lively technical discussions, arguments, debates, fights, ect... This was unsurprising because as we all know that if you place eight staff engineers in a room you are likely to come out of that room with a minimum of six completely different opinions on how to design, implement, ect... This led to quite a few lively, funny, debates with each other. They were all worthy opponents!
Nothing lasts forever because what do VPs do when they want to?
"Make their mark" (i.e. pee all over everything)
Cover their mistakes. ("Hey, that other team that no longer exists did that, not us")
Run out of things to do and just get bored
That's right, they do a reorganization! After a while they split up the team and sprinkled us in amongst the development teams
jkingsbery@reddit
I've seen it done a few different ways.
What always has to be true though is there still needs to be a primary decision maker. This person doesn't have to be the most senior person. There is often recognition that it happens to be that person now, but the next project might be someone else. But without a single decision maker, things become design-by-committee, which is often worse than having picked the wrong decision.
Beyond that, it often depends on why you have a team of only senior people. Maybe the project is just that important and high profile, in which case everyone takes all their experience to a role that task-wise looks like something more junior, focusing on delivering features. Sometimes, teams will hire the senior people first, the senior people figure out what area they are most interested in, and then the team breaks into multiple teams as they start hiring junior developers.
WhenSummerIsGone@reddit
they laid off all the juniors and we're the ones left. I miss the mentoring/pairing sessions.
j-random@reddit
Nobody codes on my team. We all take different parts of the system and work on them, but it's mostly getting things integrated with the other services. If there's any code to write we have to let AI do it, then we just review it and make sure it meets the spec (which was also AI-written). My team is responsible for four or five services, so there's usually plenty to do. We also have an insanely complex security scheme with each service requiring the use of a dozen or so roles to use any kind of resource (and each environment requires that we request new roles) so a lot of the work winds up being documentation and security checklists.
Foreign_Addition2844@reddit
Its awesome. Basically everyone knows what their role is and you dont have to scrutinize PRs etc. Just get the job done.
Bulky-Blacksmith1960@reddit
Domain expertise usually drives ownership. The person who knows payments best leads payment features, database expert handles data migrations, etc.
londoncuppa@reddit
Multiple projects going at once, rotating who leads each project when we start new ones.
Lalalyly@reddit
Same here. Each person also leads an area they are passionate about if they want to. We meet on a regular basis to check on our tasks, flesh out tasks, and determine interim due dates. If there is a task that looks like it isn’t moving forward, someone usually steps up or we rotate the assignee so it gets done.
Napolean_BonerFarte@reddit
I was once on a team like this and that’s exactly how we handled it too. Best team I was ever on, very high quality work and fast velocity too. Definitely helps to have everyone on the team be good and experienced. Eventually the company split us up to different parts of the org to help worse teams, which was better for our careers but worse for being on worse teams.
waba99@reddit
I was also on a team like this and it was amazing. I’d become jaded with the industry and it was invigorating. Until a reorg split us up and everyone left for greener pastures.
Main-Drag-4975@reddit
> Eventually the company split us up to different parts of the org to help worse teams, which was better for our careers but worse for being on worse teams.
This is one of the loneliest parts of experienced dev life. Whenever you have another person on your team who really gets it, you make magic for a few quarters before the org breaks up the veterans to redistribute them to weaker/newer teams. I miss my homies.
Some_Developer_Guy@reddit
That's what we do, 4 seniors (2 newly promoted) 2 mids.
On call is a full time job, and someone is always sick or on pto.
DoingItForEli@reddit
You take on tickets from the backlog, claim ownership both in solving them and watching for any changes that impact the work going forward.
killersquirel11@reddit
Most "all senior" teams I've seen are either "everyone works on their own projects" or "small groups divide and conquer a bigger project".
When organizing a team I try and do the latter - that way projects keep moving even if someone goes on vacation for two weeks or something
Puzzleheaded-Pen9979@reddit
I think it can largely depend on your team's composition. I'm tech lead on my team and have twice the YOE of other seniors on my team. The other seniors on my team have no interest in leadership and are 100% happy to be focused ICs.
diablo1128@reddit
Same as any other team. Implement features, add testing, do Code Reviews, update Documentation, help teammates as needed, etc...
Nofanta@reddit
Depends. There’s no need for time wasting bullshit like scrum and reviewing others code line by line, so it’s far more efficient.
zayelion@reddit
Its something akin to a half mono repo. 1 or 2 devs are usually working on a support project, and the rest in a domain of the core app. As requirements come and go they cycle around. This includes the lead. The lead is usually doing the greenfield making skeletons the rest the team can fill out.
TheTacoInquisition@reddit
Who's good at what? I've worked on projects with only seniors, and we just split responsibilty for leading the bits we were best at, and communicating a lot. It helps when egos get checked at the door, and there needs to be an understanding that once standards and conventions are setup, there can't be constant changes or challenges to them.
But honestly, with actual seniors, it was rarely a problem and we all just collaborated to get things done.
No-Economics-8239@reddit
Being a senior dev doesn't limit your responsibilities, it just adds to them. If you have other devs who can pick up the slack they can fill those roles. But in the end, as a senior, we do whatever needs doing to solve the problems at hand.
There certainly are teams who silo out work and have code ownership rituals that make the keeper of the bus number miserable. Just as there are teams with broad code ownership ideals that go out of their way to expand the team knowledge and make sure most team members understand how most things work. That's just one of the variable attributes of culture and work load.
How much you collaborate on design and architecture depends again on the culture. Larger companies can have formal architecture roles and teams that need to approve designs in an attempt to make sure people are using established and approved patterns and technology. Other places have individual devs making cryptic design decisions in the shadows that might later haunt the team for decades.
Ideally teams know how to share ideas and responsibilities and my best stint in my career was on a team where all of us had at least 10 years of experience and aside from the odd personality issues, that was the most enjoyable and instructive leg of my career by far. We would routinely practice pair programming to spread knowledge and collaborate and it really helped me shed my cowboy coder mentality.
Careful_Ad_9077@reddit
I have been in quite a few.
1) The lead grooming farm. Teams consists of 5 or so senior,the lead role get swapped around per project/stage, that way all seniors learn to lead. There is a real lead to mentor but he is only mentoring. Just like most companiesncant get enough seniors,this one can't get enough leads.
The economics of the company are 0-1k for juniors ,1-2k for seniors , 2-3 k for leads. So as you can see there is an economic incentive for rh company to make them good leads.
2) the" silo per module, use scrum to keep everyone updated and knowledgeable" model. All seniors own a module, they are free to do what they want how they want with it. The closer they have to a coordinator/lead is a product owner, when I see this working well the product owner is competent.
3) the contractor model. There is an internal company person, usually a senior dev, he is the one physically meeting the users and creating the high level business wants and needs. Then he passes those to the senior devs of the team so they do the thing, system design, developing , etc... The onsite senior never becomes a bottle neck because the other seniors can take over the business needs tasks.
3 is funny because it started with the intention of having junior offshore /near shore and keep the seniors internal only. But because the salary imbalance between countries is so big and the company wanted to hire the top candidates... They ended up getting seniors instead of juniors or mids.
rimeofgoodomen@reddit
Pick a lane and keep driving. Pick a few lanes if there are too many of them. At times you'll notice, someone else in a pretty lane. Don't judge or wallow. Make your lane pretty as best as you can.
Present_Passion_1126@reddit (OP)
This metaphor was completely lost on me lol
DocLego@reddit
My current team is about half seniors. I'm fairly new, but so far it seems to be that everyone just picks up what they want to work on and the manager assigns things out if something is important and hasn't been picked up yet. This week, for example, I saw we had a bug in the queue that was marked as important and not yet assigned, so I grabbed that and fixed it, and then did code review on a few pieces of development that needed it.
This actually matches up fairly well with my last job: the team leads would send me work that needed doing, and if I needed more to do I'd go find something. Yes, there were projects I was working on by myself, projects where I was the lead developer, and projects where I was playing a supporting role. But I was never really a "pure coding" role in the sense that someone else figured out what to do and I did it; I've always been expected to come up with my own designs, even before I was senior.
Fair_Local_588@reddit
We all work on our own projects, but we will socialize the designs across the team via RFCs before starting just to make sure we aren’t missed something.
throwaway_0x90@reddit
A team of sll sr.eng hopefully is assigned enough work at that level. Otherwise it's gonna be a "Too many chefs" scenario.
rabbotz@reddit
I usually manage teams of only senior engineers and my preference is to have a single person as an “accountable” lead per project. A bare minimum expectation on my teams, as seniors, is that anyone can lead a project.
Beyond that there are too many variables around how many engineers, how many projects, how complex the projects are, etc to have a single system of responsibility. Sometimes it’s like 9 people on one project, sometimes it’s 3 people on 4 projects. Those look very different.
craig1f@reddit
This is different on every team and often creates a "Too many cooks in the kitchen" situation.
But this is also a typical setup for the starting phase of an important project, where you want a lot of heavy hitters to build V1 or a prototype, before your team starts to scale with more devs. In this case, it's usually a lead, who respects that everyone is technically on the same level, but guides requirements. Then usually, you do a kanban, and you avoid Jira and just use Github Issues as long as possible. You switch to Jira when you either need to report burndown rates to a customer, or your issues start to becomes user stories.
Kanban is good because if everyone is full stack, you can kind of just work on whatever's next. Creating sprints and user stories don't help you move any faster. It just creates more process.
Eventually, you have enough of a product that process becomes important. A senior dev, working on the "wrong thing", is just burning money. So once you've built the core of your app, and the things that need to be build are subjective, you need process so senior devs pick the "important" tasks instead of the "interesting" tasks. When the task is "implement oidc" and "write terraform to build stack" and "build CI/CD pipelines", the tasks are important and not subjective. When the choice is between "pay off tech debt" and "implement this feature that a customer is asking for, and will start paying for licenses once finished", then you move to Jira MAYBE and start adding stories, and corral your devs.
ordinary-bloke@reddit
In my current position we are all capable to independently shape tasks or projects, which we then bring to the team for discussion and refinements. We will discuss any design choices with the whole team so we all agree with the approach.
We can all pick up tasks that are given to us and independently complete them, but we still often pair up or collaborate to discuss anything we didn’t anticipate or that changes our implementation and design.
Outside of project specific work, we have different areas that we are interested in and contribute to, for example I personally contribute heavily to the standards, guidance, maintenance, and improvement of our test automation pack, whilst another teammate is introducing patterns for feature flagging and the process to correctly follow. Another one is looking at areas of improving internal systems to reduce human error and improve app usability.
ZukowskiHardware@reddit
Yeah basically. Just a bunch of silos.
PerryTheH@reddit
It really depends on the type of project and company.
You talk about "each dev is lead on a project" so I guess your org handles multiple projects, in this case there would always be a "lead" dev on the team or a PM/SM that would need to assign and manage priorities.
It handles the same way as a team of what ever level, it's just that the complexity of each task is higher and some sr devs might do side quests base on the needs of the project/app they work.
jonnycoder4005@reddit
We designated leads in certain areas of a project. And we would cross check each other for the riskiest implementations. If the devs are nitpicky over low risk implementation details, it will kill the project and kill morale.
Only the highest risk/reward features need scrutiny and let the other senior devs implement other features how they want to.
Snoo-82132@reddit
One is the owner and coordinates with others, works on the tasks themselves as well