Chris Lucian

How do we make management more safe, lean, transparent, and empowering? What if you took these three concepts to their logical extremes and tried them in practice? When we began to scale the Software Development Department, we were faced with a question. Do we incorporate managers? The fact that we had the option to not do so is amazing in of itself because of typical organizational norms. We as a team decided no was a  great experiment to try. We have gone through 3 major phases with the flat structure concept. The 1 person Director/Manager concept, the management Kanban, and finally the Home Owner Association management system.

The status quo - Properties of traditional management

I wanted to kick this blog off by reviewing experiences that I had at other companies that influenced my thinking on the manager employee relationship. I want to clarify that I do not think the concept of a manager is a bad thing. I do however believe that having managers make it very likely that things will become less safe, lean, transparent, and people will become less empowered. There are probably thousands of blogs out there that talk to the idea of bad management, but I think one thing overlooked by many of those is the idea that problems are not necessarily the fault of the manager. It could very likely be the system set up around them that is the problem.

Safety

At a different company, when I was asked to lead a team, developers working with me flourished. The owner of the company would praise our work and I would get rewarded for it. The side-effect that I think he was not aware of was the fact that this praise caused other managers to thrash, yell at, or dis-empower their employees. This caused the other managers performance to drop, in which other comments were made about the stark contrast between us. This built up a resentment for my team and I. This is a great example about how having a clear-cut management hierarchy can be disruptive to an environment.

I have also seen the best ideas die due to a manager filtering them out in communications to their managers. The people that care the most and are best fit to solve a problem are effectively stopped from contributing because of the opinions of their manager.

Lean

If you made a value stream map of any managers involvement in a team, and you related their activity to the 7 deadly wastes, what would show up? How likely are they to inject unnecessary process, especially when a request of the manager is taken out of context?

A good example is a director asking a manager to collect a metric. I have seen this very request interpreted as "collect the metric no matter how expensive it is to collect".

I have seen managers act only as a conduit of information, effectively playing telephone with everyone involved, making the information slightly inaccurate.

1.     Overproduction

o    Managers just like any other HIPPO can inject items into the backlog based on personal preference with no real feedback from users.

2.     Inventory

o    Managers may hold back releases of software based on back market information or a tendency toward horizontal slicing.

3.     Waiting

o    Managers may wait to deliver information to the team until it was too late because of some expectation to reduce transparency.

4.     Motion

o    Managers may ask for un-necessary steps in a delivery process

5.     Transportation

o     

6.     Rework

o    Managers could cause rework by preventing the team from trying or implementing TDD and a core practice based on their fear to go “slow”

7.     Over Processing

o    Managers could force the team to spend too much team planning, analyzing, or reviewing before moving forward.

Transparency

There was a manager in an organization that I worked at in the past that closed his door and then proceeded to yell at his employees. He seemed to believe that because no one could see him yelling at them that the people in the officer could not hear it. It became such a toxic environment that everyone felt miserable for it.

Since managers are consulted on all things “private” for the company, all too often we are placed in a situation where we must keep information, though it is important to the team, hidden. If these items could be more transparent then we could improve our decision making.

Empowerment

Managers can give and take away power in these environments. Without safety we cannot achieve empowerment. Anyone that feels unsafe will act out of fear which builds risk for the business.

The one Director/Manager

When I transitioned into the director position, I had the authority to implement managers in the group. I asked the team however if we wanted to do managers in the group or if we wanted to try a flat structure. The team unanimously went for the flat structure. Initially I did spend time figuring out what was acceptable to delegate and what was necessary to execute myself. Personally, I wanted to pursue a servant leadership role on my team. I believed the team knew the best way to work and did not want to interrupt their success even though I would no longer be available as often for mobbing activities. My top priority quickly became advocating for the successful approaches that emerged from the team and spreading positive ideas about the team. I read books like “Made to Stack” and “Power of Habit” to help in this initiative.

Quickly I realized that the number of repetitive tasks were becoming overwhelming. Some of them were simply requests for transparency outside of the group. My initial response was to automate these requests which lead to positive outcomes. The Gherkin 2 Gantt project emerged as well as our CI/CD “Guitar Hero” chart. Later on the check-in frequency impact chart, and 2 day master & branch divergence report.

