Tips to effectively scale engineering teams

Arpit Mohan - Mar 2 '20 - - Dev Community

TL;DR notes from articles I read today.

The 5 levers to address ‘org smells’ and ship higher-quality software (faster)

  • Clarify roles and responsibilities for both teams and individuals, including where these overlap, to help everyone understand what they should be doing, who to approach with questions on a given area and what is a shared endeavor.
  • Create living product documentation to share insights and stay aligned. Regularly update product development processes and key product documents such as strategic objectives and roadmaps. 
  • Hold productive and engaging meetings, with separate people facilitating and leading each of them. As a facilitator, share enough context beforehand, lay out an agenda, track time, keep people focused and maintain minutes of the meeting. As a leader, decide what needs to be done synchronously at the meeting and what can be achieved asynchronously. Set expectations for the how, when and where of communication within and across teams.
  • Develop good relationships with your team members so you are able to have difficult conversations with them with ease. Remember people crave BICEPS - belonging, improvement/progress, choice/autonomy, equality/fairness, predictability, and status.
  • Share context and critical milestones of progress through stages widely with the entire organization. Explain the reasoning and history behind decisions made.


Full post here, 14 mins read


3 research-backed principles that help scale your engineering org

  • Dunbar’s research says that the most evolved part of the human brain can maintain a maximum social group size of about 150. Heed Dunbar’s number and keep a maximum team size of 150 and this should be entirely a standalone system. Ideally, have 10 people or fewer per team. Add system-level interfaces, roadmaps, and tools like Jira once you exceed 35 members. Institute monthly cross-team demos to share knowledge and make time for relationship building at personal and not just a professional level.
  • Use Conway’s Law to your advantage by strategically building your organizational structure to reflect your desired software architecture, since you will typically find the systems you design anyway mirror your company’s communication structure. This inverse Conway maneuver also means merging teams building similar systems so that duplicate systems converge.
  • Circumvent Brook’s Law (aka the Mythical Man-Month), which says adding manpower to a late project makes it later. If you must add team members to long, large projects, look for people who already have hands-on experience with the codebase or consider shuffling people across teams (in consultation with their managers). Complement this by factoring in time needed to onboard new people and train existing ones when committing to a schedule. 


Full post here, 5 mins read


Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player