Decentralised leadership for a small engineering team at Mercos

Angelo Luis Ribeiro
mercos-engineering
Published in
3 min readNov 30, 2017

Back in 2016 the leader of our engineering team decided to quit Mercos, given that situation we had two choices: Either hire (or promote) a new team leader or try to go on without one. At that time we had less than 20 engineers and none of them were ready, or wanted, this position. So we began to consider bringing someone from outside, however, as we discussed this possibility we began to foresee some issues:

  • The new leader wouldn't be used to our Culture
  • The team wouldn't feel as comfortable with an outsider "calling the shots"
  • The process of hiring an engineering leader would take a while

With that in mind we decided to bite the bullet and go ahead without a leader for the whole engineering team, instead we divided the team into smaller groups and assigned a team leader for each one of those. These team leaders would report directly to the Chief Product Officer who is actually one of the founders.

At first the team leaders were called "Scrum Masters" to avoid the impression of a hierarchical superiority. There was also an emphasis on the fact that they were not part of the company's leadership team, instead they were to be seen as peers who were still coding on a daily basis but also had some extra responsibilities such as:

  • Conducting the 1 on 1 followups with the members of their team
  • Organising the team's tasks
  • Reporting the progress of the ongoing tasks to the CPO
  • Dealing with vacation planning and extra hours management

Later we realised that this model was working really well for our team, the deliveries were still happening on time and within our quality standards, the team members were engaged in the company's projects and the Scrum masters didn't consider these new responsibilities as a burden.

As time went by we decided to give up on the idea of having a single leader for the entire engineering team, so we had to delegate some additional tasks to the scrum masters. Now they were called "Team Leaders" and were included in the company's leadership team. They also became responsible for all the steps in the selection process, even though we always had an engineering review step. The budget planning was also transferred to these team leaders, including the discussions about raising salaries and letting people go.

So far we didn't have any major issues with this approach, whenever a situation arises when someone would normally need the "leader of engineering" we take that to a group discussion that includes the team leaders and the CPO and if any additional work or research is needed the task will be given to any one of the team leaders. We have used this method to deliver a number of interesting changes such as:

  • The introduction of a Culture Code for the engineering team
  • The creation of a policy that allows engineers to use 20% of their time on personal career improvement projects that are related to our core business in some way.
  • A batch hiring effort that brought 4 new engineers to the team in a single month

We believe that this is a good solution for small teams where you have up to 5 team leaders, each responsible for up to 4 engineers. However, if a company has more than 10 small teams, a role such as a CTO might be needed to manage the team leaders directly instead of having them report to a founder. Given that we are not there yet, we don't expect to change this method anytime soon.

With insights from Israel Fonseca

--

--