I’d like to aggregate best practices and experiences to scale engineering teams.<p>We’re working with engineering teams from 5 to 100 developers today and found out that almost every engineering managers face the same challenges: engineers’ well-being & retention, scaling new hires, maintaining engineering velocity, improving collaboration in a remote environment.<p>What is your best advice or piece of experience you’ve used to scale your engineering team? Do you follow specific metrics (DORA metrics, …) or framework (SPACE, …)? I’m particularly interested in helping engineers that start management positions without much experience.<p>Main takeaways we’ve seen so far: following key metrics to assess engineering sprints' health, regularly sending anonymous surveys to engineers for feedback, creating dedicated timeslots for engineering managers to work on non-direct tech topics (hiring, management, …).
This might seem contrary to a lot of management practices you may come across but I think you're really going about it the wrong way. Things like following key metrics to assess sprint health, anonymous surveys, more manager involvement all to me signal warning bells of an environment that doesn't trust it's people, which might actually be the root cause behind all the engineering challenges.<p>I think you should take a drastically different approach and see how you can reduce manager involvement in most activities. A manager's job is to create the right environment for a team to function, and then step away. If they are not able to step away, they have failed their job. The problems that you mentioned typically happen when people lack a sense of ownership around their work. With the right culture that entrusts people with responsibilities and an environment that empowers them to do what they need easily, most people will respond well and step up to ensure the goals of the team are met.
I worked at different startups while being a freelancer. The one that provided the best environment for me to work as an engineer:<p>- Great welcome packages (computer all set up, some cool swag, and a person I could easily ask questions)<p>- Unlimited budgets for tools I judge necessary<p>- Time for learning. One company had a moment once every two weeks where an engineer would present his findings about a new technology. You could choose to share anything you thought was interesting for others in your team. Could have been a git functionality, a new framework, or a tool.<p>- Daily standups and very few to no meetings during the day. => This is important. One startup I worked at had me in meetings half a day and was expecting me to ship like I was working a full day.