Lessons learned after leading my first project

Disclaimer: This article is personal to me and does not represent my colleagues or my company

In my previous company, I led a few projects in a local team of 3 to 5 engineers. The project requires a little collaboration with the team in England and Ukraine. Moreover, the whole company is also relatively small as we are operating as a startup.

After working for ~3 months in my new company, my manager trusted me to lead a cross-team project. This time, however, is very different from my previous experience because my new company is much larger and requires me to work across multiple geographic regions.

Define your problem statement#

In my opinion, this is the most critical part of the project. Starts with the problem statement first. Do not jump to implementation details until you understand and are clear on what you are trying to solve; otherwise, you might be spending a lot of effort on the wrong thing.

This also requires reaching out to stakeholders in the company. Everyone has to be aligned on this.

Make it easy for others to review your documents#

When preparing a document, whether it’s a proposal, analysis, or literally anything, you should make it easy for your colleagues to consume. Some of the things that make it easy to read are:

• Use simple and correct spelling and grammar. Grammarly saved my ass all the time.
• Draw diagrams when it’s appropriate. Visual aids will help your peers to understand the context easier.
• If you need feedback from your colleagues, make it easy for them to do so.

Remember, this is a teamwork#

I used to think that leading a project meant coming up with and preparing everything for your team, which is not valid. What you need to do instead is to collaborate with everyone on the team.

I was constantly reminded that we have Business Analysts, Engineering Managers, and fellow engineers to help me in many ways, e.g., Escalating any issues, planning the work, building the roadmap, etc.

On another note, I’ve been reading Software Engineering at Google book, and the book suggests that engineers should not work in silos.

Always ask for feedback#

Especially for a person like me, this is very crucial to get feedback from someone to correct.

After we finished the project’s first phase, I requested the team to do a retrospect session on the project. I learned a lot from that session about what the team is experiencing when working on the project.

Present your findings to the team#

• Be calm. I rehearse a lot before doing a presentation. It helps me to deliver the points smoothly and ensure not to miss important details during the presentation.
• Remember to credit your team members for their contribution