I've recently switched jobs after 13 years from a team lead position in a corporate environment to a senior developer role in a kind of a startup, mostly due to financial reasons.

I have a ticket assigned in our sprint backlog which is solved, but I was asked to research some different approaches.

This Friday, one of the leads of the project tagged me in a Slack conversation about a customer-reported issue. I did a quick check, and it turned out it required a bit more than a few minutes' investigation.

I contacted my team lead explaining that it's a customer-reported issue and I don't know what the policy is, and that it requires a lot more than a few minutes, and asked whether I should work on it or not. He didn't actually acknowledge that I should work on it, but that was my understanding, and he helped with several queries since I don't have production database access (so he was well aware of the issue and the amount of time required for it).

Today, during our daily stand-up meeting, when it was my time to update on my existing issue, I mentioned to the team that I was tagged in a customer reported issue and tried to ask for some input. Instead of actually discussing the issue, the Scrum master proceeded to berate me for working on unplanned work (for more than 5 minutes) and ignored the fact that I pointed out several times that I checked with my team lead. My team lead didn't jump in to say anything!

I've tried to discuss with him after and he said that it's not his job to protect me and that he didn't actually tell me to work on it!

I have led teams before and, if something like this would have happened, I would have shut the discussion down instantly or at least jumped in, and then would have had a private discussion with the Scrum master. As a lead, I see that one of my responsibilities is to stop any shit raining down.

Did my previous corporate experience warp my views, and is it normal for leads to have their reports fend for themselves?

I'm already on the fence with this company. Should I consider this as one of the reasons for moving on, or can I expect the same attitude in a different place, and just learn to live with it?

The situation above is just the latest example. There were several instances of similar behavior towards me or some of my colleagues.

My question is motivated by the fact that I've approached two of my teammates and they basically say that it's not desirable, but to be expected. I'm trying to figure out if that's the general consensus.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Commented Jun 15, 2022 at 19:57

7 Answers 7


This is not a "startups do this vs. big companies do that". Your situation is simply due to any organisation having a mix of good & bad people & processes. True, a larger more established organisation will more likely have mature processes to handle customer issues vs. dev vs. business-as-usual but it's not completely out of the question that a startup can manage that just as well, if not better. The issues (I suspect) are more that startups tend to eschew process for a "get shit done NOW!" approach along that maturity spectrum.

Your team lead is immature as are your company's processes. You can work on both of those or accept that regardless of the organisation, you will find differences and you have to find something that works for you.


There is not really anything special about start-up culture or large corporate culture that makes a general difference in your scenario or similar ones. If anyone bothered to measure it, there might be some statistical difference. However, this is mostly going to be driven by personalities and office politics.

Your current team lead either dropped the ball on this one, or has a different opinion than you for where their own role starts and stops when it comes to work priorities. I don't think it is possible to judge based on a single event.

From your comment on this answer, it appears there have been a few other events, and conversations with your colleagues suggest that it is a common theme with this team lead. That makes me think that the team lead is potentially being ineffective, either in managing your time/protecting you from clashing priorities, or in communicating with you that they expect you to take that responsibility. Which it is (or even if something else applies), and why they are not meeting your expectations I could not say from your description. Perhaps they are snowed under with other work, perhaps they don't understand or don't like their responsibilities.

Those are just guesses though, and I don't think it would help much to critique the team leader further, other than making you feel justified in venting about it.

If there is a retrospective meeting, use that to bring up clarifying the roles and responsibilities for handling this kind of task clash.

Retrospectives are IMO one of the most important, if not the most important meetings in scrum. They allow the team to adjust its own rules, culture and governance. However, they are often one of the first things to go when a team is "agile, but we pick and choose which parts to implement". They also get skipped a lot in fast paced environments like start ups.

So, in the case that there is no restrospective where you can realistically hash out the correct joint behaviour when there is a priority clash, I can make some suggestions. These have worked for me to ensure I am not letting anyone down at short notice in environments that claim to be "agile" but struggle with running a tightly-managed SCRUM setup:

  • As a senior dev, you should feel free to identify the priority as you see it, then actively communicate your plans with consequences, to the team lead and scrum master.

  • You may want to feel out any similar clash next time, by referring to the team lead first and asking for their opinion on priority. You can frame your preference as a suggestion. This is a good way to have the team lead take joint responsibility for the decision later. But be prepared to have them bounce it back to you - this can be a good thing if you are closer to the work involved and the team lead is not across it in enough detail.

  • Do not rely on thinking "it's obvious if I do X then I cannot do Y". Everyone is busy with other things and probably won't register the importance of dropping/delaying Y unless you say directly. You need to spell it out, especially to the scrum master or project manager who is waiting for something that has been delayed.

  • Do not rely on a one-way communication. If you have put your preferred decision into chat or email, or the ticketing system, and got no response to show it is accepted, then this is a blocker ("I am blocked on Y due to production/customer issue X, and need that confirmed") to bring up in daily stand up.

  • Yes, your team lead could/should have picked this up and clarified things with you. But experience in this team shows that isn't happening at the moment. For now, you need to ensure your work is not impacted by a repeat of the same scenario.

