Driving Clarity of Charter in a Large Organization

Problem

As a Director of Engineering at my current company, the outcome of a large reorganization was that I was accountable for a brand new area composed of four disparate teams that were all working in silos, as well as dotted-line dependencies that stretched out to other teams throughout the company. The first order of business was to get clarity on what we did and didn't own, and what our short-, medium-, and long-term charter was. The entire process included a lot of political machinations combined with deep-diving into some of the technology aspects, and building strong relationships with the product management organization. After that, it was necessary to get buy-in from my management chain about my vision for the area.

Actions taken

I talked to and interrogated the most senior engineers on the team in order to understand how the various things each of those teams owned aligned with the specific charter for the overall area. Those initial conversations allowed me to collect sufficient information to be able to delve into inventory creation and analysis.

After that, I created a spreadsheet with all of the various code areas for which we were accountable. This was non-trivial, as many things had ambiguous ownership, and a handful of things existed that no one recognized or understood. I had to conduct a thorough analysis to be able to differentiate what I was certain we owned and what I had questions about. The first questions I asked were to other leaders and peers from other areas (since I was trying to resolve any ambiguity around ownership). I also had to go up the management chain in order to try to get clarity. As often is the case, the higher up you go in an organization, the less clarity is on the specific details of things. As such, I was asked to come up with a proposal that would draw ownership boundaries. I included things that I believed would most closely align with our charter, and tried to shed things that felt like a distraction from it. For anything that I was proposing to shed, I wrote-up a detailed explanation as to why.

I socialized the proposal with my direct manager, who was supportive of it. Then, during my monthly skip meeting with my manager’s manager, I received unambiguous support from them, too, and they committed to talking to their peers who were impacted by my proposal. I was on hold while all of those conversations were taking place. They would often reach out with questions, but since I had done the detailed inventory and analysis, and had written down a thorough proposal, these questions were easy to answer.

Once VP level people were on board, I could share the proposal with other people at my level who were not in my reporting chain and figure out how to move from ‘who owns what’ to ‘where we are and where we should be’. Because I was shedding accountability for a few things that were previously perceived to be within my area, it required loaning resources to at least one team to ramp up their engineers on things for which my area had most of the expertise. Also, I had to inform them about things we owned but we had no idea what they were about and therefore were a potential risk area.

The proposal underwent some minor iterations based on resourcing, availability, and budget and I tried to be fairly flexible with it, while always holding on to clarity of charter. Having precise explanations of the “why” for each ownership item helped me through the iteration process since I was able to have a clear rationale behind every change.

The whole process took about seven weeks, which felt like an eternity because it all happened right after a major reorganization from which the dust was still settling.

Lessons learned

• It takes time to do a deep inventory and analysis when you are new and don’t know much about the area you are stepping in. Be patient with yourself and be willing to admit your ignorance to everyone who knows better than you. Be humble and keep asking questions and write everything down.
• When you go up to higher layers of management things start to move slower. For example, from a calendar standpoint, you will need multiple executive assistants to find time when executives can talk. Patience is required.
• When things are unclear, be cautious about what you are committing to. My efforts coincided with the beginning of the planning cycle and people would by default ask me if I could deliver something and I was very careful not to commit since in some cases I wasn’t even sure that my area would be the long-term owner of the thing in question.
• Nothing ever is done! Things are always evolving, so it’s important not to get frustrated with changes. Taking your ego out of it and not being emotionally attached to the exact outcome is important. The proposal should be considered the starting point for a conversation, not the end goal.
• Asking for clarity from people up your management chain is important. Communicating upward in terms of risk rather than emotion works well. Distilling details into risks enables busy executives to easily analyze different decisions.
• At the first line of management, you must know all the details, while just one level up the leverage you have is three to six months out. Decisions you are making are much murkier and will take more time. While people are ready to adjust to a broader perspective, they are often impatient about how long things take.
• Winning in middle management is saying “yes” as much as possible, but only when you can deliver on your commitments. And, when you say, “no”, being very clear about why is just as important.