We are developing a SaaS product called Skyway that simplifies financial planning and analysis of cloud billing data for large enterprises with complex cloud spending requirements.
Enterprise cloud cost management is a deceptively deep problem we believe the entire cost management space is solving the wrong part of the problem.
We're looking for a Head of Engineering to own how Skyway gets built: the architecture, the velocity, the team, and the technical decisions that will compound for years. Today, this is a builder role: you'll be in the code every day and using that credibility to set the pace for everyone around you.
Historically, products in this space have made three fundamental choices:
They provided a cost-first data model to customers
They assumed the providerâs billing data is correct
They chose to solve a specific piece of the cost management problem domain
Weâre taking the opposite of all three: our world is consumption-first, weâre recalculating the billing for each provider, and weâre working to solve the entire domain.
Weâve started with a AWS contract management product and expanding over time to handle forecasting, scenario modeling, cost allocation, chargeback/reinvoicing, practice management, and much more. Our goal is to be the system every enterprise runs their cost management practice on.
To accomplish this, we're processing hundreds of millions of rows of billing data per customer, per month. We're turning unstructured commercial contracts into structured data and dynamically recalculating bills using rates from both the contract and public pricing data. We're building a semantic layer that translates technical cloud usage data into business concepts anyone can understand, and we're creating the world's first standardized structure for describing a commercial contract and all of its facets.
There are three core issues we have to solve:
Near-unbounded data cardinality coupled with very large and complex datasets
Consumption-first means we need to model the pricing schemes and commercial contract structures for every vendor we supportâand we intend to support hundreds-to-thousands
Hiding all of this complexity from the customer with excellent product design
Here's a sample of the kind of problems you'll help us solve:
A customer's organizational restructure moves $40 million in infrastructure spend from one VP to another overnightâboth the historical view and the future view need to be correct, but they need to be correct in different ways.
A customer has 6,000 people in engineering, 2,000+ application IDs, and a highly matrixed reporting structure. "Who owns this?" is almost impossible to answer, but we need to make it simple. To make matters worse, engineering and finance have wildly different perspectives on this.
A SaaS provider changes their pricing model, breaking previous known structures. We need to detect it, adapt to it, and recalculate downstream.
Each provider has dozens of columns in its billing data. When combined with customer-provided data, the dimensions exploded to hundreds or thousands. Given the dimensionality and customer size, the dataset reaches into the terabytes easily. The customer needs to not just be able to query the data, but to also modify the dataâand do so faster than a traditional data processing pipeline will allow.
Ship daily and set the pace. This is the single most important part of the job. You'll personally ship working capabilities every day and drive the team to do the same. You identify and remove anything that slows shipping down, whether they be tooling gaps, process bloat, unclear requirements, architectural bottlenecks. The team should be capable of shipping more in month 12 than month 6.
Build the engineering team. Youâre setting our engineering talent bar. Beyond hiring, you're also responsible for growing these engineers: raising their technical bar and building a culture where your team is doing the best work of their careers so far.
Make architecture decisions that last. Build on a stack and architecture that supports 10â50x growth in data and customers without a fundamental rearchitecture. Make deliberate, documented decisions about what's built to last vs. what's intentional tech debt. Architecture decisions should enable velocity, not slow it down.
Bring product ideas to the table. While your primary job is how, not what, you should have strong opinions about product improvements based on what you see in the code, the data, and customer behavior. Push back on product direction when you see technical or customer reasons to.
Be a credible technical voice externally. Participate in enterprise sales calls, customer onboarding, public promotional events, and investor meetings.
Youâll be given more autonomy than youâre comfortable with. We're a small team, around a dozen people today. People joining now are making foundational decisions that need to hold up to future growth in data and customers. Weâve got a lot to do and we hire for expertise and great judgement. We value quick decision-making and a âletâs find out!â attitude.
We ship daily. New engineers ship in their first week. We value making progress toward customer desires every day.
AI makes us all more capable. We use AI assistance throughout the company heavily and expect you to as wellânot just tab-completion, but agents, code review, and whatever else helps you move faster. AI skeptics wonât do well here.
You're energized by ambiguity, comfortable tearing down what you built last month if the business requires it, and you'd rather ship something imperfect today than plan something perfect next quarter.
Data infrastructure experience is particularly valuableâlarge-scale ETL/ELT, columnar storage, etc. Our stack today is Python, Flask, ClickHouse, Airflow, React, and Typescript. The stack will evolve, though, and what matters more than any specific tool is that you have informed opinions about data systems and the experience to back them up.
You're someone who's built and recruited engineering teams before. You might be a Director of Eng or VP of Eng. You might have built your own startup in the past and want to do it again, or maybe youâre thinking about that move for the first time.
You don't need to have domain expertise in FinOps or cloud billing. We'd actually prefer you don't come from another FinOps vendorâwe're doing something new and don't want inherited assumptions about what the product should look like. What you do need is genuine curiosity about hard data problems.
You're looking for a role where you manage people but don't write code. This is a builder-first role.
You expect well-defined scope and established processes. We're a seed-stage company and things change constantly.
Your background is primarily SRE or infrastructure operations. We need a product engineering leader.
You're coming from a traditional FAANG or traditional enterprise environment.
We've been doing customer research for seven years. Duckbill started life as services firm in 2019 and has worked primarily with large enterprises. Through that work, we've had a front row seat to the hardest problems organizations face. As a result, our vision for Skyway isn't built on hypotheses: it's built on having directly worked these problems alongside the people who live with them every day.
Services are a superpower. Every services engagement teaches us something new about customer pains and desires, creating an intelligence loop between services and product. At the scale weâre working at, we are exposed to the hardest cloud cost management problems in the world and can turn those insights directly into product capabilities. (and donât worry, our engineering team is separate from our services t
duckbill