An Inside Look at the Life of a Deployed Engineer at Retool

Our (soon to be former) SF office

It’s been close to six months since my first day at Retool. I first wrote about my process for finding and filtering opportunities, so thought I’d now shift focus to my experiences in the role and a realistic depiction of the day-to-day.

In this post, I’ll touch on the org functions, my specific role, and company operations and values.

What Is Retool?

Retool is not the easiest to explain since it lives in a space that isn’t entirely defined with many moving parts! At its core, Retool is an application development platform for building internal tools. Traditionally, internal company operations are handled by a disjointed mix of manual workflows through excel, emails, notes, and front-end interfaces built with custom code or hacky workarounds. This becomes especially difficult to scale over time without any one central tool to consolidate and manage such disparate data and flows. Retool is meant to quickly streamline operations through applications, which are comprised of a front-end with pre-built components + custom logic (JavaScript/SQL), and pre-connected backend data sources. Companies connect their own databases and APIs as resources and can then build apps that interact with and among all of these resources in their apps.

The Retool Editor

Org Breakdown

Retool’s org structure is conventional by many startup ‘standards’, though has evolved to properly support the needs of a technical platform offering. Our success team works cross-functionally, though interfaces with the following teams consistently:

  • Engineering, Product, & Design (EPD): Core builders of the Retool product. Until just a few months ago, we didn’t have a product function. Product development was dictated by a north star vision paired with customer feedback, which is common for developer-first product startups. As a result, our engineers have molded into product engineers with a natural intuition for our customers and their needs. This is hugely beneficial as an org and for us deployed engineers who interface with them consistently.
  • Sales: Sources potential partnerships and helps to develop a shared understanding of the platform, the value, and pricing model. Our sales team is comprised of Account Executives (who own the contractual and billing agreements) and Sales Engineers (who own the technical implementation of the Proof of Concept buildout — this allows the customer some time to evaluate the product with a light use case). Sales is a critical and highly leveraged role, but requires careful attention to the promise of Retool, and ensuring potential customers have the capacity and resources to buy into the shifting paradigm of tooling and operations. The sales cycle ranges from 45–60 days and is broken down into 6 stages of pipeline, though certain accounts do take longer due to extended proof of concept scoping, procurement and security regulations, and contract specifications.
  • Support Engineering: Dedicated team to handle customers’ technical issues. As mentioned, Retool is a product with expansive scope and configuration options. Things can go wrong, and our support team helps alleviate these bottlenecks. All deployed engineers spend a week on a support rotation in the early weeks to ramp up technically and shadow others.
  • Marketing: Develops strategies and campaigns for maintaining a strong public brand and making that brand visible to our target (and non-target) audience. Marketing is a nuanced role, and while I’ve stepped foot in with some of my internal operations work, I’ve just started to realize the nuance and subtlety of the levers they pull to generate traffic and drive exposure.
  • People: Develop all programs related to employment. This includes hiring, culture, performance management, and splendid off-sites.
  • Success (That’s Me!): Success is responsible for the lifetime success of our customers and builders. As mentioned, Retool does require a certain level of technical know-how to get up and running. We want to ensure that customers can on-ramp quickly and find sustainable success with Retool. We facilitate technical trainings, develop account strategy plans, and think about how to deploy Retool effectively within an organization. The success team is comprised of Deployed Engineers and (as of a few weeks ago) Customer Success Managers.

This list is inexhaustive, as we also work closely with other teams (data, developer experience, business operations) for specific work streams and tasks.

Success Surface Area

The nature of the success team is flexible. Our goal is to ensure that all users, regardless of their role or technical expertise, feel confident and successful in building with Retool. We’re still a startup, so the go-to-market function is a work in progress as we determine what success really entails. Many metrics that may seem promising (e.g., number of logins) may not indicate much without additional properties (number of page saves and queries run). We continue to iterate on key questions:

  • What is a healthy customer?
  • Who are our core user types?
  • What are leading and lagging indicators of success?
  • What processes are broken that we still rely on?
  • How can we scale our success function sustainably?
  • What is our long-term vision?

