This is about something that I wasn't ever able to explain well until recently. I've been using the same approach for a long while, but making it understandable was difficult.  I don't know if this achieves that. 

The key that unlocked the attempt was applying something I learned a while ago, and that I say a lot about my own processes, which is the next header line. While discussing what I was trying to get across with some people, I realized that what I was actually proposing was "go forth and Harry Tuttle your company" and honestly, that's probably the best possible metaphor here. Anyway, that thing I say too much: 

The purpose of a system is what it does

This is one of the things that I say often in my professional discussions, obnoxiously frequently in political/societal discussions, and at all times it is the foundation of my analytical efforts.

I do not care about the intended purpose of a system. I care about what it does. 

I encourage you to feel the same. You will occasionally find people who say that it's important that we care about a system's supposed purpose instead of its demonstrable purpose. In general, those people have a vested interest in the system's current impact not changing.

This focus of concern is probably fairly obvious to you. The implications may be less obvious.

• Most systems are tuned for intended purposes that are not the system's actual purpose
• Many systems have stated goals that are orthogonal or hostile to their actual purpose and demonstrable impact
• Many, if not most systems have metrics being used that aren't well-correlated with the system's actual purpose
• Many, if not most (if not actually almost all) systems are being fine-tuned and managed in ways that do not, and other than accidentally, can not improve the observable outcomes

This, obviously, is a Problem™. The usual solution is to work harder on correcting the output. Sometimes it's a whole bunch of "let's figure out the correct metric so we can measure what is happening." Sometimes it's someone doubling down on the selected or obvious metrics. Sometimes it's "accountability" impacting people's performance reviews because the system they work in isn't doing it right. This is all completely wrong, and it is also why this problem is so common. You have this problem because you have mismanaged the system in question. Applying more management of similar intent is only going to make it worse. You can't fix bad code with more code; you can't fix bad metrics with more metrics.

Are you yelling at me?

From this point, I'm going to be fairly adversarial in tone. Try to avoid reading this as me yelling at you. I'm yelling at your execs, at my execs, at every exec either of us have ever had. I'm yelling at the industry we exist in and industry in general. I'm yelling at the forces that market capitalism focuses upon us. I'm yelling at the banquet hall ceiling about this turbulent priest and no knights are about to walk in then out again. I'm just yelling, but I do have a point.

OK, let's get weird 

Managing an organization to the goals of the organization is some extreme "skating to where the puck is" bullshit.  Knock it off, immediately. 

Stop trying to make complex mechanisms do what you want in ways that make sense to you.

Start trying to make complex mechanisms exhibit the foundational attributes necessary for the thing you want to happen regardless of what else the system is supposedly doing. 

It is, unfortunately, sports metaphor time. Let's stick to something that we relatively simple like "track." The athlete wants to win. Does the coach manage towards "winning"? Does the coach manage towards foundational elements, and assume that winning is a byproduct thereof? Is there a split? Now let's strain this poor metaphor. What if it's a relay race competition with 100 competitors per team? Is the coach going to manage to "go win" or is the coach going to manage to the fundamentals of what a winning team looks like?

Answers are pretty obvious, right?

So why the hell are you trying to manage a security team to "numbers of reviews" or "ticket closure rate" or "how long a consulting ticket takes to get to done"? Do you think any of those lead directly to "winning"? Do you think any of those help with retention, which is undoubtedly your actual hardest problem this decade? Are you creating metrics based on "how annoyed my exec peers are with me" instead of "how healthy this security team is"? Yes. You are. The question is: "Can you make yourself stop doing that, and actually lead your org as if it is what it is, an organization made up of humans?"

Uh wait what?

Define for me what a successful security team looks like. What it feels like. Define for me what the vibe is. Define for me how people talk about that one team they were on that just fucking worked. Yes I'm serious. I'm stone-cold, dead serious. All of your metrics are causing you to push effort and people into things that aren't actually improving the things that cause your metrics to improve. Read that again if you need to. OK fine, another metaphor:

Artificial metrics are flying by instrument. They're individual "better/worse" dials that in amalgamation are supposed to tell you which way things are going, as long you are paying attention to the correct combination of them at the correct moment, and don't over-react to the feedback loops and crash the whole thing via a PIO. Instrument-only flight is harder than visual flight, it takes extensive practice, and the mistakes have worse repercussions.

You can instead choose to just fly visually. It's easier, it's safer, and it'll get you where you're trying to go. The thing is, your entire industry thinks it's impossible, and worse, they think it is irresponsible. They're kinda right. You have to be good at the innate skill of flying, instead of the skill of navigating by instrument. Guess which one the "become a manager in tech" system produces. Bonus points: recognize how that is itself a PIO. 

