Is it normal for startup team leads not to protect their team members?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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?

Answer 6

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.

Answer 7

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!