I’ve had the privilege of working with five very different CEOs over six exciting years (things change quickly in Startupville). I’ve learned a lot from each one. But I’ve also spent those six years learning a lot about the craft of software development. Some of the best lessons I’ve learned about executive leadership were masked as lessons about software. So, while I think organizations often mistake great software engineers for potential managers (and exchange their most productive coders for mediocre bosses), I want to make the argument that learning to develop software and internalizing the lessons from software architecture mistakes are great ways to learn about leadership.

One caveat before I start: when I talk about software development, I am referring to something bigger than coding. While Codecademy is great, I’m not suggesting that learning about loops will help you manage people. I’m talking about the lessons learned in working with a team to craft and maintain a large repository of software.

Small objects

The first (and arguably most important) rule of SOLID is that objects and functions should be small and have a single responsibility. The same can be applied to teams. Of course, at large organizations, teams will be large, but software engineers can think of those big teams (e.g. the sales team) as high level objects that delegate to lots of smaller objects (e.g. the pacific northwest regional sales team). So the big team’s single responsibility is managing all of the smaller teams, and the smaller team’s responsibility is closing deals!

Any software engineer worth her salt will look at this hierarchy of delegation and assert that each smaller team must conform to a uniform, simple interface. For example, each smaller team should report their sales numbers in a universal format and should be held accountable to the same simple metrics. That’s not to say the Pacific Northwest team should necessarily have the same goal as the East Coast team, but they both should be held accountable to revenue. In other words, the return values will obviously differ, but they should all return integers.

Naming is hard

If you’re having trouble naming an object, it’s probably because the object has too many responsibilities (or the responsibility it has is too vague). The same can be said for meetings, task forces and projects. Good software engineers often obsess over finding the perfect name for an object. It may seem like a waste of time, but if every meeting you hold has a concise and intuitive name, you’ll benefit from countless subtle efficiencies. For example, if you put “establish leading indicators of churn” on the calendar and invite your team, people who don’t need to be there can opt out with a simple, “I’m focused purely on user acquisition this quarter, so I’ll sit this one out.” When the meeting invariably takes a tangential turn, any participant can ask, “What does this have to do with establishing leading indicators of churn?” As the organizer, you don’t have to waste time putting together a robust agenda; the title is the agenda. The meeting has a single responsibility.

Test all the things

As a Rubyist, I’m cultish about testing. Maybe in less dynamic languages testing is less important, but in the programming language of business management, testing is crucial. Building on the Single Responsibility Meeting principle, every meeting should end with a test: Did we achieve our singular goal? Unlike Scripted’s frontend integration tests, this test should be deterministic. Any attendee of the meeting should be able to run the test and come to the same conclusion. TDD may be dead, but that doesn’t mean you can’t have Test Driven Meetings. If I were running the example meeting from above, I would start with a simple test: “Do we already have a list of leading churn indicators?” If the answer is yes, meeting adjourned! If the answer is no, we’d have the meeting and run the test again.


There are all sorts of other applications:

  • Knowledge silos exist in marketing, sales and customer success teams. Encourage your most senior sales rep to “pair program” with the new SDR by hopping on a call together.
  • All work can be broken down into stories. Agile methodology isn’t just for product teams anymore!
  • Blameless postmortems offer a compelling outline for organizational accountability and employee development.

What do you think? Are there other parallels between software development and organizational management that we missed? Let us know by emailing goats at scripted dot com!