Hitesh Gupta | Sr. Technical Product Manager in Gurgaon

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

I have 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 the situation, need and personal interest. Sharing a 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 piece of feedback we got from the 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 “InnovatingFridays” where every Friday (second half), the 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 customers. It came out really well where the team ended up burning few features which were taking a back seat in the backlog. Few team members got their hands dirty on Machine Learning and did a few POC’s. Though one can’t time-bound innovation, this concept really helped me boosting team morale and the team is ready to spend extra/personal time in learning technology and go the extra mile. Once a month, we do the demo to see how it’s going and celebrate it.

2. Setting Up a Complete “Engineering” Team

Few QA members wanted to move to the core development role and this led to setting up a complete Engineering team where everyone is responsible for the 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. Within 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 experiences to share as to how we managed to set up a complete Engineering team.

3. Organizing Tech Talks and Collaborating Across Teams

We tried to set up a culture of continuous learning and sharing where I connected with all other Managers/Directors who are working on other mobile apps. Then, I set up the weekly tech-talk series and asked everyone to vote on what topic they will like to discuss each week. With this, we got a prioritized list of topics and assigned speakers from the team (based on their preference). This enabled us to share our learnings and knowledge across teams in Expedia Group and helped us set a collaboration platform building trust and relationships. Also, it helped everyone in the team to speak in front of a large audience and build on their presentation skills.

4. Change of Guard

We decided to rotate regression and other recurring responsibilities within the 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 the above mentioned responsibilities every week and passes the ball to the next one. This solved the dual purpose of not having a single point of failure and everyone gets a chance to manage complete process and own it.

5. Taking Care of Platform and Tech-Debt Together

Everyone wants to work on the best feature, but you can’t have the whole team working on the 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 the best experience to travelers.

6. Setting Up a Culture of Open Feedback

We set up 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 whatever being discussed stays in the room only. We saw a huge drop in conflicts post this approach and the team started to collaborate more and more, thus making my life as a Manager easier 🙂

7. Core Working Hours

All planned meetings (planning/grooming/retro/demo/tech-talks) were moved to a morning slot (before lunch) and no meetings were planned after lunch. This ensured there is agreement on core working hours (like 1:30–5:30 pm) where the 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 set up the culture where we encourage each and every team member to ask questions as to 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 think innovatively and ending up getting a couple of feature ideas from the 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 1×1’s set up with each team member, I never stopped anyone asking for a quick ad-hoc discussion and not waiting for 1×1 to discuss that. Also, I used to maintain a separate record for each 1×1 so that I can recollect as where we left and how the individual is working on action items to be discussed in the next meeting.

10. Joint Code Review Sessions

In order to bring everyone on the same page in understanding code and helping QA moving to a developer role, we had set up joint code review sessions where teams meet every day 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 and every success (not having a grand party every time but taking the team out for tea/snacks) and then having 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 every day, half of your job is done. It took us some time to set up above mentioned processes but it went a long way for us as a team and I can see a great sense of ownership, collaboration and passion to do a better job each day.“

Join our Careers Community

Expedia Group’s Career Community is a great way to learn about new opportunities and receive important job communications and updates. Sign up now!