Building and Managing High Performing Teams and Products

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!

Vrbo Rebrand Series: Mobile App Team

From testing new technologies to launching the Trip Boards feature, the Vrbo mobile app team takes you behind the scenes of the brand refresh in part two of this series. Read on to see how the Vrbo team is helping people travel better together with the updated mobile app.

 (Read about the web app team in part one of the Vrbo Brand Refresh series)

Q: How was designing the mobile app refresh different than other projects you’ve worked on?

Brady Miller, Senior iOS Software Engineer: “One of my responsibilities was to update some of the screens in the app to the new look and feel. This allowed me to work closely with the design team and use tools that I typically don’t use like Zeplin. It was a great experience getting to work on new features with other teams in a fast paced environment.”

Alyjan Daya, Software Engineer: “I worked on the new welcome screen on the Vrbo app. At the time, I was on the Mobile Platform team, so I hadn’t spent a significant amount of time on the Android UI. The mobile app refresh was the first time I worked closely with a designer. From a technical perspective, it was very different from past projects because I had to account for differences between the Vrbo and HomeAway apps that could not be solved by simply applying different UI skins. Since the welcome screen on the Vrbo app displays a video and the HomeAway app displays an image, I had to make structural decisions on how to properly inject the correct resources while keeping the app size consistent.”

Q: What was your role in the mobile app refresh?

David Messing, Lead iOS Engineer, Traveler Apps: “Brady and I primarily worked on the iOS app UI updates and redesigns. This involved things like new fonts, image assets, redesigned screens, UX flows, etc. Basically, if you compare and contrast the old vs. updated versions of the Vrbo app, you can visually see what we worked on.”

Corbin Montague, Senior iOS Software Engineer: “My focus for the Vrbo brand refresh was building the Trip Boards feature. I had the opportunity to build or review nearly every Trip Boards related code that went into the iOS app over the last year and it’s been the most rewarding work of my career. The feature itself is spread across many different experiences within the app (Feed, SERP, PDP, Push Notifications, etc) making it hard to architect well. To tackle this complex problem we had to really flex our “One Team” mojo. Constant collaboration between Web, iOS, and Android engineers, architects, and product managers made this feature a reality and it looks to be one of the most promising features on the Vrbo app. Getting to build a feature like Trip Boards from the ground up takes the primary use-case of our service (group travel) and makes the experience as frictionless as possible. Helping travelers take those conversations they were already having onto our platform was an amazing experience I will never forget. Props to the entire Pulse team for making this feature a reality, I love you guys!”

Pavana Subbarao, Mobile QA Engineer: “I was responsible for the quality of the Vrbo Android Traveler app. I had to make sure the app worked seamlessly on different Android versions and that it was a good user experience for our travelers. This included working with designers, testing the app on multiple Android versions, validating that the features work on the new app, and providing feedback to developers. As a company, it’s our goal to release quality products to our customers and it’s my job to make sure that happens!”

Kian Villagonzalo, Software Engineer: “My role was a redesign of the feed screen and the search bar. My workflow didn’t change much, but this project became a top priority. Most of my work in the last year has been design-related so updating the UI logos, colors, fonts, and incorporating design feedback.”

Q: What was the release night like?

David Messing, Lead iOS Engineer, Traveler Apps: “Marc Perlman suggested releasing the HomeAway app a few days before releasing the rebranded Vrbo app. The two apps share the same codebase, but are skinned differently. This turned out to be a stroke of genius because it allowed us to catch and fix a low impact crash before the Vrbo app was released later in the week. On release night, we felt confident and excited for everyone’s hard work to be revealed to the world.”

Pavana Subbarao, Mobile QA Engineer: “Release night was super exciting. We were all logged in and our goal was to make sure the launch was perfect. We all worked together to make sure the release was smooth and customers did not face any difficulty. Everything went perfect once the Vrbo app went live.”

Q: What was your biggest takeaway or lesson learned from this project?

