I'M JUST A RECRUITER... What do you WISH I knew?!


Hi all,

One thing I hear from candidates I speak with all the time is “recruiters just don’t get it”. I don’t want to be THAT GUY who doesn’t get it. Help me out. What do you wish people knew about what you do?

Calling all agile devs, scrum masters, product owners, agile team coaches, agile enterprise coaches.

The poorly educated recruiter who desires to learn.
Also, Matt.


There’s so much, Matt. How long do you have? :wink:

My first few thoughts, and I hope to avoid crafting a wall of text:

  • Job descriptions. Most suck. Most read like Project Manager roles. Of course, even if you learn the difference between the two, you’d have to educate those doing the hiring that they’re not really looking for a Scrum Master.
  • Take a course. Maybe a CSM course or even spend a day with a Scrum Master. Understanding the framework can make a hell of a difference when talking with candidates.
  • Know the difference between Scrum Master and Agile Coach. There’s some seriously religious debates from some agilists around which is what, when to use which, and others who say shut up, it doesn’t matter, and get back to work.

As a parting gift, here’s a blog post I put together after spending a wealth of time hiring for Scrum Masters. Best of luck and fire back questions if you have them.


A few things I’ve always appreciated.

When I say call me in a month do so.

Know your tech stacks. Typescript is different from JavaScript. AngularJS is different from Angular. You need typescript for the second. React and vue are not the same things.

Understand Tdd is important and many devs don’t know what it is. If a devs starts talking about testing, they are worth following up.

Talk tooling, continuous integration and willingness to learn. Again good devs will roll with the punches and keep up with this stuff. What I know now isn’t important, my ability to adapt and learn the next thing is.

The only other thing I’ll say is match my skills to the job. Don’t ring me up for mobile dev work when I have no experience and my cv isn’t hitting the key marks. If I want that style of work, I’ll adjust my profile on linked in and cv to match.

I want to work with a great recruiter, the pushy ones just suck.


The other thing I should note. I once went to interview at an “Agile” workplace. At the first interview, the CTO told me that they didn’t work in low fidelity wire-frames mocks. That I would be the sole developer and we would start hiring other people in 3 months once the contracted design company had done High Quality mocks of how the program should look. Needless to say this set some alarm bells ringing.

Some design lead up can be OK such as putting together a style guide and colour palette etc, but selling a position as “Agile” when you don’t get to talk to customers and there is an external design company doing all the “design” work is disingenuous. So I’d say if ever a company says we are agile and we have a 3-6 month design phase, what they are telling you is we are waterfall, but we use KanBan or Standups to “manage” our developers. Exercise a little caution in how you sell it.


Oh my… where do I start?

I am just coming off the most profound Agile Coaching Retreat I’ve attended… I had 5 colleagues come to my side for three days of discussions around Scrum and its usefulness as a structure in an “infinite game” world.

And therein lies the problem. As a Scrum Master I have authority over the Scrum framework. I am orthodox about it. And I believe that as a framework it touches everything at a company. It’s not just about developers… heck it doesn’t even have to be about software. It touches everyone… accounting, finance, human resources, sales/marketing, and even the executive board room.

The Scrum Alliance has done us NO favors bragging about “certifying” 489,000 scrum masters in 2015. Certification means nothing anymore. And as a result, we have inept, ill-trained people who are woefully inadequate about “spreading the news” about Scrum from the executive level on down through the organization. As a result, VERY VERY VERY FEW (let me repeat… VERY VERY VERY FEW) companies who claim to be “doing Scrum” are actually “doing Scrum.”

That said, a good Scrum Master coaches:

  • The ENTIRE organization on the Scrum Framework
  • Executives and Managers on being as “servant or host focused” as possible.
  • Teams responsible for delivering product (notice I did NOT say ‘software’) on being as self-organized/self-managed as possible
  • Product Owners on taking the lead and truly “Owning” the product as THE CHIEF STAKEHOLDER in the product

That’s it… it’s a simple formula which is terribly difficult to master and a good Scrum Master is well worth his or her weight in gold when s/he is able to create an environment where teams are continuously delivering high quality products with high commitment reliability to customers who are HAPPY HAPPY HAPPY to be using the products and are willing to buy more of them.

Now, it think it is important to stress what I am NOT:

  • A project manager (self-organized teams manage themselves)
  • A project administrator (I don’t do reports… the teams’ success at consistently delivering high value, high quality products, fast, is its own measurement)
  • A project “anything” - in fact there is no such thing as “project” in Scrum… there is a product that, in theory, will continue to be improved and shaped… forever
  • A Gantt chart publisher (Gantt is a word we do not speak in Scrum)
  • A technical coach… a good Scrum Master will coach the teams’ architects and (dare I say, engineering managers) on their role in coaching their teams on technical competencies

