Leading 100+ Engineers Through High-Stress Sprints: My Wild Hacktoberfest & HNG Story

#ai #hacktoberfest #careerdevelopment #opensource

Two weeks ago, if you told me I’d be leading a team of 50 to 100 people through high-stakes open-source contributions on a real-world product, I wouldn't have believed you.

I don't specialize in standard web development: my focus is AI Product Management and Data Science. I build AI solutions and data-driven systems, not traditional web platforms.

So when the HNG Internship started, and everyone as an AI Product Builder was assigned tasks ranging from web to mobile to design and marketing, it created an unexpected mix of chaos. People suddenly lost the unique domain advantage they had in their specialized tracks. Regardless, I stepped up as Team Lead, wearing the hats of both Product Manager and Technical Lead. Imposter syndrome was very real.

Managing a massive team where contributors faced varying schedules, connectivity constraints, and limited availability across different regions meant workflow chaos was constant.

Here is how stepping into a leadership role kept me grounded, helped me navigate high-stress constraints, and drove one of the most intense technical two-week sprints of my career.

The "Selflessly Selfish" Decision to Lead

When the chance to step into team leadership came up, I volunteered.

If I'm being completely honest, it wasn't purely altruistic: it was a survival strategy.

A previous version of myself might have quietly stepped back when deadlines tightened, team availability fluctuated, or the technical stack felt outside my immediate core focus. By taking full responsibility for nearly 100 teammates who relied on me to keep the pipeline clear, guide their open-source contributions, and resolve blockers, I eliminated my own option to drop off.

While running my own setup uninterrupted on solar power allowed me to stay online consistently, managing a team with uneven availability required relentless organization. I couldn't just manage my own code; I had to structure workflows so anyone on the team could jump in and contribute without friction, regardless of their schedule constraints.

I was no longer just accountable to myself. That level of accountability became my primary fuel.

14 Days in the Trenches: What I Actually Delivered

Despite tight deadlines and coordinating a massive cohort of interns, many making their very first open-source pull requests, we executed at high velocity:

🛠️ Shipped & Battle-Tested: Took a functional web app from concept to deployment, testing it live with over 50 real users.
⚡ 100+ GitHub Contributions: Logged over a hundred contributions spanning direct commits, structured GitHub issue creation, and pull request reviews. *🤖 Workflow Automation: Built and configured GitHub Workflows (CI/CD / Actions) to automate background tasks, including automatically updating and generating the contributor list/page for the repository.
🔍 First-Time PR Reviews: Responsible for reviewing peer code contributions for the first time, learning more about contribution best practices, software architecture, and code quality in 10 days than months of isolated study could teach.
🎃 Open-Source Celebration: Decided to kill two birds with one stone by tying our sprint deliverables directly into Hacktoberfest.

!

150+ contributions in 14 days: The October sprint breakdown showing commits, code reviews, and PRs across Zedu repositories.

Lessons from the Grind

Leadership Despite Imposter Syndrome: When 50 people need you to unblock a pipeline, you don't have time to ask yourself if you belong. You just fix the problem.
Constraints Force Action: When you have limited resources and a ticking deadline, you stop overcomplicating things. You build what works, test it with users, and iterate.
Asynchronous Clarity is Non-Negotiable: When leading a distributed team with variable availability, thorough documentation, structured GitHub issues, and clear PR guidelines are what keep the project moving forward 24/7.
Leave It Better: Every PR review, issue ticket, and commit is a chance to make the codebase easier for the next developer to build on.
AI and the Future of Work: AI tools like Qoder, Claude Code, Cline, and Codex are lowering entry barriers and leveling the playing field. However, easy access to AI does not mean everyone will build products on their own. The real differentiator remains problem-solving, team orchestration, and crucial soft skills. I will be sharing more deep dives on AI, soft skills, and the future of work across various sectors right here on DEV.to and on my TikTok channel.

What’s Next?

This is just the start of my Hacktoberfest journey. In future posts, I’ll break down the technical architecture of Zedu (the product we are contributing to) in detail, as well as the personal products I’m building behind the scenes.

If you’re currently managing high-stress sprints, navigating distributed teams, or contributing to open source: keep pushing. Giving up isn't an option.

🤝 Let’s Connect & Build Together: