Anonymous
The most criticism I have received is not being more flexible to changes in scope.
When managing Flutter Infrastructure changes a common theme was changes in the scope at the middle of the program. In those cases I always ran a risk-benefit analysis and if it was feasible to integrate the changes in scope without too much disruption to the program it was integrated and documented otherwise it was pushed to programs starting in the future.
An example of this was the migration to scalable and reliable infrastructure of the flutter engine and flutter framework repositories. Right in the middle of the execution of the program I was asked to include a third repository but after careful review the inclusion of that new repository was going to slow down the program for a couple of months. Given that the repository was not sharing commonalities with the other two projects in scope I proposed that it was addressed in a future program along with some other requirements associated with the plugins repositories and explained that given the limited resources the inclusion of that new repository would cause to block on the completion of the other two repositories. All the findings were documented and presented to stakeholders who agreed on creating a new program for the plugins repository in the future.
