I was talking with someone the other day about my time as (Interim) VP of Engineering at Socialtext. Did I enjoy that? The question was framed like this: some people just like doing things and not dealing with the social aspects of management. But I wonder, are they really much different?
Originally published by me on March 25, 2009 and reprinted here as-is.
Software development is creating, maintaining, and evolving a system. Use whatever action verb you like, you are working with a system. That system can be made better or worse by your actions. If you fix a bug the system is better. Remove a networking bottleneck? Better. Introduce a needless database query on every iteration of a loop? Worse.
Software doesn’t work in isolation. The system is bigger than that. If you increase the memory requirements for your software the servers had better have enough memory to manage it. If you rewrite your code in Python a host of changes are required to make that change possible.
How are teams much different? Leading a team requires the creation, maintenance, and evolution of a system. Again, you can make it better or worse. Help a peer solve a problem with a better tool then your system is better. Reduce needless process? Better. Introduce a needless process on every iteration of development? Worse.
I think both people and technology are irrevocably intertwined. In fact, hacking on one and not the other will cause the performance of both to suffer. This is called Sociotechnical Systems Theory.
Joint Optimization
A team survives - and eventually thrives - through the joint optimization of their sociological and technological systems. Improving one alone often leads to recessive tendencies in the other. The nature of a team is the symbiotic relationship between its people and technology systems. Success can’t be realized by improving technology alone.
This concept is often hard for everyone. Technologists find it easy to ignore social aspects of an organization. Non-technical specialists are reluctant to consider the artificial reality of technical objects like software. So it can be hard to consider both technical and social aspects of a system.
The delivery of meaningful value to customers requires the actions of both people and technical objects. One can’t improve without the other. Technical achievement is equally as important as social advancement.
People are (part of) Technical Strategy
Hacking on the social realities in your technology team has strategic value. A healthy team can do more than generate fantastic technological innovations because a healthy team can more accurately assess the environment they’re in. A viable business strategy can’t simply focus on organizational capabilities as most technologists are prone to do. The environment your team operates in isn’t the primary strategic factor as many non-technical specialists see it.
The decision isn’t either/or among organizational capability and environmental reality. The winning strategy is both/and: react to environmental realities within the context of current and improved organizational capabilities.
The API is Different
The major difference between people and software on a technical team is the API. You’re still debugging, refactoring, creating, evolving, and removing what you don’t need. As a technical team leader you need to talk to both types of interfaces. The API is very different for debugging people vs. debugging software.
If you want to build world class software you have to build a world class team.
This is also why it’s hard for a star programmer to become a star manager. They never spent time learning the People API.
Footnote
Some of this thinking was done as research for a previous company. I was asked in appropriately vague terms how to fix our software delivery process. The pain was that it took months to get even the smallest changes to the customer. When I searched for the root of the problem it became clear there were two intertwined problems: one technical and the other social.
Half the company was looking for a quick technical fix that would make it all better. The other half wanted to add process to over come the social issues. It was obvious to me we would have to fix both if we really wanted to solve the problem. Any solution that ignored the fact that we were a socio-technical organization was lacking.