One thing that will be different at a start-up from a larger corporate is that communication channels for work issues won't be formalised, and in places where it looks like they are, they will be changing frequently or not cover things well. So you may need to actively make up for that.

  • I just gave the most recent example, my team lead has behaved similarly in several cases, related to me or my team mates. And I'm not the only one who noticed, but al my team mates seem to think this is to be expected Commented Jun 13, 2022 at 10:57
  • 2
    @mostafawornout OK, seems like you and your colleague's expectation of the team lead responsibilities doesn't match the team lead's idea of them (or perhaps they are well aware but lazy/ineffective). I think the last two paragraphs still stand. Like you, I have done both team lead and senior dev. I have found I prefer to be a dev that can step up and cover missing things when needed, so often end up doing some project management and active prioritisation/responses. It doesn't fix the problems with the team/team lead, but you may find your work improves if you cover this yourself a little. Commented Jun 13, 2022 at 11:08
  • 1
    @mostafawornout I have adjusted the end of this answer to describe behviour that has worked for me. Whilst I have never worked under a team lead that "threw me under the bus" in a meeting with a project manager, I have worked in many places with loose dev processes which required me to step up and cover for this kind of work clash. Commented Jun 13, 2022 at 16:30
  • 3
    Given the established behavior, I would strongly suggest you follow up any verbal discussions with the team lead in an email that CC's the scrum master (and possibly others) that outlines what was discussed and decided and asking them to confirm it. This goes a long ways towards providing a reliable record of what was hashed out. Commented Jun 13, 2022 at 20:26

This sounds like an example of a company that says it's using Scrum, but isn't.

The Scrum master's job is to organise meetings, liaise with stakeholders and the like. Other than that, teams should be self organising, deciding between themselves who is doing what. There's no place for a team lead.

So you're following a broken process, and it isn't working right.

  • 2
    "There's no place for a team lead" - who does performance reviews, approves expenditures, arranges team outings, hires and fires, etc.? Commented Jun 13, 2022 at 19:27
  • 2
    @user1172763 line manager, project manager, the team, HR, etc.
    – Simon B
    Commented Jun 13, 2022 at 21:40
  • 7
    Indeed. A possible case of Dark Scrum - "...today's power holders believe that their job is to decide what their people should do, tell them to do it, and see that they do. Scrum teaches otherwise: explain what needs to be done, then stand back and let the people self-organize to do it." Commented Jun 14, 2022 at 20:24
  • 4
    The Scrum master's job is to organise meetings - Not even to organise meetings, or attend them. Just to make sure that the meetings are happening.
    – Rob Grant
    Commented Jun 15, 2022 at 8:18
  • Part of the issue with Scrum is the term "Scrum master"; some people take the word "master" here to have the "owner" or "person in charge" meaning rather than the "expert at something" or "skilled artist" meaning. XP has a somewhat better name for this role: "coach," though that admittedly still can be taken as a "tells people what to do" role rather than "offers advice on decisions made by the team" role.
    – cjs
    Commented Jun 17, 2022 at 8:27

This is definitely not to be expected. Perhaps at this company it is, but in general it's not. You acted on a customer-facing issue to resolve it and make the customer happy, after checking with the appropriate people in your reporting line and making sure there were no conflicting issues. That's all you had to do, and you're in the right here.

Here's what I would do from here:

  1. Talk to your manager. Let him know that you expected him to back you up in the meeting and that you checked with him about working on this issue. You already did this and he basically told you to fuck off.

  2. So leave. Start applying for other jobs. This work environment is toxic. You did your work, and then you got berated for it. Get out.

  3. In the meantime (and also during your notice period, once you've submitted your resignation), under absolutely no circumstances are you to work on anything aside from your assigned tickets. Any ad-hoc requests or investigations that come in, or any client-facing issues that come to you get met with "please talk to my manager or scrum master and they will prioritize the issues as they see fit". If you get pushback on this from people external, tell them that you are extremely busy with your own tasks and don't have time to work on their ad-hoc requests (yes, even if this is a lie, say it anyway). Yes, even if there is a severity-1 service outage or total systems failure, you are too busy to handle it, you work on your own tickets and nothing else. If there is a severity 1 service outage, you must have a ticket for it and it must be added to your sprint and approved by both your manager and your scrum master, who must directly tell you to work on it.

That's it. You tried to be nice and help someone with an ad-hoc task, and you found out how your company responds to people who do that. So don't do it anymore.

  • 6
    Maybe the developers of this site should implement a bot answering every question with "Start looking for a new job", it would save the likes of you a lot of time which could be used more productively elsewhere ;-)
    – JohnEye
    Commented Jun 14, 2022 at 14:09
  • 9
    I tend not to respond to every comment with "find a new job", but in the case of irredeemably toxic work environments it's the right choice.
    – Ertai87
    Commented Jun 14, 2022 at 16:00
  • 5
    How can you tell it's irredeemable with so little context? I would just bring it up on the retrospective and let the team lead and scum master agree on the correct process. I've also had similar things happen to me over the course of an otherwise okay job and it was nothing to change jobs over.
    – JohnEye
    Commented Jun 14, 2022 at 16:34
  • 1
    @Ertai87, I made my decision, I will move on as soon as I get a different offer. Thanks! Commented Jun 15, 2022 at 10:11
  • 2
    Maybe the developers of this site should implement a bot answering every question with "Start looking for a new job" They're all too busy working on their assigned tickets and looking for new jobs Commented Jun 16, 2022 at 12:25