At the end of the day… if my executives and managers become servant/host focused and my teams as self-organized as they can be with a product owner who “owns” all aspects to the product, then, I should be “actively doing nothing” at all. If I go away for a conference or on vacation and my organization is humming along when I get back… proving they didn’t need me… I have done my job.

I hope that helps out and I would be more than happy to continue this conversation with you.



Tanner… keep “spreadin’ the word”, brother!


This is helpful - I’ll take a look at that blog post!

Job Descriptions. I hear you there. At my first company, someone told me “there’s no difference between a PM in an agile framework and a scrum master”. The more and more I talk to agile members, the more I see an error to this.
Take a course. Do you have any good suggestions for CSM courses for people who aren’t technical by trade?
Know the difference between Scrum Master and Agile Coach. As I understand it, a Scrum Master is more intrinsically focused on their specific team - protecting them, guiding them, facilitates prioritization of their steps and ensures delivery upon product requirements. Thus being more “inwardly” focused on a/multiple teams of theirs.

The Agile Coach (as I understand it) focuses more on an organizational level. They coach executives, management, and teams on agile methodologies, practices, etc. They offer more of a transformative approach if need be for the organization, rather than a team focus.

Am I on the right track here?


Thanks, Brad. That’s helpful insight.

Assuming you’re on the dev side, you might be able to help me with another question here. For someone who has a non-technical background, what courses or education would you suggest someone to engage in so they can learn some of these principles you’re speaking of? For Example: In recruiting, I’m taught the difference (mostly) between front-end/middle-tier/back-end as well as a few languages that correspond w/ each tier, but nothing of the day-to-day, aside from “they code”. The nuances are typically things that we pick up as we go.

Another question - why is test-driven development so important and what does it contrast with?

What are your suggestions here for recruiters who are national recruiters (have never personally met a manager they hire for f2f) and have never seen the development process for that organization to be able to vet their agility?



Hi David - thanks for the run down! It’s definitely helpful for me to see the distinction between the project manager and the Scrum Master. It’s been a learning curve for me to “un-train” myself from my first agency saying they’re the same thing. The insight will make it much easier to communicate.

Now, when we’re talking distinctions… Your explanation of the Scrum Master and its role in coaching appears to be similar to what I interpret as a coach. I understand there’s some nuance here, so would you be able to clarify? You could also refer to my above reply.

Thank you!


Do you have any good suggestions for CSM courses for people who aren’t technical by trade?

I don’t think a technical background is necessary for the CSM course. The material covered isn’t technical. It’s more a conversation about how and why Scrum works, how each role fits into the framework, and the basics of being an effective Scrum Master.

Your best bet is to find a CST in your area and that fits your schedule. I’m not familiar with any in NC, but here’s one close by that’s coming up from my old CST from many moons ago.

A Scrum Master is more intrinsically focused on their specific team…The Agile Coach (as I understand it) focuses more on an organizational level.

That’s how many view it, but I think that’s wrong. Both has an equal stake in resolving systemic, organizational issues IMHO. I like how LeSS frames the role of SM.


As far as the distinction between Scrum Master and Agile Coach, I don’t believe there is one.


Hi Matt!

I take a more wholistic view of Scrum than most. Certainly, the Scrum Master’s focus is on the team but I think this assumes that that the rest of the organization is also practicing Scrum. But, this is very much NOT the case. The various organizations that certify the different levels of Scrum (such as the Scrum Alliance) have done so to make this distinction. But the certifying process is another discussion for another time. If a scrum team is going to be successful at Scrum, then, the Scrum Master must look at not just the team but at the environment in which the team works… the organization. The various certifications are uninteresting to me because of my general belief that Scrum is pervasive. I work in an organization that has 7 scrum teams. I started with this organization when we had one. I still maintain “Scrum Master” role over two teams but I also “coach” the entire organization on Scrum. My two teams are very self-organized and have learned in the Shuhari form. So, I I simply watch and observe them, now. And, I challenge them to work toward higher levels of value, quality and performance. But, my focus is on making sure the entire organization follows Scrum.

But, at the end of the day, the Scrum Master is not just responsible for the Scrum framework for his/her team, s/he is responsible for making sure the entire organization follows the framework. If they do not, then, the team’s ability to do Scrum will be clipped. I am not one for “making things suck less”. I expect everyone will be doing Scrum or no one will and we go back to tradition project management based work.


Interesting, OK then. I’ll definitely look into the Scrum training. My next question would be this then - do you need to have a technical background to be a Scrum Master? I’ve had hiring managers who have rejected Scrum Masters I’ve submitted because they didn’t hail from technical backgrounds, but took a CSM course and “figured it out”.

So why do some organizations pay double to an Agile coach than what you see from some scrum master jobs then? I’m assuming this goes back to your original post about job descriptions, but is it a principled stand to say they’re the same, or are the responsibilities truly the same? Is there no hierarchy?


Do you need to have a technical background to be a Scrum Master?

