Three impossible things before breakfast
How I chartered a successful security team by doing the opposite of the obvious.
In Through the Looking-Glass, the White Queen tells Alice she's sometimes believed as many as six impossible things before breakfast. When I chartered an Engineering Security team at Tes, I only needed three. Each might look like a mistake, the opposite of the obvious. But each is a reason the team worked.
I was a staff engineer at the time, and I'd pitched a small team to raise security across a set of fast, autonomous product teams. I've written elsewhere about why I chose that shape. This piece covers the chartering of the team. Because how a team is set up can decide whether it ever gets to win.
We had six months to prove the team was worth keeping. Plenty of time to get the direction wrong. So here are the three things I believed before breakfast.
Impossible thing: I let another team write our to-do list
When I began exploring how to introduce clearer security expectations, I explored more of my organisation. And found a wall.
On the far side of it sat the people who knew the most about risk: Information Governance, experts in external threats, compliance. Owning the kind of trouble that could sink a company. But Engineering didn't really know them, and they didn't really know engineering. Two organisational and Informational Silos, almost entirely disconnected from each other in the day to day.
And how do you deal with that? You could fight it: demand they talk to you and work with you. Or go around it. Build a parallel version of their knowledge and leave the wall standing. Fighting makes enemies of the people you most need. Going around leaves the silo where it is, and doubles the problem.
I did neither. Instead we wrote the new team charter to say that work would be prioritised by the Information Governance team. The other silo.
I expected that would mean the team would gain input and information, but I got so much more.
It gave us a reason to be communicating every week. Not a kickoff wave, an ongoing conversation about what we all cared about. They set what mattered and we worked out how to solve it together. And the conversation never stopped.
Rather than knocking down the wall, we first became the connective tissue. A routing function to link up these experts and the engineering teams, when there were questions and issues. After a few months the product teams were shouting out directly to the experts in the spaces we had created. We had become the glue for a new way of working.
The wall didn't get knocked down. We put a door in it, allowing traffic through it every day. You don't break a silo by being stronger than it. You break it by making yourself useful to it.
Impossible thing: I didn't hire security people
The team began as a proof of concept. To staff it, we seconded two engineers from existing product teams. People who already knew Tes engineering. They could help plan and execute right away, because they lived there.
After a successful six months, they went back to their teams, and I had two permanent roles to fill. With the work proved, an obvious move would be to hire security engineers. But I didn't.
We weren't short of security knowledge. We'd spent six months wiring ourselves into a whole department of it. What we were short of was people who could turn that knowledge into valuable solutions inside our particular, fast-moving world. So that's who I advertised for. The job ad asked for engineers, comfortable in our stack, interested in learning security, able to "quickly comprehend security concerns and risk exposure and operate in the complex world at Tes."
Problem-solvers who understood product development, in other words. The security, we could teach (there's good evidence that teaching an engineer security is faster than the other way round). The judgement and the context, we couldn't. Amélie and Charlotte both answered that ad, and were two of the best hires I've made.
Impossible thing: we volunteered to run a live system
This one wasn't my idea. When Marco, my Head of Engineering, and I worked up the Security team charter together, he recommended that the team also own Tes' authentication and authorization stack.
My instinct said no. We were an enabling team. Enabling teams help others build; they don't operate critical pieces of production infrastructure. Owning Auth looked like exactly the gatekeeping, hold-the-keys, single-point-of-control move we were trying to design our way out of.
He was right and I was wrong. On two counts.
Firstly, it meant we dog-fooded our own solutions. Owning Auth meant that we were software owners who needed structured guidance and support to own our systems well. As we developed directives and measurement, we were also the first team to be directed, measured and tested.
Secondly, owning as a security team means looking deep. A security team sees a login system differently from the teams who built it. We weren't only asking "can a user get access?" We were asking the questions: Are we 100% confident how this works; and when something goes wrong, can we report on it, explore it, control it?
We stripped it back, added consistency and observability. And it paid off. We could look at attempted attacks and tell, quickly, which ones were noise and which ones needed action. We also found a corner case buried in the code where, for short periods, a user's password was written to a client-side cookie in plain text. We removed that, fast.
Think the impossible
Strip the security topic away and the challenge presented here is how to re-organise work and responsibility. To work across boundaries and change expectations. None of that used security expertise. It leant into empathy, communication, listening, learning.
You don't break a silo by being stronger than it. You break it by making yourself useful to it. You don't learn about the needs of teams by telling them what to do. Deep expertise rarely generalises.
The impossible here is not about breaking laws of physics. It's about what you think is possible at the start.
If you're about to stand up a team like this: security, platform, quality, whatever cross-cutting thing you've been handed. The statement at the beginning, the charter, is the most influence you'll ever have over it, and you write it before you've done a day's work. Spend that on the impossible-looking things.
Let the function you need to reach set your priorities, and the relationship builds itself. Staff for the gap you actually have, not the one written on the label. Keep enough real ownership that you pay the price of your own decisions.
So, what's the obvious move you're about to make? And what would the opposite look like?
