The 3 budgets

Software engineering salaries come from one of 3 budgets. Which budget pays your salary shapes your day-to-day and influences your career trajectory.

I think this is like a business law of physics. Nobody needs to make a conscious choice for the pattern to emerge.

The 3 budgets are:

• sales/marketing
• research and development
• maintenance

This framing can be useful when thinking about your career vision and positioning statement. I thought of it while reflecting on why some opportunities make my subconscious scream even if they sound good on paper.

Sales/marketing budget

When you belong to the growth org, your results are easy to quantify and measure. You do a thing and number goes up.

These are your growth engineers, sales engineers, devrels, etc. Folk who make sure existing products get sold, people know about their features, and buyers adopt your tools into their workflows.

The budget wants immediate impact.

This can be good. Measurable impact means you always know your ROI, you're close to the money, and your work directly makes money. Yay!

But when you're easy to measure, you're also easy to compare. This invites stack ranking employees and creating internally competitive cultures. Joe vs Jane instead of Joe and Jane vs the problem.

The work tends to be short-term focused. You're chasing the next experiment, client, or marketing fad. Like running on a treadmill.

You're only as good as the multiplier a company gets on pouring money into your bucket. This can lead to a revolving door effect as companies seek to optimize.

Research and development

Research and development (R&D) employs the most engineers. Usually under the umbrella of a product org. Larger companies may have actual research and science orgs.

These are your product engineers, researchers, architects, etc. People who build what your company sells or explore what your company might sell, if it works.

The budget wants growth over time.

This leads to a calmer environment. You're looking to balance retention and features that attract new people. Sometimes you dip towards growth and build features that improve activation (users going from signup to active use). Or you can dip towards research and explore new product lines.

Companies with proper research departments have folks working on ideas that won't be productized for years.

This is really 2 budgets in a trench-coat. Development is different from research. But the commonality is a focus on long-term results.

The shortest period you care about is a quarter. Your work is meant to become an asset and provide value for years to come. Any shorter experiments are meant as stepping stones.

Your work is harder to measure, but the company sees you as an investment. You build what they're selling and the better the product the better the sales and retention.

Maintenance

Maintenance has largely been subsumed by development. That's because of what this budget wants – cost optimization.

These are your sysadmins, folks keeping old systems running, sometimes platform engineers. The company sees this work as pure cost and wants to minimize.

You'll see this role smeared into product development at many, if not most, companies. Unvalued work that someone will do when they get annoyed enough.

Companies hate this budget so much they'll even try to convince you that having time for NFR work (non-functional requirements) is a special treat for engineers. "We give you a generous 2 days every sprint to take care of shit that's annoying! Why aren't you happy!??"

Building internal tools can fall into this category. That unloved admin dashboard that runs the company but never quite gets priority.

Why this matters

Which budget your work belongs to shapes your day-to-day. Growth is measurable and churny. Research is chill and fuzzy. Development is valued and builds over time. Maintenance is always on the chopping block.

~Swizec