A Sweet Spot!

In the essay, Balancing Control and Self-Organization to Avoid Heat Death I said that there is a need to strike a balance between controlling how individuals and teams work and just letting people do their own thing.  Stated slightly differently, there needs to be a balance between autonomy and control.

Finding The Sweet Spot!

In a world where organizations like Theranos (over control) and the City of Flint, Michigan (laissez-faire crisis management) exist, organizations have to find a way to make sure they attain their goal without killing the company or injuring their customers. A framework that guides how workflows and decisions are made provides structure so that decisions can be made when a crisis occurs (crises are inevitable). Too much or too little control makes decision making more difficult when a crisis occurs. Every organization has to find a balance between control and autonomy. Every organization and team will have a specific Goldilocks answer. This is true for whole organizations as well as software teams that have embraced agile frameworks and methodologies.  One size does not fit all without a bit of tailoring. This premise is not the controversial part of our last essay, the problem is that the word control bothered some of the readers.

The several readers that I discussed the essay with had a problem with the term control.  The problems sort into two camps: those that suggest that the satisfaction of the development team is paramount (the happy people are very productive argument), and those that suggest that delivering functionality is all that mattered (the ends justify the means argument).  Both camps felt that control was a constraint that did not apply to how they wanted to work.

Merrian Webster defines the verb control as “determine the behavior or supervise the running of.”  No software organization (more than one or two people) exists without some mechanism to guide what is delivered and how work is done. Even the more avant-garde forms of leadership such as Teal and Holacracy have feedback and control mechanisms that are designed to keep teams on track. The argument to eschew control seems like a lack of understanding of why teams and organizations need to be both effective and efficient. 

The goal of control in software development is to enable teams to work as efficiently and effectively as possible. This how software development firms make money and internal development firms make sure their CFO does not outsource them for cheaper people. Efficiency and effectiveness means that the solution delivered is the best solution possible (right stuff, done correctly) at the lowest total cost. The definition of the phrase, “efficiency and effectiveness”, includes the required quality of the solution and the impact of any change in staff turnover.  The impact of changes in the process that impact, efficiency and effectiveness, can be measured and refined over time (inspect and adapt).

Adopting one or more of the myriad rough frameworks, examples include Scrum or Kanban, provide a basis to control the flow of work without micromanaging.  Frameworks also provide a tool to align how work is done to an organization’s goals and principles. Alignment to the organization’s goals and principles helps to remove the need for heavy-handed control that will lead to heat death. Given that no single framework is perfect for every context,  there is a need to perform data-driven experiments to see whether changes to the framework to improve their efficiency and effectiveness. Finding the balance between autocratic and laissez-faire leadership approaches, between heat death and gray goo, requires a framework to establish alignment with the organization’s goals and the autonomy to experiment to adapt to the team’s environmental context.

Next –  Experimentation and Continuous Improvement