Meet our new Head of Developer Relations

Because developers are core to everything we do and build, it was important that we found the right person to lead developer relations at this critical point in the Retool journey.

Enter: Taylor Singletary, who recently joined the team as Head of Developer Relations. We asked him a few questions about his path to devrel, his philosophy of developer advocacy, and what he hopes to achieve at Retool. 

My twin brother and I fought over the Commodore 64 in the house early on. My favorite cartridge was Story Machine from Spinnaker software—the stories I could tell at five with a limited vocabulary. I was ready to ZOT the universe or at least a ROCK or two.

Programming in BASIC was fun. It was exactly like the line in Willy Wonka & the Chocolate Factory (the 1971 version)—“I am now telling the computer exactly what it can do with a lifetime supply of chocolate.” The library also had dozens of COMPUTE! magazines you could copy the code out of line-by-line, modifying on the fly to make it your own.

Later we got into local bulletin board systems, and then ran a series of BBSes, mostly switching the name and theme and art every time we found some new software we liked more. We hacked our way through C and Pascal to make things reflect our (still pretty young and silly) world view.

Through these BBSes we discovered the Internet. Through the Internet we discovered Linux. Through Linux we learned how to build and break and explore everything else a relationship with a computer could be, at least up to then in the early 1990s.

As I was leaving college, I got a job as a Perl programmer for a Portland-based consultancy. This is where I had my big “aha” moment that brought me from programming enthusiast to developer. At this consultancy, we built custom solutions for local wineries, coding systems for Allergen, online reservations systems for Bullwinkles and bowling alleys, and e-commerce portals for peddlers of ink stamps. It was a great way to learn how other businesses worked, what they needed, and how one could build the full stack of software (and often hardware) they needed. I also learned Ruby on Rails and spent time at Versation writing turnkey social software for colleges, universities, and English Language learners via englishbaby.com.

In 2007, I learned LinkedIn was looking for Ruby on Rails programmers to join a very small team eventually called “Light Engineering Development” (compared to the “Heavy Engineering” the monolithic Java folks were doing there). We lived and breathed APIs and rapid development, and eventually helped launch a series of platform products together. That’s how I became the company’s first Technical Evangelist, and building developer relationships there led me through a series of devrel IC and management roles at Twitter, Clever, Slack, and now Retool.

It’s difficult to hold on to pride when the things you’re most proud of have a habit of disappearing. Some of my greatest achievements have been successful deprecations and API retirements, but no one wants “graceful murderer of platforms” written on their tombstone.

Often the things I’m most proud of are a turn of phrase I wrote like: Learn how to sync status with calendars, cubicles, conference calls, and bathroom stalls. I was quite proud of the rollout of Twitter’s API v1.1 tier-based rate limiting system—it’s a good example of how far into product and engineering and platform operations developer relations can go.

Ultimately, work is a team-based sport. I’m proudest to have worked with many of the best developer relations practitioners, software engineers, product managers, marketers, project managers, and so many wonderful recruiters over the years. Working with and being inspired by people who care is where it’s at for me.

Stewart Butterfield’s “We Don’t Sell Saddles Here” philosophy is my inspiring metaphor. It goes beyond building products. In life, do you want to be someone focused on bedazzling a hunk of leather parked in front of you? Or do you want to put your everything into the experience of riding a horse—of sharing that experience with the wind blowing in your hair and the gentle rhythm of the hooves hitting sand and dust you can smell and taste? Like anyone, I spend some time customizing my tools, but I don’t like to burn too much time better spent using them instead.

As a manager of what I consider essentially education programs, I found the book Street Gang: The Complete History of Sesame Street particularly inspiring as someone who loves to see creative, cross-functional multi-year projects come together to stupendous results.

As for developer relations inspirations, Bear Douglas, head of developer relations at Pinecone, remains the boss in my head, which I take with me everywhere. Some of her questions are like the Jenga block that knocks a whole tower down, and others are the missing pieces that reinforce it.

I spent years doing developer relations for platforms that were (important!) value adds to the “main thing.” Retool is the first builder-first product I’ve worked on, and it’s refreshing to work at a company so aligned with the needs of its customers—developers.

When I worked at the consultancy, I liked that the customer’s business was then my business. Businesses are unique. People are quirky. They love to see things spelled out in their own terms. In their team colors. Retool really makes it possible to make so many businesses' technology stack their own.

Retool can reset minds. Retool could become your primary tool to explore the conjunction of services and APIs and data and AI computing. I believe programmers want to program and that writers want to write and builders want to build. And they want to do those things mostly on their own terms.

Retool lets mindful devs get closer to business logic and the data in motion without worrying about what’s popular in the last 15 minutes in the client-side framework wars. With on-prem hosting, you can write your most important business logic in your language of choice and leverage Retool RPC and queries to quickly tie it all together.

We have lots to learn from past and present trends of developer enablement. Working in the Retool IDE is reminiscent of working in IDEs like Turbo Pascal, Scratch, Godot, and Unity. Working in these environments is fun and working in Retool is fun too. Getting work done is always better when it’s fun.