With the portion of the work related to team productivity transparency out of the way other management work crept into focus. It is almost like Mazlows Hierarchy of Needs in a management context.

Management Kanban - the pain of unbounded growth

Once there was a big portion of our needs automated, we now needed a way to allow everyone in the department to easily participate in management tasks. I wanted this process to be a pull system so anyone could participate if they wanted to and saw value in it. The process however had a few major flaws.

It was not as high as I would have liked, this put people in a situation where when they took as task they became souly responsible for the outcome. This made their participation a single point of failure, which implied risk of high impact failure.

At first I believed this process was lean because it was a practice of a pull system but what happened is we fell into the lobster growth situation. Lobsters grow forever, they are effectively immortally young, but they die when they become too big and their shell becomes difficult to move. This is what or management backlog was doing to us. Out management work grew in an unbounded way reducing the amount of work our software developers ended up doing.

Transparency

The management Kanban was very transparent. People would attach their names to tasks they took on so you saw what everyone was doing and how long it was in process. This was extremely effective regarding transparency and helped us move away from the process when we saw how many people were engaged in the perceived management needs.

Empowerment

I believe the Kanban board was half way to the level of empowerment we sought. The team could work on anything that I though might be a management activity but it was rare that people on the team would add any tasks themselves. Realizing the team could have more agency on their work environment was a large influence on the next iteration on this set of needs.

Overall, we felt the management Kanban was a useful tool while we scaled but the later to be obvious flaws made was for the next and most recent idea.

The Home Owners Association

People outside the USA seem to give me a blank look when I talk about the concept of Home Owners Associations. These community regulatory bodies exist when a series of houses get built and a HOA is put into place. These usually govern the rules of the community, anyone in the community is allowed to attend meetings and participate in elections, however it is common for a small portion of the community to participate in making these rules. Regardless of whether or not you participate, by buying a house that is part of an HOA, you are agreeing to their rules, and the rules created by others later down the line. If you want to change you HOA you need to participate in the meetings. This is where my moniker “Be there if you care” comes from.

We implemented the practice with a few things in mind. We wanted to create an experimentation cycle on all processes and rules within the team. We wanted to create an accountability group for each of the actions that each HOA enacted. We did not want any one person to be strictly responsible for the failure or success of an HOA decision.

We started by creating a role of the HOA Facilitator. Each HOA could have up to 2 of these people. This pair is responsible for creating a cycle of retrospectives and actions that the process would undergo until they did not feel needed anymore. The HOA Facilitators are only responsible for putting together an optional retrospective on a process and finding and following up with delegates to carry out actions that emerge from the HOA meetings.

In each retrospective we look for one action item and only one. This way we can have a follow up HOA retro to see if the expected results were realized with the new process.

Safety

Since the days of the management Kanban I believe that safety has improved. Since the HOA facilitators find delegates to carry out the tasks that come out of the retrospectives there are multiple people involved in following and making it safe to take these tasks on. It ends up being a peer supported accountability group. In the end if everyone forgets the task then it must not have been that important in the first place. The team together is responsible for making sure the process improves over time. Since the decisions about how to move forward are based on interest groups, the team together shares the responsibility of the outcome. We do the best we can do with the tools we have.

Lean

When an HOA forms, it is usually on a process or rule that needs refinement. We do not look for perfect, only better. For example if we wanted to improve our budgeting process, someone may ping the HOA facilitator for budgeting and request a meeting. There will be a retro, a new action item is defined and delegated. Budgeting happens. A follow-up retro is done. Then the process may be closed if there is no follow up change. This has a few side effects. The meeting is called only when needed, and follow-ups last only if necessary. This way the expansion of the management work gets regulated by the frequency of HOA meetings.  There is also an HOA for the HOA process meaning that rate limiting of HOA meetings can happen as well.

Transparency

Since it is extremely unlike any one person would change a process in an HOA without input from anyone else, the result is total and optional transparency. See as much or as little of the process as needed. (Post HOA decisions to slack/teams?)

Empowerment

When the HOA process replaced the management Kanban an interesting thing happened. The types of changes happening to the team changed from a task level to a process level. The execution of related tasks ended up becoming a detail of the grater evolution happening within the team. We have new experiments all the time and each one creates a variation of an older process. After adopting the process, the ability for any one department member to effect relevant change increased dramatically.

                                 

Keep exploring the unexplored potential!