Research Summer Week 4: Building Resilient Research
At the start of this week, I realised I had made a mistake. As I began to process the secondary data I had collated and combined from sources such as Companies House, and the Charity Commission, it became clear that, as a result of a bug in my code, a large number of entries had inadvertently been merged with information from multiple organisations. In some cases, a charity’s objectives had been paired with another organisation’s website, contact details or activities.
The problem was compounded by the fact that, since the merge had taken place, a considerable amount of additional work had been completed on the database. Correcting the issue was therefore not simply a matter of reverting to an earlier version; doing so would have meant losing many hours of subsequent manual research. Instead, we were faced with the much more time-consuming task of identifying and correcting each erroneous record individually.
At the same time, I became ill, making it increasingly difficult to maintain the pace of work I had anticipated. Alongside manually reviewing the affected records, I was also taking on responsibility for drafting sections of the team's initial findings report. For the first few days, I tried to continue managing all of these tasks myself. Eventually, however, it became clear that this was neither realistic nor productive.
This meant I had to acknowledge both the coding error and my own limitations to the rest of the team. This became one of the most difficult parts of the week. I had to explain the source of the problem, the scale of the work required to fix it, and the fact that I would need others to take on a greater share of the workload while I recovered. I initially found this very uncomfortable. I realised that I often approach teamwork with the mindset that, if I can complete a task efficiently myself, it is quicker to do so immediately than to ask someone else and wait for them to finish before continuing my own work. This attitude had shaped the way I approached the technical aspects of the project. I had undertaken much of the coding independently and had not documented every stage of the data-merging process in sufficient detail. While this initially felt efficient, it became a weakness when I was suddenly unable to contribute as much. My teammates had less familiarity with the underlying code and the structure of the datasets, making it more difficult for them to step in and help resolve the merge errors.
However, ultimately, owning up to my mistakes and asking for help massively strengthened our team’s ability to collaborate. My teammates were incredibly supportive and immediately adjusted the tasks assigned to each member to ensure that we could meet our deadlines despite the setbacks, allowing me to recover fully. I'm very grateful to them for their understanding and dedication to the project.
This experience has fundamentally changed how I think about collaboration. Contributing effectively to a team is not simply about completing as much work as possible yourself. It is about creating systems that enable the team to continue making progress even when one individual cannot. Documentation, knowledge sharing and delegation are not administrative burdens; they are essential components of rigorous and sustainable research. Although involving others may initially feel slower, it creates resilience that cannot be achieved through individual effort alone.
Looking ahead, I want to make a conscious effort to document technical processes more thoroughly, involve teammates earlier in specialist areas of work, and communicate more openly when I need support. This experience has reinforced that rigorous research depends not only on careful methods, but also on collaborative systems that allow knowledge to be shared and work to continue when circumstances change. These are lessons I hope to carry forward throughout the remainder of this project and into my future career. Whether in research, public service or leadership, resilience is rarely an individual achievement. It emerges through trust, transparency and shared responsibility.
Please sign in
If you are a registered user on Laidlaw Scholars Network, please sign in
Isabel, this is an exceptionally honest and insightful reflection. You have moved beyond acknowledging a coding error to identifying the organisational conditions that made its consequences more difficult to manage: limited documentation, concentrated technical knowledge and an understandable tendency to equate individual speed with team efficiency. That is a sophisticated piece of leadership learning.
Your decision to explain the error clearly and ask for support demonstrates integrity rather than failure. Research inevitably involves mistakes and unexpected complications; rigour lies partly in whether these are recognised, communicated and corrected transparently. Your team’s response also supports your conclusion that resilience is relational: it emerged through trust, redistributed responsibility and colleagues’ willingness to adapt.
I was particularly struck by your recognition that documentation and knowledge sharing are not merely administrative tasks. A process that depends upon one person’s continued availability may be efficient under ideal conditions, but it remains fragile. Creating systems that others can understand, scrutinise and continue is therefore part of both good research practice and responsible leadership.
If—and only if—it does not add significantly to your workload, there may be value in including a concise account of the data workflow in the report appendix. This could document the data sources, merge rules, validation checks, correction process and any remaining limitations. You might then add a short “recommended workflow” showing how version control, staged validation and shared documentation could prevent similar problems in future. This should be a team-owned output, perhaps as a one-page flowchart or checklist, rather than something you feel personally responsible for producing.
It is important that the appendix distinguishes the process actually followed from the improved process developed through hindsight. That transparency would turn a difficult experience into a valuable methodological contribution for the partner and any future team working with the database.
This is an excellent reflection on accountability, collaboration and sustainable research practice. You made a mistake, but you also created significant learning from it — and responded in a way that appears to have strengthened rather than weakened the team.