Brady Miller, Senior iOS Software Engineer: “My biggest takeaway from this brand refresh is the importance of writing robust, maintainable code. We have shared UI components from our UIToolkit that use our fonts and color schemes. I was in charge of updating colors and fonts for the brand refresh. It turns out there were over 100 spots in our code where those shared components were not being used so the color and/or font did not get updated. I had to manually go through and find all of these places and update them to use the shared components. It was a very humbling experience and now our code is better positioned for any future brand updates.”

Q: Have you booked a vacation rental on the new Vrbo app?

Corbin Montague, Senior iOS Software Engineer: “Absolutely! My wife and I are expecting our first child later this year and we booked a house by the beach to do a small baby shower/family reunion. We used the new Trip Boards feature end-to-end and it was great to use it as a consumer and see how my family interacted with it. We all added properties to the board, voted, and made comments within the app until we decided on the perfect vacation rental for us. It’s hard to even describe how happy it made me seeing my family use a feature I poured so many hours into building.”

Follow Vrbo Life on social to learn more about what their teams are up to!

Vrbo Life Facebook

Vrbo Life Instagram

Vrbo Life Twitter

Vrbo on LinkedIn

Deciphering Product Roles

Amanda McArthur | Talent Advisor, Expedia Group in Bellevue, WA

Product, Technical Product, and Program Management. If you are in the product world, you know the struggle is real. Companies (and sometimes even teams) have different definitions for each. It can be difficult to understand what roles are a strong fit given your background and personal career goals.

My goal here is to help you maneuver Expedia Group and find exciting opportunities with us that are more in-line with your experience or career goals.

First, the Program Manager:

In several large tech companies, this is a title predominantly used to describe someone who is closely aligned with Engineering. Generally speaking, within Expedia Group, the Program Manager is more focused on business process and programs. With one exception; the title Technical Program Manager is used in a few divisions and the responsibilities are similar to a Technical Product Manager.

This role is great for someone who excels at surveying the ‘big picture’. You enjoy finding and fixing inefficiencies. You build business processes and programs that scale, are streamlined and cross-functional. Like most other Product or Program roles, you are also an excellent communicator who is able to build consensus through influencing without authority.

While searching, I would consider areas of expertise as well and use keywords as part of your search to narrow your results. Maybe your area of specialty is talent acquisition, business operations, finance, or marketing. If you do have a functional area that you are focused within, do include it in your search.

Technical Product Manager:

Within the Expedia product ecosystem, we have both a Technical Product Manager (TPM) and a Product Manager. As a TPM, you are more closely partnered with Engineering teams.

All of our teams follow the Agile methodology, which means you can expect to attend (if not lead) daily standups. You will likely build user stories and participate in sprint planning. The lengths of our sprint cycles vary by team. Some could be as short as a week, others are a few weeks. We have a ‘Test and Learn’ culture and a bias toward action – giving our teams the ability to move faster with less red tape.

While most roles don’t require a background in software development, it does help in most cases. I’ve seen a lot of Engineers make a successful transition from development to TPM. It’s a natural progression for those wanting to take on broader responsibilities over product creation. You’ll partner cross-functionally with several teams. You act as a liaison and help your less technical counterparts understand technology constraints and possibilities. You’ll also help to communicate timing for execution, helping to prioritize feature work within the roadmap.

Keep in mind if you’re looking to move into Technical Product Management, there are some TPM roles that definitely need someone who comes from a hands-on development background. While this isn’t the norm, I have seen roles where the TPM would continue to own some code as part of their broader responsibilities.

Product Manager:

This is purely my opinion, but I believe finding the right Product role is pretty tricky. The level of technical aptitude needed to be successful is different for each team and depends heavily on the product space. Because most of our Product teams are dealing with digital products, the level of technical knowledge needed tends to be on the higher end of the spectrum.

That said, there are definitely Product Management roles that are more focused on stakeholder management, strategy, or user journey and UX. As the Product Manager, you own the roadmap planning, feature release cycles, backlog prioritization, varied levels of reporting, and product related problem-solving.

In general, all of our Product Management teams are going to be looking for someone who is comfortable working in a highly matrixed organization. Because a lot of products span multiple brands, you may have several stakeholders and they could be located all over the world. That means that not only will you work cross-collaboratively with UX, Engineering, Marketing, etc. you may also have the added complexity of working across brands. For someone who’s looking for more complexity, this may be perfect for you.