There is no "normal" for start-ups, their whole schtick is that anything goes—it's untethered by beaucracy or organization (to a point).

The team lead's problem is:

  • He didn't take responsibility for his (new!) team member's mistake.
  • He didn't support you by defending you.

The scrum master's problem is:

  • He berated at length a new(!) developer for being led wrong.
  • He lost his temper in a professional setting.
  • He seems to only care for numbers. Because the issue wasn't adding to his numbers, he lost it. This is an awful type of person to work with.

At the end of the day you need to consider:

  • Is this team worth putting up with for the money? (a very valid question)
  • If not, can I help change these people to be better at their job?
  • If not, can I find a better job elsewhere?

Instead of asking whose fault it is "the too-powerful Scrum master or the milquetoast team leader" and regardless of whether you or not, you can handle situations like this better.

Make sure both the Scrum master and team leader are informed that you see a need to do this unplanned work, and how long you think it will take, and ask if that is OK, - before you do it. If there is pushback, then cover yourself by emailing them, and possibly the team, that since you were told not to do this unplanned work, you suggest they might want to make a story for it. Put the ball in their court.

Then, if they turn right around and tell you to do it, only then will you do it. But my suggestion does not fully handle the case where you think it will only take a little bit of time and it turns out to be a lot bigger. Then email them again with the new estimate and ask their permission if they want you to continue or not.

If they want to micro-manage you, let them do their job micro-managing you, - until they get tired of it. If they ask why you always email them about everything, remind them of this situation and say you realized how important it is to the Scrum master not to do any unplanned work.

Finally, realize that they might be under pressure too and just want a scapegoat. With your emails you are "passing the hot potato" so that the scapegoat is not you.

  • OP: If you want to try continuing at this company to see if things can be improved (or just because you like the money), this would be the way to go. Also consider a slight change in your communications style: rather than just asking what you should do, suggest a course of action and say you will be taking this course unless they request otherwise. This gets around the problem of getting a vague or unclear reply to your question that then allows the counterparty later to claim that they did not want you to do what you did.
    – cjs
    Commented Jun 17, 2022 at 8:34

There are two problems here. One is the SCRUM master with bad communication, but the other is a change in your position.

You jumped down from a lead position to a senior position, and now you are surprised that you have less autonomy and must checkin with your lead before spending time on something not agreed upon before.

As the others are saying, company policy and processes are still immature, but that doesn't address the whole picture in my view so I'd like to offer another one.

Perhaps you are not used to not being your own boss anymore to a certain degree, and that's why you got angry (in addition to the SCRUM master's unprofessional behavior which is definitely not right).

P.S. the lead either did not tell you to work on it or he did. It might be that you are still getting used to his way of communication, and should take care of making sure your assigned tasks are clear. If you think he did but he said he didn't then there was a miscommunication which you should fix more than your lead, as you are new therefore the burden of adapting is on you. That's also something you can think about because you worked 13 years (!) in the same company so you need time to adjust to everyone's differences. Communicating is hard!

  • 8
    Nope, I asked the person that was indicated to me to be responsible for my onboarding (which happens to be my team lead in this company these persons may be different) what is the policy and if I should work on the issue. I didn't get an response to those questions, just an indication where in the code to look for (which was useless, since I got tagged because I recently worked on that code) and to ask for an Issue to be created in Jira, I responded with "the issue exists - here". To any normal person this would be an indication to work on the issue, but technically he didn't say yes. Commented Jun 13, 2022 at 16:09
  • 3
    Sorry, OP said they did check in with their lead. With it being a customer reported issue and without a clear signal not to work on it, the only reasonable interpretation I can see is that the lead passively assented. As described, the lead should be responsible for assenting to this work and the "scum manager's" behavior is abusive and unprofessional.
    – Thomas W
    Commented Jun 14, 2022 at 3:42
  • 2
    you are surprised that you have less autonomy and must checkin with your lead before spending time on something not agreed upon before - no, this is not what happened. OP did check in.
    – Rob Grant
    Commented Jun 15, 2022 at 8:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .