Developer doesn't make deadline

Question

Situation:

Company is about 50 people. Total number of developers is about 15, split into three teams. Team 1 has five developers working hard building a new system. The deadline is yesterday, which means there's no specific dealine set, but the sooner we finish, the better.

We have no scrum master or project manager. I'm the most experienced developer on the team and seen by the CEO as the lead of the team, I preside the weekly meeting with the CEO and other stakeholders etc.

T is a new teammember since three weeks. He talks with the CEO about something he really likes to do the new system, however it's not something that's currently on the task list. The CEO is enthousiastic and asks how long it will take for T to do it. T says it will take about half a day to day. "Great" answers the CEO. "Come and show it to me tomorrow".

Tomorrow comes and the task is not finished. So T wants to continue with the task the next day.

My feelings:

I feel like T intentionally made a low estimate of the task, to make the CEO say yes to the task. However T now has no time for the other planned tasks, and his new task is taking an unknown amount of time. I feel this is a problem for the planning, and it should be solved by T.

Question:

What should I do?

My answer:

I'm really torn about the way to act:

1. I can ignore the situation. T will do his best and probably finish the task soon. Making estimates is difficult, maybe even more so when asked directly by the CEO.
2. I can ignore the situation, as I'm not the manager or official leader.
3. I ask T how he's gonna solve the situation. Accepting a deadline and then not delivering is not something that can be ignored. Of cource one can always miss an estimate, but when one's going to miss a deadline it must be anounced before the deadline is over.
4. Since I'm not the official leader, but the CEO is seeing me that way, I need to make a mark. So I have to talk with T, saying he has to let me know about the situation so we can find a solution together.

Update

Wow, great answers! I have upvoted them all (not publicly visible unfortunately). I was a bit afraid I was taking my percieved role too seriously, but you guys gave me the feedback so I know I'm on the right track. I already talked to the CEO about the scope creep and will continue to do so on any occasion. Again thank you very much!

Answer 1

You are perceived as the team leader, so in the absence of anyone with that formal title, you have to take on that role. You already meet regularly with the CEO as though you have that formal role, so, by default, you lead the team.

I suggest that you talk to the new team member, find out whether it is realistic that he can develop the new capability in a realistic timescale, and then discuss the options with the CEO, explaining your findings. If it is reasonable to complete the development within a short timebox, then the CEO may agree to the work continuing. If your advice is that it is unlikely to be completed, you should recommend a course of action, such as stopping the development, or deferring it to a later phase, or even allocating time to it, if the feature is sufficiently important. What you can't do, given your de-facto role, is ignore the situation - otherwise you are not fulfilling your role.

Taking a step back from this, I worry that one developer has been able to take the project off track in this way. Once again, as you are the team lead in all apart from name, you should be controlling the development activity, and ensuring that any proposed scope changes are impact-assessed before being approved. If you don't impose your authority now, then you are going to have anarchy within the team, with other developers (and especially this new one) going to the CEO whenever they think of something new to add into the scope, and the project will never deliver because there is always something new and shiny to build. Perhaps you need to complete the agreed scope, then have a further release where new ideas can be added?

Answer 2

Leaders of teams are not only because they were officially designated as said leader of a team. They lead because they assume the role and once assumed they are the de facto project manager and are responsible and accountable for the project in the exact same way as if they were officially designated. You cannot lead the team, be looked at as the leader of the team, but then shirk off the responsibilities and accountability therein.

And you made a fatal error: you allowed T and the CEO to creep your scope. And now you're dealing with the effects of scope creep. Nothing more, nothing less.

The good news is, scope creep happens to the best of us. And recovery is available to you. You need to sit down with the CEO and outline what you have observed, that T and the CEO introduced an out of control change that jeopardizes the entire project as a whole. Though the change might be a super idea, introducing it needs to be "in control", that it is analyzed by the broader team, impacts identified and understood, schedule and costs adjusted accordingly, things reprioritized, estimates and planning values agreed upon holistically by the broader team, and then have the work scheduled. You need to "teach" your CEO about scope creep and scope control and how important these things are and to have your CEO commit to this moving forward.

After this, you need to have a meeting with the rest of the team, maybe with T alone, too, and set proper expectations about this kind of thing and never do it again. If you feel like you don't have this authority and the team won't follow you, then you are not the leader of the team.

Answer 3

In the absence of formal authority here, you will need to tread carefully. You may be inferring how the CEO sees your role and it may not actually be how he sees it. Also, if you have a formal manager who although not a senior developer is still your boss, I'd be wary assuming formal authority you don't have. I do agree with others that it's in your best interest to demonstrate leadership but you need to do this informally e.g. by simply removing the obstacles and making things happen. My gut instinct is to work with your colleague and treat him as an equal unless you are formally above him. Even if you are senior developer and he is junior developer, if both of you report to the same manager, you are not his boss and he won't appreciate you acting as if you were. Try and understand what's blocking him, offer to help him, remind him of the dangers of over-promising and under-delivering. I am assuming that you do want to help him and are thinking in terms of the team and don't simply want to take his scalp. It may be that you end up having to do the work yourself but make sure this is known, without rubbing his nose in it. After all, even if he is actually underperforming, if you are not his boss it is not your place to sanction him.

Answer 4

Short term you can give T enough rope to hang himself. You preside over the weekly meetings, so hold him accountable for the work that he isn't doing when this affects the project schedule/cost/scope/risk/etc. If his going off on a tangent doesn't cause a problem then no harm and no foul, but if it causes delay don't try to be a "nice guy" by covering up for him.

Longer-term, your project has a couple of major challenges:

• No formal leadership. Without this there will be little in the way of authority, responsibility or accountability for success. You don't need a scrum master or a project manager, you need someone in your leadership structure to own this project who will make decisions like the one T went to the CEO for.
• No formal deadlines. You need a date that the system has to be ready by. And "as soon as possible" is a Bull-Sh*t answer, you need a clear date that is reasonable, feasible and achievable given your scope.

Ideally you will be able to address these core issues to prevent T (or someone else) going rogue and adding scope or cost or whatever with no control. This will take some effort but will save you problems long-run, because at some point if your team doesn't have discipline someone somewhere is going to cause the project to fail.

Answer 5

Since you are not the official leader, the best you can do is to talk to the project manager or scrum master. Talk about the importance of the project, and suggest to timebox the off track project; maximum one day more, and then the team needs to move on. Moreover, the team can check this project after delivery.

The new person may start this project, because he or she does not have the domain know-how yet, and would like to prove that he or she will be good for the company.

Answer 6

This could have been a test from your CEO - he did not consult you about your thoughts on T's idea - although he sees you as team lead and therefore as an expert.

I would talk to your CEO about a bit (!) formalism in the planning of new requirements, so that more than one developer can think about them and the estimate of effort is done either only by one experienced team member or by two or more developers together.

For time estimations I recommend the book "Waltzing With Bears" by Tom DeMarco and Timothy Lister. It's not too long and fun to read and will teach you an improved method of time estimations (optimistic - realistic - pessimistic) where you can set the reliability you want to have.

Also talk to T, but more to get his intentions why he did that solo with the CEO. Does he want to be part of the team? I think his action will have cost him trust of the CEO and the rest of the team. Did he think of this risk before? Is he just an a**hole and wants to be the shiny star of the company? Does he want to take over your leading role?

You should not ask him all those questions directly, but I hope you have enough intuition to find out.