How Tech Consulting Shaped My Approach to Molecular Biology
Life has a way of connecting dots you don't always expect. When I left my position at a major tech consulting firm to pursue molecular biology research in my late 20s (a journey I'll dive into in another post), I carried a host of hard and soft skills that I'd assumed would be generally useful. But, I found myself drawing on my consulting background in ways I hadn't totally anticipated; after settling in, I began to see how the tech industry's methodologies could enhance scientific research, and how software development practices could address common pain points in lab work. While context matters, the fundamentals of building great teams and orchestrating complex projects are remarkably consistent regardless of field.
In this post, I aim to highlight management styles common in the software development industry but perhaps less familiar within the scientific community. Here, the term 'management' encompasses both individual task planning and broader team orchestration. Whether you're a scientist seeking improved self-organization or leading a team/project — as a PI, post-doc, or industry researcher — I hope this piece provides insightful frameworks for you. I believe there remains a gap in graduate programs and academic labs regarding exposure to these crucial management skills that enable systematic approaches to how we structure experiments, manage projects, and run labs.
While I'm not the pioneer in addressing this topic — several individuals have shared their perspectives nicely on similar concepts such as those found here or here — each of us brings a distinct lens and presentation to our experiences. And as is the case in science, there's value in independent voices arriving at a shared consensus, right?
A Brief Dive into Work-Style Management
For those unfamiliar with the terms, let's take a brief detour. In the arena of project management, there are two primary standard methodologies: Waterfall and Agile.
Waterfall: Originating from the manufacturing and construction sectors, the Waterfall method was first conceptualized in the 1970s. It’s a linear, phase-based approach where one step logically follows and depends on the completion of another. I like the analogy of setting up dominoes in a line; you carefully plan each step and placement one after the other, and only when one is fully knocked over can the next do the same. There is one end-product or deliverable in mind that is considered complete when it’s ready in its entirety. It's systematic, thorough, and leaves little room for deviation.
Agile: Born out of the software development boom of the 1990s and early 2000s, Agile emerged as a response to the limitations of the Waterfall method in the rapidly evolving tech industry. The Agile Manifesto, published in 2001, emphasized flexibility, collaboration, and feedback. Instead of a linear progression, tasks are broken down into smaller chunks or 'sprints', typically spanning two weeks. At the end of each sprint, progress is reviewed, adjustments are made as necessary, and tasks move forward. It's dynamic, adaptive, and iterative, and prioritizes deliverables early and often.

While popular narratives often depict these strategies as opposing forces, the truth, like many aspects of life, is more nuanced. In practice, they often coexist on a hybrid spectrum and their applications determined by the scale and context of what is being addressed. The real question is where each is relevant, and when to employ each as a best fit in the context of your specific projects.
Consider this: when planning an individual experiment or assay, the Waterfall approach is often most effective. You want to measure the effect of gene X on the transcript levels of gene Y. You make a workflow – seed the cells, transfect them with an over-expression plasmid containing the sequence of gene X, wait some pre-determined time, collect the cells, isolate RNA, perform cDNA synthesis, and run a qPCR for gene Y. Each step requires the completion of the previous in a methodical and sequential fashion. Invest time meticulously planning each task beforehand, making detailed calculations, and visualizing workflows. Ensure you have the appropriate types and quantities of reagents and kits before starting. This thoroughness ascertains that when you finally execute, you're well-prepared. It's the old adage: measure twice, cut once. Your final deliverable is the completion of the individual experiment along with generated results.
Yet, when we zoom out to broader projects or even tasks spanning a month in research, a strict Waterfall approach is rarely the best fit. This sentiment is even inherently baked into guidelines for best practices when submitting grant proposals and outlining specific aims: minimize the amount of interdependency between your aims in case one doesn’t work out entirely as expected.
Agile for Researchers
Given this context, I want to spend the rest of this article focusing in on when and how to implement Agile. Here's the thing: research, especially in fields like molecular and cellular biology, is unpredictable. Experiments can yield unexpected results, hypotheses can change, and new leads can emerge. In such a fluid environment, Agile shines.
It’s easy to get lost in the myriad of tasks or going down rabbit holes while chasing an idea.
When planning for oneself, it can be daunting to get over the activation energy needed to take the first steps working towards generating data and clarify exactly what need to be done. While orchestrating a team, it’s crucial to ensure that every member knows their role and what's expected of them in both the short and long term. Let’s break down where to start, and how Agile can help:
1. Create a sprint schedule
In either case, create a 2-week sprint timeframe. While you can extend this to 4 weeks if necessary, I'd advise sticking to the 2-week timeframe and determining achievable tasks within this scope. Begin by determining your active projects. For each, create and assign specific, bite-sized, actionable tasks to accomplish. The granularity of these tasks can be fine-tuned to what works best for you and the team – as detailed as individual actions like ‘seed plate, perform transfection, harvest cells’ (more applicable to your own or individual task tracking) to as broad as an end-to-end assay (more geared towards orchestration of whole projects or labs). When tracking yourself, I'd suggest starting with more detailed tasks; the satisfaction of ticking off even small tasks can boost mood and motivation. Any tasks that won't be able to get done within the next 2 weeks go into your 'backlog' section, which acts as a pool for your next sprints.
2. Visualize and track your sprints:
In addition to ensuring a constant flow of work and tangible deliverables by the end of each 2-week period, the beauty of sprints and their tasks is that they can actively be tracked visually, using Kanban boards:

