Building an engineering team

Your company is growing, there are new products that must be built to bring more customers. Your manager comes to you and asks you to assemble a new team to work on a brand-new project, they also provide you with a small number of engineers to get the project going ASAP.

You’ve been part of the company for a while, and as a Senior Software Engineer, you’ve been expecting a chance to show your potential in team management and leadership, and today is your once in a lifetime chance to do your best, at least in this company.

As an experienced engineer, you are used to working on small or big projects, new or legacy ones, but you never had to put an entire team together, there was always someone else that did it, or you always joined a team that was around for a while.

In today’s article, I’m going to share my thoughts on how to build a Dev team, what does it take, and how you can tell if you built a good team, as well as what is a good team.

Before we start, we need to set some ground rules:

  • We are not going to talk about hiring people, assume that you got an entire team ready to go, they just need guidance. Hiring is another entire topic that does not fit in today’s context.

  • I’ll also assume that you are a senior engineer (in experience, not in titles), have worked in multiple environments and companies, as well you are used to helping and/or mentoring new hires and interns.

  • Our team will also have a size, let’s say 6 to 8 people on it. Different levels of experience. SW as well as QE engineers, maybe someone more focused on DevOps or SRE if required on your project.

Now that we have our rules, let’s dive in and build our team.

Personas

If you have been working for a while, you probably have noticed some personas that always appear in every team, it does not matter the company or project. I’m not going to classify these groups as there are better studies and books to help you with this subject.

For example, there’s always a leader persona, that person that is always looking forward and driving the team, and also there are the followers, people that like to be led and told what to do. Yet, the leader can also be a follower from time to time, that’s not a problem.

Try to get a sense of what personas your team has, each persona has a way of thinking and working. Address them accordingly to their persona, one size fits all does not work here. You may also find people that fit in more than one persona, or that their persona changes over time, mood or tasks, that’s completely normal.

We are constantly evolving as a person, we change, we adapt, and so are your teammates. Don’t expect someone to be the same forever, if they change, learn to work with their new persona.

What you want to ensure is that your team is diverse, there are multiple personas on it because this brings balance and harmony.

Structure

You have identified the personas in our team, but we still need to structure it in some way. For that, we will make use of Agile.

Extreme Programming (XP) and Scrum are the best options. They are very alike. Scrum is more flexible when talking about code and development process, XP, on the other hand, enforces some rules. I’ve been using Scrum for quite a while with good programming practices that you find in XP.

By using Agile you get some process or ceremonies that you need to follow. This will help you organize all the work that needs to be done. Also, by working in sprints, you commit to delivery changes in small iterations, and this is good for your team’s visibility and also to adapt quickly to new changes.

A good sprint length is two weeks. Less than that is usually not ideal because you have little time to work on something. Also, more than it may be too much time to get feedback and notice that something is wrong. Two weeks is the sweet spot, not one, not three.

There are multiple software options to track and plan teams’ work. I’ve been using Jira, but there are similar tools available. You should really consider something that allows you to track progress and Trello is not great for past activities.

When dealing with the organizational structure is up to your company layout. What works for a startup may work for a middle size company but not for a big company globally with distributed teams.

My advice on the organization is, treat everyone as equal. Don’t divide your team in Devs, Ops, and QE. It’s a well-known fact that Devs don’t get along with QEs. They’re all equal and capable, they just have different tasks and responsibilities.

Roles & Responsibilities

Every person in the team needs a clear view of their role and responsibilities. This is usually easy to set, you go over their experience and desires. Whenever possible, balance it, allow them to work on areas that they don’t have a lot of experience yet, so they can grow and improve as an engineer.

When they have a clear view of their role and responsibilities they can usually work without someone in control all the time. Also, you can’t control people, just guide or lead in the right direction. With a clear view of their role and with tasks in the backlog, you can rest assured that you can go on vacation and when you get back everything is still smooth as if you never left.

Tasks & Backlog

You need to ensure that there’s work for everyone, you don’t want people with anything to do. When you start a new project or team, it may be quite difficult to get a lot of work to be done in the beginning.

A new team usually means that you are going to work on a new project. Don’t jump directly into coding, it’s wise to spend a good amount of time in designs and scoping of features first. Once you have the new project scoped you can break it down into tasks in Jira, define priorities, deadlines, sprints, and everything else.

There’s no magic formula here, but with scope properly set you can verify if all requirements are met with project stakeholders. Also, there may be the case for proofs of concepts, to ensure that a certain technology will solve the problem accordingly.

Meetings, Emails, and Slack

Meetings usually break someone’s workflow, try to not schedule too many meetings, you don’t need a meeting for every single detail. You could also schedule meetings that are close to the team’s break before lunch is a good time to do stand-ups for example.

Avoid as much as you can mailing lists, nothing important goes there, and if it does end up there, most won’t read it. The worst type of email is the one that is just FYI, which means it does not need my direct input. My advice, if you need mailing lists, have at very least two, one internal, only for the team and another for external people.

Slack, Google Chat, IRC and others, are all amazing tools, but every time that you send a private message to someone you are interrupting them. If you want updates on the progress of tasks you have the stand-up to do it so.

Dealing with conflicts

Every team has conflicts, the way you deal with conflicts is what puts you aside from others. Conflicts will happen once in a while, on the development side, or your relationship with others.

Technical conflicts are the easiest ones, you can do a proof of concept, the team can vote on the best solution, things can be put on a whiteboard. As long as everyone has a voice, and they are heard, you can easily solve, even if not everyone is happy with the final decision, in this case, the best solution wins.

When conflicts are related to relationships with others, it’s usually a good idea to seek or give feedback. If the team is not happy with you, or if your management is not happy with your team, that can be a potential problem because your team may fall apart.

The rule of thumb is feedback. Listen to what others have to say, change, and adapt if required. Give feedback to others, and if possible bring ideas or action items that can potentially solve the problem.

Keeping the team together

When you have good employees you usually want to keep them around for as long as you can. They’ve built the product, they know all the little details, training someone new will take more than six months usually.

You need to discover what makes your team happy, everyone has a different need, approach each individually, don’t generalize. In my experience, it’s a balance of multiple items. Salary and benefits are in one group, but there’s still the company culture, the type of project that they work on, the deadlines and pressures around them, an infinite list of items if you wish.

Be respectful when someone’s time to leave comes. Don’t try to force them to stay. Our priorities change over the years, and we need to move along and chase new challenges.

Is my team good?

The definition of good and bad changes according to people and context, what is good for me may not be for you.

A good team for me consists of transparency, trust, and respect. Transparency, trust, and respect need to come from all sides. We should not forget that a good team also delivers its promises.

Are you transparent with your teammates? And are they with you? Do you trust them and do they trust you? Do you respect them and do they respect you? If you can answer yes to all these questions you have a good team.

Conclusion

Your team can have many flaws, but as long as they have a good relationship, it can overcome and improve almost anything.

Listen, always. Give your teammates a voice and let them drive their ideas whenever possible. Help them reach their goals and ambitions.

Be patient and lead them to success.

The pessimist complains about the wind. The optimist expects it to change. The leader adjusts the sails. — John Maxwell

Comments

comments powered by Disqus