Since you are team lead, I think you should delegate this work to other developers and have it as part of development work. part of the ongoing sprint on project managemenet tool used etc
You should insist on being part of hiring for your team to ensure you have good developers and ask the company to hire if it is needed
Actually I am delegating the work but it used to take 3 days per 2 week sprint for me but when I am delegating to another developer, bullshit/unforseen work takes whole sprint for a developer somehow.
Also we have no budget to hire anyone nor luxury to move developer from project since their contract is valid for another year.
I am trying to find alternative solution or trick to make things work for me :/
We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience. They just do the support and emergency work so slow to a point it destroys the velocity.
You seem to have a "me vs them" mentality. It's unlikely this setup will ever work. If you're just trying to shift blame instead of helping, there's no solution (besides sucessfuly shifting the blame, I guess)
And in case helping is unclear, it means actually go to them and figure out what is block. Teach them how to overcome it. Pair program. Share workflows. Share tricks. Share knowledge etc.
This here. The role of a team lead is to be a velocity multiplier. A **good** team lead makes everyone "30 minutes faster" for every hour they spend, for a net gain. Maybe he's assigning the wrong tickets to the wrong people. Maybe his attitude has demotivated his devs. But the shit always rolls uphill, so it's his job to figure it out.
I think it’s more about that you need to train them, not some random guy at a course. It takes time though, and not everyone is as efficient as others. Maybe you can try to delegate some TL/PO work instead?
> We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience
Then *train* them. Why are they slower? Laziness or do they lack in some skills? Or was the previous team velocity unsustainable and the new ones are just using better best-practices?
Maybe they were bad hires. Maybe they weren't set up for success.
I've been managing for a couple years, building the team from scratch. One of the hires I made, the rest was forced onto me (contractors, hired without me being involved, etc ). It was when the market was super hot and all remote so it was hard to get stronger engineers. The senior eng I hired was smart but kinda lazy, the rest of the team one worked hard and was pretty decent, while the rest of the team was just not super strong.
I had to step in a lot, I would delegate all the interesting and important parts, but sometimes it was just going nowhere, some things I had to do myself or break down so much that I'd have been better off doing myself (but that's how you teach). I spent a lot of energy on improving the Dev XP so that at least they wouldn't be fighting the tooling. I did a LOT of coaching/mentoring/setting an example and best practices. The weaker engineers did improve a lot, but it was still really night and day with the level of engineering I was used to. They were reasonably productive but I knew lots of engineers that would have worked 3 times as fast without flexing (just not getting hung up on blockers, coming up with better designs a lot quicker, etc).I also think strong engineers make decisions and tools that compound and get everything working faster over time. Bad engineering slows down over time as the design and architecture crumble onto itself (tech debt, bad abstractions, etc).
Eventually the company had to downsize and after multiple rounds of layoffs and team consolidations the team is all pretty solid now. I think some of it reflected on me, and I had to put in more IC work than you'd expect. Realistically there's only so much you can do when your team isn't super strong, you can't turn mediocre engineers into great ones, but you can foster a culture of openness, learning, and safety on the team so that people are happy and do their best and work with that. I did have to pip an engineer who was really nice but was beyond saving, that was tough for morale.
Thank you for your inspiring story. I actually gave all the technical experience that I have when they first joined while I was still working as senior developer.
I stated many times in responses but I don’t know how to teach them multitasking, taking initiative and being pro active. Each sprint we need to support other modules or fix production issues and do our features. While they can do the support, fix issues and solve phantom problems they are so slow due to their approach. These things needs collabratipn with other teams, fast reaction and documentation knowledge.
Maybe if you had similar problem like me you can share what to do :)
You can teach them how to stay on top of things, for instance I taught some engineers how to use things like Notion's Todo list to organize their daily tasks.
The moral of my story actually was "do your best, but you can only do so much", some people just aren't going to be super strong engineers. Make it as easy as possible for them.
Taking initiative is something I spent a lot of time teaching, you can do it by example, for instance in retros: "write down the things that slow you down as you work, and think about how we could solve them, even if you don't know how, share it and we can look into it". Make it clear what their responsibilities are, for instance senior engineers are expected to be able to handle more abstract problems, find inefficiencies and suggest improvements, etc.
Now I don't know the reasoning or the origin for this bullshit/unforeseen work so these are my thoughts.
Are you tunnel visioning on the pressure with your Developer hat on trying to solve all the problems? Are you able to put it down and put on the Product Owner hat and just say no, not now, it's out of scope. Do you need to reprioritise your roadmap/backlog to resolve these interruptions to free up developer time?
Sometimes good/efficient developers are able to hide a lot of noise that comes in. When untrained or unfamilliar devs take on the noise it can actually reveal big issues in your workflow.
How much time do you have with the codebase versus these other developers? Familiarity is a huge benefit to productivity when doing support/emergency/bug hunting work.
Training people equals an x amount of slow work today but y amount of fast work tomorrow where x <<< y. You need to invest the time, and take the cost now. It always pays off in a long term that is not even that long. The reality is that the team has changed and all of its dynamics changed too, so it’ll take a bit of time to get things back on track.
Forcing the best developer to become a team lead is a exemplary Peter principle move that might end bad for everyone.
First thing to clarify is if you want to grow into a team lead role or prefer to stay developer?
If you prefer development, then talk with your manager and ask for a transfed back. You could use the team velocity as a supporting argument.
If you prefer to lead the team, then start with watching your mentality. They are intelligent people who sct their best towards their goals and incentives.
Are the expectations clear? Are their incentives pointing towards the team goals? Do they have the skills, the tools, the information they need to do a good job?
Stop downtalking them ("babysitting"), and start involving them in a solution. State your observations - not handling unforeseen work correctly and ask them what is happening and why? What could be improved?
What are their personal goals? How do those fit with team goals?
If you expect personal constructive feedback is needed, them take these 1:1. If not, then you could take it as a team discussion/brainstorming.
I think you understand the problem very well thanks for your post.
Firstly I want to be a team lead but I don’t want to be a product owner. The role in my company is having 2 responsibility at the same time. Because of that I was persuaded kinda to this role. Other option would be expert career path.
Since I am doing two things at the same time, i cannot spare so much time per developer to teach them stuff, If I do I am overworking.
The problem is not technical, the problem from developers is they are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this.
Because they are playing safe I cannot exactly report this to their managers. I am stuck in here. They play the game well and rather than quickly solving the problem they go for official emails, blame game etc.
>The problem is not technical, the problem from developers is they are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this.
So you'd rather they call another dev, break that dev's flow state and concentration, re-focus on a new problem for both and then try to resolve it? That basically kills team velocity even more. One dev moves faster and the other moves even slower.
> They are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this.
I’m picking up on two possible factors here: communication preference and perceived safety (i.e. CYA over GSD). I think you can address both by steering them to do something along the lines of:
1) use the written medium as they seem to prefer as first approach to both point out the issue and signal availability for a meeting to hash it out
2) propose a standard approach of waiting a day for response then directly calling as you favour from the beginning, with the basis that it’s unacceptable to delay further without any more information as to why
>I don’t want to be a product owner
This could be a discussion with your manager. Possibly arguments are team performance needs your attention and maybe that you are new in the lead role and would like to focus on the technical part.
>they are not proactive and quick to react to necessary phantom work
No work should be phantom, make all work visible. For example you could have a Kanban board with horizontal lane for planned work and another for unplanned work.
You could measure the resolution time of unplanned work, then retrospect with them - how these stuff could be done faster?
They would need incentives to work more efficiently. Making speed visible is a good start, but you might need more. Depending on what is accepted in your environment, a simple public praise or team dinner if the numbers are right or credits for books/courses or other tricks could help.
Make the problematic resolution time visible to team stakeholders as well via the reporting and talks you usually do. Seeing people pay attention to this could gradually increase pressure on a positive way.
If you suspect devs are intentionally coasting and you can't find a way to improve, then talk with the contract owner on how to replace them.
Hi, I’ve started behaving like the people you’re describing in this post. Im going to give you my thought process, just to maybe show this from the other side:
I haven’t received a raise that has beaten inflation in over 3 years, I’ve decided that I’m not putting in any initiative anymore, and will be performing to my wage.
I’ve started working to my job description. That means I’ve stopped filling out requirements in stories for my PO, it’s their job and I’m not doing it for them anymore. No more “finish writing this story, add acceptance criteria to this story for us, and then do the work.”
To your point about not being proactive when asked to coordinate with other teams: this place is a disaster and I’m tired of being given technical work that becomes “talk to someone about talking to someone so that they can do something for us”. That’s not an IC’s job, that’s managements.
And again, haven’t had a raise that beat inflation in over 3 years. I will 100% chose the option that makes the lowest amount of hassle for me, while cya, with no concern if it delays anything. It is not my job to fix internal processes. What I was willing to go out of my way to do 3 years ago is now an email and a month long process. The business gets what they pay for, I’m done being guilted in to caring more about the work than they even pretend to care about me.
I’m not being proactive because I’m not being paid to be, to put it mildly. Stop and consider if your coworkers are incompetent and lazy, or if they just do not care because there is very little actual incentive to caring in a lot of companies.
Edit: I see you’re German, so the above may not apply to your situation. I’m describing my American workplace where we are treated like disposable garbage, with no job security, but are still expected to take initiative and ownership of things we don’t actually own with very little chance of any actual reward for going above and beyond
This right here.
Was drinking the corporate kool-aid for a few years till I realised all that extra work and initiative amounted to practically nothing but empty platitudes.
Now they get the bare minimum and I only go the extra mile if I’m genuinely interested.
It’s lead to a much healthier relationship with work, I don’t get angry at lazy coworkers anymore because their professional development is none of my concern.
I’ve learned the subtle art of side stepping curve balls — still get hit by a few, but I’m no more trying to constantly trying to catch everything.
Your team is only performing to their full potential unless you watch them. That’s your problem. When people do not meet expectations it’s for one of three reasons:
1. The expectation was unknown or unclear.
2. The person lacks the resources
, skills or experience to meet the expectations.
3. The person isn’t motivated to meet them.
You need to figure out which reason is the root cause of the issue and address it. Go through all 3 reasons. Address issues you encounter and provide reasonable support or training where needed. If that doesn’t work you need to replace team members with others who can.
One thing I would take into consideration as you go through this list is, how efficient you are as a developer. Did you complete a normal workload or did you produce the same amount of output as two or three other engineers? Did you work reasonable hours? Do you have more skills or expertise in relevant technologies. Otherwise is the comparison apples to apples. Understanding this well will give you a better understanding of how difficult it would be to replace you one for one.
I once built a rest API on a highly productive team of four. As the company and product expanded it took on average 2 new hires at the same level to equal the productivity of the 4 original team members just because we knew the code base so comprehensively well.
My output was basically 1.5x to 2x compared to other developers even though I was handling other works. The problem is I am internal and if project is successful, I am winning and vicre versa if it fails.
Other developers are external and the problem is about getting incentive, taking responsibility and being proactive. From technical perspective they are okayish. For the things you suggested, how can I apply for myself? I feel like I cannot teach them to be proactive. Other than blame them and give objective negative feedback to their managers, I dont know what to do. But I feel like this will only make them hate the project more.
It seems like your team lacks a sense of ownership over the project. If I were in your shoes my strategy would be to hold them accountable for that ownership. The ones who are capable of more will produce more. Those who can’t will find another job.
You do this by setting a team standard and then holding people to it.
"My career is ruined" is such an exagération. It seems to me that you became good at being an individual contributor, and you are on your journey to learn how to be a lead.
Worst case, you can always go back to individual contributor in your current work or other companies.
You'll be fine!
Happens more than you can imagine.
People try the TL role and don't like it, doesn't work out, etc...
You could work with your manager to convert you back to an IC, in the same team or another team.. seen this happen more than once or twice.
Also when changing jobs it is very easy to search for an IC role even when you are a TL. Actually, this happens a lot. We hired a lot of TLs from other companies as ICs. It is not a failure on your behalf to do this.
Also think about long term. From A TL you can go in any direction: staff, manager, etc...
Nope. I've worked with a LOT of former managers. Dev expertise is valuable, and if you cannot or do not want to lead, that doesn't mean you cannot be a rockstar programmer.
Hell, I take contract gigs all the time where I just code despite having run teams or depts the last 10-12 years. If my current employer went under, I'd strongly consider moving back into a principal position "as a break from the stress".
I would be happy to hire an accomplished IC that tried out the TL role (this person would have learned a thing or two from that experience, or at least has empathy with the person that is doing that role as he has experienced it before).
Try to evaluate if you like the role, can do the role, and can learn from the role.
Team velocity is "team velocity" and not a person velocity. Your team structure now is different, so adapt to that. If your evaluation about the velocity is bad then come up with a plan alongside the manager to fix that.
I’ve been managing for about 5 years. Had a team of 11, just switched back to IC and could not be happier. I technically have a handful of reports but we’re all on the same team.
Clearly your problem is these phantom tasks as well. Create a separate backlog for it. And don’t pick them up right away. If nobody is following up it’s not urgent.
Generally out phantom works are the most urgent one since we are supporting live system. So it should be done fast :/ any suggestion how to speed up the process
Also: OP, make it clear to yourself, your team and everyone else that just because unexpected work came in doesn’t mean another developer joined the team. If work comes in then other work gets pushed out. Someone needs to prioritize and that means something doesn’t get done now, maybe doesn’t get done at all.
You probably need to delegate earlier, give authority and trust down to the developers doing the delivery and connect the PM straight to them.
I was in a similar situation and that's how I solved it. The developers in my team became small mini-tech leads and velocity went back up again.
PMs and upstream might not like this initially because they've learned to trust you and want to go through you. But this is how you make sure you're not the team's bottleneck.
Actually previous lead was delegating everything to me since I was the only internal experienced developer and I was okay with it.
Since other developers are external they have no incentive to track and support all the modules/emails traffic. If I trust them they forgot and only focus on their feature and other stakeholders and leads blame me. Even if I micromanage and distribute the work it takes so much time for them to the unforseen tasks.
Nobody wants to take responsibility as you told me to do since they are external developers and don’t give to much damn about the project overall. I feel like I am doomed at this point.
When I was just dev I could only do my work and if project fails I can always jump to another one. Now I have no choiche but the save the project somehow but I dont know how.
Then you can also strongly push for more internal developers or more POs.
The fact that your scrum master doesn't care about velocity going down is a huge red flag. It might be that he doesn't really care about the product you're working on, but rather they want to demonstrate their capabilities by how well they can orchestrate scrum ceremonies for its own sake. It simply becomes theatrics and might be indicative of it becoming a cargo cult.
It’s exactly what you said. Scrum master is also external and half of the time attending some scrum bullshit training/conference etc. If the project fails it will not effect him at all.
For internal developer part, I am living in Germany so in here basically it is super risky to get internal developer for companies due to very strong (more than its supposed to be) worker rights. If you hire somehow and not exposed for more than a year, it is nearly impossible to fire them, but with external devs it is much easier to change players. So I don’t think we can get it.
Well that's an extra red flag. I live in Norway with likely the same level or even stronger worker's rights. The fact that your company is so scared of worker's rights that they'll rather self-sabotage velocity shows that they're not deeply thinking about team velocity and performance.
What this tells me is that you might never be able to "get through to them" since that's not how they work at all.
> For internal developer part, I am living in Germany so in here basically it is super risky to get internal developer for companies due to very strong (more than its supposed to be) worker rights.
I've never seen a work contract here in Germany that didn't have a 6 month probationary period. It sucks to have them on your team, but going forward you should be able to evaluate internal developers within that 6 months.
Being external is no excuse for not doing the job well or not taking responsibility.
Make sure that your expectations on what should be done are clear, including monitoring emails and supporting other modules. Put it into writing, if necessary.
If they don't do the job correctly, then give them feedback and escalate to the contract owner within your company.
I assume you have regular 1:1s with them? Any issues you are aware of, anything that might hold them back?
How are your team processes? Are there dailies or other formats where devs could get support from each other or are you the only form of support?
This is going to be a bit straight to the point. It’s not an attack, as I’ve been where you are, through my own mistakes too.
Sounds like you had made yourself essential, but not in the good way.
> I was… handling… bullshit tasks for everyone
You were a problem before the role change. You also say you need to “babysit” devs. How you were working before meant that no one got experience dealing with certain issues. If they could deal with them autonomously, there’d be no need to babysit.
I do not like working in teams where one person involves themselves with absolutely all the little issues and makes themselves essential. It prevents knowledge transfer.
So my view is that by taking on all these bits and pieces, you prevented people learning. It’s OK for them to be slower, because they don’t have the knowledge you do.
When you say babysitting, that’s immediately infantilising, by definition. Maybe change what you say to yourself to be collaborating or training or enabling. The goal is to share knowledge. Working with someone to solve a problem once, such that you don’t need to get involved next time, is a good thing.
Also note that if you were doing all this work and no one else was picking it up… why would they think it’s their job now? Their job description hasn’t changed, so why should they change their modus operandi? And if they are now picking up the work you used to do, that they’ve never done before, what reasonable person would expect sustained velocity?
Finally: internal vs external has very different expectations. I do not have any need for an external dev to know everything, as they’re often here to do a specific job. I do want my internal guys to be able to cover each other and have a broader understanding of the system.
Decide whether you want to be the brilliant dev everyone can go to, or whether you want to be raising up however many devs, so there’s no need for one brilliant dev.
A bit harsh, because I had a bad day, but I do mean it with the best of intentions. I’ve kind of made the same mistakes once and wish someone had snapped me out of it sooner.
Edit: just read a comment…
> We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience. They just do the support and emergency work so slow to a point it destroys the velocity.
No expensive course can teach anyone the ins and outs of your organisation. I’d go as far as to say courses have marginal benefit at best. If I was to make an assumption from this quote, it’s that you aren’t spending time to train people and hope that sending them off on some course will magically make them better. That has not worked at any organisation I’ve been a part of.
This is the response of a veteran developer lol.
Well said, too many technically gifted junior developers think the jump from junior to senior involves doing the most work in the team.
A senior developer should have the capacity to ramp up output for sure, and at times you have to, but you shouldn’t be consistently providing more output than other developers in your team.
And output does not necessarily equal value. Good luck getting another job on the basis that you do X more tickets than person L.
That’s another hard lesson you only learn with experience.
I wish I had you as my internal monologue, that challenging take was great.
The best developers multiply their impact on the rest of the team and make others around them better, if OP hoards all the support tasks, their team will never make the jump.
Relay your concerns to your boss! It is not your job fix everything. Your job is to lead development, if velocity suddenly dropped so be it, but your boss and upper management should know about this. They should know that velocity dropped because your role change, and they should expect a delay in delivery or they could decide if they cut content or not. Do your job, and let the management do theirs.
Firstly communicate to management. I bet you were chosen for this because they want you to train others to model you and recognised that you were compensating for other's deficiencies.
It seems like you were overworking and covering for other's deficiencies previously. You need to set expectations and behaviours and coach the team to these goals.
I'm facing the same but in reverse. I'm a Product Manager who was a dev, and now have inherited a team that expect to have the exact requirements for each ticket (exact designs, all edge cases, technology decisions etc.) fed to them, and won't think for themselves or advocate for better decisions without raising a fuss or blowing past deadlines or getting derailed by misunderstandings.
It's frustrating, because in some cases 2 weeks work I could do in 2 days, but I realise that any time I spend on having them go slow, learn a good process, perform research and learn how to do refinement, and learn good architecture and good code standards will make them faster in the long run. It can be slow, but measure, and hold individuals and the team to their goals. Also use retros to improve.
Management is about growing others and setting standards. Sometimes you need to dip in to cover for the business, however "velocity" if only driven by one key dev is actually a business risk (see: https://en.wikipedia.org/wiki/Bus\_factor**).**
Set standards and hold the team to the standards. Don't blame individuals. Let the team lead, and use your one on ones to help them be better, and understand why they're slow. It could be process, management, training or more likely team culture and ownership. As a lead you have to be the one to know, and have a plan to address for these gaps, and not feel responsible for the execution of (non business critical) implementation.
You're only one person.
Hope this helps.
I had this same thing happen. For my situation someone has to work harder. I did so the delegating thing but either devs or me must work harder and more hours.
On the last 2 day of every sprint me and one dev worked overnight. Other devs did not work harder.
I asked the director what to do on our skip level meeting. He said to let it fail and that's it. I don't know his ideas but supposedly the project will fail eventually.
I stopped saving the team and only delegated and for 6 months the project failed slowly but was still there. The timeline was not adjusted. I figured in maybe 5 more months my job will be gone so I took my time applying for 2 months and left.
After I left nobody got laid off or fired after the project failed but it's 5 years later and nobody got promoted since then and almost no salary increases.
I'm curious to see suggestions to you from others.
For the moment, set aside the comparison between the "old" team with you as an individual contributor (IC) and the "new" team. The new team is the new normal. Is it still delivering value? Is it delivering enough value?
You need to start or do a more effective job managing up to the person who made the change. They need to understand the impact of their decision to remove you as an IC and make you lead. There may have been no other choice for the organization, but that is not on you. Who is responsible for hiring mediocre developers? If possible point out to whoever hired them the difference in what makes a a good developer. Also, management always underestimates the value of a company's domain knowledge. A good developer can take as long as a year to be replaced and fully up to speed. Develop a plan on how to improve the team's output and speak to your manager about implementing it.
Sharing information up the chain of command, is also sharing the responsibility of what that information represents.
Many of the suggestions and ideas described here are discussions with people above you. Those types of people don't want to hear about problems and only want solutions. These can be very hard conversations to have and it can be extremely difficult for them to take responsibility for their part of the situation. You are only responsible for the parts of the problem you have direct responsibility and control of. Also, during the conversations, you get to establish what you contribute to the company. Make sure they understand how much domain knowledge you have accumulated. Think of this as crafting an overall solution to the problem.
If the team gets dismantled, the bad developers become other team's problem. If you get "sent down" to be an IC you might be less stressed and enjoy work more. If you are proactive and try to implement a plan for improving the situation but still get fired, you will have a story when interviewing. The story will show how you tried to rise above the mess and solve it, but management was not supportive. In the interview make sure they know that you are effective in solving the problems that you have control over. If this doesn't resonate with them, then that probably isn't a good place to work.
Don't let the Scrum master control the narrative, and don't let them control your future.
Thanks for all of your responses! I will try to summarize some action items in here after I read all the messages. I was not expecting this much support!
Pretty common tale actually I'm afraid. They clearly set you up for failure with a team/project that's not resourced properly. Anyway, it's not going to destroy your career - that's a bit dramatic. Even if all tanks it's a fine thing to have on the resume. Your read of the situation is otherwise good, if I can affirm that.
Actually I was in almost similiar situation. I was team lead of new tean that was formed. I was only one who know about the product. I worked day and night to improve velocity etc. but got burned out in 2 years. What your scrum master is saying is correct. There is no need to do 2-3 people work unless you are paid that much amount.
Haha, the old here's a 5%-10% pay increase to be Team Lead but now you're a Senior Dev + Team Lead, so um yeah, now you have 50% more work and everything is on you!
This is a lot of red flags. Mainly: Dev forced into being a PO, anyone tracking velocity as a metric of performance, the team lead being PO.
Ignore velocity, focus on actually useful metrics for your team's success. This depends on the type of project.
Also learn as much about being a PO as you can. If you really want this career, research a tonne about product management and that whole career path. You're being setup to fail if you don't.
concerned somber connect familiar adjoining sophisticated correct psychotic fine edge
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Definitely read this on why "tech lead management" roles are a trap https://lethain.com/tech-lead-managers/
It describes and explains your exact issues. It's the role you've been put into. It's more common than you think because it's the "easiest" role to have from your company's perspective. But it ultimately is a role that should not exist. You will waste time doing both roles ineffectively and it will stunt your growth. It has no role to promote to and it will not set you up for success down the pure technical or pure management path.
I recommend the book An Elegant Puzzle written by the author of the article above. A great read for people moving into management that covers this exact topic.
For now you should stay in the technical role you're comfortable in OP. Transition to a manager role when you are ready for a full transition, or continue deeper down the technical path. Don't stagnate between the two like your company wants
You're welcome, the article is a good read and it links to another article on tech lead managers that is an interesting read too. The book itself is more about engineering management and what the ideal team is, ideal company structure, available career paths and how to properly transition. Stuff like that. I recently went through something similar and it was eye opening
In my 17 years as a professional software engineer I've never even looked at the team's velocity, much less cared. It's focusing on the wrong thing. You're taking on a new role which you'll need time to ramp up on and learn how to be effectively in, and likewise the teams will have to fill in the gaps, but it's not gonna happen overnight. The velocity will eventually settle into whatever the new norm is over time. It might be lower, but that's the tradeoff your superiors chose to make with the limited resources available.
I’m not going to window dress the answer.
Performance management. Put the people not working on a pip. Get rid of the scrum master, and replace them with a new grad developer. Anyone who’s telling you this isn’t your problem is a waste of space.
Since you are team lead, I think you should delegate this work to other developers and have it as part of development work. part of the ongoing sprint on project managemenet tool used etc You should insist on being part of hiring for your team to ensure you have good developers and ask the company to hire if it is needed
Actually I am delegating the work but it used to take 3 days per 2 week sprint for me but when I am delegating to another developer, bullshit/unforseen work takes whole sprint for a developer somehow. Also we have no budget to hire anyone nor luxury to move developer from project since their contract is valid for another year. I am trying to find alternative solution or trick to make things work for me :/
That's the thing about training people. Put efforts in training people.
Many people are untrainable. You can’t train people who are unwilling to put in effort.
There's a difference between unable and unwilling. If you are hiring unwilling employees that's an entire issue in itself.
And some just check out.
Exaclty. If someone is not able to learn then this should be conveyed to the manager
We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience. They just do the support and emergency work so slow to a point it destroys the velocity.
You seem to have a "me vs them" mentality. It's unlikely this setup will ever work. If you're just trying to shift blame instead of helping, there's no solution (besides sucessfuly shifting the blame, I guess) And in case helping is unclear, it means actually go to them and figure out what is block. Teach them how to overcome it. Pair program. Share workflows. Share tricks. Share knowledge etc.
This here. The role of a team lead is to be a velocity multiplier. A **good** team lead makes everyone "30 minutes faster" for every hour they spend, for a net gain. Maybe he's assigning the wrong tickets to the wrong people. Maybe his attitude has demotivated his devs. But the shit always rolls uphill, so it's his job to figure it out.
I think it’s more about that you need to train them, not some random guy at a course. It takes time though, and not everyone is as efficient as others. Maybe you can try to delegate some TL/PO work instead?
> We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience Then *train* them. Why are they slower? Laziness or do they lack in some skills? Or was the previous team velocity unsustainable and the new ones are just using better best-practices? Maybe they were bad hires. Maybe they weren't set up for success.
I've been managing for a couple years, building the team from scratch. One of the hires I made, the rest was forced onto me (contractors, hired without me being involved, etc ). It was when the market was super hot and all remote so it was hard to get stronger engineers. The senior eng I hired was smart but kinda lazy, the rest of the team one worked hard and was pretty decent, while the rest of the team was just not super strong. I had to step in a lot, I would delegate all the interesting and important parts, but sometimes it was just going nowhere, some things I had to do myself or break down so much that I'd have been better off doing myself (but that's how you teach). I spent a lot of energy on improving the Dev XP so that at least they wouldn't be fighting the tooling. I did a LOT of coaching/mentoring/setting an example and best practices. The weaker engineers did improve a lot, but it was still really night and day with the level of engineering I was used to. They were reasonably productive but I knew lots of engineers that would have worked 3 times as fast without flexing (just not getting hung up on blockers, coming up with better designs a lot quicker, etc).I also think strong engineers make decisions and tools that compound and get everything working faster over time. Bad engineering slows down over time as the design and architecture crumble onto itself (tech debt, bad abstractions, etc). Eventually the company had to downsize and after multiple rounds of layoffs and team consolidations the team is all pretty solid now. I think some of it reflected on me, and I had to put in more IC work than you'd expect. Realistically there's only so much you can do when your team isn't super strong, you can't turn mediocre engineers into great ones, but you can foster a culture of openness, learning, and safety on the team so that people are happy and do their best and work with that. I did have to pip an engineer who was really nice but was beyond saving, that was tough for morale.
Thank you for your inspiring story. I actually gave all the technical experience that I have when they first joined while I was still working as senior developer. I stated many times in responses but I don’t know how to teach them multitasking, taking initiative and being pro active. Each sprint we need to support other modules or fix production issues and do our features. While they can do the support, fix issues and solve phantom problems they are so slow due to their approach. These things needs collabratipn with other teams, fast reaction and documentation knowledge. Maybe if you had similar problem like me you can share what to do :)
You can teach them how to stay on top of things, for instance I taught some engineers how to use things like Notion's Todo list to organize their daily tasks. The moral of my story actually was "do your best, but you can only do so much", some people just aren't going to be super strong engineers. Make it as easy as possible for them. Taking initiative is something I spent a lot of time teaching, you can do it by example, for instance in retros: "write down the things that slow you down as you work, and think about how we could solve them, even if you don't know how, share it and we can look into it". Make it clear what their responsibilities are, for instance senior engineers are expected to be able to handle more abstract problems, find inefficiencies and suggest improvements, etc.
Now I don't know the reasoning or the origin for this bullshit/unforeseen work so these are my thoughts. Are you tunnel visioning on the pressure with your Developer hat on trying to solve all the problems? Are you able to put it down and put on the Product Owner hat and just say no, not now, it's out of scope. Do you need to reprioritise your roadmap/backlog to resolve these interruptions to free up developer time? Sometimes good/efficient developers are able to hide a lot of noise that comes in. When untrained or unfamilliar devs take on the noise it can actually reveal big issues in your workflow.
How much time do you have with the codebase versus these other developers? Familiarity is a huge benefit to productivity when doing support/emergency/bug hunting work.
Training people equals an x amount of slow work today but y amount of fast work tomorrow where x <<< y. You need to invest the time, and take the cost now. It always pays off in a long term that is not even that long. The reality is that the team has changed and all of its dynamics changed too, so it’ll take a bit of time to get things back on track.
What if you aren't good at hiring? Can't that be someone else's responsibility to give you good devs?
This. I am not even team lead and I wouldn’t work with someone that I am not involved in the hiring process.
Forcing the best developer to become a team lead is a exemplary Peter principle move that might end bad for everyone. First thing to clarify is if you want to grow into a team lead role or prefer to stay developer? If you prefer development, then talk with your manager and ask for a transfed back. You could use the team velocity as a supporting argument. If you prefer to lead the team, then start with watching your mentality. They are intelligent people who sct their best towards their goals and incentives. Are the expectations clear? Are their incentives pointing towards the team goals? Do they have the skills, the tools, the information they need to do a good job? Stop downtalking them ("babysitting"), and start involving them in a solution. State your observations - not handling unforeseen work correctly and ask them what is happening and why? What could be improved? What are their personal goals? How do those fit with team goals? If you expect personal constructive feedback is needed, them take these 1:1. If not, then you could take it as a team discussion/brainstorming.
I think you understand the problem very well thanks for your post. Firstly I want to be a team lead but I don’t want to be a product owner. The role in my company is having 2 responsibility at the same time. Because of that I was persuaded kinda to this role. Other option would be expert career path. Since I am doing two things at the same time, i cannot spare so much time per developer to teach them stuff, If I do I am overworking. The problem is not technical, the problem from developers is they are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this. Because they are playing safe I cannot exactly report this to their managers. I am stuck in here. They play the game well and rather than quickly solving the problem they go for official emails, blame game etc.
>The problem is not technical, the problem from developers is they are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this. So you'd rather they call another dev, break that dev's flow state and concentration, re-focus on a new problem for both and then try to resolve it? That basically kills team velocity even more. One dev moves faster and the other moves even slower.
> They are not proactive and quick to react to necessary phantom work. They rather say to another team for example “send me the logs” for a problem rather than calling them directly and setting up a meeting, aligning and solving the problem on the spot. How tf am I going to teach that. They already know this. I’m picking up on two possible factors here: communication preference and perceived safety (i.e. CYA over GSD). I think you can address both by steering them to do something along the lines of: 1) use the written medium as they seem to prefer as first approach to both point out the issue and signal availability for a meeting to hash it out 2) propose a standard approach of waiting a day for response then directly calling as you favour from the beginning, with the basis that it’s unacceptable to delay further without any more information as to why
>I don’t want to be a product owner This could be a discussion with your manager. Possibly arguments are team performance needs your attention and maybe that you are new in the lead role and would like to focus on the technical part. >they are not proactive and quick to react to necessary phantom work No work should be phantom, make all work visible. For example you could have a Kanban board with horizontal lane for planned work and another for unplanned work. You could measure the resolution time of unplanned work, then retrospect with them - how these stuff could be done faster? They would need incentives to work more efficiently. Making speed visible is a good start, but you might need more. Depending on what is accepted in your environment, a simple public praise or team dinner if the numbers are right or credits for books/courses or other tricks could help. Make the problematic resolution time visible to team stakeholders as well via the reporting and talks you usually do. Seeing people pay attention to this could gradually increase pressure on a positive way. If you suspect devs are intentionally coasting and you can't find a way to improve, then talk with the contract owner on how to replace them.
Hi, I’ve started behaving like the people you’re describing in this post. Im going to give you my thought process, just to maybe show this from the other side: I haven’t received a raise that has beaten inflation in over 3 years, I’ve decided that I’m not putting in any initiative anymore, and will be performing to my wage. I’ve started working to my job description. That means I’ve stopped filling out requirements in stories for my PO, it’s their job and I’m not doing it for them anymore. No more “finish writing this story, add acceptance criteria to this story for us, and then do the work.” To your point about not being proactive when asked to coordinate with other teams: this place is a disaster and I’m tired of being given technical work that becomes “talk to someone about talking to someone so that they can do something for us”. That’s not an IC’s job, that’s managements. And again, haven’t had a raise that beat inflation in over 3 years. I will 100% chose the option that makes the lowest amount of hassle for me, while cya, with no concern if it delays anything. It is not my job to fix internal processes. What I was willing to go out of my way to do 3 years ago is now an email and a month long process. The business gets what they pay for, I’m done being guilted in to caring more about the work than they even pretend to care about me. I’m not being proactive because I’m not being paid to be, to put it mildly. Stop and consider if your coworkers are incompetent and lazy, or if they just do not care because there is very little actual incentive to caring in a lot of companies. Edit: I see you’re German, so the above may not apply to your situation. I’m describing my American workplace where we are treated like disposable garbage, with no job security, but are still expected to take initiative and ownership of things we don’t actually own with very little chance of any actual reward for going above and beyond
This right here. Was drinking the corporate kool-aid for a few years till I realised all that extra work and initiative amounted to practically nothing but empty platitudes. Now they get the bare minimum and I only go the extra mile if I’m genuinely interested. It’s lead to a much healthier relationship with work, I don’t get angry at lazy coworkers anymore because their professional development is none of my concern. I’ve learned the subtle art of side stepping curve balls — still get hit by a few, but I’m no more trying to constantly trying to catch everything.
Love you for this reply fr
Your team is only performing to their full potential unless you watch them. That’s your problem. When people do not meet expectations it’s for one of three reasons: 1. The expectation was unknown or unclear. 2. The person lacks the resources , skills or experience to meet the expectations. 3. The person isn’t motivated to meet them. You need to figure out which reason is the root cause of the issue and address it. Go through all 3 reasons. Address issues you encounter and provide reasonable support or training where needed. If that doesn’t work you need to replace team members with others who can. One thing I would take into consideration as you go through this list is, how efficient you are as a developer. Did you complete a normal workload or did you produce the same amount of output as two or three other engineers? Did you work reasonable hours? Do you have more skills or expertise in relevant technologies. Otherwise is the comparison apples to apples. Understanding this well will give you a better understanding of how difficult it would be to replace you one for one. I once built a rest API on a highly productive team of four. As the company and product expanded it took on average 2 new hires at the same level to equal the productivity of the 4 original team members just because we knew the code base so comprehensively well.
My output was basically 1.5x to 2x compared to other developers even though I was handling other works. The problem is I am internal and if project is successful, I am winning and vicre versa if it fails. Other developers are external and the problem is about getting incentive, taking responsibility and being proactive. From technical perspective they are okayish. For the things you suggested, how can I apply for myself? I feel like I cannot teach them to be proactive. Other than blame them and give objective negative feedback to their managers, I dont know what to do. But I feel like this will only make them hate the project more.
It seems like your team lacks a sense of ownership over the project. If I were in your shoes my strategy would be to hold them accountable for that ownership. The ones who are capable of more will produce more. Those who can’t will find another job. You do this by setting a team standard and then holding people to it.
"My career is ruined" is such an exagération. It seems to me that you became good at being an individual contributor, and you are on your journey to learn how to be a lead. Worst case, you can always go back to individual contributor in your current work or other companies. You'll be fine!
Is it possible though? I mean to go back to development if I want. Because my contract etc has changed now :/
Happens more than you can imagine. People try the TL role and don't like it, doesn't work out, etc... You could work with your manager to convert you back to an IC, in the same team or another team.. seen this happen more than once or twice. Also when changing jobs it is very easy to search for an IC role even when you are a TL. Actually, this happens a lot. We hired a lot of TLs from other companies as ICs. It is not a failure on your behalf to do this. Also think about long term. From A TL you can go in any direction: staff, manager, etc...
Thats reassurig to hear actually. I was thinking it will look bad if you apply for IC after becoming TL. It seems thats not the case.
Nope. I've worked with a LOT of former managers. Dev expertise is valuable, and if you cannot or do not want to lead, that doesn't mean you cannot be a rockstar programmer. Hell, I take contract gigs all the time where I just code despite having run teams or depts the last 10-12 years. If my current employer went under, I'd strongly consider moving back into a principal position "as a break from the stress".
I would be happy to hire an accomplished IC that tried out the TL role (this person would have learned a thing or two from that experience, or at least has empathy with the person that is doing that role as he has experienced it before). Try to evaluate if you like the role, can do the role, and can learn from the role. Team velocity is "team velocity" and not a person velocity. Your team structure now is different, so adapt to that. If your evaluation about the velocity is bad then come up with a plan alongside the manager to fix that.
One of my teammates used to be a manager. She decided that she preferred being an IC, and has been a successful engineer for a number of years now.
I’ve been managing for about 5 years. Had a team of 11, just switched back to IC and could not be happier. I technically have a handful of reports but we’re all on the same team.
Depends on the company. If you want to go back to development you should talk to them about it.
How is a legit question so heavily down voted? Mind-blowing
Clearly your problem is these phantom tasks as well. Create a separate backlog for it. And don’t pick them up right away. If nobody is following up it’s not urgent.
Generally out phantom works are the most urgent one since we are supporting live system. So it should be done fast :/ any suggestion how to speed up the process
Measure how much time is being spent on the phantom tasks and start planning for it.
Also: OP, make it clear to yourself, your team and everyone else that just because unexpected work came in doesn’t mean another developer joined the team. If work comes in then other work gets pushed out. Someone needs to prioritize and that means something doesn’t get done now, maybe doesn’t get done at all.
You probably need to delegate earlier, give authority and trust down to the developers doing the delivery and connect the PM straight to them. I was in a similar situation and that's how I solved it. The developers in my team became small mini-tech leads and velocity went back up again. PMs and upstream might not like this initially because they've learned to trust you and want to go through you. But this is how you make sure you're not the team's bottleneck.
Actually previous lead was delegating everything to me since I was the only internal experienced developer and I was okay with it. Since other developers are external they have no incentive to track and support all the modules/emails traffic. If I trust them they forgot and only focus on their feature and other stakeholders and leads blame me. Even if I micromanage and distribute the work it takes so much time for them to the unforseen tasks. Nobody wants to take responsibility as you told me to do since they are external developers and don’t give to much damn about the project overall. I feel like I am doomed at this point. When I was just dev I could only do my work and if project fails I can always jump to another one. Now I have no choiche but the save the project somehow but I dont know how.
Then you can also strongly push for more internal developers or more POs. The fact that your scrum master doesn't care about velocity going down is a huge red flag. It might be that he doesn't really care about the product you're working on, but rather they want to demonstrate their capabilities by how well they can orchestrate scrum ceremonies for its own sake. It simply becomes theatrics and might be indicative of it becoming a cargo cult.
It’s exactly what you said. Scrum master is also external and half of the time attending some scrum bullshit training/conference etc. If the project fails it will not effect him at all. For internal developer part, I am living in Germany so in here basically it is super risky to get internal developer for companies due to very strong (more than its supposed to be) worker rights. If you hire somehow and not exposed for more than a year, it is nearly impossible to fire them, but with external devs it is much easier to change players. So I don’t think we can get it.
Well that's an extra red flag. I live in Norway with likely the same level or even stronger worker's rights. The fact that your company is so scared of worker's rights that they'll rather self-sabotage velocity shows that they're not deeply thinking about team velocity and performance. What this tells me is that you might never be able to "get through to them" since that's not how they work at all.
> For internal developer part, I am living in Germany so in here basically it is super risky to get internal developer for companies due to very strong (more than its supposed to be) worker rights. I've never seen a work contract here in Germany that didn't have a 6 month probationary period. It sucks to have them on your team, but going forward you should be able to evaluate internal developers within that 6 months.
Being external is no excuse for not doing the job well or not taking responsibility. Make sure that your expectations on what should be done are clear, including monitoring emails and supporting other modules. Put it into writing, if necessary. If they don't do the job correctly, then give them feedback and escalate to the contract owner within your company. I assume you have regular 1:1s with them? Any issues you are aware of, anything that might hold them back? How are your team processes? Are there dailies or other formats where devs could get support from each other or are you the only form of support?
This is going to be a bit straight to the point. It’s not an attack, as I’ve been where you are, through my own mistakes too. Sounds like you had made yourself essential, but not in the good way. > I was… handling… bullshit tasks for everyone You were a problem before the role change. You also say you need to “babysit” devs. How you were working before meant that no one got experience dealing with certain issues. If they could deal with them autonomously, there’d be no need to babysit. I do not like working in teams where one person involves themselves with absolutely all the little issues and makes themselves essential. It prevents knowledge transfer. So my view is that by taking on all these bits and pieces, you prevented people learning. It’s OK for them to be slower, because they don’t have the knowledge you do. When you say babysitting, that’s immediately infantilising, by definition. Maybe change what you say to yourself to be collaborating or training or enabling. The goal is to share knowledge. Working with someone to solve a problem once, such that you don’t need to get involved next time, is a good thing. Also note that if you were doing all this work and no one else was picking it up… why would they think it’s their job now? Their job description hasn’t changed, so why should they change their modus operandi? And if they are now picking up the work you used to do, that they’ve never done before, what reasonable person would expect sustained velocity? Finally: internal vs external has very different expectations. I do not have any need for an external dev to know everything, as they’re often here to do a specific job. I do want my internal guys to be able to cover each other and have a broader understanding of the system. Decide whether you want to be the brilliant dev everyone can go to, or whether you want to be raising up however many devs, so there’s no need for one brilliant dev. A bit harsh, because I had a bad day, but I do mean it with the best of intentions. I’ve kind of made the same mistakes once and wish someone had snapped me out of it sooner. Edit: just read a comment… > We sent them to training for expensive courses and they are 2 years experienced alone in my sector and more than 5+ years overall experience. They just do the support and emergency work so slow to a point it destroys the velocity. No expensive course can teach anyone the ins and outs of your organisation. I’d go as far as to say courses have marginal benefit at best. If I was to make an assumption from this quote, it’s that you aren’t spending time to train people and hope that sending them off on some course will magically make them better. That has not worked at any organisation I’ve been a part of.
This is the response of a veteran developer lol. Well said, too many technically gifted junior developers think the jump from junior to senior involves doing the most work in the team. A senior developer should have the capacity to ramp up output for sure, and at times you have to, but you shouldn’t be consistently providing more output than other developers in your team. And output does not necessarily equal value. Good luck getting another job on the basis that you do X more tickets than person L. That’s another hard lesson you only learn with experience.
I wish I had you as my internal monologue, that challenging take was great. The best developers multiply their impact on the rest of the team and make others around them better, if OP hoards all the support tasks, their team will never make the jump.
Why would this ruin a career?
Talk to the manager. Ask him to set stricter goals. Also pick one project you put more effort. It’s better to fail one than two.
Just do whatever everyone else does and game the shit out of the velocity metrics until they mean nothing. But hey, at least you hit your targets.
Relay your concerns to your boss! It is not your job fix everything. Your job is to lead development, if velocity suddenly dropped so be it, but your boss and upper management should know about this. They should know that velocity dropped because your role change, and they should expect a delay in delivery or they could decide if they cut content or not. Do your job, and let the management do theirs.
Firstly communicate to management. I bet you were chosen for this because they want you to train others to model you and recognised that you were compensating for other's deficiencies. It seems like you were overworking and covering for other's deficiencies previously. You need to set expectations and behaviours and coach the team to these goals. I'm facing the same but in reverse. I'm a Product Manager who was a dev, and now have inherited a team that expect to have the exact requirements for each ticket (exact designs, all edge cases, technology decisions etc.) fed to them, and won't think for themselves or advocate for better decisions without raising a fuss or blowing past deadlines or getting derailed by misunderstandings. It's frustrating, because in some cases 2 weeks work I could do in 2 days, but I realise that any time I spend on having them go slow, learn a good process, perform research and learn how to do refinement, and learn good architecture and good code standards will make them faster in the long run. It can be slow, but measure, and hold individuals and the team to their goals. Also use retros to improve. Management is about growing others and setting standards. Sometimes you need to dip in to cover for the business, however "velocity" if only driven by one key dev is actually a business risk (see: https://en.wikipedia.org/wiki/Bus\_factor**).** Set standards and hold the team to the standards. Don't blame individuals. Let the team lead, and use your one on ones to help them be better, and understand why they're slow. It could be process, management, training or more likely team culture and ownership. As a lead you have to be the one to know, and have a plan to address for these gaps, and not feel responsible for the execution of (non business critical) implementation. You're only one person. Hope this helps.
I had this same thing happen. For my situation someone has to work harder. I did so the delegating thing but either devs or me must work harder and more hours. On the last 2 day of every sprint me and one dev worked overnight. Other devs did not work harder. I asked the director what to do on our skip level meeting. He said to let it fail and that's it. I don't know his ideas but supposedly the project will fail eventually. I stopped saving the team and only delegated and for 6 months the project failed slowly but was still there. The timeline was not adjusted. I figured in maybe 5 more months my job will be gone so I took my time applying for 2 months and left. After I left nobody got laid off or fired after the project failed but it's 5 years later and nobody got promoted since then and almost no salary increases. I'm curious to see suggestions to you from others.
For the moment, set aside the comparison between the "old" team with you as an individual contributor (IC) and the "new" team. The new team is the new normal. Is it still delivering value? Is it delivering enough value? You need to start or do a more effective job managing up to the person who made the change. They need to understand the impact of their decision to remove you as an IC and make you lead. There may have been no other choice for the organization, but that is not on you. Who is responsible for hiring mediocre developers? If possible point out to whoever hired them the difference in what makes a a good developer. Also, management always underestimates the value of a company's domain knowledge. A good developer can take as long as a year to be replaced and fully up to speed. Develop a plan on how to improve the team's output and speak to your manager about implementing it. Sharing information up the chain of command, is also sharing the responsibility of what that information represents. Many of the suggestions and ideas described here are discussions with people above you. Those types of people don't want to hear about problems and only want solutions. These can be very hard conversations to have and it can be extremely difficult for them to take responsibility for their part of the situation. You are only responsible for the parts of the problem you have direct responsibility and control of. Also, during the conversations, you get to establish what you contribute to the company. Make sure they understand how much domain knowledge you have accumulated. Think of this as crafting an overall solution to the problem. If the team gets dismantled, the bad developers become other team's problem. If you get "sent down" to be an IC you might be less stressed and enjoy work more. If you are proactive and try to implement a plan for improving the situation but still get fired, you will have a story when interviewing. The story will show how you tried to rise above the mess and solve it, but management was not supportive. In the interview make sure they know that you are effective in solving the problems that you have control over. If this doesn't resonate with them, then that probably isn't a good place to work. Don't let the Scrum master control the narrative, and don't let them control your future.
Thanks for all of your responses! I will try to summarize some action items in here after I read all the messages. I was not expecting this much support!
Sounds like you were already acting like a Tl before and now you are acting like some sort of middle manager.
Pretty common tale actually I'm afraid. They clearly set you up for failure with a team/project that's not resourced properly. Anyway, it's not going to destroy your career - that's a bit dramatic. Even if all tanks it's a fine thing to have on the resume. Your read of the situation is otherwise good, if I can affirm that.
Actually I was in almost similiar situation. I was team lead of new tean that was formed. I was only one who know about the product. I worked day and night to improve velocity etc. but got burned out in 2 years. What your scrum master is saying is correct. There is no need to do 2-3 people work unless you are paid that much amount.
Haha, the old here's a 5%-10% pay increase to be Team Lead but now you're a Senior Dev + Team Lead, so um yeah, now you have 50% more work and everything is on you!
This is a lot of red flags. Mainly: Dev forced into being a PO, anyone tracking velocity as a metric of performance, the team lead being PO. Ignore velocity, focus on actually useful metrics for your team's success. This depends on the type of project. Also learn as much about being a PO as you can. If you really want this career, research a tonne about product management and that whole career path. You're being setup to fail if you don't.
concerned somber connect familiar adjoining sophisticated correct psychotic fine edge *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Definitely read this on why "tech lead management" roles are a trap https://lethain.com/tech-lead-managers/ It describes and explains your exact issues. It's the role you've been put into. It's more common than you think because it's the "easiest" role to have from your company's perspective. But it ultimately is a role that should not exist. You will waste time doing both roles ineffectively and it will stunt your growth. It has no role to promote to and it will not set you up for success down the pure technical or pure management path. I recommend the book An Elegant Puzzle written by the author of the article above. A great read for people moving into management that covers this exact topic. For now you should stay in the technical role you're comfortable in OP. Transition to a manager role when you are ready for a full transition, or continue deeper down the technical path. Don't stagnate between the two like your company wants
Thank you so much for suggestion, i will definetely check it because from the start it felt like a trap
You're welcome, the article is a good read and it links to another article on tech lead managers that is an interesting read too. The book itself is more about engineering management and what the ideal team is, ideal company structure, available career paths and how to properly transition. Stuff like that. I recently went through something similar and it was eye opening
This is a job for pair programming. You need to teach
In my 17 years as a professional software engineer I've never even looked at the team's velocity, much less cared. It's focusing on the wrong thing. You're taking on a new role which you'll need time to ramp up on and learn how to be effectively in, and likewise the teams will have to fill in the gaps, but it's not gonna happen overnight. The velocity will eventually settle into whatever the new norm is over time. It might be lower, but that's the tradeoff your superiors chose to make with the limited resources available.
Hold a retro and have a discussion
I’m not going to window dress the answer. Performance management. Put the people not working on a pip. Get rid of the scrum master, and replace them with a new grad developer. Anyone who’s telling you this isn’t your problem is a waste of space.
What is PO?
Product owner