Having worked professionally as a software developer for several years, I’ve been part of multiple teams where development workflows, responsibilities, and expectations were well understood. Across different teams, including at my current job, there has always been a common framework for how work gets done, with clear expectations around code quality, collaboration, and accountability that team members consistently follow. There has also always been an unambiguous leader–someone to make final decisions, set expectations and priorities, and keep things on track.
This project has presented a very different dynamic, and it has made me realize how much I took for granted the structure and leadership that helped my previous teams run smoothly. I initially assumed that a well-functioning development process would emerge organically, but I now recognize the importance of deliberately establishing structure and alignment. Without clear expectations, work is done inconsistently, best practices are an afterthought, and accountability is hard to maintain.
As the project progressed, I found myself needing to take on more of a leadership role to help establish the structure we were lacking. This has been an uncomfortable shift for me. I’ve always preferred to focus on my own work rather than trying to manage others, and I don’t at all enjoy feeling like I’m telling people what to do. But without clear expectations or direction, the team struggled to stay aligned, and progress suffered. This wasn’t anyone’s fault–everyone works differently, has different priorities, and brings a unique level of experience to the table. I remember what it was like to work on a development team for the first time–how overwhelming it felt to navigate unfamiliar tools, processes, and expectations. I had no idea what was going on half the time, and I relied heavily on the more experienced developers around me to provide guidance and structure. Now, for the first time, I find myself on the other side of that equation.
One of the biggest lessons I’ve taken away is that, while high standards are important, focusing too much on perfection can slow progress and create unnecessary friction. At the end of the day, working software is far more valuable than perfect software. Keeping momentum is key, and if something truly needs refinement, I can always revisit it later or fork the project once it’s complete. I also feel that I’ve grown significantly as a developer over the course of this project. Unlike other projects where I’ve focused more narrowly on specific tasks or smaller parts of larger systems, this time I’m involved in everything (backend, frontend, DevOps, project management, etc.) and understand the project from top to bottom. This has helped me develop a stronger sense of how to make architectural decisions, troubleshoot complex issues, and ensure that different components integrate smoothly.
This experience has given me a new perspective on what makes teams and projects successful. These are some of the most important lessons I’ve learned along the way:
- Leadership is about taking responsibility
Leadership often emerges out of necessity rather than position. Even when roles are loosely defined, someone has to take ownership to keep things on track. - Structure doesn’t emerge on its own
Clear workflows and expectations don’t happen by accident–they have to be deliberately established. Without them, even talented teams can struggle with inefficiencies, misalignment, and stalled progress. - Effective teamwork isn’t just about individual contributions–understanding the big picture is crucial
A successful project isn’t just a collection of completed tasks–it’s a system that needs to function as a whole. Making sure everything integrates smoothly is just as important as getting individual pieces right. - Every team operates differently, and adaptability is crucial
What works in a highly structured, experienced team might not apply in a more loosely defined environment. Recognizing those differences and adjusting expectations is key to being an effective team member. - Progress > perfection
Chasing the ideal version of something can often slow progress. Prioritizing working software keeps momentum going, and if something really matters, it can always be revisited later.
All in all, this project has been one of the most valuable learning experiences I’ve had. It has pushed me outside my comfort zone, forcing me to take on responsibilities I wouldn’t have otherwise. I’ve gained a deeper appreciation for what it takes to keep a project moving forward and the immense value of clear communication, shared expectations, and collaborative problem-solving in building successful software.
