Enable Real Relationships

“Every company has two organizational structures: The formal one is written on the charts; the other is the everyday relationship of the men and women in the organization.” – Harold Geneen

If you are a leader and you currently are staring at org charts and considering alternatives, I ask you—I beg you—to rethink. It is highly likely you are digging in the wrong place to solve the issues that are in front of you; it is far more likely you feel the need to make a cosmetic change that establishes your authority, which is self-serving and will not help your team succeed. Don’t dismiss that last statement but think about it. Your team has as good a lock on how to organize to get the job done as you (quite possibly better). Every formal organizational structure has seams that your teams must manage through the formation of informal networks and relationships; so it is extremely hard to get an organization structure right. If you want to unleash the team, pick a “not wrong” structure and press; resist the temptation to tout your brilliance at putting blocks and lines on Visio or PowerPoint and reinventing.  Most of the time, it is a waste of resources, energy, and has the potential to disrupt the informal network. You know…the one that defines how the work REALLY gets done and will exist long after you are gone. 

Another program manager is starting a program. Susan has risen through the ranks and shown successes in several projects that have grown in scope as she flies up the structure. I, the functional manager for matrixed engineering support, am trying to pass on what I know about how we can be most effective in applying the lessons learned from across our multi-program, multi-decade portfolio to unleash the team. Based on our past relationship and her kick-ass leadership, I trust her implicitly. In this case, we are—of course—looking at a stupid org chart; it’s Susan’s “new” creation, a wheel reinvented, and my heart sinks. She has every good intent in the world to try to fix organizationally the problems she has seen in the past, and she feels a compelling need to be taken seriously as a leader and establish her level of accountability and responsibility. The org chart seems to Susan to be the right tool. 

I make a first attempt: “Susan, your team knows who you are. A few on your team have commented on how the company ‘got it right, finally.’ We know you are accountable for cost, schedule, and technical performance, so the buck stops with you. You’re in charge. Are we focused on the org chart because you really think it is broken and spending hours on it will help?” It takes some uncomfortable candor to get to the meat. Susan is focusing on this because it is a way for her to establish authority, both visually and actually. At the start of a complex program it is a way for her to be in control of something, and a way to signal to the team that they can have confidence in her. It is absolutely human, imperfectly. The first piece, that she feels a need to be in control, is a real emotion, not to be dismissed. In the Air Force, when a new base commander stepped in, we had a joke: “well, I guess the speed limit by the club is going to change again.” This was no joke, as there were always cosmetic changes made very quickly after a change of command, all borne from insecurity. The second piece, that she thinks this can build trust on the team, is not correct. The team instead wonders why we are wasting time on something that it will need to figure out with the boss’ help; that the real organization will be created by the team; it will be fluid, dirty, and impossible to put on paper. A not wrong org chart is essential to help initiate the first conversations about how to manage the seams; a perfect org chart is impossible, so pick one that is okay and press on. The relationships are what matter.   

Susan’s past problems were not due to organization. Oh, if only we could fix our problems by reorganizing, as every single one of the enterprises I have worked in would be humming by now! I imagine a Lion-King-like scene where I hold up the power point chart with all its text boxes and lines, and all my kingdom bows to its brilliance as I become the leader I have always wanted to be—ridiculous to think about how I have fallen into the org chart trap myself. Here’s the problem, though: it is impossible to find the right one, but quite possible to pick the wrong one. Therefore I prefer a leader pick a ‘not wrong’ one, because a good leader can do that, and it doesn’t take long at all. What defines a wrong one? 1) accountability is not precisely assigned/allocated; 2) there are diodes (one-way information conduits); 3) too many layers. If accountability for the same thing is shared between too many people, then nobody is accountable. If you have diodes or gates, then it takes more spaghetti lines for the team to work around them. If you have too many layers, then there are too many cooks in the kitchen, and I have seen teams in this situation stop talking altogether or putting in their own diodes. Given an org chart that suffers from these issues, choose another one that does not, but there is no need to spend the time to scheme, reengineer, and redesign on to try to get it “right.”  

Microtransactions in Engineering

“Famous quotes about Engineering are, annoyingly, mostly centered on individuals and not the team.” - Buster Myers      

