Loading...

Building a New Domain Team

Thomas Lamirault

Associate Director at Ubisoft

Loading...

Problem

I joined a startup that used to organize its teams around components. I strongly felt that organizing them around specific domains would be far more effective. Some domains were left unattended and without clear demarcation of ownership over domains, and therefore, teams were reluctant to take ownership.

My proposal was met with approval, and I was eager to roll up my sleeves and start building a new domain team. I was tasked to build it from scratch, drawing the team boundaries and attracting new team members.

Actions taken

To start with, I had to provide a solid explanation of why we were undergoing this change and reorganizing the teams. Engineers are not always willing to embrace a change, and they often demand to know why something like that is done. They need to hear compelling arguments; otherwise, they would push back. Therefore, I delivered some robust arguments and expanded on benefits making sure that they would embrace the upcoming change.

The next step was to formulate a team charter, define a team mission and key objectives. I made sure all our strategic documents were clear and concise, which made new engineers who were joining the team well-informed and motivated. Following on that, Product and Engineering sat together to precisely define a roadmap and prioritize features that we would be working on in the upcoming period.

We populated the team with engineers from the company first. We circulated the team charter around, which quickly brought us some volunteers. Clearly defined charter proved to be a great way to attract mission-driven and proactive people. We also added some senior people who had extensive knowledge of the domain, but we also had to fill in our ranks by hiring people externally.

As a result, our domain-based engineering team became more efficient, and Product was happier with the structure they found to be more logical. However, the domain itself (security) is notorious for its strict deadlines, which was generating a lot of tension and caused some junior people and those less attracted by new mission to leave.

Lessons learned

  • In retrospect, I feel that I should have aimed for different profiles more suitable for our specific mission. My original plan was to have people of various profiles, and I felt that it would benefit the team. However, some of the juniors simply didn’t fit in. If people, like some of our juniors, didn’t feel they were the right match for our mission, you should let them go.
  • Build a rapport with the team early on. Explain what you plan to do, what your expectations are, and use that to build cohesion around the shared goals and aspirations.
  • Start small. Let things roll, but start small. It’s easier to consolidate and set up for success on a smaller team than a large one.

Be notified about next articles from Thomas Lamirault

Thomas Lamirault

Associate Director at Ubisoft


Leadership DevelopmentCommunicationOrganizational StrategyEngineering ManagementCareer GrowthCareer ProgressionSkill DevelopmentIndividual Contributor RolesStaff EngineerTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up