Navigating the Start: How to Set Up a New Team for Long-Term Success

Towards the end of 2022, as an Engineering Manager, I was presented with the opportunity to set up a brand new team here in Phorest. There can be huge costs associated with kicking one off so you need to make sure all bases are covered to set the team up for success. This is the approach I took with lessons along the way which will hopefully support others who are setting up a new team for the first time!

🗒️ Put it down on paper

To ensure you can communicate the plan effectively and consistently, drafting up a proposal is the first step. This forces you to get all your thoughts and ideas down on paper as well as identify gaps as soon as possible. At this point, you and others already know the why or what problem this team could solve but that doesn’t mean everyone will, so start off your proposal by reiterating the why, it will equally act as a record of decision making to look back on.

Importantly as the engineering manager, prepare a section detailing the team make-up in the short, medium and long term. This should include the roles, including their seniority and level of domain knowledge. For example, the team I was building, I knew I needed people who could deal with a high level of ambiguity as we figured out first steps as well as being proactive in assessing the technical stack in detail and making recommendations for improvements. Providing this team make-up will ensure costs are considered from the get go of what will be required to put this team together. It will allow everyone to assess if those people already exist on other teams internally or will hiring be required. It’s vitally important to start the team with as much domain knowledge as possible to be productive quickly, by already having this context it reduces the number of hurdles to overcome.

💵 Get buy-in

Now that the proposal is put together it’s time to share. The idea of starting a new team could be unsettling for some so be conscious of the order you share it in. Start from the top down, share the document and allow time for them to digest, have conversations with people to gather feedback, adjust your proposal if needed and continue. While you might think this is the right thing, encourage people to challenge it. By doing this you will give yourself the confidence that it is the right step as well as building up awareness of the team so others can speak on your behalf if needed.

📅 Set deadlines

Unless the setup of this team is your single and only responsibility without a deadline things will just keep slipping. The day to day would always keep you busy so it’s important to set yourself deadlines and share them with someone who will hold you to account. Additionally, you may need others involved in helping you put this team together, for example, you might need someone to be responsible for hiring a product manager and ensure the deadline you set works for them too. Some important milestones for your timeline could be:

• Comms date; when to share comms with your wider engineering team to gauge interest in potential internal moves
• Hiring deadline; when to advertise new roles and when, ideally, those hires should be confirmed.
• Team kick-off date; when should internal moves expect to happen. Their current teams need to plan for the impact.

💬 If you think you have communicated the plans enough, you haven’t.

I can’t stress this enough and is definitely one of my biggest takeaways from setting up this new team. When the day comes when this team has its first standup it should not be a surprise to anyone in your product and engineering group, everyone should know who we need for the team, what the team will be responsible for and what they will be tackling first. If people are surprised it can give off a sense of unease across the department and potentially show a lack of planning.

My advice is to first create a document for your target audience built from your initial proposal, then record a video discussing it in more detail and find as many opportunities to share from Slack channels to department newsletters and everything in between. If possible, keep track of who has/hasn’t engaged with the material and if you notice people who could be perfect candidates for this team or who will definitely be impacted, reach out to them for an informal chat on it.

Keep in close contact with other engineering managers and work with them to see if they can suggest people who would be a good fit for the team, at the end of the day they know them best. They will also keep their team consistently informed of the changes coming too as well as adjust future deadlines with stakeholders if required.

Once the team is fully formed, create a team homepage and share it via all those same means. It will create a buzz around the team forming and get everyone excited for what’s to come. Maybe at that point, you can say you have communicated enough!

🧑‍🍳 Preparation

As a manager you can get this team set up for success well ahead of the kick-off day.

You want to be able to provide a vision for the team of the potential ways of working and what they can expect to be working on in those first couple of weeks. I started off by “accessing the landscape”, this involved taking a high level look at the projects like if they were outdated and by how much, the last time they were touched etc. it’s also good to get an overview of all the current components making up the new teams area. Additionally, I spoke with our support team about open client issues that have not been tackled and other frustrations. These are ideal first tasks for the team to work on!

Now for the ways of working, keep meetings simple to start. These can be added and evolved as the team settles in and gives you feedback about what they need. We started with daily standups, one weekly product backlog and a weekly tech backlog for just the engineers. I created a Jira project and again kept it simple with a Kanban board of “To Do”, “In Progress” and “Done” columns, again this can be evolved in time and other methodologies can be used based on what works for the team.

One more small but important thing, name the team! Team names stick very quickly so avoid creating one without working with your team on the naming.

🚀 Kick-off

The day is here, you’ve made it and your preparation was worth it! That first stand-up is exciting and the team is ready to go, the plan is clear. Resist all your instincts to take control, stand back, give the engineers breathing room to get a lay of the land and craft their plans for tackling any potential tech debt to start. By doing this they take ownership immediately.

Next start working through some bugs, support escalations or minor feature improvements to keep the clients happy. This has so many benefits by continuing to give time to the engineers to get up to speed with the project, the deployment and release process and for them to start crafting plans of what they would like to improve. Lastly, celebrate the first wins with the wider group, no matter how small!

☁️ Reflection

After a period of time or completion of the first big project, it’s important to look back and reflect on what the team has accomplished but also what they learned along the way. No matter how great the team, there’s always room to improve. My team did ours after nearly 6 months as an established team and our first major rollout to our clients. A basic retro of start, stop, continue brought forth many topics of discussions for us and some key actions. Notably what the team were now ready for was more structure around processes such as introducing cycle planning, monthly retrospectives and looking for improved ways to log and action minor client feedback. For me, it proved my idea that it was much better to keep it simple and allow the team to decide what they needed and what worked for them rather than enforcing a framework too early. No doubt we will continue to own it and adjust it as we retro monthly!