Mid-week check-in
Event
On day 3, I think this is where the panic started to shake in for some team members. No one really made any breakthroughs, but I had told them just having the process was fine. I had also previously confirmed with people on the client side that the sources we found were new and valuable to them. To help calm them down, I decided to call the client asking them what they maybe wanted apart from the brief questions, and what should we present should we fail to find anything. Luckily the client was really nice and just mentioned they were interested in the process too. I think the ice-cream and snacks I bought also helped boost team morale.
I quickly called a meeting to reassign tasks based what they just said as well as start creating the powerpoint and also started documenting what we did since day 1. Hearing the client’s response I think a lot of people was re-motivated and some even managed breakthroughs. Some team members were skeptical of their work, but being a tyrant, I forced almost everyone to present. To their surprise the client seemed to be very impressed with everyone’s work.
Keeps
Lots of quick meetings:
Whenever I felt like there was changes in our objectives, I held a quick meeting followed by a stand-up scrum to reiterate the tasks again. This ensured everyone knew what they were doing (except on day 1, even I had no clue). This way everyone was constantly work on something different and not do repeated work.
Forcing everyone to present:
I think getting the client’s input on our work so far was important. It not only provided confidence for us, but also more information and what the client further wanted from our work currently. I also got everyone to start preparing what they were going to show 30 minutes before the check-in started, so everyone was well-versed and the demonstrations were working.
Improvements
Document earlier:
As a team leader, I should have been constantly documenting the process on where everyone was and what they were doing. This would help create references to what we’ve tried, and also a greater coherent story in the presentation.
Priority:
I generally wanted the team environment to be easy going and relaxed. However, I think I could have put slightly more pressure towards time and priority. At this point the client seemed to already be impressed with what we have done, so I think it was better to tie it up there and finish everything we showed. Some team members that had finished their original tasks started to explore more. Although this worked greatly in our favour in the end, I think it’s best if they helped the others finish up instead.
Presentation
Event
As everyone started to go towards the end of their tasks, I stressed the fact to not be a perfectionist and just created something that would work. At this point I had to stop all attempts of team members trying to do tasks outside of their assigned ones, instead focusing all their efforts on the one they have. Work was going smoothly and I think at this stage most people realised that the seemingly insurmountable task was actually doable.
In the quick morning Friday meeting, I stated I wanted everyone to finish by 10 am. This was obviously a pipe dream. With all the stubborn last minute changes and the template for the workflows I introduced a little too late, we finished at 2 pm. Luckily before then I had gotten a lot of help and advice from others on how to add value to the presentation from a team leaders perspective.
Keeps
Keeping up the meetings:
Confidence is a great thing within the team. The quick meetings gives everyone the sense that the team has everything covered and instills a positive notions. However, with the newfound confidence people tend to steer off the initial brief and this also allowed me to make sure they are on track.
Presentation practice:
Having understood that we already had all we needed work-wise, I wanted to make sure the presentation was perfect. I think I benefited the mostly from this, as I’m never great at addressing the presentation in a structured way.
Consistent Templates:
The template not only made our workflows consistent, presentable and readable, I also asked for everyone to put the business problems they were trying to solve there, as well as use cases for their parts.The screenshots and readable large text made code presentation, which I think is often quite boring and hard to follow much easier to digest.
Improvements
Focusing on the negatives too much:
As I told everyone to put what they thought could be improved, there were a lot of points on how to improve our work. It was also at the end of their presentation, so it was like ending on a low note. I think either presenting earlier or just going over it more briefly would have been better.
Time:
In hindsight, I think things could have been time-boxed better. I gave everyone the time I think they needed, not accounting for sudden changes and blockages along the way. I noticed this only on Friday, so I tried to put an earlier time limit on finishing. However, in the end we still missed out the chance for a full practice run, which resulted in some small errors in the presentation.
More structure:
This is always something I have struggled with in the past. I think the little things like having everyone always put in their work in the folders and putting a general time constraint towards each step all contribute to making things clearer. However, I realise that this is something that I should focus on immediately when I come in as a team leader as trying to bring it in mid-way through is quite difficult.
