Hi, I'm Ron. I AM what I do.
I'm Ron Bar-Tor, an engineering leader. As a director of engineering I ran a group of more than fifty across three countries, then gave up the title for a team at one of the largest technology companies in the world, because the scale was worth more to me than the org chart. I've led engineering in the US, the UK, India, Australia and Ukraine. Today I lead nine engineers in the US and the UK. My corner of engineering is identity, the machinery that decides who you are and what you may touch: the OAuth dance, SAML's enterprise plumbing, passkeys and Kerberos tickets, and the thousand ways login can ruin a Tuesday.
Developing engineers is what I care most about in this job, and this site is that instinct with the volume turned up. Most of what I know arrived slowly, from a handful of people who took the time, and in the gaps between them I worked it out myself. I would rather hand it over than watch someone spend the same years on it. So everything here is written the way I wish it had been handed to me: plainly first, rigorously second, with the reasoning left in rather than the conclusion alone.
It comes in three shapes. The writing is where I put what I've learned running teams and where I make my own case: what actually helps a team through a re-org, why we reach for a solution before anyone has stated the problem, what it takes to run a team spread across nine hours. All of it comes from things I've done, things I've seen, and places where I changed my mind. The dojos are that same instinct pointed at craft: identity, software engineering, JavaScript, machine learning and cloud-native infrastructure, nine courses where every lesson ends with you doing the work rather than nodding along. Machine learning is there because graduate school introduced it the way a cliff introduces the sea: all at once, and from a great height. And authlint is a tool rather than a lesson: paste any artifact from an authentication flow into it, decode it, and see the errors. It is the same knowledge with the reading taken out.
When my kids were little, both of them insisted I read Green Eggs and Ham cover to cover, every single night. Sam-I-Am never left me. So here is mine: Ron-I-AM. Identity in both senses, the field I work in and who I am.
“These heroics aren’t a sustainable model. They aren’t a model at all.”
Where identity meets production.
Who you are and what you may do are different questions, and most of the identity failures we build ourselves come from a mechanism built to answer one being trusted to answer the other. Everyone in this field can define the difference. Almost nobody builds it. I live that daily, and this site is where I sort it out, one mechanism at a time.
I've spent years in the identity domain, and I've done it at scale. I've seen tokens that expire at the worst possible time, redirects pointing to the wrong place, federation between companies that don't really know how that works, SSO as a protocol rather than an experience, and authentication code that worked until it didn't. If you want to know how I actually think about this stuff, take the Identity Dojo. Every flow is documented and diagrammed, plain English first and the technical detail second, and I dig into the attacks each of these solutions exists to stop. Start wherever it hurts: OAuth 2.0 & OIDC · SAML & Web SSO · WebAuthn & passkeys · Kerberos & AD · service-to-service auth & SPIFFE · advanced OAuth threats · running identity.
alg: none to a SAML response whose assertion is not the thing that got signed.
One HTML file, no dependencies, and nothing leaves your browser, which is the only way to build something people paste production tokens into.
Open authlint
How I lead
“Build trust, then unleash.”
Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.George S. Patton, War As I Knew It, 1947
At some point I looked at everything my teams owned, identity, the APIs, the platform under other people's products, and admitted that the version of me who could personally make sure it was all right didn't exist anymore. There were more decisions being made before lunch than I could review in a week. The work outgrows you, or it waits for you, and the second one has a name: you're the bottleneck, and everyone below you knows it first. So the method is plain. I own the outcome and the accountability; the engineer owns the problem and the how. I say what has to be true when it's done, not how to get there. "It's faster if I do it myself" is true this afternoon and a lie over a year, and I've regretted the quick fix more often than the hour of explanation. Trust comes first. The surprises come after.
“People first, engineers second.”
Deliberately in that order. I get to know the person before the engineer, because the strengths people undersell only show once you know them. After that, I work with them to develop them by finding the right balance between what they want and what the organization needs. One of my engineers is brilliant and has no wish to lead. Knowing that is what lets me aim his strengths where they count most, and more importantly, it's why he's happy. That's why the 1:1s are sacred. I don't cancel, I reschedule, and I focus on them, not the work they're doing.
Leading a platform team through a re-org“Smart bets, shipped.”
Meticulous engineers are great engineers. They look around corners, find the edge cases, and build things that last. Done every time, that same strength becomes analysis paralysis, and my job is to ground it in reality. We work in a business that expects results, so I say plainly that the best solution will take time and that right now we ship something that solves the problem. When we hack it together, we call it out and we come back to it. That is a promise I keep. The bets themselves run on the most relevant data at the time, and I ask my engineers to go and get it: move from I think to I know. What we know may change later, and that's fine, because we build in a way that lets us change quickly. Adding PKCE once we learn a client is public. Very few doors are one-way doors. And the hardest bet is the one you don't make: I've killed a project I could have shipped.
“Measure it before you manage it.”
In one job every report I read came back green while the thing that was actually wrong stood in plain sight in the same building. I walked past it for months. So now, in the first weeks anywhere, I write down what we measure and what we only talk about, and the second list is where I start. Everything on that second list is a thing somebody can already see and nobody can yet act on. A number you don't have is not the same as a problem you don't have.
The wall of boxes, and what it cost to miss it“Hire strong, not good.”
The first people through the door set the culture for everyone after them, and the pressure to fill a seat is loudest exactly then. Once there are good candidates in front of a committee, the committee wants to move. I've held the line through more than one round of "we can't afford to wait," and I've never regretted it. I do the money side first, with HR, so the bar is about the person and never about the offer. And I sit in the loop myself. The proof isn't who you hire. It's who's still there a year later.
Building a team from zero, and the bar I heldWritings: essays and proud scars
Engineering management, identity, and the occasional bug worth telling the whole story about.
A development center from zero
A company whose customers ran million-dollar machines needed engineers on the customer's clock, not its own. I was sent to build that, from an operations office in Tucson with no engineers in it. What it took, what it cost, and what I would do differently.
The deadline was game one
In 2018, four engineers and I had a few months to make a CDN do something it had never done, for the NBA Finals. Here is what the project taught me, including the parts I only understood much later.
In the critical path of evolution
Reorganizations land hardest on the teams that sit in the critical path of everything. Identity is the clearest example. What I learned, from both sides of the chart.
Things I've Learned, Written Down
People learn in different ways, and most of the engineers I've worked with learn by doing. The dojos are built for them. Every dojo runs on belts, white to black, and what each belt asks for is written down. Reading a lesson doesn't move you up one. Doing the work does, and then going further than the work asked for, until you have the intent as well as the mechanics and the syntax. That is the part that survives contact with a problem nobody wrote a lesson about. It is the same rule I use with a team: reading about it isn't doing it, and I would rather watch someone work through an exercise than watch them watch me solve it.
The skills rubric: where you actually standAnd I hold the material to the same bar I would hold a team to. Every push runs nineteen checks, and one of them takes all 3,095 assertions behind the graded exercises and runs them against their own reference solutions. If a single one fails, the build fails. That has stopped my own work more than once, which is the point of it. A bar you can wave yourself through isn't a bar.
Where AI fits, and where it doesn't
I want to be transparent about this. AI generated the first drafts of much of this site, with a lot of input from me, and what you are reading has been through more than ten revisions. The ideas, the curriculum, the sequencing and the technical judgments were mine before a first draft existed, and the voice is what survives the rewriting. When I saw the AI drifting, I corrected it and wrote that part myself. And regardless of who wrote a given line, the quality gates applied to every one of them. The typing was AI's. The thinking was mine. I will keep iterating on it and improving it. I'm not done yet.
Take the course.
Tutorial hell is watching someone explain something, following along, and finding out later that you never had it. Everything here is built against that. Every lesson ends with an exercise you complete in the page, and it has to pass, and when you get a quiz question wrong it tells you why that answer is wrong, not just which one was right. Nine courses, from JavaScript for someone who has never programmed to identity protocols at the depth you would argue about in a design review. And a large part of it is the work nobody teaches you: how a commit becomes a running service, how to read a log file at 3am, what to do in the first ten minutes of an incident. Free, no accounts, no tracking. Knowledge shared is the whole point.
Let's build something.
I'm always happy to talk shop: identity architecture, engineering management, course feedback, or a collaboration you have in mind. I read everything that lands in my inbox, and alpha volunteers get a personal onboarding.
Drop me a line