It is pretty standard for companies to define the vision or mission for every year or per quarter, and we all work towards that common goal. I’m here to pitch you that your team should also have your mission or vision, no matter what size it is. At WeTransfer, we came up with a vision for ourselves for a team of five Android engineers and for the last year, we could visually see how our synergy and collaboration have changed and how much we are aligned regarding our decision-making.
What can the vision statement do for your team?
Imagine sailing on a ship with your team, and you realise that you are lost and have no idea how you decide which way to go. You are still moving but you don’t see where to go – Vision is like your north star, where you go back to the basics with it. Your whole team make the ship head in that direction. You may not reach the north star – it is like chasing the end of a rainbow, but the idea is to walk or run in that direction, accumulating all the benefits of progress.
Here’s our team’s vision statement
Easy to scale codebase supporting multiple form factors with accessible components
– Android Mobile Engineering, WeTransfer, 2023 – 2025
This statement sounds very obvious right? But how did this statement help us? In short, faster decision-making and bringing the team together on the same page
In brief, we want to be ready to support multiple form factors – meaning, it is up to the product team and the management to invest time and resources to build or optimise for multiple form factors and it is not in our hands – but, we as a team we want to be ready for it and our codebase must be ready for it. This means I’m not asking to prep for the doomsday – to make the multiple form factors happen, we must make a few technical decisions to keep the codebase accommodating to other form factors. While we are making changes to accommodate that, we are keeping our codebase up to date with latest dependencies and stacks. When there are scenarios where we need to decide on the solution for a feature or some technical challenge, we take this vision into our thinking, asking ourselves how this solution will impact our vision. This will chart course to a particular solution that we would all agree.
This made us decide a little bit faster. Usually, developers will have a lot of opinions, and we will commonly be stuck on a whirlpool of opinions and having a vision would help you, in most cases, to quickly lean on a solution.
Engineering excellence (EE) backlog
Even though a vision statement helps keep the team on the same page, it cannot do much in the long run. To keep things rolling and accountable, we must devise a plan to achieve or move close to our vision. For this, a rolling engineering backlog comes in handy to track all the initiatives and proposals that help achieve our vision. We call it “Engineering excellence” – this commonly has many forms, such as engineering initiatives, engineering backlog, technical road map, etc. I’m sure many companies follow this process to keep the engineering up to date. But now, with the vision, it gives a concrete purpose, and it would be a fantastic sight to watch how everyone collaborates to drive it to the finish line. If this backlog is appropriately planned and broken into actionable or releasable entities, the vision statement will help us sequence the work effectively.
Here’s a small example to show how the vision and EE backlog helped the engineering and product teams. To accomplish our vision and supporting multiple form factors using Compose (an Android UI toolkit), we first need (we wanted to do the Compose way) to migrate to the new toolkit – all the modules and core user journeys. As an engineer, I would first pick the easy or smaller module and go sequentially. However, we involved the product team to identify which module has more features in the backlog and which has many crashes or bugs. With this information, we picked the one that needs more attention and love. In this way, our engineering goal is achieved, as well as the product team as happy as we now have fewer bugs and no roadblocks for new features.
Another example – we have an item in our EE to migrate to the latest design system. There was a requirement for the whole company to change the branding colors for all our products. If we did not have this EE item, we would have simply changed the color and moved on. However, we tried introducing these new colours and the new design system together, which co-existed with the old design system. We then made plans to migrate the old one out slowly.
To summarise, keeping the EE backlog up-to-date helped the team to come up with the plan to achieve our end goal – the vision and also when the product team comes up with the requirements, we can plan effectively to sequence the work better. This helps not just one team but all the teams and the whole product.
Drafting your vision
Drafting your vision is not a lead’s job but the team’s job. We conducted multiple jam sessions with our team to identify what we must do to keep our codebase healthy and up-to-date while allowing space to accommodate newer APIs and integrations.
The jam session involved asking every engineer to jot down the things they like currently in the codebase, things they don’t like, and what they wish they would see soon. Also, questions like what are they most excited about with the future of Android app development (take your own space).
Then we need to discuss each item and sort them based on the priority which would be in the following buckets – highest, high, medium and low. The author of each item should justify why this ticket takes the following priority. Now, if you see the priority buckets, this becomes your Engineering excellence backlog and if you can identify a pattern with between what all developers would like to see in the codebase plus their big bets on the future of Android development – you’d have your first draft of vision. Of course you would be taking this to the product, design and QE/QA team to check if they need to add something. In the second iteration, you’d have your vision.
I would advise drafting multiple vision statements and presenting them to all the stakeholders to align closely with the company’s OKRs and other strategies.