Gearing up: the challenges of managing a growing team

<p>When 2018 started, Vinta was a team of 12 people. As the year passed, the demand for new hires was constant, and today we're a group of 21 among developers, designers, and managers. As the team grew, project managers faced a new challenge: transitioning a process that worked great for small teams into one that would not be hindered by team size, while maintaining product quality, and managing the client's expectations.</p><p>Every manager at Vinta is also a developer, and this adds an extra layer of complexity when managing large teams. Keeping managers technical gives them a deeper understanding of the project's complexity, and therefore improves roadmap planning. If you're curious about how we manage projects at Vinta, check <a href="http://vinta.com.br/playbook">our Playbook</a>.</p><p>This context is particularly close to me. I'm a Senior Developer and Project Manager, and I lead a team of 8 people. To keep up with the growth, I had to learn new management approaches quickly. My primary challenge was learning how to divide project responsibilities and manage tasks while thinking about how to deliver value to the product at every step of the way. I had to learn how to lead the team as a group towards the goals of the project while keeping an eye on each individual's career and goals. It is essential to assign developers challenges that allow them to grow professionally.</p><p>Before I jump into my key lessons, I want to state this: the main thing I learned is that there is no magic formula. Different contexts require different solutions, and what works for one team, may not work for another. This is the case even when comparing different projects in the same company. Balance is an ever-evolving goal.</p><p>Here are 7 insights that might help you as well:</p><h3 id="keep-expectations-aligned">Keep expectations aligned</h3><p>Keeping the client's expectations realistic is every manager's responsibility. As new resources are added to the team, it's essential that the client is aware that more people don't mean shorter deadlines. Instead, it means that with time you'll have more parallel deliverables.</p><p>New team members aren't an instant boost of productivity. You need to factor in the cost of the addition of more people. After all, onboarding takes time for both the new team member and the person who is responsible for the onboarding. Before someone is truly productive, they need time to understand the project, and this will vary according to its complexity and the individual's previous experience.</p><p>When discussing team growth, let this be your mantra: "9 women can't make a baby in one month".</p><h3 id="avoid-communication-overheads">Avoid communication overheads</h3><blockquote>"Communication overheads increase as the number of people increases." -- <a href="https://en.wikipedia.org/wiki/Brooks%27s_law">Brooks's law</a></blockquote><p>Part of my job is making sure that communication is not an overhead. I need to be the bridge between the product team, the client, and third-party vendors. I'm responsible not only for guaranteeing that everyone is on the same page but also for detecting early on when we have communication noises and for finding solutions moving forward.</p><p>When we had a smaller team, the communication among team members happened fluidly. As the team grew, we started noticing that we were losing track of each other's work. The solution we found was a known Agile method: daily standup syncs. Each day, at a scheduled time, we stand-up for 5 minutes and share what's our priority for the day. This practice allows us to keep everyone informed about our work, share learned lessons, and figure out who can help us when we're stuck on a problem.</p><p>For small teams daily standups can be a burden, so we waited until we felt the need to apply the process. At Vinta we don't follow processes just because they are in the book, we believe they exist to solve problems as they appear.</p><h3 id="encourage-autonomy-and-share-responsibilities">Encourage autonomy and share responsibilities</h3><p>Being honest, at times, being a part-time developer/part-time manager can be overwhelming. When the team grows, the amount of code being merged on each Sprint also increases, and with that the risk of introducing new bugs. At this stage, you'll notice the need to spend more time assessing risk, reviewing code, doing QA, and making sure that support is working well. You should do all of this while balancing everything with the other responsibilities such as product development, features deliveries, planning Sprints, managing the client's expectations, developing your task, etc. That's a lot, right? And the truth is you can't handle it all alone.</p><p>A positive aspect of bigger teams is that it makes micromanaging almost impossible. You just don't have the time. Instead, you're forced to encourage autonomy and share responsibilities. With my team, we tested a few different ways of dividing responsibility. What worked for us was dividing responsibilities by areas of concern such as Support, Deliverables, Performance, Security. Each area has a designated dev responsible for it. Their job is to manage everything that falls under their scope and report back to me. My job is to follow up with each area and keep the work flowing. That's not only how we can balance a large team, but also how we develop seniority in team members. This practice builds other leaders, gives them responsibility and encourages them to be decision makers.</p><h3 id="take-a-step-back-as-a-developer-but-stay-technical">Take a step back as a developer, but stay technical</h3><p>As a part-time manager/part-time developer your responsibilities will limit what features you'll be able to develop. If you love writing code, there will be times where you'll want to develop challenging new features. But you'll soon realize that doing so may compromise your other responsibilities. At this moment, it's time to take a step back as a developer and only assign yourself with small or low-priority features that are detached from the epic and won't require your total focus during the Sprint.</p><p>To stay technical, dedicate more time to code review. PR reviews enable you to assure a quality standard, follow up on developer's evolution, discuss the code, and understand how complex features are implemented. It's a great way to stay up-to-date with the codebase, as it changes daily. Knowing the code gives you the context to avoid blockers, crossovers, and assess risk. As the manager, you must evaluate how the new code will impact the project as a whole before it goes to production.</p><h3 id="avoid-code-crossovers">Avoid code crossovers</h3><p>Code conflicts are inevitable in a team of 10 people. However, there are ways to mitigate this. A key rule is to detect possible conflicts at the Sprint planning stage, not only when you're trying to merge the code. Identifying potential conflicts is a team effort, it's both the manager's and the developer's responsibilities. Ideally, tasks in a Sprint should be decoupled from each other, but that's not always possible. When crossovers happen, the developers involved should, on the kickstart of the Sprint, work on what I call a "base branch" containing the conflicting code. Then, the work continues from this branch; making sure there's a level of agreement so that no ambiguities are being introduced.</p><p>This concept might be a bit complicated to wrap your head around, so let me exemplify in a more practical sense. Let's say we have a front end task where we're developing a couple of web pages. The pages are different, but there are shared elements between them such as fonts and color palette. In this Sprint, time is a constraint, and we need both pages developed by the end of it. At day one we would make sure that developers set a "base branch" defining the typography and color palette. Both developers can then continue to implement the pages from there, with the assurance that they're not duplicating unnecessary code. Even if you don't catch all the possible duplication points at first, the amount of duplicated code is reduced, which is already beneficial.</p><h3 id="documentation-matters">Documentation matters</h3><p>We want to grow strong, and for that, we're continually upgrading our processes and documenting it. <a href="http://vinta.com.br/playbook">Our Playbook</a> is particularly crucial for us as new folks join the company (which is continuously happening). New members mean a new set of eyes and opinions on architecture and documentation. It's an opportunity for improvement, especially if they are in a more senior role, so we encourage them to give feedback and contribute from the start. As managers, we must promote the documentation culture, allocate time for the team to contribute, and guarantee that the docs are up to date.</p><p>The documentation culture starts from day 1 with our onboarding process. It occurs in 2 stages: first, we onboard people on the company, then we onboard them on their teams. Each team is responsible for their onboarding process, and although it evolves, the core steps are always the same. At the end of the onboarding, if new members have any feedbacks, they must contribute to the process. We document the onboarding steps not only to facilitate the task but also to assure anyone from the team can help onboard new team members.</p><p>Another important aspect of our documentation is our project Wiki. It's where we document the project's business logic, common support issues, and how to proceed with them. Learned something new? Document it right away. Found the documentation outdated? Update it right away. Knowledge should never be concentrated in a few individuals; it should always be documented for posterity.</p><h3 id="don-t-lose-track">Don't lose track</h3><p>My last tip is a bit obvious, but should not be forgotten: track absolutely everything. Every single task I have, as smallest as it might seem, is tracked on a tasks manager, and every meeting is an invite on my calendar. This system keeps me organized and gives me confidence that I won't forget to do something. You should find the self-organizing way that works best for you. Tracking what you are doing is not only a benefit to yourself, it also helps the team. It's a proof and validation for them that you have everything under control and that the team can trust you to alert them if something new might get in the way of their work. Every day, I open my list, view my schedule, and prioritize my tasks. If I add a new task to my list, I have a clear view of how this will affect my work. By Friday, I make sure I have a clean To Do list, which is incredibly self-rewarding.</p><hr><p>I'd love to know how you've been handling similar situations, so leave a comment below or tweet at <a href="https://twitter.com/laisvarejao">@laisvarejao</a>. Also, I've recently started experimenting with Squads, so do expect another post on my learnings on that.</p><p>Before I end, my gratitude to <a href="https://twitter.com/pereiragislene">Gislene Pereira</a>, <a href="http://raquelguimaraes.com/">Raquel Guimarães</a>, <a href="https://twitter.com/robertson_filho">Rob Novelino</a>, and <a href="https://twitter.com/xima">Filipe Ximenes</a> for their precious contribution to this post.</p><p>Here are some interesting references in case you want to read more about the topic:</p><ul><li><a href="http://adaptivepath.org/ideas/size-matters-dealing-with-large-teams/">Size Matters : Dealing with large teams</a></li><li><a href="http://allyouneedisbackend.com/blog/2018/08/03/what-does-a-tech-lead-do/">What Does a Software Tech Lead Do?</a></li></ul><hr><h3 id="keep-following-us-to-know-more-">Keep following us to know more!</h3><p>We publish a monthly newsletter where we talk about coming events, interesting topics that might have sprung on twitter or interesting blogposts we came across. If you like our content and want to receive drops of it, you can enroll <a href="http://bit.ly/subscribe-vinta">here</a>!</p>

Gearing up: the challenges of managing a growing team

Join the Tech Forward newsletter

Related articles

Uncovering input fields from iOS Keyboard

Why Should Every Software Development Team Have a Product Designer?

Pull Requests: Merging good practices into your project (part 1)