This deck is for Principal Backend Engineer (Go) at FunnelStory Job description
Quoted from the posting on Wellfound. Remote (India), full time.
What are we building?
FunnelStory is building the GTM context graph — the infrastructure layer that lets revenue teams and AI agents reason over live customer intelligence. We fuse GTM data from many systems, maintain durable account truth, and power permissioned actions and agents on top.
Backend: Go, PostgreSQL, Docker, AWS; enterprise and on-prem deployments.
Opportunity
- Own major backend work across the data platform (connections, ETL/reverse ETL, sync) and the agent layer (workflow runtime, reliability, usage/billing)
- Solve hard product problems — incremental refreshes, reconciliation, integrations at scale
- Shape architecture, engineering process, and culture with the founders
- Work closely with the team to design and ship new features
- Mentor others and help lead as we grow
Who are you?
- Opinionated, accountable, and ownership-driven
- You tackle unknown problems and find practical solutions; you communicate clearly
- You challenge weak ideas and care about products customers can trust
- You use AI tooling to ship faster — and you still write clean, reliable code (not slop)
Your experience
- 7+ years as a senior/principal backend engineer
- 4+ years building services and REST APIs in Go
- 4+ years of SQL with PostgreSQL (or similar)
- Docker and AWS
- Experience with data pipelines, integrations, or AI/agent systems in production
- You have designed or owned major backend modules/components
What we offer
- A small, senior, passionate team
- Competitive salary and equity
- Flexible vacation policy
- Remote (India)
Skills
SQL Artificial Intelligence REST APIs Docker Go (Golang) AWS Docker / Docker Compose / Kubernetes LLMs Agentic AI
Sanveer Singh Osahan
The primary value what I bring to the team is Care. This pitch is just a snippet into it.
Not only my Customers, I treat my team and every around me as my End Users.
This is reflected in the code I have written, the RFCs I have drafted, the presentations I have created.
Business is built on Trust
Trust is built on Care
Care is built on Discipline
A simple principle I follow is
What Customer's really want?
More of
- Love
- Money
- Acceptance
- Free time
Less of
- Stress
- Conflict
- Hassle
- Uncertainty
Let's address the problem statement for a B2B business's post sales customer journey.
What impacts the revenue is the renewal and the churn of user accounts.
The metrics that teams track to define the success criteria are often lagging indicators. These indicators are tracked after the event occurs (renew or churn), and they drive reactive actions.
To be proactive, what we should track is leading indicators. Leading indicators are hard to track. They are scattered across many data sources, structured and unstructured. They are not always deterministic, for example customer sentiment. They are also missing context and relationships, both with one another and with the lagging indicators.
Moreover, there are CSMs, CSAs and account executives working in silos, each managing their own accounts. They often miss out on 2 types of context:
- Common indicators that are relevant to all accounts, or to a group of accounts by type, region, industry, and so on.
- Definitions for the same indicator that change from account to account, even though the accounts overlap on type, region or industry, and even though some of them share the same parent account.
Atlan's User Journey
Strategy
The contract sets the scope. Which data sources to ingest metadata from, and what to implement on top: lineage, tags, glossary, data products, data quality, and governance workflows.
Data Estate Onboarding (Catalog and Lineage)
The team creates connections to the data sources. Workflows then ingest metadata and lineage. A workflow runs on a schedule, or on demand, to keep the data in sync.
Implementation and Adoption
Once the metadata and lineage land, the customer data teams implement the downstream use cases and adopt them.
Measure and Scale (Value)
Business users drive the use cases and collaborate with Atlan as the source of truth and the context layer.
Renew and Expand
The contract renews or churns on value and viability. Expansion adds breadth, which is more data sources, or depth, for example data quality added after a successful lineage rollout.
The traditional SaaS has 3 layers - User Interaction, Logic and Data
LLMs and Agentic AI have evolved the landscape of each of these layers
Agent = Model + Harness
There are 3 types of companies in the AI space
- Those who provide compute
- Those who train and build models
- Those who build the harness and agents
The competition between the companies who are not in compute and model training business is to make their place in the context window
So how does FunnelStory earns it's place in the Context Window?
FunnelStory ingests structured and unstructured data from various sources - Data Warehouses, CRM tools, Ticket Management Tools, Product Analytics etc for Accounts, Users, Product Activity, Support Tickets, Conversations, Meetings to build the Customer Intelligence Graph
So why can't the B2B businesses build their own Context Intelligence Graph?
It's the Buy vs Build question.
Execution is cheap but maintenance of a system is still not.
If there is no system to pre-compute and provide the right facts, the LLM models tend to hallucinate as they are optimized to predict the next token based on the probability scores.
If the cost of building and managing an in-house system exceeds the cost of buying a system that can do it for you, then why not go for the value?
Atlan as a Context Layer Atlan
Quoted from the Atlan docs.
A context layer is the governed layer that makes your existing data understandable and usable by AI at runtime.
MCP is the delivery mechanism, not the context itself. The context is the metadata, lineage, glossary, and governance that Atlan exposes through that interface.
I don't have the internal context of how teams at FunnelStory operate, but I can make my assumptions based on the overlaps with Atlan and on what I have learned so far.
The target customers that Atlan serves are Data Scientists, Data Engineers, Data Analysts, Data Stewards, Business Intelligence, etc. to make them collaborate and break the silos. We call them Humans of Data + AI.
My understanding is that the target customer base for FunnelStory includes CSMs, CSAs, Technical Account Managers, Solutions Architects and FDEs, which can be termed as Humans of CX.
As the FunnelStory user journey also includes setting up the data models and ingesting the customer data from various data sources, a Human of Data expert is required from the user's end to build the connections, write the queries, and monitor the subsequent ingestions for data sync.
Based on this I can think of a few strategies, if they are not being followed already.
1. Have a persona beyond the Customer Success role
In Atlan, we have personas for Customer Enablement and Education. They drive the education of Data + AI best practices and enable adoption of the product across various data teams and personas for the customers. Then there are Implementation Engineers who are hands on with the product and fast-track the data estate onboarding.
2. Turn prospect calls into onboarding
Get on a call with the prospect, understand their pain points, success metrics, needle movers, what data sources they have, and what matters the most. And then in the call onboard their workspace, create data connections, ingest the accounts data, and configure the data models. When the call ends, the customer already has a workspace, saving the setup hassle. From here they can evaluate the Proof of Value and convert a deal. The conversation, interactions and use cases become a user story, and can be used to create content for social media marketing on X, LinkedIn, Instagram, etc.
Based on my experience, this is what I think the ingestion workflows look like.
In such types of setups, the Connectivity teams have to solve for these metrics.
- Workflow success rate
- Workflow runtime
- Data estate correctness
- Handle high volume data
I believe in the following principles, and these are what I can bring to the Team, the Company, and the Customers.
Problem First, Solution Second
Engineers in general have a tendency to be solution first.
They are always eager to jump on the implementation without fully understanding the problem: maybe the reward is adding a new line item in their resume, or just feeding the new tech and problem hunger.
It takes practice to map out the effort and the impact on a quadrant, and to pick up the items with low effort and high impact.
There are high impact problems which require no code, or a minimal amount of code, and I have examples to discuss this.
Another instinct is to follow the Pareto Principle.
- 20% of the features drive 80% of the value
- 20% of customers bring in 80% revenue
- 20% of the patterns cause 80% of customer issues
Sell before you build
I have worked in a team where we optimized to build a product with awesome features, clean code, best practices and a decent architecture, but low customer adoption.
I have worked in a team where we have 5M+ ARR with new enterprise customer deals. But the codebase was just spaghetti scripts stitched together, built by interns working during their Covid online college tenure.
If given a choice, I will always prefer the latter.
But I also understand that what takes you from 0 -> 1, or maybe from 1 -> 10, will not take you from 10 -> 100, 1000, and beyond. A quality product also becomes as important as sales.
The fun part is to be able to navigate between shipping fast and shipping quality. With years of practice, you learn to ship quality fast.
There is no smart work without hard work
My SOP for something new is this: do the grunt work, feel the pain, understand the patterns that can be automated, and then automate them.
The AI breakthrough lets this go in 3 stages.
I read that LLMs are good at finding patterns. But so are humans, and in some contexts humans are better, because our memory and context windows also find patterns in unrelated topics. We evolved to find patterns in our environment.
The 3 stages -> AI Assisted, AI Augmented, AI Autonomous.
Breakdown your day to day tasks and actions -> Find the patterns -> Use AI Assistance to perform -> Convert to AI Augmented -> Review the outcomes -> Convert to AI Autonomous.
With practice you will know what tasks can be Autonomous, and what can be limited to Augmented or Assisted.
Highlights
-
I have worked on Data estate ingestion and have solved the following challenges
- Workflow resiliency
- Workflow runtime
- High volume data ingestion
- The Enterprise Customers only allow ingestion in their environments. I was the first to get the initial success to have this ingestion possible, and I contributed to the overall architecture of customer side ingestion.
- There are lagging indicators which I converted to leading indicators, and I built the systems for tracking them.
- I designed the industry first incremental metadata ingestion.