Voluntary Complexity

Right around the addition of the 50th person, something often goes awry in a startup company.  Between 30 and 50 people, I’ve seen it happen that the group loses the ability to feel like one team – to cluster in a room or a Slack channel and include everyone in the conversation.  Teams and roles become more divided, and just around 50 people a threshold effect happens.  Not everyone knows what decisions are being made any more.  The “why” of a decision becomes something harder to discover.  And all of a sudden, every piece of information comes with an invisible tax of figuring out who needs to know.   

What can happen at this point is that the self-directed, fast-moving engineering team can become a little less certain of what they’re doing. Each person is still doing roughly the same thing but with less ability to see how it fits into the whole.  And from the top, it becomes much harder to see the details of the decisions being made and why people are doing what they’re doing. 

At this point, there’s still all the start up energy, the intelligence and enthusiasm for the mission, the desire to do something excellent together, but suddenly it can become hard to trust that we are all doing the right things. Compared to the “good old days”, an immense amount of energy flows into internal communications.  

I’ve seen organizations stumble at this point by putting in damaging amounts of process but it seems to me that the right path is to refrain from controlling the details of every leaf of the tree.  Rather, build the structures and cadences of communication that allow people to discover for themselves where their particular contribution and talent fits into the big picture. The roadmap becomes a guiding document internally, and perhaps for the first time, so does the org chart. 

One management tool that becomes more important is process documentation, not to be a straitjacket but to help inform and socialize, this is how we do things here. The patterns you’ve chosen for development and deployment, for handling customer problems, for when and whether to publish information, and others, reflect the values and core concerns of the organization. The more they’re shared, the more the detailed decisions can be trusted to be the right brushstrokes to paint the picture – and the more all the new people that your startup would like to include can join in and make quick and independent decisions with confidence that they’re doing the right thing.  

Judging from the job descriptions I see for management roles, a lot of people think that a “hands-on manager” should be making pull requests and writing production code.

Even managers have a finite number of hours in the day, and need to choose where to focus their time and attention The small slice of code they could be implementing will come at the expense of bigger picture work – building relationships with stakeholders, explaining the relationship between business problems and the work the team is doing,  being available to listen when someone is having a problem, and all the other bits that go into the sensemaking function of a manager’s job.  

It’s perfectly understandable that those activities hardly look like “work” from the point of view of an individual contributor engineer.  Many of us who have moved from engineering roles to management struggled with that at some point –  how do we  measure our own contribution when there are no lines of code to count and JIRA tickets to close?  The problems headed off that didn’t happen, the employees that didn’t leave, the introduction we made that blossomed over time into a cooperative relationship  – we can’t see these clearly at the scale of a day or a week.

 But it’s something of a red flag when senior management doesn’t appear to recognize management as a discipline itself that needs time and thought to flourish. Mapping out where we’re going and making sure we have the tools to get there is not a part time task, especially in a large organization,. How do these managers have time to code?  The things they are leaving undone invisibly slow down their teams more than the velocity of the features they ship.  Then, the code and tasks that they’re involved with visibly block other engineers when their attention isn’t present. 

But it’s more complicated than that.  Managing a technical team does come with some responsibility to understand what work is being done. Being able to do the work yourself is not the bar but being able to provide meaningful feedback to plans and to individuals as they grow is necessary . Managers, too, have to keep growing in technical understanding, and learn more about engineering – even as they hone the craft of management.  Even when we’re not first line contributors to new tech, the technical empathy that we develop pays off in the relationships we can build with our teams.  

What are some good ways to keep technical skills fresh without writing code for new features? Careful and critical reading of the design documentation that your team is writing is one important element. If there are areas where the decision-making is unclear, that’s an area to dig in. Pair programming often has a teaching function, and that’s just as valid for a manager as for a new hire.

A different approach is to write some code that’s not on the critical path. Maybe there’s some tools you need for yourself, data analysis or reporting.  Struggling through those can help develop technical empathy.  Another way to do this is to write some test code. You’ll see the internal workings of the pipelines your team uses without slowing down necessary releases.   

Every now and again I pick up a personal coding project. This quickly reminds me how much skill and practice I’ve been missing as I’ve concentrated on other things!  

All these things help me keep a technical oar in the water, if only to remind myself of how hard the engineering work can be. Hopefully those experiences will keep me from eliding the critical details that go into appropriate designs and accurate estimates.