Drawing on their team's experiences, full-stack and backend engineers Josué Prieto-Paz and Babajide Owosakin discuss the benefits of a 'project mindset' and how to plan for success.
Our team, like any other, goes through continuous iterations of services and products. For example, just recently we worked on experiments including implementing a whole new booking assistant and migrating some endpoints from our monolith application to a new service.
To ensure every new project implementation goes even better than the last, we record team and individual learnings — both losses and wins. With that in mind, we’re sharing useful takeaways for helping projects run smoothly, including preparation and groundwork, as well as points to consider during implementation. Collectively, these guidelines can be called a ‘project mindset.’
{{divider}}
A ‘project mindset’ is the attitude of acknowledging that a piece of work before or during the sprint might require particular planning and should be treated with even more care than other tasks.
Here are some questions that should be asked before starting a potential project.
By addressing these questions you can determine the level of seriousness and care with which to handle the project. The answers will also help define how to manage communication, documentation, alignment, risk management, planning, rollout, and all other aspects in the best possible way. To help answer these questions and save many, many potential headaches, we’ve put together the following guidelines to help engage a ‘project mindset.’
Identify the stakeholders of the project. Think about whether someone might need to know about what you are implementing in the future and to what level of detail. Consider all the possible changes that will occur after beginning the project. Think about all of these scenarios, and choose the source of truth with intention.
If you are working on defining an API between engineers (which can suffer from a lot of back and forth), it could be that the best place could be a GitHub pull request with OpenAPI specs signaling the changes made. If you are working with product and design stakeholders, it might be better to keep it on a Google doc instead, as a place for product stakeholders to provide product context and design to link a Figma file.
Missing a message with an update on new changes can result in the wrong implementation. And vice versa, if a stakeholder is not aware of a part of the implementation that could not be completed, they might also fail to set the right expectations for others. It might also be the case that a stakeholder or engineer is not getting involved somewhere where their input is needed. To keep communication transparent, efficient, and accountable is to publicly share anything that is or could be relevant at once.
Uncertainty can come from a lack of knowledge of a certain technology or a misunderstanding of the various systems you interact with. To start a project with a lot of uncertainty often results in the possibility of failing to accomplish what was promised. That could mean the project not being possible, the extension of the deadline, or adding more work than was initially expected.
Investigation before implementation allows engineers to make feasible commitments. Moreover, it reduces the possibility of encountering changes in expected complexity, as well as mishaps or errors.
What is this project trying to solve? As engineers, we have greater knowledge of our systems than external stakeholders — we are the specialists. If the proposal is a solution to a problem, it could even be the case that what is being put forward will not solve it. By thinking critically, understanding the business logic, and weighing new ideas versus simply accepting what is being proposed, it is possible to make suggestions and improve the plan ahead of implementation. This could even end up reducing workload, thereby saving engineering time.
Setting expectations early about something going wrong or encountering unexpected complexity is significantly better than not setting them. Often scrambling to get a working solution is not better than taking the time to deliver meticulous work. Communicate with stakeholders, let them know that the agreed deadline for what is expected will not be possible, and try to see if there is an alternative solution. This could mean one of the features will not be included, or that the deadline will be pushed. Whatever it is, transparency should always come first; otherwise, trust will be broken.
Having a leading engineer steer a project will reduce the workload for other engineers involved. The leading engineer should be responsible for investigating (even) further, communicating with stakeholders, and planning and/or coordinating engineering work. To set the project up for success, it is also important to have an engineer per platform, as they are the specialists in their respective systems and reduce blind spots.
This is true for any work you do, but especially true for a project.
By holding a pre-rollout bug-finding session with stakeholders, it is possible to fix them without stress and potentially save yourself from some reverts in production. This also allows stakeholders to interact with the project before completion which increases trust (and even allows them to already start thinking about v2).
These guidelines serve as recommendations, but in reality, the ability to implement best practices and deal with ambiguity when trying to achieve great results comes with time and the intention to improve. Also important to remember: these guidelines are and will always be a work in progress. As our team and everyone in it continues to grow, we will make changes to our ways of working to adapt to new challenges.