How a Wall Street Analyst Built His Way Out of the IT Queue
And spent thirty years proving the gatekeepers wrong, one shipped system at a time.
“I don't do 6-month roadmaps, or ticket queues, or steering committees. I just deliver solutions that solve problems.”
— Shane McGrath

Shane McGrath
Guild Master, Vibe Code Guild
I started in Finance first. The code came later.
In 1998 I was an Economics and Finance major at Southern Illinois University Edwardsville, headed straight for a career as a financial analyst. I took an internship at a life insurance company because that's what finance majors did, and they put me on the monthly reinsurance calculations.
Here's how that job worked when I inherited it. My predecessor would print out reports by the ream, sit at her desk with a calculator and a highlighter, and type numbers into spreadsheets one cell at a time. The whole process took seven full working days every month, and that was just how it had always been done.
One afternoon, my boss showed me how to record macros in Excel.
Something in my brain rewired itself permanently in the next three seconds.

I wasn't interested in becoming a developer. I was interested in being a better analyst. If a computer could repeat a click, it could repeat all of them, which meant I could spend my brain on the parts of the job that actually mattered: the analysis, the judgment, the recommendation. Not the data entry.
I went home that night and bought a stack of VBA books. By the time my internship ended, the seven-day reinsurance process took two hours. The other interns thought I was a wizard, but I just thought I'd found a faster way to do my actual job.
That's the part I want you to understand. I didn't fall in love with code. I fell in love with what code let me do as a finance professional. The two were always connected, and the technical skills were a force multiplier on the financial skills rather than a replacement for them.
Two Careers, Run inParallel for Thirty Years

I left college and went straight into equity research at AG Edwards. While the other associate analysts were updating their valuation models by hand, I was writing code that updated mine automatically. I got my analyst work done in a third of the time and used the rest to build tools the team didn't know they wanted yet.
In 2003 I picked up the CFA Charter, which meant three years of brutal exams covering equity analysis, fixed income, derivatives, portfolio management, ethics, and economics. I wanted the credential because I wanted to be taken seriously on the finance side. At that point, the technical side was still just a tool that I used to be better at the finance side.
After three years I went independent and contracted to hedge funds, money managers, and brokerage houses. The pitch was always the same: I'm a finance person who can build the system you need. There was no translation layer between analyst and engineer because I was both. I shipped applications in weeks that internal IT teams had quoted in years, and the work kept coming.

While I built my consulting career, the technical side kept expanding. VBA was just where I started. I taught myself SQL and database design because the analytics I needed to run required real data infrastructure. I picked up C# and the .NET stack because I needed to build production web applications. Java and Python came the same way, when the work demanded them. Over the years I built and deployed full-stack web applications, desktop applications, and backend systems running in Java and Python in production environments managing billions of dollars in client assets.
I understand the full technical stack as well as anyone with a CS degree from Stanford. The difference is that I also understand what the software is supposed to do at the business level, because I came up through the business.
Then came BlackRock. I joined to manage a team of developers building tactical solutions, and the work was fast, scoped tight, and built for traders and analysts who needed answers in days rather than quarters. After a couple of years running that team, I transferred internally to become an investment strategist for one of BlackRock's global macro hedge funds. That was a real seat with real money and real positions, and there were real consequences for being wrong.
A couple of years into the strategist role, I moved again to be the West Coast Head of Equity Analytics on the Aladdin Platform. If you've never heard of Aladdin, it's the operating system for trillions of dollars in global assets, and the largest asset manager on the planet runs on it. I led the analytics team responsible for delivering the tools that equity portfolio managers needed to implment investment solutions for BlackRock's clients.
The progression matters. I didn't get hired into BlackRock as an executive. I got hired to run a small team building tactical tools, and they kept moving me into harder roles because the work kept landing. Engineering, then portfolio strategy, then analytics leadership. Three different functions inside the same firm in seven years. Most people pick a lane, but I built credibility in finance and engineering at the same time and let BlackRock figure out where to use me next.
After BlackRock I consulted at CalPERS, the largest public pension fund in the country, as a Senior Product Manager. The title was product management but the work was hands-on engineering. I designed and built a desktop application in C# for their transition management function inside the index equity group. If you're not familiar with transition management, it's the operation of moving billions of dollars between portfolios without moving the market against yourself, which means the tooling has to be precise, fast, and trustworthy. I shipped it.
That's the resume. The resume isn't the story.
What ItActually Felt Like