The notion that everybody should be able to use good software and that those who choose to should be able to build good software resonates well with me. It’s certainly easier to get your own way if you can do it yourself. Even better if the pieces naturally fit together into something usable.

Retool scales beyond “I, me, mine,” though. Most great projects are a team effort and teams need tools to fight entropy and collaborate, govern, and maintain software. Retool understands this too. In so many ways our developers are just like us—platform providers, too. What we need, they need, too.

We are here to approach a developer experience with beginner’s mind again and again and again. Developer relations is also here to grow old with and know every corridor of experience. To know what it feels like to turn a corner and find yourself well-suited to face what’s next. To turn the next corner to find yourself ridiculously under-prepared. To walk into a seemingly safe open field only to find yourself deep in the underworld with no hope in sight. We’ve slept on it. We’ve woken up in the morning and still slayed the dragon and saved the day. And we do it again and again and again so we remember all the parts. The being new. The being old. The being defeated. But mostly the winning. The building. The dreaming. The reteaching. The retooling! And we take those memories and turn them into a support network that lives and breathes throughout all aspects of the developer experience: docs, tutorials, tools, handshakes, and events to bolster developers every step of the way.

Showing developers how powerful Retool is. It’s too easy to dive in briefly and convince yourself it isn’t technical enough for you. Retool will scale to your team’s growing ambitions.

Developers should be able to use Retool as if they were working at a company that lives and breathes it.

I want to meet developers where they are, where they work, and where they gather, to make Retool meaningful for the person and programmer they are. When you discover Retool, you should quickly learn how well it works with your way. For programmers who prefer their own code editors and the command-line especially, there’s so much we can do to make the first-time Retool learning experience really meaningful.

In my first few months it’s been all about understanding all the ways we currently interact with, educate, motivate, and encourage our developer community. I’ve found folks in every corner and floor of the Retool org chart directly doing the good work. I want to take what’s already working so well and enhance it—to see what happens if we coordinate those efforts of folks already doing devrel. I don’t want to mess up a good thing, but of course, I’m still here to help us evolve with our customers and business.

There’s so much in store for the multilayered Retool community. Seeing how much the community already shows off their work, their tips, and lend a hand in our community forums and Discord warms my heart.

I’m always listening. I read every developer quote, post, ticket, question, idea, bug, use case, gripe, and compliment I can. If there’s something else I can scalably do—answer, escalate, pontificate—I will. It’s best when I am part of the system itself—I can develop a better gut instinct of the day-to-day successes and challenges Retool developers face.

Retool works well with so much software that we can reach many by highlighting that. You’ll find me at a conference like AWS re:Invent trying to visit as many booths as possible, making connections with developers and the devrel teams behind some of the most innovative software and services out there.

What trends in software development or low-code platforms are you most excited about?

While I like to resist hype and hyperbole, AI has an enormous role to play in networked software development. For me, the most exciting stuff is less about content and code generation and more about taking the objects, representations, metadata, and patterns apps and services commonly work with and making them interoperable (and understandable and modifiable) in a way that doesn’t just disappoint and underdeliver. The most powerful workflow engines will speak common business objects with fluency, regardless of provider, language, or corporate boundaries.

How do you see Retool fitting into the evolving landscape of internal tools development?

For so many companies, “internal tools” are just the “custom software” they need to thrive. For these companies, Retool is going to be the decided way to build, maintain, and grow their business on a platform that’s right for them.

When you encounter a tool your coworker made that dazzles you, you wonder—could I build something like that too but fork it out in this direction instead? With Retool that should get easier and easier to do.

First, synthesizers—I love exploring sound for its own sake but the most interesting thing to me as a programmer working with discrete synthesizer modules is that every module has well-defined inputs and outputs. Something happens in the function—state transitions, computations, simple message passing—but each and every module can be defined by its inputs and outputs and what happens in the little black box within. Working with modular synthesizers is strikingly similar to functional programming and complex workflow design.

I also love creative writing. I always want to channel Gertrude Stein and Richard Brautigan into developer education. They inspire me to build beautiful, deliberate glitches into every system.

It’s incredible to feel like you know what you’re doing. With Retool, once you reach that point where you can tell yourself that—you really can build anything you set your mind to. That being a hero at work feeling doesn’t just stop when you leave the office. Confidence begets confidence. But it also opens you up to dream bigger next time.

I love to see how businesses and developers work in their own words, rituals, and programs. Every day I learn about a new use case or customer or quirk and I add to the ongoing “What do people do all day?” Richard Scarry book I’ve been building in my mind all along.We can all learn so much from each other.

How you Retool isn’t how I Retool and it isn’t how someone else Retools either. You might Retool the way you do because Retool taught you that way. I want everyone to have a chance to learn from the best Retool developer around—you.

—

You can find Taylor on X (@episod) and around the Retool Community. Special thanks to Ryan Crowe for conducting and documenting this interview.