Much of our work is tied directly into other teams — as the first point of contact for most customers and users, we drive the prioritization and relevance of any customer requests and/or operations that would challenge our current success methodology. This has included initiatives like a tighter, structured pipeline for feedback with our engineering and product teams (EPD), tailored marketing campaigns based on our identified user types (marketing), and improvements to the handoff of a customer between sales and success (sales).

The Deployed Engineering Role

Deployed Engineers (DEs) are responsible for partnering with Retool customers to ensure they’re successful building on the platform. We often partner with customers immediately post-sale and work with these accounts for the duration of their lifetime with Retool. The role is cross-functional by nature — before the product function was spun up, DEs served as the primary point of contact for customer requests and feedback. This is still a role that we play, but with the birth of our product teams, the structure and processes are slightly shifting.

Our time is (generally) split between customer-facing technical/strategic calls, internal syncs, customer enablement work (guides, debugging, async chats), and operations/OKR work.

Here’s a look at a few weeks ago:

Four day work week due to holiday

Rather than discussing each individual event, I’ve distributed events across a few common categories:

  • Weekly Internal Meetings 🟣 : The success team comes together at least twice a week to discuss internal strategy, customer issues/successes, or simply upskill together through a technical brown-bag. Success is also added to most sales calls as well to help align on pipeline and metrics.
  • 1:1s 🟢 : DEs collaborate closely with most teams, so 1:1s are common for both alignment and catching up. I’m also continuing to make my way across the company (which is now growing too fast to keep up with).
  • Block Time 🟡 : Since our calendar is open to customers (and colleagues) to set time, most of the team blocks out working time throughout the week, both to catch up on pending action items from calls or put heads down work into project work. The project work can range from mini-tasks to help out customers (e.g. building a small app for them), preparing for larger training calls/debugging sessions, or dedicated work on OKRs. Each quarter, all teams create and execute on a few objectives and key results they’ve defined. The Wednesday meeting was our quarterly review and planning session for the next set of OKRs.
  • Customer Calls 🟠 : This was a lighter week than most with customers, but included a few customer kickoff calls, a use case scoping call, and a builder check-in. Kickoff calls are meant as a discovery session for both sides: I look to find out more about their goals, intended use cases, timelines, and infrastructure setup. They usually want to know more about how to deploy Retool, what onboarding looks like, and how I can help. The other calls were with existing customers to discuss our current state and upcoming use cases. My customer interaction varies depending on the skill level, needs, and state of the account. We work with c-suite leadership who need to understand the value proposition of Retool as well as builders in the weeds of a particularly complicated Retool workflow. This dynamic has been an exciting highlight of the role.

My Thoughts On Retool So Far

I’m a bit bewildered as to where the last five months have gone. It’s common knowledge that startups move fast, but the constant velocity and pace of iteration have warped my sense of time. There have been a few key traits that have emerged since I joined:

  • High Ownership, Autonomy, and Responsibility. This has been an apparent pattern across the company, and it levels everyone up. There is so much ground to cover, and there are not always dedicated teams who can take on certain work streams and projects. This allows for autonomy and a bias for action that has been refreshing.
  • Native Collaboration (Beyond the Immediate Team): At Retool specifically, I’ve found collaboration a natural necessity for two reasons. For one, the surface area of the product is too broad to cover single-handedly. Beyond learning how to build performant apps on the platform itself, the infrastructure and tooling powering the service + variations in customer needs and structures + growing number of services + the continuous product updates and offerings force a culture of learning and collaboration. Secondly, Retool dog foods its product. Heavily. Most of our own internal tooling is built in Retool, and we’re quick to bring up areas that can be improved, work together on apps, and hold internal training sessions (which are common across all teams).
  • Solutions, Not Problems: This is also part of the employee handbook and company values. It’s often easy to realize the problems without actively looking for ways to solve them. We’re owners of the company and expected to act like so.
  • Transparency: Retool relies on openness. Most anything in the company can be accessed by just about anyone. Calendars are public, decks and strategy plans are all in the same shared Confluence, we have weekly Q/A’s and All-Hands meetings to surface comments and concerns with leadership. This was an adjustment as it required a level of vulnerability I hadn’t seen at a job before, but it’s enabled a sense of openness and expedited growth across the company.

