The Other Kind of Staff Software Engineer

13 minute read     Updated:

Adam Gordon Bell %
Adam Gordon Bell

The article clarifies the differences between engineering roles. Earthly provides reproducible builds essential for staff software engineers overseeing build systems. Learn more about Earthly.

Let’s talk about a career in tech, but not the usual boring stuff about salary or how to pass the interview process at the place with the most oversized comp packages. Instead, let’s talk about how your relationship to how the company accomplishes its goals influences what your job is like and what skills and strengths you’ll develop there.

A Simplified World

Imagine a simplified world where there is only enterprise software and only two broad types of software jobs.

( What is enterprise software? It’s large, bland software for large corporations. My story will also apply to other areas but bear with me here. )

Ok, so only enterprise software exists, and so you can work at two types of companies. First, you could work at a large company, where you build and maintain their internal billing software. Second, you could work outside the large company selling software and development services to them.

You can either work at Duke Energy (a large utility company) or Thoughtworks (a consulting company). But in either case, by some coincidence of made-up-anecdotes, you’ll write billing software for a utility company.

These jobs may sound similar. Some even argue that an internal dev team and external dev team are the same:

If you are a dev team within a bigger, non-tech company, you are basically an in-house agency with one client.

The Coding Career Handbook

After all, at both Thoughtworks and Duke Energy, you’ll work for a utility company. You’ll work to understand the current system’s gaps and develop a solution for them. But there are significant differences between these jobs: One is a line position, and the other is a staff position.

Line and Staff Software Engineers

The division of employees into line and staff comes from the military1. A line officer can fight on the front line, and in doing so, they directly contribute to the core mission. On the other hand, a staff officer contributes only support. They are the doctors, IT people, and administrators.

The term spread from the military to business schools, where it became a helpful way to group employees into categories:

Staff and line are names given to different types of functions in organizations. A “line function” directly advances an organization in its core work. This always includes production and sales. A “staff function” supports the organization with specialized advisory and support functions. For example, human resources, accounting, public relations and the legal department are generally considered to be staff functions.

Wikipedia makes the roles sound innate to the profession: accountants are always staff. But it depends on where the accountant works. An accountant at an accounting firm is a line employee. And so it goes for software developers: you can be either, and which you are will determine a lot about the pace of your job and the career trajectories you are on.

Understand the difference, and it will help you structure your career.

Line Has Higher Stakes

Back to our example, the dev team members at Duke Electric are staff developers. The billing software supports Duke Electric. The electricity is the product, not the billing software. However, the stakes are different for the team at Thoughtworks, even if working on similar billing software at a similarly sized region utility company (Dominion Energy, maybe).

Someone at Thoughtworks sold Dominion Energy on the idea that Thoughtworks could do a great job on the billing software, and they are going to charge a lot for this work. If things go well, they will get follow-on business and maybe even a whitepaper. From there, Thoughtworks will try to get into more regional utilities ( Florida Power & Light, here we come!). In other words, if you work on the team deployed into Duke and endanger the project timeline, you might end up on the ‘the bench,’ which is a half-step away from a lay-off.

On the other hand, if someone in billing complains about you and you work on the internal dev team at Duke, your boss will deflect that, and life will go on. Market pressures don’t apply to internal teams, which can be both good and bad. The internal customer has one vendor (you), and you, in turn, have one customer. It’s not better than working at a consulting company, but it is different. Each has career advantages and disadvantages. And I’ll get to that shortly but first, let me beat this distinction to death.

Profit Center vs. Cost Center

A similar concept I’ve heard used a lot is Profit Center vs. Cost Center. I found this phrasing less clear because it’s never obvious what a profit center is and what a cost center is. Everyone wants to present themselves as a profit center. The concepts are similar, though.

I like that staff vs. line is role-based rather than business-unit-based. So, for example, an Agile coach embedded in the dev team of a highly profitable product is still in a supporting role ( unless the company is selling burn-down charts and platitudes) and, therefore, a staff position.

Staff vs. Line Examples

Here are some examples of roles:

  • You maintain logistics software in a dev team at Walmart. Staff
  • You work on logistics software that your company sells to Walmart, Target, or other companies. Line
  • You are the expert at customizing the ERP software from SAP at a large accounting firm. Staff.
  • You add new features to ERP software that SAP sells. Line
  • You are an in-house recruiter at a software company. Staff
  • You are a recruiter at a recruiting company. Line
  • You work in PR at Google. Staff
  • You work in PR at a PR firm. Line
  • You’re a doctor on a military base. Staff
  • You’re a doctor at a medical hospital. Line

Some Roles Seem Mixed

Things aren’t always as straightforward as in the military: where “Will anyone ever shoot at me?” draws a clear dividing line between line and supporting roles. The Wikipedia definition asserts that if you make a product your organization sells, you are a line employee, and the farther away you get from that, the more of a staff employee you are. By that measurement, if you work at a software company but maintain the hand-rolled internal ticketing system, you are staff.

However, another way to think about it is that the internal tools person is a software developer at a company that makes money with software, so they are a line employee by role, although perhaps in a staff position.

Things are murky, but I think you can tell what type of team you are on by what it feels like. For example, suppose your platform engineering team, or dev-ops team, is high pressure and highly respected and is considered an essential part of how the organization accomplishes its goals. In that case, it’s a line position. But if it feels like a slower-moving, sometimes ignored, backwater, then it’s a staff team.

