Accelerating Project Delivery: Reflections from a Productive Discussion with My Manager
I had a one-on-one with my manager yesterday, and he asked me great questions about my project. Some I had given thought to, and some I hadn’t. I believe those are important questions that we need to ask ourselves.
Why hasn’t the project been completed yet?
That question wasn’t meant to judge me or anyone; it’s simply meant to reflect on what the blockers or time-consuming factors were. There are many dependencies of a project and it helps to spend sometime thinking about that helps for future. Reflecting on yourself, what did you do better? which parts can you change and improve? what would you do differently? These seem like an interview questions, but I think we should ask these questions ourselves in a regular cadence.
How can we do the it faster?
That is an excellent question that we should ask. There are multiple dependencies in a project, such as internal team dependencies, priorities, cross-team dependencies, code freeze, mobile side challenges, and roll-out, among others. Parallelising the work and initiating communications early are positive steps. However, it’s important for your internal team to determine the number of engineers required for this project. Can one engineer handle the work? What about two engineers? Would it improve the speed? What about three? After a certain point, adding more engineers doesn’t help; instead, it increases friction and complexity. What is the optimum number? That’s a great question, and I don’t have the perfect answer for it. The framework I use for this is based on considering the size of the work. Is there enough work for everyone? If so, can we parallelise and divide the tasks, or are they highly interdependent? If the former is true, you can quickly add more engineers, but it will require more collaboration effort, more meetings, code reviews, discussions, etc., which may not be very efficient at the end. How to measure this, i don’t have an answer for that.
Do we need to wait for other teams to complete their work?
There is a term that I particularly like in big tech companies, which is “dogfooding.” It means that internal engineers test the product themselves and provide feedback or create bugs to improve its quality. This approach can also help if you want to test your team’s work in the project. You can work on and test a part of it without having to wait for other teams to finish up. This is a great exercise and I personally like this. It reduces the stress of launching a product to millions of users, instead you test it with you colleagues friends and improve the product.
