The theme of this week’s lecture is about Driving Action and Accountability. We learned how leaders can turn plans into execution by delegating effectively, maintaining accountability, and using structured methods to ensure consistent team performance. If you are new, this is a continuation of the IT2900 Weekly Reflection series where I share my responses to the weekly assignments of this course.

The previous week’s blog post was titled “Courage Can Be Reduced to Stupidity in Polynomial Time” You can take a look if you later find this article interesting.

Personal Takeaways (From Lecture)

I personally found this lecture quite content-heavy compared to the others. We went through several methods and techniques regarding the driving of operational excellence in an organisation where “execution” matters. We also learned that leaders should delegate responsibilities to people in the team, but not accountability. This lesson is meaningful to me because I believe it is a great rule of thumb to keep in mind. Sometimes, inexperienced leaders may over-delegate tasks, pushing not only responsibility but also accountability to the team, which should be avoided, as accountability lies in the ownership of outcomes and consequences.

Aside from that, the takeaways I would like to share are about the key problem-solving techniques and algorithms that we learned in courses like CS1101S and CS2040S, which can have impactful implications and make operational execution more approachable and easier to understand.

1. Wishful Thinking: This was introduced when creating plans for a project. We first think of what we want to achieve and then break it down into smaller problems. I believe frameworks like OKRs are also built on this principle.
2. Binary Search: This was introduced as a rule of thumb for leaders to check in with people on the team. In short, we should define the minimum and maximum viable duration between check-ins and use a “binary search” approach to find the optimal frequency for each person (essentially: if the person is doing well, check in less frequently, and more often otherwise).
3. Fractional Knapsack: This idea was introduced to optimise the overall work output across a team. We can think of the size of the work as one parameter and the working speed of each person as another. By understanding these two factors, we can estimate timelines and plan workloads to maximise efficiency. I personally like this one the most, as it closely relates to my experience at CVWO, where Prof. Ben mentioned a similar idea.

The key implication of these principles is clear. When I lead a team and need to make decisions where these techniques apply, I will use them. The last one (fractional knapsack) is a bit tricky, but it essentially requires understanding both the team member’s capability and the scale of the work assigned. Using these two factors, I can assign tasks more efficiently, which makes it particularly useful for a leader.

I love these takeaways because they are “common sense made clear.” There is no need to prove that they work since these techniques directly guide us toward achieving our goals. Having them in mind helps us operate in “auto-pilot mode” when performing repetitive tasks, and over time, this becomes second nature (unless other factors arise that require a system-two thinking). Having a concrete framework also ensures perceived fairness within the team, since it focuses on the “process rather than the person”, which aligns with the idea of dealing with failures in organisations that I discussed in previous reflections.

Personal Takeaways (From Readings)

For the reading, I think I resonate the most with the article “How to Stop Delegating and Start Teaching” by Art Markman. In the article, he emphasises that leaders should not simply hand off tasks when they are busy but rather teach others the reasoning and processes behind the work. It suggests that true leadership involves cultivating others’ abilities so that, over time, they can handle complex responsibilities independently.

The idea presented here connects closely to what we also learned in class about how “leaders should delegate responsibility, not accountability.” This article reinforces that insight by offering a structured way to avoid the trap: “to train before trusting”. From my past experiences in CVWO, for example, I think my team lead did a great job in this aspect. He first identified the gaps in the Gantt chart to see where people were available and could take on work. He also had a strong understanding of each team member’s capabilities by training everyone equally during the early period of the program. By the time we reached the middle of the internship, when the actual project work began, he could assign tasks based on our capabilities, strengths, and weaknesses.

If I were to lead a team again, I would adopt this apprenticeship-style teaching. For example, I might start by explaining my own decisions and reasoning for task allocation or code review criteria and gradually allow team members to take ownership under my supervision.