Bonus Bonus Bonus points: Consider that if you've learned the skillset of visual flight poorly, and you don't use the instruments to correct yourself, how will you ever know it's going wrong in time?

Yea, the thing itself is easier to do this way. The thing itself will produce better results when done this way. You cannot hire fools to do it. You have to actually hire for emotional intelligence and the ability to connect on a personal level with all your hard-skills engineers. I do actually know how to do that but I won't ever write that one down. That's my whole secret.

OK so, confused? Is this where I sell you on the self-help book and the associated cult membership? Nah. 

Integration

You're already routinely discussing terms like "emotional intelligence" when talking about leadership and management skills, even with the most obnoxiously "i am my code" people you know. I'm asking you to take those ideas and apply them as if they're primary skillsets with important uses, instead of something that's "useful for keeping the employees feeling like you care." I'm asking you to set aside the inherent sociopathy in managing people as widgets while dealing with them as people. As is often the case in all these posts, mostly I'm asking you to reject cynicism. Emotional intelligence matters for every single thing about managing humans. Why wouldn't it matter for managing your team's collective direction and output? 

What I'm getting at is that defining how you run your org should be based on those soft skills that actually affect how the people who make up that org interact, rather than what fits cleanly in a ticketing query. The query can tell you if your org is doing the things you think it should do. It cannot tell you if your org is functioning correctly, healthily, or sustainably. If you manage to the ticket metrics instead of those things, you will lose those things, and never quite understand why.

WTF I cannot put "team vibe" on a dashboard

Not with that attitude you can't. Yea, it is gonna be hard. I'm not trying to say this is easy. Your company has processes in place to make sure you don't do something weird like this. You're going to have to work around them for long enough to prove that you have a point. This is a subversive strategy. This is the Harry Tuttle method of organizational management repair. If you're lucky you can define this well enough that your own management layer can give you a window to prove it out. You won't be. You'll need to prove it out without pre-clearing it a few times, probably in a few places, before people accept that you've got a knack for this.

You won't have people crediting that the thing you're obviously doing is what you're actually doing. In general, other managers will view this as being unfairly manipulative since obviously you're misleading your people about what the real priorities are and how you will help them achieve success through them. Ain't nobody ever going to approach you to say "hay your team metrics are great and everyone wants to work on your team and you haven't lost any engineers all year and what's your secret?" They're going to ask your boss how long they will let you get away with running a good feelings daycare. Gravitas is the currency of tech engineering management, and you have to deliberately disclaim it at every opportunity. It's hard.

What matters for your team/org's success is the fundamental human relationships, comradery, esprit de corps, support and space-curation, and especially, all of the prior while treating-em-like-adults. Those things make up the totality of why people want to work on your team and are excited about working with and supporting their peers. These are not invisible things. These are things you can pay attention to, structurally. These are not things you can quantify with numbers. You're going to have to get comfortable with forming, expressing, and defending opinions based on things besides "data." Not because you don't have data, but because you don't have quantifiable numbers that represent themselves, and our industry is poisoned into believing that only such things are data. We've got thousands of years of evolution helping us understand how group dynamics are flowing. Yes, using that is a skill set. That's my point. Build and use that skill set. Learn how to read people's reactions. Learn how to understand people's motivations. Learn how to see how people work in groups and as individuals. Do the work.

Cheery "You can do it!" motivational section

When someone says "what metrics do you manage by?" I say "mostly feedback in 1:1s, career conversations, impact feedback on my people from their peers, and to an extent, retention." When they ask "how do you quantify those things?" I ask them "why the hell would anyone try to quantify those things?" 

Even the most self-deceiving engineering orgs, insisting that they make always their decisions on quantifiable data, do most of their ratings and promotion decisions based on loosely-defined statements of support and feedback forms. Objective decision making about subjective human performance is, at best, a beneficial fiction. I submit that the benefits have long since expired.

Everyone has opinions. This leads children to think that all opinions are equal. Look around you, that is demonstrably not so. 

Someone promoted you at some point because they thought that your opinions are usually right. Take a firm grasp of that and your confidence that long-term, the people matter as much as the mission. Forcefully reject all the cynical nonsense they try to sell you as pragmatism, seriousness, managerial gravitas, and lead. Lead by demonstrating that the people are the most important thing. Lead by insisting on good, supportive, healthy culture. Lead by demanding that people treat each other and themselves fairly and respectfully. Make that team a thing that those people will talk about being the best team they were ever a part of for the rest of their lives.

The work will happen. All those outputs you were worried about will flow in droves. If you have to, you can build a dashboard of nonsense based on the quantifiable outputs. Just don't go mistaking the numbers for what matters, or you'll lose what actually matters, and then you'll lose the numbers too. 

Bonus bonus bonus bonus bonus points section:  How would the company overall perform if it treated customer health/growth the way I'm saying you should treat employee health/growth?