I play in multiple dynasty fantasy football leagues. And for as much time as I spend thinking about them, I was spending a surprising amount of that time just trying to get a basic read on where things stood.
Who’s winning? How old is my roster relative to the rest of the league? Did that trade I’ve been thinking about actually happen? Where did I even save that roster export?
None of that lives in one place. The Sleeper app is great for managing moves and checking scores, but it’s not built for the kind of standing-back, big-picture view that dynasty managers actually need. So I started building tools to fill the gap.
The first problem I hit was practical: I wanted my roster data in a spreadsheet so I could sort, filter, and think about it without fighting a mobile UI.
Sleeper Dynasty Roster Sync is a Google Apps Script that pulls your Sleeper roster into Google Sheets automatically. Point it at your league, run it, and your full roster — player names, positions, ages, and ownership details — populates a clean sheet you can work with however you want.
It’s a small script, but it solved a real workflow problem. I was manually copying roster data before big decisions. Now I don’t.
Built with: Google Apps Script, Sleeper API
Once I had roster data flowing into Sheets, the next question became bigger: what does my whole league look like?
The Sleeper League Health Dashboard is a single-page web app that pulls live data from the Sleeper API and surfaces it in one view. Enter your Sleeper username and it loads all your leagues for the season. Pick one and you get:
No login, no backend, no install. It runs entirely in the browser off the public Sleeper API.
Built with: Vanilla JavaScript, HTML/CSS, Chart.js, Sleeper API
Both tools came from the same starting point: a specific thing I wanted to know that I couldn’t easily find out. That constraint turned out to be a good forcing function. It kept the scope tight and made it easy to know when something was done.
On the technical side, the dashboard pushed me to think carefully about data architecture before touching the UI. The Sleeper API is well-documented but you’re pulling from several endpoints — league info, rosters, users, matchups, transactions, and a player database — and stitching them together client-side. Getting the fetch strategy right (parallel where possible, cached where expensive) made a real difference in how the app feels to use.
The roster sync taught me something different: sometimes the right tool is a ten-minute script, not a full application. Not everything needs a UI.
Both tools are actively used and I’m planning to extend them. On the dashboard side, I want to add dynasty value integration (KeepTradeCut or similar) so the roster age view has market context, and shareable per-manager links so you can send someone a direct view of their team. On the roster sync side, I want to add automatic scheduling so it refreshes on its own without needing to be run manually.
If you play in a Sleeper dynasty league, both tools are open source and free to use. Links below.
Sleeper League Health Dashboard — GitHub
Sleeper Dynasty Roster Sync — Google Apps Script
I’ll be posting twice a month. If you’re into product management, software, or just figuring out your career as you go, stick around.
]]>I didn’t plan a career in tech. I just knew I didn’t want to spend my life cleaning bathrooms. This is the story of how I found my way into QA, one wrong turn and reset at a time
In 2008, I graduated high school with no real plan.
I wasn’t a bad student, but I wasn’t a disciplined one either. I tested well, but I didn’t take school seriously enough to do anything with it. I didn’t even apply to college. I just followed the default path and enrolled at Ivy Tech because that’s what people around me were doing.
That pattern continued for a while.
I told myself I’d transfer to Indiana University–Purdue University Indianapolis, but I didn’t put in the work. I spent more time traveling to visit friends at other schools than focusing on my own classes. After two years, I didn’t even have enough credits for an associate’s degree.
So I tried something new. I moved to Muncie and eventually got into Ball State. I explored social work, then operations management. I did… fine. Not terrible, not great. But after four years of my parents supporting my education, they drew a line. Fairly.
By 2012, I was back home, working jobs that paid the bills but didn’t feel like a future.
I made pizzas. I delivered them. I cleaned bathrooms. I worked at a deli. I picked up a second job at a liquor store just to piece together something that looked like full-time income.
And one day, cleaning a bathroom at work, I had a very clear realization:
I didn’t want this to be my trajectory.
I went back to school with a different mindset.
Not because I suddenly loved school, but because I finally understood what happens if you don’t take it seriously.
With help from my dad, I finished the last few credits I needed and earned an Associate’s degree. It wasn’t glamorous, but it was momentum.
When I met with an advisor at IUPUI, they asked what I wanted to study.
I didn’t have a polished answer. But I knew two things:
I liked helping people I was always drawn to computers and technology
That led me to the School of Informatics and Computing and a program that was just getting started at the time: Human-Computer Interaction.
That decision changed everything.
When I started at IUPUI in 2014, I treated it like a second chance.
And early on, I almost slipped back into old habits.
I struggled in my first math class and bombed the first two exams. That could have been the start of another spiral, but instead I did something I hadn’t done before: I asked for help.
I went to the Math Assistance Center every day.
I did my homework there. I asked questions. I stayed until I understood the material.
My next three exam scores were 94, 98, and 100.
I finished the class with a B+, and more importantly, I proved to myself that I could change how I approached problems. After that semester, I made the Dean’s List every term.
That experience stuck with me more than any single class.
Near graduation, I hit another unexpected hurdle.
An internship I had lined up didn’t count toward my capstone requirement. I suddenly needed a new one, fast.
I ended up landing a session internship with the Office of Technology Services for the Indiana Legislative Services Agency.
That’s where I was introduced to quality assurance.
Up to that point, my studies focused on designing good user experiences. QA flipped that perspective. Instead of asking, “How should this work?” I started asking:
“What happens when this breaks?”
I loved it immediately.
Testing wasn’t just about finding bugs. It was about protecting users from bad experiences before they ever saw them. It was problem-solving, systems thinking, and user advocacy all rolled into one.
I also started experimenting on my own. I built small proofs of concept using QR codes to improve access to public information like livestreams when government rooms were full.
At the time, the idea was brushed off.
Too much access. Too much transparency.
A few years later, QR codes became everywhere.
That was the first time I realized I liked not just testing systems, but thinking ahead of them.
After graduating in 2016, I joined ADESA (KAR Auction Services) as a junior QA.
Within six months, I was promoted and moved onto a major project building dealer-to-dealer auction applications for Toyota and Lexus.
That role escalated quickly.
We shifted from waterfall to agile. I took ownership of mobile QA. I stepped into scrum responsibilities. I worked across onshore and offshore teams.
Less than a year in, I wasn’t just testing anymore. I was coordinating, leading, and helping shape how work got done.
At the same time, I got pulled into experimental projects, like testing a custom car photo booth built with Raspberry Pi hardware. That happened because I had casually mentioned I’d built one at home for fun.
That moment stuck with me too.
The things you tinker with on your own eventually become the things people trust you with professionally.
In 2019, the company eliminated QA roles.
The reasoning was that developers could handle testing.
I was laid off.
The next day, they asked me to come back. Same role, same pay.
I said no.
Instead, my wife and I moved to Denver.
At the time, it felt like a risk. In hindsight, it was a turning point.
I didn’t take a straight path into tech.
I failed classes. I changed directions. I worked jobs that had nothing to do with where I ended up.
But each of those experiences added something:
Service jobs taught me empathy and patience School (eventually) taught me discipline and how to learn QA taught me how to think critically about systems and users
Today, I still approach problems the same way I approached that math class and those early QA projects:
Figure out what’s actually happening. Understand where things break. And make them better before someone else has to deal with it.
That’s the work I care about.
I’ll be posting twice a month. If you’re into product management, software, or just figuring out your career as you go, stick around.
]]>I’m not a writer — let’s just get that out of the way up front.
I’ve spent my career in software. I started in QA, which means I spent years trying to break things other people built — and honestly, I was pretty good at it. Somewhere along the way I moved into product management, which means I now spend my time figuring out what to build and why before anyone writes a line of code.
That shift changed how I think about software, about teams, and about what “quality” actually means. And I kept having these moments — conversations with my team, decisions that went well (or didn’t), patterns I kept seeing — where I thought, “I should write this down.”
So here I am, writing it down.
A few reasons, if I’m being honest.
First, I want to get better at articulating what I’ve learned. When you move from a technical role into product, you pick up a lot through experience that’s hard to put into words. Writing forces you to make it concrete.
Second, I think the QA-to-PM path is more common than people realize, but nobody really talks about it. If you’re a QA engineer thinking about product, or a PM who came from a testing background, I want this to be a space where that perspective gets some airtime.
Third — and this is the selfish one — I want a record. A few years from now I want to look back and see how my thinking evolved. That’s worth the discomfort of putting myself out there.
I’m going to keep this simple. Twice a month I’ll share something — a lesson from work, a take on how teams build software, a reflection on my career so far. Some posts will be practical (here’s a framework I use, here’s how I handle X). Others will be more personal (here’s something I got wrong, here’s what surprised me).
I’m not going to pretend I have all the answers. I’m still figuring a lot of this out. But I think there’s value in sharing the process, not just the polished takeaways.
If you’ve ever thought “I’m not a writer” as a reason not to share what you know — I get it. I’m right there with you. But I’ve realized that having something worth saying matters more than saying it perfectly.
So here goes. Thanks for reading the first one.
I’ll be posting twice a month. If you’re into product management, software, or just figuring out your career as you go, stick around.
]]>