WEEK 41 · GOVERNANCE

Trace one funded decision back to the day security first saw it.

In separate rooms, technology and security each planned for their own best outcome, and the board got shown one strategy.

In separate teams and separate rooms, each entity planned its roadmap and strategy around the best outcome for itself. Never in combination, and never in a manner where one team's decisions make the other better.

Technology planned for the outcome it gets measured on, which is shipping the platform on time and under budget with as few people slowing it down as possible. Security planned for the outcome it gets measured on, which is a shorter findings list and a clean audit. Each one is a good plan. Put them side by side and you can see they were built to win two different games.

Then both plans go to the board in the same deck, and the deck calls it one strategy. That's a disingenuous process for the shareholders of any organization. Shareholders read that deck as proof that somebody weighed the platform and the risk together before spending their money on it, and nobody in either room ever did.

The two rooms do meet eventually, and the meeting usually opens with one sentence. We are doing something, please review the risk. Security reviews it, writes up findings, and the project carries on with a risk register attached, marginally safer and no better. Better was never on the agenda.

Nobody asks how the two sets of decisions could make each other better. A security requirement shaped at the start can make a platform simpler to run, and a platform choice made with security in the room can retire a control nobody wanted to operate anyway. Neither one happens while each team plans for its own best outcome.

We know the rooms are separate, so we try to align them with crosswalks and joint steering committees. Our desire to align still doesn't fit, and it never has. Alignment maps where two finished plans happened to land after the decisions were already made, and it never changes where either one went, however many people sign it.

It's disingenuous to the shareholder when team alignment and the myopic focus of engineers create risk nobody priced into the plan.

So, here's the MondayMove

Find one technology decision your organization funded this year that security saw only after the money moved. Write down what designing it together would have done for the project itself, separate from the risk findings, and bring that page to your next planning conversation.

One decision is enough. If everything on your page is a risk finding, you just ran the review again, late. Look for what each side would have gained from the other, whether that's the simpler build or the control that never needed to exist.

If you can't find one, look harder. It's there.

Friday Follow-Up

The page is the hard part.

You'll find the decision in a minute. Writing what the two teams could have built together, without writing the review again, is where it stalls.

MondayMove gives you one concrete action every Monday. FridayFollowUp closes the loop.

Each Friday, a short dispatch on what practitioners actually found when they ran the week's move: where they got stuck, what surprised them, and what to do next. Not sanitized case studies. Field notes. Practitioner to practitioner.

Monday's move asked you to find one technology decision funded this year that security saw only after the money moved, and to write down what designing it together would have done for the project. I'd already run it on our network, and Wednesday covered what came out of that. These notes are about where I expect it to stall for you.

You'll find the decision quickly. Most people can name it before they finish reading the move. The page is the hard part.

Habit will fill that page with risk findings, because risk findings are the only thing security has ever been asked to write about somebody else's project. Read it back before you share it, and read it the way the owning team will, as somebody whose project just got graded by a team that wasn't in the room. If every line describes a gap, you wrote the review again, and the other team will read it as one.

The team that owns the decision will push back, and the pushback will sound reasonable. Their design passed its review, it does its primary job, and they'll tell you the best design is always the target. All of that is true, and none of it answers what the two teams could have built together.

Don't argue the design. Ask what they needed from it, and write that down in their words.

Watch the reporting lines. If the owning team and security answer to different leaders, your page will go up two chains and come back down as two opinions, each of them reasonable and neither of them a decision.

Under one leader it lands as one decision. That's why alignment under one leader belongs at the front of this. It should be the catalyst, and most organizations never get it.

Some of you won't find a decision at all, because security saw everything. Check what "saw" meant. Reviewing a finished design counts as seeing it on paper, and it still left the how to one room.

Take the page into your next planning cycle and hand it to the team that owns the decision. Ask them to write the what for the next version of it, with no product names, and bring yours to the same meeting. Start with anything that carries real traffic and draws real attackers, and spend the first session on the what alone, before anybody in the room gets to say a product name.

Keep going. See what a week can do.

No correct answers here. This is practitioner-to-practitioner. The more honest the responses, the more useful this gets for everyone reading on Monday morning.

See you then.

Discussion