The short answer: developers often start the process, but managers and other approvers usually decide whether money gets spent. In most B2B purchases, it is not one buyer making one call. On average, 5.4 people take part in a standard buying decision, and developer tools often follow that pattern.
If I had to boil the article down fast, I’d put it like this:
- Developers find and test the tool first
- Engineering managers judge team fit, cost, and risk
- Security, procurement, finance, and execs can block or approve later
- Small deals lean user-led
- Larger deals shift toward committee review
- Bottom-up deals need usage proof
- Top-down deals need budget logic, security answers, and rollout plans
A big stat stands out: 87% of developers with a leadership role say they influence tech purchases. So even when they do not control the budget, they still shape the outcome.
What this means for you: if you market only to developers, approval can stall. If you market only to managers, you miss early product pull. You need one message for the person who tries the tool and another for the people who approve, review, or block it.
Quick comparison
| Area | Developers | Engineering Managers |
|---|---|---|
| Main role in the deal | Discovery, trial, internal push | Budget, rollout, risk review |
| First question | Will this fit my workflow? | Will this help the team and justify the spend? |
| Proof they want | Hands-on use, docs, fast setup | ROI, reliability, security, rollout plan |
| More influence in | Small-team and bottom-up use | Mid-market expansion and formal rollout |
| Can they stop the deal? | Yes, if the tool fails in practice | Yes, if cost, risk, or rollout does not work |
So no, the answer is not “developers” or “engineering managers” alone. The tool is found by one person, pushed by another, and approved by a group. That is the core idea behind the whole article.
Who is in the buying group for a developer tool
Buying a developer tool almost never comes down to one person.
In most deals, different people step in at different moments. One person finds the tool. Another checks whether it fits the stack. Someone else looks at budget. Then legal, procurement, or finance may step in before anyone signs.
Each role controls a different gate: trial, validation, budget, review, or final sign-off.
| Role | What they influence | Primary concern |
|---|---|---|
| Individual developer | Discovery and trial | Workflow fit and ease of use |
| Tech lead | Technical fit | Technical fit and maintainability |
| Engineering manager | Budget approval and team-wide rollout | ROI and reliability |
| Security / procurement / finance | Compliance and contract review | Risk and pricing terms |
| Executive sponsor | Final sign-off on larger deals | Strategic fit and long-term impact |
So the key question isn't only who shows up in the deal. It's who can stop it.
Developers as discoverers and internal champions
Developers often create the first internal pull.
They find the tool, test it, and decide whether it's worth bringing to the team. In many cases, that first trial is what gets the whole process moving. And their influence isn't small. 87% of developers with a leadership function report influencing technology purchase decisions . That means a developer doesn't need final budget control to shape the outcome. They can still become the internal champion who kicks off the evaluation.
Engineering managers as budget and risk owners
Engineering managers usually decide whether the tool is worth team time and budget.
They're not just asking, “Does this look good?” They're asking whether the tool will help the team ship more, fit the roadmap, and hold up in day-to-day use. Just as important, they need to explain that decision to the next layer of people involved in approval.
In plain terms, if developers start the momentum, managers often decide whether that momentum goes anywhere.
Other stakeholders who can change the outcome
As the deal gets bigger, more review functions tend to show up late in the process and make the path to approval tighter.
This usually starts once the purchase moves past a single-user test. Security looks at data handling and access controls. Procurement reviews contract terms. Finance checks price and contract length. On larger deals, an executive sponsor may need to give final sign-off.
That split between discovery and approval is what shapes bottom-up and top-down buying.
Bottom-up adoption vs. top-down procurement
Developer-tool buying tends to follow two main paths: bottom-up adoption or top-down procurement. That path affects who looks at the tool first, who controls the budget, and what kind of proof the team needs.
That distinction matters more than it may seem. The same tool might start with a developer in one company and with a manager in another. Bottom-up and top-down change the entry point, but the purchase still comes down to the buying group.
Bottom-up: developer-led usage before formal approval
Here, a developer runs into a real problem and starts using the tool to fix it. If it works in day-to-day tasks, interest spreads across the team. After that, the manager steps in to approve broader use.
In this path, proof comes from actual usage. Not just curiosity. Not just a demo. The tool has to earn its place in the workflow.
Top-down: manager-led evaluation before team rollout
In this path, an engineering manager starts with a team need. They review the tool with tech leads or platform owners and decide whether it should be part of the rollout. Developers usually come in later to check whether it fits how they work.
Workflow fit still matters here. But approval starts with the manager’s business case.
| Bottom-up | Top-down | |
|---|---|---|
| Trigger | Developer's immediate problem | Manager's business need |
| First evaluator | Individual developer or small team | Manager or platform lead |
| Budget owner | Manager, after usage shows value | Manager, from the start |
| Final approver | Manager | Manager |
| Proof needed | Usage data, team adoption, workflow fit | ROI justification, security review, executive sign-off |
| Sales timing | Late, often after organic adoption | Early, during structured evaluation |
| Path to purchase | Trial → team spread → paid conversion | Business need → evaluation → validation → purchase |
Deal size shifts how much influence each person has. As the deal gets bigger, one person is less likely to make the call alone.
Who decides at different deal sizes
Deal size tells you who has the most say. As the contract gets bigger, more people join the process. And the odds that one person can approve it on their own drop fast. In plain English: deal size changes who can say yes.
Small-team tools: the user often drives the decision
At this stage, the tool is often self-serve or on a free tier, so the risk feels low. A developer or team lead can try it, see that it works, and get approval fast. In some cases, there isn't much formal review at all.
The bar is simple: does it fix the problem fast?
Mid-market expansion: managers weigh ROI and consistency
Once a tool needs to roll out across more than one team, the engineering manager often becomes the gatekeeper. They want to know if it can scale, if it pays back, and if it fits the team's standards.
Here, developer usage becomes the manager's best proof point. If a small group of engineers already uses the tool and output has gone up, that starts to look like a business case. Workflow fit, ease of adoption, and measurable team impact are the things that move mid-market deals ahead.
Enterprise deals: committees and executive sign-off matter
Enterprise purchases usually go through a buying committee. That often includes engineering, security, procurement, and legal. The conversation changes too. It moves from day-to-day usefulness to security, compliance, and scale.
As the deal gets larger, the center of gravity shifts from usage to governance. Developers still matter, but in a different way. They confirm that the tool works in practice. And they can still stop adoption if the tool fails technical review, even after leadership has approved it .
| Deal Size | Main decision-maker | Key Evaluation Criteria |
|---|---|---|
| Small-team | Developer / Team Lead | Utility, ease of adoption, immediate pain relief |
| Mid-market | Engineering Manager / VP of Engineering | Team productivity, workflow fit, measurable ROI |
| Enterprise | Buying Committee (CTO, Security, Procurement) | SOC2, SSO, scalability, compliance, total cost of ownership |
Once you know who leads at each deal size, you can shape the message for that person.
How to target and message each role
Knowing who shapes the deal is only half the work. The other half is giving each person the message they need to say yes.
Messaging for developers: usability, speed, and workflow fit
Developers tune out fuzzy claims fast. So instead of saying "a powerful observability platform," say "find the failing query in 30 seconds." That lands better because it tells them what they can do.
A simple gut check helps here: can a developer get a real result from the page in five minutes without talking to sales? If not, the message is probably too soft or too vague. Trade demo CTAs for API docs, free trials, or templates. Developers usually want to test things on their own and see if the tool fits their workflow before they talk to anyone.
That same style of message shouldn’t stay the same once the buyer shifts from an individual contributor to a manager.
Messaging for engineering managers: reliability, team impact, and budget logic
Engineering managers aren’t looking for code samples first. They need proof that the product will help the team, lower risk, and make sense for the budget.
A good move is to build a champion kit with:
- a rollout memo
- a one-page ROI summary
- a security overview
Manager-facing CTAs should send people to demos, case studies, or expansion planning talks instead of self-serve trials. At this stage, the question is less "Can this tool work?" and more "Can this team adopt it without pain, and is the spend justified?"
Those role shifts should shape where each campaign goes, not just what it says.
Routing campaigns by org-chart signals
Start with title and seniority. Developer-focused content like code-level proof, sandbox links, and tutorials helps drive discovery among individual contributors. Manager-focused assets like ROI data, architecture diagrams, and security whitepapers help during approval. For high-value accounts, add account-based marketing (ABM) aimed at engineering managers and CTOs directly .
Also pay attention to multiple sign-ups from the same company domain. That’s a strong sign that organic adoption is already in motion. When that happens, shift the message from individual feature wins to team collaboration and enterprise governance. Platforms like daily.dev Ads let you target by developer seniority, programming language, and tool interest, which helps you reach likely champions early in the discovery phase.
Use buying signals to know when to move from developer-first messaging to approval-stage messaging.
| Adoption Stage | Primary Persona | Key Signal | Campaign Focus |
|---|---|---|---|
| Discovery | Developer / IC | Documentation visits, GitHub stars | Code-level proof, free trial CTAs |
| Team Adoption | Team Lead / Senior Dev | Multiple sign-ups from same domain | Collaboration features, team onboarding |
| Evaluation | Engineering Manager | Multiple active users | ROI data, case studies, demos |
| Procurement | VP Eng / CTO / Legal | SSO/SAML inquiries, SOC 2 requests | Compliance docs, ABM outreach |
Conclusion: Target the champion, sell to the buying group
Developers often kick things off. Managers usually sign off on rollout. And as deals get bigger, security, legal, and finance step in too. In other words, the buyer shifts by stage, not just by job title.
You can see that clearly in companies that move from bottom-up use to formal approval. Postman is a good example. It started as a developer API client, then changed its story into an enterprise governance platform, reaching 98% of the Fortune 500 by 2024 . Developers drove adoption first. Then the company made the case for approval, which turned usage into revenue.
Buying motion, org chart, and deal size shape who holds the decision at each stage. That’s why the same tool needs different messaging during discovery, evaluation, and procurement. Target the champion, but write for the people who can approve, block, or expand the deal.
FAQs
How do I know whether to target developers or managers first?
Usually, you start with developers.
That’s how most developer tools get picked up in the first place: from the bottom up. A developer tries the product, likes it, and starts using it in day-to-day work. From there, they often become the first internal champion, pushing adoption through hands-on use and technical review.
Then, when buying starts to look more serious, shift your attention to engineering managers.
You’ll usually see that moment coming when a few signals show up at once:
- Usage is getting close to free-tier limits
- More than one user from the same organization is active
- People start asking about features like SSO, RBAC, or integrations
Those signs often mean the conversation is moving from “Does this work?” to “Can we roll this out across the team?”
What signals show a deal is moving from product-led adoption to formal buying?
A deal often starts to look like a formal purchase when high-intent signals pile up inside one company.
Here’s what that tends to look like:
- Multiple users from the same domain sign up
- Free-tier usage gets close to 80% of plan limits
- Team invites start climbing
Technical behavior matters too. If usage shifts from quickstarts to API docs, or toward SSO, SAML, and RBAC setup, that’s a strong clue the team is moving past casual testing. Production deployments and pull requests tied to integrations are strong signs as well.
What content should I create for each stage of the buying process?
Match your content to each stage of the developer buying journey. Early on, people want help with a technical problem. Later, they need proof for teammates, managers, and purchasing teams.
- Discovery: original research, compliance-focused SEO, and engineering deep-dives that help developers learn, compare options, and find your product in search
- Evaluation: documentation, quickstarts, sandboxes, and code snippets that let people test things fast and see how the product works
- Team and manager review: integration guides, architecture fit content, and peer case studies that help teams judge fit, risk, and internal buy-in
- Procurement: ROI calculators, SOC 2 docs, security whitepapers, and MSA templates that help move the deal through legal, security, and finance