Sometimes the easiest way to tell is to look at the org chart.

The Org Chart

In most cases, the easiest way to tell if you are line or staff is to look at the org chart of your business. You are line if your role makes up the largest fraction of the org chart. There will always be fewer doctors than soldiers in the army and fewer IT people than accountants at the accounting firm.

In many cases, the staff (orange) and line (green) departments can be recognized by looking at an org chart. Supporting staff roles are less numerous.

Being a Line Software Developer

Being a dev at a software producing company is a well-explored topic. Michael Lynch’s story about the pluses and minuses of working at google is great. “I was surrounded by the best engineers in the world, using the most advanced development tools in the world, and eating the free-est food in the world.” Also, Zach Lloyd’s Promotion-Oriented Cultures article is worth reading. But quickly to summarize:

  • You’ll get great at software development.
  • You’ll be well-paid.
  • You’ll work with a lot of great developers.
  • You’ll specialize and become great in your specialty.
  • Competition for advancement will be fierce.

The advantages of working at a non-tech company, of being a staff software engineer are less well covered. But benefits do exist.

Advantages to Staff: Corporate Ladder Climbing

It’s going to be hard to climb the ranks of an organization where most of the teams are made up of people who do the same job as you. For example, I once managed twelve people as an engineering manager and my boss, a director, managed around that many managers himself, the pattern continuing up to the CTO. So if you envision being part of the C-suite yourself someday, then out-competing the 12^N people below the CTO or CPO is a brutal way to do it.

Meanwhile, I have a friend building software at a utility company. He is on a team of 6, and his boss reports to the executive level. If his boss goes on vacation, then he is giving status updates to the COO.

This ladder-climbing disparity is how I learned of the staff vs line breakdown. In the one business class, I took in university, the teacher pointed out that trying to become a partner at Goldman Sachs was a fool’s errand, but working your way to CFO at one of the thousands of publicly traded companies was very possible. So staff beats line if you want to be in the C-Suite, and indeed many CFOs end up as CEO when companies encounter financial issues that become a top concern. Similarly, when Starbucks declares tech is its biggest focus and puts Kevin Johnson, a software engineer, in as CEO, it’s a excellent time to be a staff developer at Starbucks.

Advantages to Staff: Business Focus

At a tech company, especially a large one, you will specialize. You may become an expert in a particular subsystem or a particular layer of the stack and then good luck telling your mom what you do. In a staff role at a non-tech company, you will likely have a much larger but shallower scope. You may talk to the stakeholders, make changes to the frontend, build that backend, and keep the database up. Depending on the size of the place, you may do all of that in a single day, and spend time getting familiar with the intricacies of the business your company operates in.

If having a broader scope and understanding how businesses operate is interesting to you, this could be a great fit.

Retiring to Staff

Retiring to a staff role is a typical pattern I’ve seen. You used to work at Thoughtworks on billing systems but now you retire to Duke Energy and do maintenance on the existing billing system. You get to be the expert who can solve real business problems with your built-up expertise and work at a company where tenure’s in the decades and planning is done over similar timelines. ( Finally, you get off the sprint treadmill, and you’ll have so many opportunities to start sentences with “When I was at Thoughtworks …”).

Advantages to Staff: Different Values and Pace

The line of business a company is in, and the type of people it employs affect what it values and what it’s expectations are. A tech company where the average employee is 28 years old will have different values than an accounting firm where the average age is 47 years. If you value working with people for decades more than you value a kombucha keg, then a slower-moving industry might be a better fit for you. A developer at a utility company will get paid less than a unicorn startup, but most utility companies expect you to work there for decades. My local utility company has lower total comp but also has a union and a pension, and they are generally aware that any investment they make in you can be recouped over your career there rather than over the time it takes your shares to vest. For some people, that is a great trade to make.

Warning: Some Industries Suck

Culturally, the tech companies I’ve worked at have all assumed that good employees want to do a good job. As a result, employees are empowered and valued. But unfortunately, I don’t think this is the case everywhere.

My one role as a staff developer was at a place where I felt there was an implicit assumption that people disliked their work and needed to be strongly directed.

The Staff Role Is Under Discussed

So, when considering your next job or thinking about how you want to spend the decades that will make up your career, think about whether you will most enjoy staff or line roles. They are very different, and if the grind of a product company has worn you out, you might enjoy working on a small dev team at a non-tech company.

And if you’ve worked at both, let me know what you think.

What did you find were the advantages and disadvantages?

And no matter your coding career path, Earthly might just be your ticket to simpler, faster builds. Give it a try.

Earthly Cloud: Consistent, Fast Builds, Any CI
Consistent, repeatable builds across all environments. Advanced caching for faster builds. Easy integration with any CI. 6,000 build minutes per month included.

Get Started Free

  1. When talking about “staff” in this article, I do not mean the Staff software engineer role that is found at tech companyies after senior. That is a different usage of the term.↩︎

Adam Gordon Bell %
Spreading the word about Earthly. Host of CoRecursive podcast. Physical Embodiment of Cunningham's Law.
✉Email Adam✉



Get notified about new articles!
We won't send you spam. Unsubscribe at any time.