Engineering Success: Why a Project Mindset is Key

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}}

What is a Project Mindset?

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.

• Will this be worked on for the long term?
• Does it take extensive communication with other stakeholders?
• Is there collaboration involved with other engineers and stakeholders?
• Are there any unknown pieces before starting to implement?
• Is it prone to changes in the middle of the implementation?
• What is the complexity?
• Is there any uncertainty?

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.’

Click on the suggestions or scroll down to learn more.

• Define a source of truth with intention.
• Keep communication transparent, efficient, and accountable.
• Investigate before getting started with the implementation.
• Engineers are the specialists: think about the problem you are trying to solve to improve the proposal.
• Set expectations early: communicate changes in expected complexity, mishaps, or errors.
• To have a leading engineer lead the project is to work efficiently.
• Err on the side of caution by having a collaborative quality check before a production rollout.

Define a source of truth with intention.

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.

Suggestions:

• Be consistent with the source of truth. Avoid having a Jira ticket that keeps getting comments, a thread on Slack, and a Google doc that has random changes. While it is nice to accommodate all stakeholders, encouraging everyone in the team to be consistent with the source of truth will result in better communication.
• Think to what extent changes will need to be recorded and ensure the source of truth of choice has a space to keep up with them.
• Think about who will interact with your source of truth and whether it could be useful to make this public to other audiences in the future.
• Check what is available in terms of templates. Perhaps your organization already has custom spaces that capture what needs to be documented.
• Don’t overcomplicate the source of truth. If a Jira ticket is enough, then it is a good space to choose.

Keep communication transparent, efficient, and accountable

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.

Suggestions:

• Choose a communication channel, which could be a private channel in Slack. This would result in all stakeholders being notified and made aware of what is happening throughout. This also works as a source of information.
• There might be too many questions on Slack or Jira through comments. Don’t hesitate to organize a meeting to quickly resolve remaining doubts. Be mindful of stakeholders’ time.
• Don’t forget to have an assigned note-taker in all meetings. Record these notes in the chosen source of truth and preferred communication channel. This ensures relevant information does not get lost.

Investigate before getting started with the implementation

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.

Suggestions:

• Set a scoping task unless there is a certainty that all requirements can be met as described.
• Collaborate with another engineer if there are any doubts about the feasibility of the implementation.
• Think about what the scoping task would comprise. It could be writing a document, or just taking a look at the data received from an endpoint. You could also consider a proof of concept, where an engineer implements a scrappy demo to see that the implementation is possible. Alternatively, come up with a list of questions for stakeholders and ask them as early as possible.
• Communicate any concerns early on once the investigation is done. This sets the right expectations.
• {{divider}}

Engineers are the specialists: think about the problem you are trying to solve to improve the proposal

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.

Suggestions:

• Don’t hesitate to give your thoughts on the proposal.

Set expectations early: communicate changes in expected complexity, mishaps, or errors

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.

Suggestions:

• Communicate early and publicly to everyone involved.
• Try to find what can actually be delivered on time.
• Be willing to have a conversation about revising a deadline instead of scrambling to finish.
• If a deadline does need to be revised, set a meeting with other engineers to scope additional work, have a note-taker, and communicate publicly.

To have a leading engineer lead the project is to work efficiently

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.

Suggestions:

• Have a clear owner set before starting to plan work.
• Have an engineer per platform validate that the implementation will be possible. This will save engineers’ capacity and keep the project agile.

Err on the side of caution by having a collaborative quality check before a production rollout

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).

Suggestions:

• Hold a bug bash. Invite all stakeholders and other engineers to the meeting. This will minimize errors before a rollout to production.
• Set up a quality assurance session with another engineer.
• Use a testing cluster before rolling it out to production if possible.

So….

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.

‍