Building an engineering team

Building Blocks

Photo by Jeremy Thomas on Unsplash

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. As a Senior Software Engineer, you’ve been expecting a chance to show your potential in team management and leadership. It’s a 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, big, new, or legacy projects. You probably 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 an engineering or development team. I’m going to cover 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 only 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). That you have worked in many environments and companies. You are also comfortable helping and/or mentoring new hires and interns.

Our team will also have a size, let’s say six to eight people on it. Different levels of experience. SW as well as QE engineers, and also 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 have perceived some personas that always appear in every team. In fact, it does not matter the company or project, they are always there. 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. There are also the followers, people that like guidance and to be 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 description. 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. That there are many 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 team’s workload. By working in sprints, you commit to delivery changes in small iterations. 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 many 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. 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 that is global and has 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 and 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 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. You can go on vacation and when you get back everything is still smooth as if you never left.

Tasks and 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 hurry into coding, it’s wise to spend a good amount of time in designs and scoping of features first. As soon as the project is scoped, you can break it down into tasks, define priorities, deadlines, sprints, and everything else.

There’s no magic formula here. With the scope properly set you can verify if you met all requirements with stakeholders. There are cases that you can work with proofs of concepts. This technique can ensure that a certain technology will solve the proposed problem.

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 can 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. They can happen on the project development side or in 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 them. Even if not everyone is happy with the final decision, at least they were heard, in this case, the best solution wins.

If the conflict relates to relationships with others, it’s usually a good idea to seek or give feedback. If the team is not happy with you, or your management is not happy with your team, that can be a potential problem. Management problems can cause 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. 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 usually take more than six months.

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 many items. The salary and benefits are in one group. The company culture, the type of project that they work on in another. The deadlines and pressures around them, the list goes on, you name it.

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. As long as everyone has a good relationship, you 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