Several years ago I was an Integrated Product Team (IPT) lead for a subsystem that was being designed for integration and operation in satellites. My perception from past work with Bill, the assigned lead subsystems engineer, was that he didn’t freely share important information. My perception had been created in a previous project where he had finished design, assembly, integration, test, and moved on to another project. Tribal knowledge went with him, and I needed it to succeed at my job. I would set up formal meetings and send detailed data sheets with questions and, in my opinion, these were ignored or rushed; I ended up writing him off and going it alone. With this new project, in a fit of brilliance on my part (not really—office space was scarce) I put us both in a shared office. We were in there for maybe 15 minutes together before there was an interruption at the door: “Bill, sorry but this should only take a few minutes. Can you help me with…” Bill tore his concentration away from everything (and me) and placed it on the person at the door; he listened intently and in that single conversation he both learned and taught. It was the most useful engineering conversation I had seen at the company, and it really did only last a few minutes. With three more such engagements over the next half-hour with different systems and subsystems engineers, I realized that I had never, ever just stood in Bill’s door to ask him my questions and dammit I should have.

A few things came immediately to light from my experience with Bill: 1) Bill was a master of his craft, more competent at this subsystem than I could ever be; 2) He loved to communicate and share information; 3) the formal structures for communication I tended to prefer at the time were a complete waste of time for pretty much everyone. He worked requirements, interfaces, staffing challenges, configuration control; he worked everything in and outside the systems engineering “V.” In meetings I would hear language like, “Bill and I worked that out already,” or “remember we talked about this last week and decided we were not going in that direction,” or “let’s use this meeting to work out the implementation details.” I can’t imagine how many formal meetings did not happen because of these microtransactions. Despite my need for structure and my propensity to try to design organizations for optimal communication, people in the engineering org were getting it done. Bill’s method for collaboration then became my model, and then “management by walking around” finally made perfect sense to me. It also made sense to me why Bill thought my prior requests for 30-minute blocks to answer 1-2-minute questions was met with ambivalence and frustration.

The creation of complex systems from technology components and a good pinch of black magic is what engineering is all about. What I learned over quite a few years is that this is best accomplished from a series of microtransactions: quick-hit opportunities to learn and teach to solve a problem and move on to the next one. There are big-rock things of course that process and formality facilitate, but they don’t typically involve the black magic piece. This black magic is composed of experience and learning; therefore, it is most effective when individuals are completely free to pound ideas against one another. Per Dr. Brené Brown, people need to rumble. There is no way to design this freedom into blocks on a PowerPoint slide, and any attempt is more likely to constrain the problem than it is to enable its solution. 

How to cultivate the informal network

"Innovation is the lifeblood of an organization. Knowing how to lead and work with creative people requires knowledge and action that often goes against the typical organizational structure. Protect unusual people from bureaucracy and legalism typical of organizations." --Max De Pree                

So leader, what should you do? It’s tough, because the leader must triage the health of the informal network—which most of your teammates don’t even want you to know about for fear you might constrain it. They are managing seams in the existing org structure, and there is enormous value in learning how they have done it without your help. As a leader, you must assess how effectively the microtransactions at the tactical levels contribute to your mission success. If these do the job well, then encourage and acknowledge the success, and invite yourself to play in that arena. If the microtransactions are unhealthy, then take accountability for it. It is not an organizational problem, but an expectation management problem: I submit that if the informal network is unhealthy it is due to a leadership deficiency and can be repaired only through leadership. Attack the causes of unhealthy networks to unleash the team and make it unstoppable. 

            This is what Susan and I started to focus on: to identify the root causes of the problems she had seen in the past, and none of them had organization as a root cause. She ended up still releasing her org chart, since she had spent so much time on it and since it was not wrong. But the team never hemmed and hawed about it, and the leader never really enforced anything about it, until she moved up and was replaced by someone else who felt he needed a cosmetic indicator of authority. Susan had shifted her focus to establishing a real foundation of trust, and she killed it! The team was able to build the relationships and engage in engineering microtransactions freely, which led to an accountable organization that was unleashed to do great things. 

           Some people will read this and think I am advocating anarchy. If this is you, you are exactly right. The formal structures and processes we put in place as leaders are necessary, but not sufficient, which is why you needed the team in the first place. Structures and processes (e.g. org charts) need to enable the free movement of knowledge, the leveraging of diverse ideas, and “rumbling”/healthy conflict that leads to learning. A level of anarchy is desired, as ownership and accountability require freedom to act. To be honest, leaders fool themselves and impede the mission if they overconstrain the team. The game is about finding balance between innovation and crushing souls; figuring out how to get it is the leader’s job and is nontrivial. Spending more than a few minutes on an org chart is dangerous to the balance. In the voice of your favorite TV cop: “Put the org chart down!”