In terms of core skills, I’ve found the technical bar across the company quite high. There are many complexities in the product, and it required deliberate action and experimentation to get up to speed. That said, this has also created a team of doers and experimenters. The amount of movement is palpable even over Zoom. My current work is helping to bridge this ramp through engineering guides and technical breakdowns on relevant topics.

My Learnings (Just a Few)

  • Soft Skills Matter. So do Hard Skills: DEs are the first point of contact for most customers, and requests can come from any angle for any reason. We provide value through our technical and strategic expertise and should feel comfortable leading company-wide training sessions, strategic calls with leadership, and technical debugging calls with builders. The ramp has been swift but empowering.
  • One Can’t Do It All: I continue to be bullish on Retool. I love the product, people, and direction. At the same time, I’ve realized how much damn work goes into scaling a company. From setting company vision to determining metrics to establishing processes to hiring to sales strategy to monetization, it’s clear that each phase of the journey requires entirely new tactics, even when things are going ‘well.’ At the micro-level, I’ve realized the power of delegation of work and trust in each other.
  • Procrastination is Evil: A follow-up on Solutions, Not Problems. Identifying a problem and taking action are distinct areas. I’m still learning to get over this hump and just start, whatever it is. Hoping to carry this into my life.

Where We’re Going

I’m excited by the space Retool lives in and the breadth of potential use cases. There is natural friction in building any web-based application, and the abstraction of the technical details into simple drag and drop UIs will serve as an enabler for technical/non-technical builders alike. It has already proven to democratize access to entrepreneurship and product building, and I foresee an ongoing shift to novel ways to build simple apps or entire companies. We’re still learning the exact balance on ‘product opinionation’ — that is, how much flexibility and freedom we give to developers without breaking from the core offering, but continually focus on customers to learn what’s next.

I’ve also found that the vision for Retool is boundless. We’ve found a product-market fit and there is a clear need for these internal tooling solutions. With that, there’s no simple playbook for addressing and executing on that vision. We need to stay nimble and experiment with new product lines to test what sticks while still maintaining an exquisite core product. There are areas that we understand the need to improve on but are intentional about experimenting with techniques and making calculated bets on new product lines. We’re just starting to build a product roadmap as we better define what success looks like.

Beyond the product itself, I’m realizing first-hand the challenges of scaling an organization! We are growing quickly and processes that worked yesterday can quickly turn outdated. I’ve found a liking for internal operations work, especially on the training and onboarding side.

I’ve loved my time at Retool and do feel that everyone should try their hand at a startup, as its flexed muscles and soft skills I didn’t previously realize the true value of. We’re continuing to hire across the company, so do reach out if you have any questions or see a role that fits you!

Devilishly good looking Success team

Updates to come!

-SB

--

--

--

Engineer @ Retool. Love tinkering, writing, reading, and hammocking.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Delegate to Automate

When Employees Cry I Want to Run Away

Top Tips for a Successful Business Conference

Stuck in the Mundane

Will Your Legacy Represent Your Hopes and Dreams?

The Experimenter’s Mind

The best way to earn money as a student (No one talks about)

Handling Compliments in the Workplace

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sachit Bhat

Sachit Bhat

Engineer @ Retool. Love tinkering, writing, reading, and hammocking.

More from Medium

Best practices for effective startup board meetings

Transforming the Process of Making Business Connections

Prepare Your Business Now to Respond to the Next Big Security Flaw

Engineering & Economics Geek