Jr Software Developer Project Lead

Huh? What’s that? The title makes no sense and it’s an oxymoron?

Well normally you’d be correct and you’d never see a Jr Developer in a Project Lead role, but in the magical land of startups, anything is possible.

Setting the Scene

The story begins with when a couple of UX/UI designers and a software engineer, all Flatiron Alumns, decided to start an agency called City of Wind Design. That one engineer invited me onto the agency so that we can all work with real clients, develop real world experience, and practice our craft while searching for full time employment. At City of Wind Design, I ended up working on many things outside the scope of Software Development, but also outside the scope of a typical Jr Developer. This was becoming a project lead for an in house e-commerce project while on-boarding two new software developers as well.

There I was, timid Jr Developer who was also working on another project and was given this management-like task. The situation proved to be daunting at first. Exciting, of course, but I wanted to provide a great experience to our two new developers while creating high quality code for a high quality project. While we are a few weeks into the project, I believe we are through the toughest parts of the project. These being the toughest tasks any engineer has ever faced. Social interaction and proper communication.

Plot Conflict

Interestingly enough, the biggest time eaters wasn’t coding or even frustrating bugs. Instead it was communicating between the Design team lead and my own team members. This all included learning how the design team worked, what they tangibly brought to the table, and making sure that all of my fancy words made proper sense. Obviously, these weren’t fancy words, but most non-developers don’t really understand what a schema, hash, migrations, or CRUD means from basic context alone.

Part of the issue was also getting to know my team well enough to understand their strengths, preferences, and pace. That last point is the hardest to determine. In today’s world, society instills into us that we need to grind and always hustle just to get by, all the while putting an eager face on and keeping any complaint internal. As part of the agency’s vision and my own philosophy, I did not want to continue this cycle. I wanted to help these engineers by giving them code and features to work on while also not overloading them and burning them out. On the other hand, I also didn’t want to give them so little work that the project barely moves forward and that the developers themselves don’t become unaccustomed to these expectations.

Conflict Resolutions

This was complex scenario with a lot of challenges that wasn’t directly related to each other. As such, I had to step back and really evaluate my position and understand it. To solve the Design team communication issue, I decided to sit in on Design meetings to observe. The Design team being the wonderful individuals that they are, indulged me with answers to any questions I had, no matter how simple they may have been. While this process is ongoing, I have learned so much of what I have available to me that I didn’t realize I had.

To solve my time consumption issue, I blocked off time just for communication or discussion and also for coding. For it to be effective, I had to strict on these divisions to avoid distractions and the time wasting that multi tasking is known for.

To solve my team responsibility concerns, I continually ask for general feedback but also feedback on specific actions I take that I’m not sure are the best decisions and also on communication tone. It’s easy to forget that the many facets of language, such as satire and energy, aren’t as easily translated across text than in person. I also make sure to not just make my team feel heard, but actually are. Furthermore, I organize an agenda document before team meetings to stay on track over video calls and to make sure that all important items are covered.

Conclusion

As scary as this position seems, it is doubly exciting. This is an excellent opportunity to really determine what practices are best from a project lead and project member perspective. However, accountability and responsibility are the biggest lessons here. The forward movement of a project is traced back to me, but the quality and success of it is due to the whole team. Team camaraderie has always been my favorite part of Software Development.

Leave a comment

Design a site like this with WordPress.com
Get started