Congratulations! You've been tasked with building the engineering team that you've always dreamed of. Now it's your time to bring the people who share your passions and drive, that will make the perfect team you can lead to success.

Right?..... Well, yes, but not really :).

Before you start refusing and accepting candidates left and right, there are some steps that will hopefully help you in making sure you've built the NEEDED team.

While there is no magic formula, I will give some points I've observed and learned in my experience while building and leading software engineering teams.

So let's dive right in!

I. Understanding the company and current context as fast as possible

I'm sure the persons who tasked you with this didn't tell you to "take as much time as possible". This team is built for a need and more often than not, that need has to be fulfilled sooner rather than later.

Because of this, one of the first requirements for you is to understand as much as possible how the company operates, what issues it's currently facing and what are its strong points.

Some of those will be transmitted directly to you, but some are more subtle, though also important, and you will be able to observe them from the interaction between people, teams and departments. Try to get a good feel of the company and how it's working and this will help you in identifying the possible future issues this team might encounter and what type of people would be suited for this kind of environment.

After you think you will have a good grasp of this, comes another part.

II. What are the expectations from you

While you are part of the team and more likely than not you will be evaluated by your team's success, you also need to understand what are the expectations from you.

As in the previous point, some will transmitted directly, but as every company has different gaps and needs, identifying them and getting a good idea from the start will help you tremendously in knowing how you will need to operate, but also looking for people who might help you in fulfiling them.

Some examples are:

• are you also expected to lead the team technically?

• will there be a product owner for the team? If not, how are the needs/requirements gathered, understood and then given to the team?

• how is the QA process handled and who is managing it?

• how is the release/deployment process handled and who is managing it?

• who is handling the people management responsibilities like one to ones, performance reviews, PIPs and so on?

• will the team work on a greenfield project?

• will the team receive some already existing solutions that need to take care of them or maybe even rewrite them?

You could ask those questions in the interview process to get a good idea of the responsibilities that will occupy your day-to-day work.

A point of note! While you will get some answers and people usually answer with the best intentions, you will often find things are a little bit different when starting. Take note of this and see what you will also need to fulfill and take into consideration.

III. Team seniority and size

Usually, when it's decided that a new team will be created, the team composure and size are decided as well for the budget to be allocated/approved.

While you might be able to take part in this, most of the time you will not have this opportunity and will be bought after this was decided. Because of this, it is important to understand if the expectations and the needs match the seniority and/or size of the team that wants to be built.

Maybe the team will have no place for a junior/mid developer. Maybe you already foresee that you will need one more front-end dev, or an additional QA person. Maybe you will need an expert in X technology to make sure the solution will be the right way from the start.

If you see any such needs that differ from the proposed plan, don't be afraid to say them. At the end of the day, you will be asked why is the team not performing according to the expectations or why the project is late.

While it might not make a change right now, it will introduce an easier possibility of this being done in the future if things go according to what you've already mentioned.

IV. Owning existing solutions

As companies grow, so do their needs for the software that it's already running. From this comes a natural need to split services or domains that previously were being held by a single team to multiple teams to make them scale according to the increasing needs.

If the team you will lead is supposed to take over one or multiple such solutions then it's recommended you do some additional steps:

• dive into the solution code. How is it looking? Does it have tests, if yes how many and what types?

• is there any code quality tool like Sonarqube that has some statistics about the code? How is it looking?

• how is the documentation looking? Do you personally think that you could work with it if there is a need for a change in the solution?

  • if it does not exist, ouch :)... ask for the team that is coming from to write one with the most important parts of it. Review it and see if you understand it and if your developers can work with it.

• how is the observability/monitoring looking? How complete it is? How are the alerts configured, do they make sense? Are there a lot of alerts daily that are ignored?

• does your solution have SLA? If yes, how is the history in the past year looking for it?

• how many incidents did the solution had in the past X period? How were they resolved? Are there any public or internal post-mortems for them?

After you get an overview of the state of the solution, identifying what are the immediate needs but also how they will need to be handled in the medium and long term will help you in looking for candidates who can contribute on it.

IV. Closing thoughts

And that's about it... at least for now :)

Building a team is never easy, don't despair if in the end your team is not perfect or the one you dreamed of. Just make sure you get people who are interested in growing and are open to change and feedback.

Things can always be improved.