What common engineering personas care about

Selling to developers is difficult, especially if you've never spent time inside a product or engineering organization. Regardless of the company, these departments tend to operate in a similar way.

Engineering individual contributors

Common role titles:

• Software Engineer/Developer (front/back)
• Senior Software Engineer/Developer (front/back)
• Web Developer

The majority of technical roles at companies fit into this bucket. These are the people writing most of the code. Quite often, they do not manage anyone directly, though they could lead projects and initiatives within the company. Normally, their scope stops at the technical details of the project. Business concerns are often delegated to product or someone higher up in the engineering org.

A good way to spot individual contributors is by how much time they're spending hands-on-keyboard coding. If that number is under 25 hours per week, you're probably not talking to an engineering IC. Engineer ICs generally have pretty wide-open calendars as they try to follow the makers vs managers schedule.

Most of the conversation with an engineering IC will remain technical.

It's important to note that software developers are tasked with ensuring high code quality, reliability, and longevity of code. They are given business constraints in the form of timelines, but revenue, costs, and other common business concerns are not their top priority.

Keep this in mind if an individual contributor's actions seem strange to you.

While this might seem strange to a sales team, software developers have very minimal variable pay. They do not make more money if they ship features that make the company more money. They make more money by focusing on their technical skills, delivering consistently, and empowering others.

This is why your "Hey, wouldn't you like a 314% ROI" won't resonate. It's not their primary focus. Honestly, it's not even in the top 10.

Key metrics

• tickets finished per sprint
• code reviews completed
• code quality on a per-feature basis
• uptime/reliability on a per-service basis
• web performance (core web vitals)

Engineering managers

Common role titles:

• Engineering Manager
• Lead Software Engineer
• Development Team Lead

These are the direct managers of the individual contributors mentioned above. These folks often still code, but not nearly as much as they did before they became a manager. They're likely intimately involved with project timelines, coaching their teams, and are often the hiring managers for their specific team.

Team sizes vary across companies, but this person likely manages somewhere from three to seven developers. They spend a lot of time in planning meetings, one-on-ones, and interviews. A good engineering manager will often coordinate initiatives and advocate for resources internally, but they're not often doing the hands-on work of writing code on a daily basis. There are exceptions, but this pattern is very common in the industry.

Key metrics

• employee retention/happiness/engagement
• hitting roadmap timeline targets
• team efficiency

What a win for them looks like

Engineering managers really understand the importance of developer experience (DX). If their team spends a bunch of time on pointless activities, they might not hit the goals they set out to hit at the beginning of the year. Even worse, bad DX leads to employee retention issues.

Engineering managers care about things that directly impact their direct engineering team. If you're talking about getting their team on a trial, talk about the ROI for their specific team. No need to generalize things to the entire company.

If you can make their team more efficient or happier, you've got an in.

Principal engineers & architects

Common role titles:

• Principal Engineer
• Chief Architect
• Systems Architect

If you're looking at the technical career ladder, the principal software engineer is usually the top technical IC role. These folks do not manage people but rather manage technology choices and projects. To become a principal engineer, you've generally got to be a "get shit done" engineer. The best principal engineers spend a lot of time teaching and mentoring the team below them.

If I had to describe good principal engineers with a meme, it would be this one (hint: they're mostly on the right):

Principal engineers and architects are the visionaries behind the technical direction of a project, vertical, or the entire company. They are responsible for the high-level design and structure of the software, ensuring it meets both current and future needs. They often work closely with engineering managers to align technical strategies with business objectives.

These folks have a deep understanding of both the technical and business issues. They are less involved in day-to-day coding but frequently spearhead important initiatives or prototype new directions for the business.

Key metrics

• Code quality at the company level
• Web performance for the entire company
• Uptime/reliability for all codebases
• Developer efficiency company-wide

At this level, the employee starts to own some responsibility for business metrics but is likely not compensated on these numbers alone. Rather, impacting these numbers is often viewed as a requirement for promotion or being above expectations for performance reviews.

Some examples:

• conversion rate
• churn rate
• top-line revenue
• reducing costs

What a win for them looks like

Principal engineers are always seeking improvements across the engineering organization, whether through enhancing team collaboration, fostering a culture of continuous learning, or streamlining development processes.

If you can offer any of these with a technology or service you're selling, make sure to position it in this lens.

Directors and VPs of engineering

Common role titles:

• Director of Engineering
• VP of Engineering
• Head of Engineering

Directors and VPs of engineering oversee the entire engineering department, setting the strategic direction and ensuring that projects align with the company's goals. They are responsible for managing budgets, timelines, and resources, as well as hiring and developing the engineering leadership team.

Their role is to bridge the gap between the technical and non-technical sides of the business, translating business objectives into engineering goals and strategies.

Key metrics

At this level, the engineering leader likely co-owns some of these business metrics with their counterparts in product:

• conversion rate
• churn rate
• revenue
• budget

What a win for them looks like

Directors and VPs live in deadline hell. If you can ensure speedy delivery of new features/projects, bring that up immediately. The previous organization-wide improvement themes apply here too (collaboration, learning, efficiency).

The CTO

The Chief Technology Officer (CTO) is the highest technical authority in the company. They are responsible for the company's technological vision and aligning it with its business goals. The CTO makes decisions on the adoption of new technologies, oversees the development of new products, and ensures the company stays ahead of the competition in terms of technology.

The CTO often has a background in software development and engineering management, allowing them to understand the challenges and needs of the engineering team. They work closely with the CEO and other executives to drive the company's growth through technology.

In conversations with a CTO, consider that they've got a lot on their plate. Keep your messages short and direct. Do your research to find out what topics they've been discussing publicly. Reach out when you can find a direct way to pitch your company. You get one shot here, and then you're likely delegated to the spam folder, so make your message worth it.

Key metrics

This is where the buck stops. If the outcome involves technology at all, the CTO owns it. All things technical roll up to the CTO, the great new product features, the multi-day outage, the tech debt, all of it.

What a win for them looks like

Top line and bottom line revenue growth, especially where technology is the driver.

Writing a great pitch

Keeping this all in your head is pretty difficult, especially when you're talking to tons of these folks per day. If you're trying to write a great pitch to one of these personas, consider using AutoPitch.ai.

AutoPitch takes into account a prospect's role, ambitions, company tech stack, and more before writing a pitch. Start a trial below.