Unemployed Agilists: How to Move from a Staff Role to a Line Job, Part 2

Manage Your Job SearchYou're an unemployed agilist. And even if you can find an agile coaching or Scrum Master job, the pay is so terrible, you don't want to take it. That's because potential employers think these jobs are staff positions. Your previous managers and potential managers don't see the value of someone in your position.

That's because these managers think agile coaching and Scrum Mastering is a staff job, not a line job.

Staff jobs only offer intangible and peripheral value, as I briefly discussed in Unemployed Agilists: How to Show Your Value to Support What Managers Want, Part 1. But line jobs offer value that can result in something the customers can use, which means those jobs offer some sort of net revenue increase.

Let me first describe the difference between staff and line jobs.

Define Staff and Line Jobs

Staff jobs support the organization's overall mission—as overhead. In product development, line jobs contribute to the products themselves, which means they contribute to revenue. That's why companies cut overhead jobs, often with layoffs, whenever they think they need to save money.

Cutting overhead is definitely not personal—it's all about how managers perceive an employee's value. That's why showing tangible value, as I asked you to do in Part 1, is so important.

Worse, many staff jobs are commodity positions. While managers can determine how different various developers, testers, UX, etc people are, very few managers can differentiate one agile coach from another. Or, one Scrum Master from another. That often means managers want to categorize an unemployed agilist in “overhead,” not in “R&D.”

Cost Categorization Matters

If you're not sure what I mean by categorizing costs, look at your former company's Profit and Loss statement. You should see SGA: Sales and General Administration—overhead. Look farther down a little, and you'll see R&D costs. Companies want to reduce all the costs, but they want to keep overhead to a minimum and to keep R&D costs to some (small-ish) percentage of total revenue. (Agility allows R&D costs to be capitalized earlier, which is why managers want agility but they could not care less about “agile.”)

If your company is publicly traded, market analysts will look at the P&L to analyze both the SGA and R&D costs. Those analysts don't like to see R&D costs get too high. And if your company is a startup looking for funding? Same problem, different kinds of analysts.

Here's the bottom line: Every manager needs to keep their costs as low as possible and the net revenue as high as possible. That's why they cut any job that looks like a staff job.

However, you have expertise you can turn into a line job.

Rethink Your Expertise So You Can Apply for a Line Job

Before you became a coach or a Scrum Master, what did you do? What kinds of technical skills did you have?

In Hiring Geeks That Fit, I categorized technical skills into these four areas:

  • Functional skills, such as how you build or test the product. For Scrum Masters, have you ever been a project or program manager, where you had to work with customers, across the organization and facilitate a charter, etc? Those are functional skills.
  • Subject matter domain expertise (problem-space and solution-space). At what level do you understand the products you've worked on? Problem space is a customer (outside) orientation. Solution space is from the product (internal) orientation.
  • Tools and technology: Operating systems, languages, anything specifically technical.
  • Industry expertise. The unsaid expectations of the industry in which you work. For example, if you have 20 years of experience in banking, you know a lot about the various regulations and how they affect product development.

Now, assess your technical skills to prepare for a line job.

Assess Your Technical Skills

How many of your technical skills are still useful? I like to say I am an old programmer, because my tools and technology skills are in old languages and operating systems that no one cares about and often, no longer exist. And I haven't done any formal development or testing in a very long time.

But I've consulted for a long time. That means I can use my problem solving, organization, and learning skills—part of project and program management—as a basis for a new role. And I am quite capable of reasoning about products from a solution space perspective.

These skills plus my deep agile and lean understanding, would allow me to use the flow metrics to increase agility. Notice that I did not discuss any specific framework or method. Instead, I used principles to clarify my technical skills so I could affect net revenue.

That's what I hope you do as you rethink your expertise. Remember the pirate metrics so you can consider how you affect net revenue in some way: customer acquisition, activation, retention, referral, revenue.

Rethinking  is just the start of your changes. I'll suggest specific actions in the next post. I'm going to stop here because this is long enough.

The Full Series

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.