A few things to keep in mind:

Our teams are truly Global. I know, on the surface this doesn’t sound very different from other large tech companies. I’ll explain. I’ve worked with some companies that have a large global footprint; however, in a lot of cases, the product work was dispersed by location. London had their part, Sweden had another, and both were part of a larger body of work. In those cases, they had regular check-ins but the interdependencies were fewer which required less coordination. In our case, your immediate team may have a global footprint. It’s possible that you’ll be managing close dependencies where you’re coordinating with immediate team members located on the other side of the globe.

Your Search:

First and foremost, don’t be discouraged if one position isn’t the right fit. If you are a Product veteran you probably already know how unique each position is. Maybe you don’t have enough experience with complex information architecture, but nail the customer experience and user journey. Everyone has different professional experience and those are the things that will make you a unique fit for the right team.

Landing my dream job and the magic of giving it away

Marnie Weber | Sr. Technical Product Manager in Bellevue, WA

“You can only become truly accomplished at something you love.  Don’t make money your goal. Instead pursue the things you love doing and then do them so well that people can’t take their eyes off of you.’ – Maya Angelou

Ms. Angelou had it right of course.  As did Kahlil Gibran who said, “work is love made visible.”  I live by these ideals because I believe that people who love what they do are less likely to start wars, starve babies, or shoot teenagers.  They’re too busy being happy.

Loving what you do sounds awesome – but only one-third of us are highly engaged[i] in our work.  Businesses love the idea of high engagement because it’s linked to high performance.  And individuals want to be highly engaged because it leads to rewards and recognition.  But neither really know what to do to increase engagement.  They haven’t made the love connection.

As a child, I was a performer.  I made up skits, sang along with my parents’ LPs, danced, did gymnastics and was a cheerleader.  I performed in the two school plays that were produced by my tiny High School. I loved being on stage and, thus, I wanted to be an actress when I grew up.  But when I grew up I studied computer science.  I enjoyed programming and was good at it – and I didn’t want to be a starving artist.  My dream of performance was put away.

Computer science was the way to go in the late- 80s.  I won an internship at Microsoft in 1988 and stayed for a long time, pursuing a variety of jobs and learning, learning, learning.  Sometimes I really loved my work, sometimes I didn’t and by 2011 I was ready to do something different, more meaningful, something with more love in it.  I decided to leave Microsoft and start a coaching and facilitation practice because, as a leader, I was good at those things and they made me happy.

But before I started out on my own…

I was a bit underutilized during the last few months of my Microsoft career, so I decided to get a jump on my new role by developing a career planning workshop just for the fun of it.  I offered it to any group within my organization who was interested, and several teams took me up on it.  My love of performance was rekindled as I engaged my audience and I felt fulfilled by their positive response.

Shortly after I started my business,I was contacted by Adobe about designing and facilitating a series of career planning workshops. I hadn’t advertised or contacted Adobe, so I was a bit surprised.  It turned out that the Marketing VP who contacted me had taken my free Microsoft workshop and had chosen her new career at Adobe based on her learning from it.

How serendipitous.

For the next couple of years, I worked as a coach and facilitator and I co-curated TEDxSeattle 2013.  I learned more about coaching and facilitation and I gained interesting insights about storytelling, but I wasn’t making ends meet doing what I loved.  After much soul-searching (and with two children readying for university), I reached out to Strong-Bridge Consulting and they graciously brought me onboard as a consultant.

When I first started consulting, I was placed almost exclusively in project management roles.  I was good at project and program management, but they weren’t my dream gigs.  To be happy and super productive I knew I needed to bring more love to my work, so I found ways to incorporate workshops and coaching into my project management roles.  My clients loved the creativity and unique results I was able to bring with these additional, often complementary, services.  I was happy and Strong-Bridge was super supportive.

Over time, the mix of work I was awarded shifted more toward facilitation until I was hired by Expedia Group to teach an engineering team how to use storytelling techniques to improve their written and verbal communications.  I had the luxury of six months to deliver training and coaching for each team member such that they would be able to present their best TED-like talk.  This engagement was 100% facilitation, coaching, and storytelling, and was unlike any I had done before.  I felt excited to go to work almost every day and noticed that I was making an even greater impact than I had before.

