I feel fulfilled when the work I do makes a positive impact. I may work for core systems and our platforms power other teams’ applications. I may work with end-user-facing fintech applications, and we help small businesses. I may work for children’s entertainment sites, and our content makes children smile.
It’s a common thing to say in townhalls that “all of us made this happen” or “everyone’s work contributes to the company’s success”. So what does your team do?
Where is the team’s place in the company?
How does the team contribute to Business?
How does the team contribute to Tech?
We are a business, and our specific contribution is engineering. It doesn’t matter if we have fully-compliant, reliable and scalable architecture if we can’t support the business’ needs.
It goes both ways though for industries like FinTech. See it’s not just fin and it’s not just tech. Tech initiatives should be supported as long as they are contributing back to the business’ goals.
Domain and scope
It should be pretty clear in the team’s name. What is the scope of your team? Do you handle everything about the user’s profile or the core banking platforms?
Knowing the scope will help the team make the right decisions. If the team is focused on a domain, there’s no need for a lot of context-switching, and there’s a higher likelihood of projects being conceptualized, nurtured and grown properly by the members.
Mission and vision statements
Mesh teams are just little units of organization, don’t you think? It’s like a little company. It makes sense that it also has its own mission and vision statements. It should give you everything you need to know about what’s expected of your mesh team and they should be aligned to your domain and scope.
Example
Mission: To design and manage a strong, scalable, and fast mobile core framework that speeds up development, ensures consistency, and improves the user experience for all mobile applications.
Vision: To give mobile teams a top-notch, reusable, and efficient core framework that boosts innovation, enhances app stability, and sets the standard for smooth mobile development in the company.
Current roadmap and future roadmap
Knowing what you’re supposed to do and actually doing it are different.
What are we doing right now?
Where are we heading?
What is the ideal state?
Designing roadmaps, planning and execution should be aligned to the mission and vision of the team. If something does not contribute to the company’s goals, just.. don’t.
The “ideal state” may be ideal for the time being, depending on how granular you’ve designed it.
If it’s like a high-level vision, that’s ok.
If it’s a specific snapshot of the golden infrastructure, that is more prone to changes. New frameworks, new tools, new everything. Everything evolves, and so will your team.
Learnings
Meet with the key leaders (especially if you are leading the Team)
- Including but not limited to Tech Leads, Product Owners, business counterparts, senior engineers in the team
Look for the people who are passionate for their team. Sometimes they are not the usual leads. You may miss them if you base everything on the organization tree, but their passion will always stand out.
- If you have 1:1s with members, you’ll see just how much someone lights up when talking about the team or how much someone feels concerned about existing challenges and wanting to fix them. More often than not, they actually have the answers. :)
If there’s anything that cannot be answered easily/directly, then that’s a gap that needs to be filled.
It depends on how big the gap is, but this is an opportunity to pitch solutions to address these concerns. For example, there is no roadmap or the scope of the team is vague. Maybe it’s time to meet up with the Product Owners or Enterprise Architects, respectively.
If you are not in the position to lead (org-wise), it does not hurt to ask these questions to your leads just the same.
Seriously, it’s not hard to come up with a mission and vision statement. I used AI for the example. 🤣 It’s only difficult when you don’t know why your team was created in the first place.
Scope concerns. If your team handles services/projects that are clearly outside of your domain, then there’s an issue, no? Addressing this head-on will help your team focus on what you should be doing, reinforce boundaries but also interconnectedness, and will help the rightful owner to gain full ownership of their domain.
Sometimes, there seems to be no way around this for now. Maybe there’s a headcount problem or prioritization concerns. As long as you know where you are going, you will eventually get there. It may take time, but your team (and the people working with you) can make it happen.
Those who don’t know their scope are prone to being the default receiver of projects no one wants to own 😂😭😂
Roadmap concerns. Not having a clear roadmap is sad. The only thing worse than that is members not giving a damn about it.
Things change. Yes, even the domain and scope and everything else that follow. Having periodic reviews and retrospectives are important. Being able to adapt to changes is important. A strong leadership will always get you through.