Back to resources

Driving Clarity of Charter in a Large Organization

Managing Up
Reorganization
Ownership
Team Reaction
New Manager Of Manager

27 September, 2020

Jeffrey Wescott
Jeffrey Wescott

Director of Engineering at Splunk

Jeffrey Wescott, Director of Engineering at Splunk, describes how he introduced clarity on ownership between four disparate teams by drafting a charter that precisely demarcated who owned what.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Should You Stay Up to Date with Technical Skills As a Product Manager?

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, describes how she keeps learning hard skills to increase motivation and respect her team.

Alignment
Innovation / Experiment
Different Skillsets
Personal Growth
Ownership
Coaching / Training / Mentorship
New PM
New Manager
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Getting Creative to Land Your First Tech Job

19 January

Nani Nitinavakorn, the Sr Product Owner at Revolut, shares how she gained her first technical position, creating a direct method to apply for jobs.

Personal Growth
Ownership
Hiring
Strategy
Juniors
Career Path
Nani Nitinavakorn

Nani Nitinavakorn

Sr Product Owner at Revolut

Completing a Successful Reorganization within a Well-Established Company

19 January

Jason De Oliveira, CTO for more than 10 years, shares his experience completing a reorganization, implementing agile, and collaborating with multiple teams.

Alignment
Product
Leadership
Reorganization
Agile / Scrum
Jason De Oliveira

Jason De Oliveira

CTO at Kolquare

How to Recognize Traits of High-Performance From Candidates with Non-Traditional Backgrounds

19 January

Federico Fregosi, VP of Engineering at Contino, shares how he hired a candidate with an untraditional background and grew into a key player in the industry.

Alignment
Scaling Team
Onboarding
Ownership
Hiring
Federico Fregosi

Federico Fregosi

VP of Engineering at Contino

Embodying a Growth Mindset for Engineering Leaders

7 January

Balki Kodarapu, Director of Engineering at Shogun, provides some resources that he uses to broaden his horizons and expand his growth mindset through podcasts, books, and hands-on experience.

Personal Growth
Leadership
Ownership
Career Path
Performance
Balki Kodarapu

Balki Kodarapu

Director of Engineering at Shogun

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.