The story is that every one of those roles came with the same fight.
The traditional IT teams didn't want to work with me, and sometimes they actively obstructed me. Their reasoning was always the same, even when the wording shifted. VBA wasn't real software. Self-taught wasn't real training. A finance background wasn't real engineering background. I'd ship a working system that solved a million-dollar problem, and the engineering team would tell my boss it shouldn't count because I'd violated some dogma about how software was supposed to be built.
Steering committees. Six-month roadmaps. Ticket queues. Meetings to schedule the meeting where we'd discuss the meeting. I watched senior people with my problem wait literal years for IT to get around to building them tools that I could have shipped over a weekend if anyone had asked. Half the time I built it anyway, in the background, without permission, because the work needed to be done.
The pattern of my entire career, in one sentence: the outsider does the work, gets the result, and gets told the work doesn't count.
I shipped anyway. I learned to speak the engineers' language fluently so I could meet them on their terms when politics demanded it, and by the end of my BlackRock tenure I could hold my own with credentialed engineers in any technical conversation in the room. They still didn't think I was one of them, and that was fine. I wasn't trying to be one of them. I was trying to solve the problem.
What kept me going was that the work always won. The systems I built kept running. The analysts I built them for kept using them. The money kept moving. The gatekeepers could call it whatever they wanted, but the production systems I built ten years earlier were still running when I left BlackRock, and most of them are still running today.
Why I’mTelling You This

The reason I'm telling you all of this is that the gates are finally gone.
The thirty-year head start I had on the people who were locked out is over. AI didn't just lower the barrier to entry, it demolished the building. The skills I spent three decades grinding for, the syntax fluency, the architectural intuition, the database design instincts, the ability to translate between business and engineering, all of that used to be the moat. It was the reason gatekeepers could keep gatekeeping. They could point at the moat and say you can't cross this without a CS degree, and most people believed them.
The moat is dry now. AI fills in the syntax. AI handles the boilerplate. AI knows the documentation better than the people who used to use the documentation as a weapon. What's left is the part that was always the actual job: understanding the problem deeply, judging tradeoffs, and shipping something that works.
If you understand your business better than anyone else in the room, you can now build the software for it. That used to be impossible, and now it's a Tuesday afternoon.
I keep watching it happen. Founders ship in a weekend what would have been a $50,000 development quote two years ago. Operations leads automate workflows that used to consume entire departments. Team moms build tools that would have required IT tickets, approvals, a project manager, and a six-month timeline. Now they just build them over coffee while the kids are at school.
This is the most exciting moment to be a builder in my entire lifetime, and probably in any lifetime.
It’sOur Turn

I built Vibe Code Guild because it's finally our turn.
The IT department doesn't control us anymore. We don't have to sit in steering committees waiting for our number to come up, and we don't have to beg for budget. We don't need to translate our needs into a language someone else gets paid to interpret. We can build, we can ship, and we can change our lives.
This is for the people I spent three decades watching get told no. The finance professionals who knew exactly what tool they needed and couldn't get IT to build it. The founders with ideas they've been describing to their spouses for years. The business owners who got quoted insane timelines for tools they could ship themselves in a weekend if someone showed them how. The forty-something professionals watching AI eat their industry and wondering if they're allowed to use the same tools. The teenagers who've already figured it out and are waiting for the adults to catch up.
You don't need permission. You don't need a degree. You don't need to wait for IT, and you don't need the blessing of someone in a Patagonia vest at a tech conference. What you need is to understand your problem clearly enough to describe it, and then you need to start.
I figured this out as a 20-year-old finance major in 1998 because my boss showed me a button. You have access to AI tools that would have looked like science fiction to me at any point in the last three decades. If I could become a builder in 1998 with a stack of paperback VBA books and zero prior experience, you can absolutely build what you want to build today.
The cohorts are how I help people get started. The 1-on-1 mentorship is how I help people ship their specific idea. The consulting engagements are how I help businesses solve the problems their existing IT can't get to. Pick the one that matches where you are, I can't wait to help you.
Let's get started, the Guild is open.