Structured Critical Reflection
What Happened? (Concrete Experience)
Initially, everyone had agreed to using Vanilla PHP. Later, with previous knowledge on Laravel I
challenged using Vanilla PHP with Laravel aiming to enhance the team’s technical skills which
everyone agreed to. However, when reviewing the backend team, Dhruhil suggested returning to
vanilla PHP as he did not feel confident in it. I noticed Dhruhil was not the only one unfamiliar with
the framework. Instead of immediately defending our original choice, I took this as a chance to
practice responsive leadership by observing body language, discomfort when discussing Laravel,
silence when asked about progress and nervous eye contact. I asked for input from Trisha, she
seemed uncertain, but we collectively made the decision to switch back to vanilla PHP based on the
team’s confidence levels and our approaching deadline.
What Was It Like? (Reflective Observation)
These moments showed the importance of individual expertise and team capability. My first
reaction was to be defensive; I felt like Laravel had good built-in features and save us time as well
as develop our future careers knowing its importance in the industry. But when I observed the
dynamics of the back-end team; from hesitance to relief, I understood that my good intentions
would cause my team to feel more pressured to focus on understanding the framework instead of
productive coding. This experience revealed to me that collective needs are much more important
than individual needs and team members hadn’t felt heard due to team dynamics and therefore
struggle in silence. The shift in team energy showed that creating space for others’ expertise and
preferences creates empowerment.
What Have I Learnt / Noticed? (Abstract Conceptualisation)
I now understand project prioritisation and team dynamics differently. The Moscow analysis
showed me that my individualistic perception of what was important meant that technical
advancements were a ‘Must Have.’ With feedback, priorities were redefined as team confidence
and productivity was just as important. As a Monitor Evaluator, I noticed that I tended to over
analyse. I learned that when suggesting Laravel, the technical analysis overshadowed the team’s
capabilities and feelings. This aligns with Belbin’s research on team roles responsible for team
psychology and performance. I learnt that prioritising feedback and team concerns would better
collaboration.
What Happened? (Concrete Experience)
Initially, everyone had agreed to using Vanilla PHP. Later, with previous knowledge on Laravel I
challenged using Vanilla PHP with Laravel aiming to enhance the team’s technical skills which
everyone agreed to. However, when reviewing the backend team, Dhruhil suggested returning to
vanilla PHP as he did not feel confident in it. I noticed Dhruhil was not the only one unfamiliar with
the framework. Instead of immediately defending our original choice, I took this as a chance to
practice responsive leadership by observing body language, discomfort when discussing Laravel,
silence when asked about progress and nervous eye contact. I asked for input from Trisha, she
seemed uncertain, but we collectively made the decision to switch back to vanilla PHP based on the
team’s confidence levels and our approaching deadline.
What Was It Like? (Reflective Observation)
These moments showed the importance of individual expertise and team capability. My first
reaction was to be defensive; I felt like Laravel had good built-in features and save us time as well
as develop our future careers knowing its importance in the industry. But when I observed the
dynamics of the back-end team; from hesitance to relief, I understood that my good intentions
would cause my team to feel more pressured to focus on understanding the framework instead of
productive coding. This experience revealed to me that collective needs are much more important
than individual needs and team members hadn’t felt heard due to team dynamics and therefore
struggle in silence. The shift in team energy showed that creating space for others’ expertise and
preferences creates empowerment.
What Have I Learnt / Noticed? (Abstract Conceptualisation)
I now understand project prioritisation and team dynamics differently. The Moscow analysis
showed me that my individualistic perception of what was important meant that technical
advancements were a ‘Must Have.’ With feedback, priorities were redefined as team confidence
and productivity was just as important. As a Monitor Evaluator, I noticed that I tended to over
analyse. I learned that when suggesting Laravel, the technical analysis overshadowed the team’s
capabilities and feelings. This aligns with Belbin’s research on team roles responsible for team
psychology and performance. I learnt that prioritising feedback and team concerns would better
collaboration.