That question always makes for a lively debate. Some emphatically say yes, they must have a technical background. Others emphatically say no. It’s not necessary. With some hesitation, I say no, a technical background isn’t necessary. Can it be helpful? Absolutely, but I currently work with a successful Scrum Master whose background is as a school counselor. The role is largely about navigating personalities and having an innate ability to understand and diagnose systems. Having a technical background does help in one realm: coaching technical practices such as those found in XP.

For example, here’s a job opening we have at my company. I think the job description is spot on (largely because I wrote it). Nowhere do you find a need for technical skills. Preferred … sure, but not needed:

So why do some organizations pay double to an Agile coach than what you see from some scrum master jobs then?

I don’t know. Perhaps for the same reason they think a two day course is enough to qualify someone as a master? Maybe because they feel that a title is indicative of the value s/he can deliver?

Is it a principled stand to say they’re the same, or are the responsibilities truly the same? Is there no hierarchy?

Scrum Master is a clearly defined role in the Scrum Guide. In fact, you’ll see a section describing the Scrum Master’s responsibility to the organization like we had discussed previously. Agile Coach though? I’ve yet to see an agreed upon definition of the role across the community. IMHO many claim it when they have no right to or they end up like me where my bio on Medium reads:

“A confused soul who can’t decide whether he’s an agile coach or Scrum Master.”

Is there a hierarchy? Some think so, but doesn’t hierarchy imply title? A servant leader worth his weight isn’t concerned about titles; s/he is concerned more with how valued he feels to those served.


On TDD side, the best way to learn how it works is to do. I like something like http://codewars.com/ to get a feel for it. If you are just starting out, TDD is a little intimidating. Something like Code Wars put it in a less scary framework.

TDD is so important because it helps a developer build code that is easily refactored and maintainable. It also lets a dev test ideas out so that when they have their working code, it actually does what it says on the box. The tests do a number of things, they reveal dependencies (i.e. you change one part in this section and another section breaks), they help you think through a problem systematically, they give you confidence you have solved the issue, they do help improve code quality and to a degree they document what the hell you were thinking when you wrote your code.

The alternative is often coding by coincidence. “Let’s change this bit, it should work” then see what happens. And then when the code is “working” the tests are added (if at all).

I have found every single time I have strayed from doing TDD, the code has come back and bit me in the butt later. It costs a little time, but saves so much more.

If you want to learn the basics of a number of technology stuff related to web, I’d probably suggest http://www.codeschool.com. The courses are simple and interactive, egghead.io is another one I’ve had suggested. For a deeper dive, I like pluralsight.com which covers not only the language side of things but also things like Kanban, TDD and a host of things that face developers. Some courses are amazing, others are just so so, but the breadth is pretty good.

I think that there are others here who might be more qualified on this one. Here are some of my red flags. They talk about a long design phase, they talk about projects not product, they focus on control/reporting structures and line managers more that what is being built. Anything that talks about “rigorous documentation” or “enterprise experience” or “project management” declares a focus I might not be interested in.

Other things might be 12 month contract that will deliver “xyz” at its conclusion would be worth investigating further, places that focus on continual deployments don’t focus on the tail end of a contract.

Something along the lines of you will be coordinating and managing several offshore teams might also be a worry depending on the context, but that one varies.


If I had to answer this question I’d say “I wish you knew as much as me if not more.” When a recruiter calls me up and says “I have a client who needs an agile coach/scrum master/agile practitioner” you should know WHY. You should know what the client is looking to accomplish, what their definition of success is, and what their expectations are. It makes both our lives easier, it prevents wasting time, and it’ll show the client that you’re getting into the weeds to truly understand their ask (better for you!).

When it comes to technology…you don’t have to know how to write the code, but you should understand conceptually what you’re asking for. “A full stack java developer who’s familiar with docker” sounds impressive, but as a recruiter you should at least have a layman’s understand of what that entails, and how that differs from other jobs in the software engineering industry. You don’t have to be a genius, but understanding generally what those attributes are and how the relate to the client’s opening will make a candidate’s life easier and will also impress the client; recruiters are a dime a dozen, but I keep in touch with the ones who I feel “get it.”

Just my two cents. Early on a Sunday, house to myself, over-caffeinated, apologies if this comes off as snarky or insulting.


Hi Matt!
The most efficient recruiters I met were always up to date with their niche market. Who hires, who is available, a very pro-active networking.
In terms of what I expect from my recruiter - apart from the general commonsense stuff, like answering, like keeping me up to date with the selection progress etc - I do appreciate people who know indepth what problems the client is looking to solve when hiring a contractor. In the same time, a good recruiter should, in my opinion, have a good idea about the principles of work to be done by the successful candidate.
Above all, I do expect a recruiter to be open and to understand that a specialist is hired because there is no inhouse knowhow available on client side. As such, the entire selection process should focus on the hands-on experience and skills of the contractor, and not on his past three decades of work :slight_smile: