5 Useful Methods to Form and Empower Your Engineering Teams
Remember your first day at school? When you walk into the building for the very first time... get assigned to a class… find your seat in the classroom… see so many new faces… A lot of things happened on that single day. How is this connected to empowering and forming Development Teams?
Every day on this planet a new Development Team gets formed. What I underestimated as a first grader back then was how prepared and scheduled my “onboarding” into school was.
In short: It was all exceptionally well planned!
Without a clear product vision, mission, and purpose you can’t work towards a goal. That’s why teams should spend time together to define these things.
In this article, I’ll share 5 useful methods to form and empower Engineering Teams from a Product Management perspective with you. The main focus will be on communication, alignment of roles, and setting goals. On top of that, I’ll share a way to map out existing and lacking skills so you can make better hiring decisions.
Everything I’m describing is applicable to new and existing teams.
1. Getting to Know Your Team & Bonding With Them
Joining a new team as a PM is always exciting and can be challenging sometimes. Aside from all the ceremonies and team meetings, I like spending “one-on-one” time with every team member. The sooner you reach out to every teammate the earlier you’ll get to know each other. That doesn’t only mean learning about their history and what they do in their current role. The first meeting is ideal for getting to know each other’s personalities and setting clear expectations for your work together. I coach multiple Product Managers and I’m always surprised by how many of them don’t do the above.
What to talk about in the first meeting? 🤷
If you’ve read some of my articles you might know that I’m a big fan of approaching things in a structured way. At some point in my career, I came up with an agenda for myself that I go through when I meet my new colleagues.
Let’s take a look at the points and goals I always aim for.
The First 1:1 With New Team Members
I always block one hour to get to know each other. If you need less time that’s fine. If you need more it seems like you already have a lot of stuff to talk about. 😉 Let’s take a look at the topics I always cover:
1. Get to Know Each Other
Obviously, a conversation starts with an introduction of myself and sharing some background of what I’ve done in the past as well as something personal like my hobbies.
Right after that, I focused fully on learning as much as possible about my colleague by actively listening and asking questions. But we don’t need to dive too deep into that. If you’d like to learn more I recommend reading: How to win friends and influence people.
2. Asking What They Expect From You
I love asking this question because it can give you a lot of insight. Whether you join a new team or an existing team, the expectations of others tell you how they usually work with Product Managers. It can also help you to understand how processes worked or didn’t work for them in the past.
BTW: I always come ready with a notebook and pen and take notes while people share information.
3. Sharing How You Work (and What You Expect)
The more my team members know about me the better. That’s why I always share how I approach certain topics. I’m a big fan of e.g. doing kick-off meetings for projects, sharing tickets for a grooming one day in advance via email, etc. Whatever your “working style” is, let your team know. They’ll appreciate it.
4. Asking About the Team
I like asking how the team works, who does what, and how you (the person I’m talking to) like working in the team. It’s important to not make this a “gossip” session. Sometimes people are very emotional about certain topics, ceremonies, people, etc. In such cases, tell them frankly that you want to stay unbiased and instead focus on the professional side of things.
5. Sharing Things About Your Personality
I’m, for example, very extroverted and direct. That can be misunderstood sometimes especially when you don’t know me (German genes 🇩🇪 🧬).
I tell people if they feel pushed or offended that they need to tell me immediately so I can correct my behavior and recognize when I go “too far.” Letting people know that you always look at things from a business point of view and not a personal one can be very clarifying.
6. Continuing to Meet and Bond
Obviously, as a Product Manager, you’re not the supervisor of your team members. Nevertheless, what stops you from regularly catching up with them? These days, more people than ever work remotely. And there are many people and books that say communication should be reduced and mainly happen in team channels, and so on...
I believe Product Managers are Leaders. They have a mission, they have a plan, but they can’t achieve it by themselves. Why not try regularly catching up with your team members to bond and share insights with one another, or even just give them space to ask questions? When I was working as a PM I did monthly lunch sessions or one on ones outside of the office to catch up with people. I’ve never prepared an agenda for one of these sessions. We always talked about everything including private topics. We’re all humans!
2. Defining the Product Mission Together
A clear mission helps a team to better act and react to fast-changing environments, markets, and technologies. This increases the chance of achieving a product/market fit and going to market at the right time.
Sidenote: Some people might call this “agile.” 😉
Previously, I’ve written an extended article about defining a product vision. The product vision (or company vision) is the “foreplay” before you create a team mission. If you’re interested in a full guide on how to create a product vision and mission feel free to follow this link. 👈
Many times teams define a mission based on their domain e.g. backend, tooling, a specific micro-service, etc., without looking at the overarching company and product goals. Without a clear high-level goal, it’s much harder to define a team mission that suits the company’s needs.
Talking about change: A team mission is a living thing and should be adjusted if needed. That doesn’t mean that you change it once a quarter though!
Defining a Team Mission Statement (With Examples)
Let’s take a look at a real-world example. I’ll use the Google Calendar Team as a follow-up example from my product vision article. Firstly, we should check out Google’s company statements one more time:
Company vision: To provide access to the world's information in one click.
Company mission: Organize the world's information and make it universally accessible and useful.
The Google Calendar team’s 4-point product vision was/is:
Fast, visually appealing, and joyous to use
Drop-dead simple to get information into the calendar
More than boxes on a screen (reminders, invitations, etc.)
Easy to share so you can see your whole life in one place
The best way to define a team mission statement is by having a workshop. I recommend scheduling around 1.5 hours for this. As for every meeting, one person kicks things off by explaining why having a mission can be beneficial and answering open questions. This can be the Engineering Manager, Team Lead, Agile Coach, Product Manager, etc. After the intro, it’s mandatory that the company vision and mission get pitched one more time to make sure everyone is up to speed.
In order to stay focused on defining a clear mission statement for the team, I like filling out this sentence:
We the squad/team are “doing” [what] for [who] because of [why].
Now there are a couple of ways to throw this together as a team:
Have an open discussion (recommended for smaller teams of up to 5 people)
Break out in small groups of 2-3 people and come together to merge ideas
Every person writes down their ideas on sticky notes, puts them all on the wall, and the whole team aligns with them
Let’s take a look at how a team mission could look using Google’s case as an example.
We, the Google Calendar team, are building the easiest-to-use calendar experience for every human being with an internet connection because time is the most valuable resource.
We could also have said “the best calendar experience” but it’s better to be as detailed as possible and eliminate room for interpretation on a mission level. On a vision level, that’s totally fine.
PS: I’ve got no idea what their team mission is and I wasn’t able to find it on Google. 🙈
With the above exercise, you’re almost set. There’s one more thing that’s important. Discussing what you don’t do. I’ve seen many companies with unclear ownership of services, a lot of cross-team/cross-project dependencies, and other stuff. Make it clear what is and isn’t part of your mission and domain first for yourself as well as for people outside of your team.
What we don’t do:
Point 1
Point 2
Point 3
...
Once you’re set with the team mission it’s time to look at numbers…
3. Define North Star Metrics
Working with North Star metrics is definitely a best practice. However, many teams don’t work with them. The north star metric or one metric that matters (OMTM) is the number one figure teams focus on during their day-to-day business. It’s the number everyone identifies themselves with and the whole team has agreed upon. It tells teams or companies if their product, service, finances, revenues, etc. are doing well or not.
If you’re interested in the world of KPIs and metrics feel free to read my article about product KPIs that make the difference.
North Star Metric Examples
Let’s take a look at the North Star metrics of Google’s search engine. Google’s goal is to help people find what they are looking for as quickly as possible. Therefore, they need to generate clicks. A north star metric could be:
The time spent from entering a search term to clicking on a result (the shorter the better)
Let’s imagine there's one team working on the search bar and its auto-suggestion (not the search results). The team’s north star metric could be:
Time spent from typing the first two letters to clicking/pressing enter (again: the shorter the better)
For a company like Square Inc. the global north metric could be:
Total processing volume (TPV, the amount of money that flows over their terminals considering they make money with transaction fees)
Whether you look at your product as a whole entity or as certain subsets, the better you identify your most relevant metric the better you’ll know how it’s performing. That also has an impact on your plans for the future. You’ll try to increase or reduce the defined metric with new features or improvements you launch to deliver the biggest value to your customers.
4. Skill Mapping to Grow in a Stable & Healthy Way
For a couple of years, I worked in a hypergrowth startup as a Product Manager and nowadays I consult a handful of hypergrowth companies. There’s a pattern that they all struggle with. Hiring the right people at the right time to scale up their teams.
To hire people with the right skill set you need to know what you want to build in the future. Are your product strategy and product development roadmap already defined?
If your answer is yes, skill mapping might be very interesting for you! A skill map is a two-dimensional matrix that focuses on:
The skills needed to plan & build a product/feature
Previously built features (from the last 6 months) & planned features (for the next 6 months).
How to Create a Team Skill Map
As always, the best way to do it is as a team. Therefore, an onsite or remote workshop for 1 to 1.5 hours is a great way to start. I recommend starting to create a list of 3-6 features you’ve worked on in the past. Make sure you mix them up between domains, technology, and size. Right after that, you list a couple of upcoming features for the upcoming 6 months.
The next step is to think about the skills you need or will need to plan and develop the features. This can be skills like:
Testing/QA
Programming languages
Domain knowledge
Etc.
Once you’ve created the columns, it’s time to go through each feature. Start checking which skill was needed and which wasn’t. Give them a ✅ or ❌. Next, take a look at how much time you’ve spent building that feature by distributing 100%. I recommend going in 5% steps to not overthink it. It’s not about finding the exact percentage it’s about aligning on efforts.
Important: Don’t do it all by yourself. Involve your team members and let them think about it instead of just writing down the percentages.
After you’ve filled out the whole map you’ll be able to identify bottlenecks by looking at the columns (see the example below).
FYI: The columns aren’t restricted to 100%.
What to do when you identify bottlenecks? There are a couple of options:
hire new people
re-prioritize the roadmap
add internal resources/new team members
accept the bottlenecks & support each other (changing team processes)
As you can see there are many options. Hiring isn’t always the best solution.
Team Skillmap Example:
If you like you can copy-paste my free skill mapping spreadsheet.
Bear in mind that it’s not only about looking at the numbers. It’s important to have a conversation with each team member about their role and workload.
5. Retrospecting & Candid Conversations
There are many retrospective guides and retrospective games on the internet. Therefore, I won’t dive into the games directly. Instead, I’d like to take a look at the reason for doing these games.
Many teams and companies call themselves agile but they don’t all hold regular retrospectives. That’s absurd! If you’re working for two weeks or longer on something(s) you should take some time to look back and review the outcome. Sadly, many teams and managers don’t see the need to do so. They spend time and effort on:
planning projects
creating roadmaps & timelines
talking to stakeholders & customers
doing market research
defining a strategy
building stuff
and not wanting to regularly retrospect on how they are doing.
I recommend taking the retrospective seriously and dedicating enough time to it.
On the other hand, there are teams that hold them regularly but don’t progress or solve their challenges. One of the biggest reasons for that is that they have too many action items and no driver/owner. One big tip I like sharing is to not commit to too many action items. Rather go with a few ones and make sure you can solve them within e.g. two weeks.
Additionally: Decide on a driver for each action item. One person who’s responsible or reports back on progress to the whole team.
Lastly, I believe it’s important to be as open and honest as possible. The retrospective is a safe place to share how you feel. It is not a space to blame others though. Sometimes people are tempted to hold back to avoid discussions or believe sharing their opinion could cause conflict. I’ve learned the hard way that not saying what’s on my mind makes things worse. My dad always says:
Rather a scary end, than scaring without an end.
I tried my best to translate it from German into English 🙈)
Forming & Empowering Engineering Teams in a Nutshell
Let’s take a short recap of the points above:
💑 Make sure you bond with your team members by regularly talking to them as a Product Manager.
🚀 Help your team with all your product input to define an awesome team mission together.
⭐️ Define a clear north star metric to make sure you’re sailing in the right direction.
📍 Map out your skillset and forecast what skills you’ll need in the future to start hiring the right people in time.
🤝 Retrospect regularly in an open and honest matter to continue improving as a team.
If you’d like to learn more about team building, agile methodologies, and product planning feel free to sign up for my newsletter.