Originating in post-World War II Japan, the term "Kanban" translates to "visual signal" or "card." It was developed by Toyota factory engineers who, inspired by efficient supermarket inventory tracking and stocking methods, aimed to optimize their production system. The core idea was to maintain an efficient flow by minimizing waste and maximizing value.
Kanban emphasizes the visualization of work. Through Kanban boards, teams create a visual model of tasks and workflows, enhancing understanding and communication. This approach has been widely adopted in various industries, including software development. A typical Kanban board is divided into columns representing different stages of a task, such as "To Do," "In Progress," and "Done." As tasks progress, cards are moved between columns, offering a clear visual of progress, workflow, and helping users identify bottlenecks and balance workloads efficiently.
There are several popular free or paid tools (such as Notion) available for creating and maintaining Kanban board-style tracking of sprints and tasks, some options of which can be found outlined elsewhere. You can also create your own with preferred methods of tracking (ex. Excel, OneNote, etc.) – what’s important is to keep a task backlog, in-progress, and complete section at its core, and be able to save sprint history.

Tasks can roll-up to user stories (ex., an assay), which roll-up to epics (ex., an aim), which roll-up to initiatives (ex., a project or grant). Several other resources detail and describe examples of how you can break down a hierarchy that parents individual tasks. This part will be unique to your use cases and customizable to what you find works best.
3. Conduct retrospectives:
After each sprint, set aside time for reflection. If you're leading a team, gather everyone for this review. Did any tasks encounter obstacles ("blockers") and remain unfinished? Determine if the challenges were due to misjudged effort estimates or other issues that need addressing. Transfer any incomplete tasks to the next sprint, ensuring they're balanced with the new tasks being introduced. This ties into the principles of scrum, which won't be covered in-depth here but can be found explained elsewhere.
4. Plan the next sprint and iterate towards the big-picture goals: As you start progressing through tasks and getting results back, you’ll undoubtedly get new ideas or directions to follow. Re-adjust the sails as necessary, re-prioritize, and use this information in tandem with lessons from retrospectives to plan the upcoming 2-week sprints.
Conclusion & a Final Note of Caution
By integrating the adaptability of Agile with the precision of Waterfall, researchers can navigate the complexities of science with newfound clarity and purpose. In essence, while Agile provides the roadmap guiding researchers through the broader journey, Waterfall ensures that each pitstop and task along the way is well-planned and executed.
A final word of caution: while these management techniques can be powerful tools, they shouldn't become an end in themselves. Be wary of getting caught up in rigid frameworks, excessive planning meetings, or inflexible sprint schedules that consume more energy than they save. The best implementation is one that adapts to your project's needs, not vice versa. Whether it's choosing the right tracking tools, adjusting timeframes, or setting meeting frequencies, focus on finding a rhythm that enhances rather than hinders your research progress. When implemented thoughtfully, Agile principles can significantly boost productivity. But remember: these are tools to serve your research goals, not checkboxes to maintain. Stay flexible, observe what works, and adjust accordingly. The framework should evolve with your project, creating a natural synergy that propels your research forward.
This is amazing!