One of the things I was hoping to do in my new job is take on more leadership responsibilities. Not management or leading a team (although those are both potential future goals for me), but leading projects and maybe even having the opportunity to mentor junior engineers. When my team was discussing our goals for Q3, my team lead offered me the opportunity to lead a small project, and I was excited to take on this challenge. It involved rewriting one of our features from a legacy codebase to our more modern codebase, and not only was I asked to plan out the project, I was asked to find work for our team's junior engineer to do and to help guide them through any questions or problems they may have.
My first attempt at leadership was not exactly the resounding success I was hoping for. While the project looks like it will be completed (it's still in progress, but we're getting close to the end), I don't think I planned it well or distributed the work effectively. At the start of the project, I made a document that (I thought) included all of the information we needed for the project, including a list of test cases (and I then asked one of our QA engineers to look over my test cases and add any additional cases they thought of). But as we went through the project, we came across questions that I didn't have answers for and things I should have looked into more. I didn't do enough research into a (new to me) library that we would be using for the project, and I didn't look into how we normally do accessibility testing (even though I created a ticket for a11y testing). I also didn't have the answers to some questions that the junior engineer working with me had (although I did know who to ask).
I also didn't distribute the work very well. I went into the project knowing that I wanted to find work that would be manageable for my team's junior engineer but still challenge them a bit. In fact, in the early stages of planning, I had a particular project in mind for them. As I was creating tickets, I realized that there wasn't really much work to do outside of what I was asking the junior engineer to do, and while I did have some work for myself at the start of the project, I needed to finish that work before the junior engineer could complete their work, and for most of the time I didn't really have anything to do (at least related to this project). After I finished that early ticket, I realized that the whole project could have been done, and I should have advocated for the junior engineer to be working on it by themself (with me available as a consultant if they ran into any trouble or wanted a second set of eyes on something).
Another area where I could have done better was pairing with the junior engineer on my team. We had a few parts of the project that we worked on together, and for those I felt like I was either writing most of the code or telling the junior engineer what to do, rather than letting them figure it out. This was effective in getting the work done in a timely fashion, but since we weren't on a specific deadline, I probably could have given the junior engineer more opportunity to learn it on their own with me on a call as a reference, but not really saying much. That said, most of the pairing we did was at the request of the junior engineer, and I'm hoping that they did see it as a good learning opportunity and gained as much as I did (or more) from our time working together.
Although this project didn't go exactly as I had hoped it would, there are some aspects of my work that I am proud of. Tthe planning document I wrote was fairly thorough, and while it was missing a few things, it did contain a lot of useful information that I referenced several times during the project. I was also very proud of the main ticket I worked on, both because it was a more design-centered ticket than anything else I had done at this job so far and because it required me to put a lot of thought into how to make it a good experience for all of our users, including (and especially) those who interact with our site using a screen reader, since the project I was working on was fairly visual. I'm also proud of the fact that when I realized that the work I had done didn't really fit well within the context of the feature, I took a few days to refactor my work and make it work much more seamlessly with the feature we were building.
Even though I wasn't the one doing the work, I'm very proud of the work done by the junior engineer on my team. I wasn't sure how they would feel about the project, since they were also (relatively) new to this library. I knew that this work might be a stretch, but our junior engineer really stepped up, did a lot of research to understand what was happening, and did a really good job building out the feature, and I'm really glad I asked the junior engineer to do this work because they did a really good job. I'm always happy to see others succeed, and I'm excited to have been part of making this project a success for our team's junior engineer.
There's not much I can do to fix the things that went wrong with this project. I've already asked (most of) the questions that needed to be asked and done the research that needed to be done. While it's too late for me to correct the mistakes I made on this project, I can learn from them and hopefully set myself up for success on future projects. In the future, if I'm working on converting or changing an existing feature, I'd want to walk through the existing work with as many people as I can to be sure that I fully understand all of the important considerations. For new features, hopefully this would happen as part of the design and planning process. I also want to make sure that I'm fully familiar with any libraries or technologies we will be using in the project, and I want to be sure to include links to documentation and (if applicable) other places where we use it in our codebase as part of my technical plan. I'm starting to get set up with the tools we use for accessibility testing, and I'm hoping that I'm all set up in time to run a11y testing for my next project. I know things will always come up during the process, but the more research I do before the work starts, the more confident I will be in my leadership skills. While I don't know when my next opportunity to lead a project will come, I do know that I will take the lessons I've learned from this project and do an even better job on my next project.