Building and Managing High performing Team and Product

“We at Expedia Group, wanted to be a place where Exceptional People who share our Passion for technology and travel want to do their Best Work”

I had played multiple roles in my last 3 years of experience with Expedia Group ranging from Program Manager to Engineering Manager to a Product Manager based on situation, need and personal interest. Sharing few experiences on how we were successful in building and managing a high performing team and product while incorporating all the feedback and getting better each day.

1. Innovating Fridays

One of the feedback, we got from team is that they would like to have more dedicated time for innovation while working on sprint stories in parallel. We (I and my peer Manager) discussed with Management and came up with the concept of “Innovating Fridays” where every Friday (second half), team innovates. It can be anything from learning new technology (Machine Learning/AI) to writing blogs as this is non-project time and they are free to work on any feature which they feel is good for end customer.

It came out really well where team end up burning few features which were taking a back seat in backlog. Few team members got their hands dirty on Machine Learning and did few POC’s. Though, one can’t time bound innovation but this concept really helped me boosting team morale and team is ready to spend extra/personal time in learning technology and go extra mile. Once a month, we do the demo to see how its going and celebrate it.

2. Setting complete “Engineering” Team

Few QA members wanted to move to core development role and this led to setting up a complete Engineering team where everyone is responsible for development and testing of the features. We came up with a plan where every QA member is paired with a core developer who helps them in day to day questions and ramp-up.

With-in 3–6 months, we started seeing the impact where newly added developers (QA) started burning complex stories (moving from 1 and 2 story points to a 3+ pointer story). Also, during this duration, they shared the regression and testing duties with the existing developers and let them own it while shadowing them. This is one of the great experience to share as how we managed in setting up a complete Engineering team.

3. Organizing Tech talks and Collaboration across teams

We tried to setup a culture of continuous learning and sharing where I connected with all other Managers/Directors who are working on other mobile apps. Then, I setup the weekly tech-talk series and asked everyone to vote as what topic they will like to discuss each week. With this we got a prioritized list of topics and assigned speakers from team (based on their preference).

This enabled us to share our learning and knowledge across teams in Expedia Group and helped us setting a collaboration platform building trust and relationships. Also, it helped everyone in team to speak in front of large audience and build on their presentation skills.

4. Change of Guard

We decided to rotate regression and other recurring responsibilities within team instead of one team member owning it every time.

How we did this — Created a monthly roster where every team member takes a lead on above mentioned responsibilities every week and pass the ball to next one. This solved dual purpose of not having a single point of failure and everyone gets a chance to manage complete process and own it.

5. Taking Platform and tech-debt together

Everyone wants to work on best feature but you can’t have whole team work on same feature. At the same time, you have to take care of tech-debt and platform work since you have to take care of Engineering KPI’s (Quality and robust Architecture) too.

We decided to reserve some % of bandwidth in each sprint for burning tech-debt and platform items. Also, this goes back to the rotation cycle where we have one developer contribute to this work each sprint, thus enabling them to take platform and feature work hand in hand and get some time out from routine feature work.

With each feature being delivered, we introspect and see what/how/where we can improvise and try to provide a best experience to travellers.

6. Setting culture of Open Feedback

We setup a concept of open feedback where we meet as a team (twice a month) and provide open feedback to each other. This can be anything related to work including appreciations and constructive feedback. This is more of a Vegas style meeting where we set the ground rules as not to discuss anything out of the room and what ever being discussed stays in the room only.

We saw a huge drop in conflicts post this approach and team started to collaborate more and more, thus making my life as a Manager easy :)

7. Core working hours

All planned meetings (planning/grooming/retro/demo/tech-talks) were moved to morning slot (before lunch) and no meetings were planned post lunch.

This ensured there is agreement on core working hours (like 1:30–5:30 pm) where team can concentrate on actual work and there is no more context switching with so many meetings running around the day.

8. Own the product as your own baby

We tried to setup the culture where we encourage each and every team member to ask questions as why this feature is really important, why not prioritizing this over there, what benefits we expect here and what are the metrics we are targeting here. This really led to useful grooming meetings where everyone (including product) enjoyed the discussion and is actively contributing there.

Inducing the feeling of product ownership made the team to think innovative and ending up in getting couple of feature ideas from team itself :) Also, we encouraged them to share any suggestions/bugs which they find in other Products/Line of Business and communicate it using Dogfood process.

9. 1 on 1's

Though, I had recurring 1x1’s setup with each team member but I never stopped anyone asking for a quick ad-hoc discussion and not waiting for 1x1 to discuss that. Also, I used to maintain a separate record for each 1x1 so that I can recollect as where we left and how the individual is working on action items to be discussed in next meeting.

10. Joint Code Review Sessions

In order to bring everyone on same page in understanding code and helping QA moving to developer role, we had setup joint code review sessions where team meets everyday for half an hr and opens up existing PR (Code Review request) and jointly reviews it to cover the why and how part of coding. This helped everyone (specially the new developers) to think from a common coding ground perspective.

11. Celebrating success together

I believe that a small appreciation note goes a long way. We made it a habit to celebrate each n every success (not having grand party every-time but like taking team out for tea/snacks) and then having a lunch together, once a week.

Well as a Manager, your primary responsibility is the people and if you make them feel like coming to work everyday, half of your job is done. It took us sometime to setup above mentioned processes but it went a long way for us as team and I can see a great sense of ownership, collaboration and passion to do a better job each day.