And then… my work got noticed by the group’s Vice President and shortly thereafter I was hired by Expedia Group to do MY DREAM JOB!  I am grateful every day that I get to do the work I absolutely love.

It all started with me giving away the work I loved to do the most.

I believe the shifts in the type of work I do happened because I didn’t wait to be paid for what I love to do.  Rather, I brought love to my work and more work that I loved followed.

If you are less than highly engaged and want to feel more love in your work, try bringing what you love to your work.  Do you love coding, but that’s not your job?  Create a helpful app for the team.  You long to work in a nonprofit but feel stuck in the corporate world?  Enlist and lead a group of volunteers in a charitable activity.

You get the idea.

[i] Gallup, State of the Workplace Report 2017

Common Tools & Services equals Developer Collaboration which in turn empowers Productivity!

Tammy Stockton | Sr Product Manager in Bellevue

As a Sr. Product Manager of Developer Collaboration and Productivity for Expedia’s IT organization, I’ve been participating in a Common Tools & Services initiative. But, lets back up about a year. In 2017, I had the opportunity to sit down with Technology Leaders across Expedia Group. In these discussions, I listened and they talked, mostly about developer pain points within their pipelines and processes.  I was noticing some real themes here:

  • Lack of transparency across development teams
  • No common development tools
  • Lack of a centralized pipeline
  • Development teams are siloed and want to collaborate
  • Developers want to focus on building great Expedia products

These common themes uncovered a common problem which led to a common solution… Developer Collaboration & Productivity via Common Tools & Services. As a developer, collaboration and productivity were the primary themes here. After doing some analysis, there was also some underlying redundancy. Decentralized development tools incur redundant costs. Costs like:

  • Infrastructure costs
  • Administrative costs
  • Maintenance costs
  • costs, costs, costs

Well, with a blessing and the support of Expedia Group leadership, this led me on a mission to provide the best in class development tools that facilitate collaboration and productivity via Common Tools & Services for thousands of Expedia developers. Let’s consolidate…One Team, Group First!

Welcome Artifactory, Same but Better

You have to start somewhere and Artifactory was the test for consolidation to improve developer collaboration and productivity. After all, Artifatory is the same but better! Right? Having many flavors of “Binary Repository Managers” at Expedia, I and a few Engineers rolled out and have been successfully paving the way to consolidating development teams, providing common tools, and reducing redundancy and overhead costs.

Hello Github Enterprise – Goodbye Bitbucket

They say, “Coders Gonna Code” and with Expedia Group developers operating out of a variety of source code instances, with different tree structures and limited access across these instances, they do code… but they lack collaboration, and in turn, this impedes productivity. By means of persistence and facilitating the collaboration of a group of influential Tech leaders across Expedia, we collaborated on a plan for consolidation onto a single Github Enterprise for Expedia Group. This was a task I was not super confident about at first. In fact, for quite some time the “Octocat” haunted me in my sleep. Well, I’m excited to say we are well on our way to closing the gap on siloed development practices.

A Continuous Delivery Pipeline

It was a “build your own” world with a variety of home-grown solutions that lacked speed, transparency, quality, and compliance controls. A group of us from Expedia’s eCommerce Platform group conducted some working sessions with key technology folks supporting their own flavor of a Delivery Pipeline, and after much debate and testing, we landed on a solution right under our noses. As Brand Expedia Group’s Cloud Acceleration team had been supporting a very mature pipeline “Kumo” (which means “Spider (nature’s preeminent Web builder) and Cloud”). It was a no-brainer that we should engage this team on adoption and testing application deployment.

The adoption of Kumo across Expedia Group is a win/win as Kumo does also facilitate common tools & services which leads to developer collaboration, and in the end, we have happy, productive developers.

Now, this is a theme I can get onboard with! I’ve got to go now as I have much more work to do to continuously improve Expedia Group’s Developer collaboration and productivity. Stay tuned for more on Common Tools & Services at Expedia Group.