Arguably, the job of an engineering manager is to hire and sculpt a development team that is not only highly productive, but also precisely resourced for immediate business priorities.
Easier said than done. Businesses are highly erratic organisms. Especially start-ups. From week to week our business environment changes and company priorities evolve accordingly. In response to this, so does the position of senior management on the best way to adapt.
Senior managers flourish in these rough seas, happily charting new courses as new storms brew.
Development teams don’t fare as well when deprived of continuity. Reorganizing teams and re-prioritizing efforts at the first sign of trouble is problematic for a few reasons:
Engineers can’t be thought of as fungible resources that can easily skip between teams. Optimal team dynamics form slowly. Interactions take a while to mature and processes need time to be adapted to the specific needs of the team.
Great products don’t happen overnight either. They typically result from several iterations by stable teams. The first incarnation of any effort is almost always sub-par. This is as it should be. As Reid Hoffman said: “If you’re not embarrassed by your first product release, you’ve released too late”. The real magic happens after the first or second iteration when the team really starts understanding what the problem is and has acquired the domain knowledge and built the tools to attack it.
So how should you get the most of out your team in an unstable environment?
Balance the team: When the ratio between engineering team size to the rest of the company is too small, you create the capacity to generate many more ideas than can possibly be implemented, or even discussed fully. This results in endless distractions and prioritization sessions, and reduces critical focus on the work currently being done.
There are a few models for creating balance. One is to simply drive everything from the tech team, for example GitHub has zero managers and developers are 100% responsible for the product direction. This isn’t an option for most companies, but creating a engineering team that is appropriately resourced for the overall organization is.
Maintain Focus: Create a North Star for engineering teams by creating, communicating and repeating a strategy for your company and product. Define KPIs to track progress against the strategy. Stay focused on these KPIs for at least a quarter before iterating the strategy.
Limit Distractions: A colleague recently reminded me of a great quote from The Mythical Man Month: “the best engineering manager I ever saw served often as a giant flywheel, his inertia damping the fluctuations that came from the market and management people”.
Be the flywheel and keep your team focused on your strategy. Limit non-essential or off-track meetings and help cross functional teams focus and work tightly on active initiatives. Project rooms allowing face-to-face communication and tight teamwork can be extremely effective.
Empower and Encourage Ownership: Encourage teams to take complete, long-term ownership of initiatives and the artifacts (code) that they produce. Adopt tools that help reinforce ownership while maintaining flexibility (we use Gerrit at Gilt). Defend the team from the inevitable onslaught of requests to “re-prioritize” their current work that reduce ownership and focus.
Doing this isn’t easy, but as a managers our responsibility, perhaps our biggest responsibility is to make sure we have a strategy, to repeat it until people are tired hearing it and to do everything we can to maintain appropriate inertia around it.