How I Vet Other Business Process Consultants
Look, hiring sucks.
It is the most time-consuming thing you can do, and it is always needed when, by definition, you have little time to dedicate.
There is no silver bullet to this. Is it possible that someone who checks all of these boxes could still ghost you halfway through a project? Sure. Set clear expectations, communicate often, do all the things good managers do.
But this is the standard I hold myself to, this is what I look for to tell if another consultant I meet is “legit”, and this is the advice I give my friends running their own startups when they’re looking to hire.
I hope it helps!
Let’s set some ground rules
Let’s assume three things about you:
You already know how to find these people
You’re not looking for a button clicker.
You don’t have the technical skills required to evaluate their technical skills.
How to find business process consultants
Need to find your systems integration consultant before you can vet them? Search Google, search LinkedIn, search Upwork. Take an hour and reach out to 4-6 people. Hustle and just get it done.
You’re not looking for a button clicker
A button clicker is someone you hire when you already have everything exactly mapped out, and you just need someone to execute. They click buttons for you.They don’t architect solutions, they just implement what you have already designed.
If you already have everything mapped out, great! Have a few people show you demos and pick the one who scores the highest across eagerness, availability, and whose demo most closely matches your vision.
You’re a founder, not a CTO
Or you’re a COO, CEO, CMO, etc.
Point is, you’re not technical. Maybe you know just enough to be dangerous. You could be good at Excel, or maybe you have put together a few Zapier automations, but architecting a whole automated system or building a web app or whatever you are trying to do is well outside your realm of expertise.
If that’s the case, how do you effectively evaluate someone else’s technical chops?
This person is going to be building the core engine of your business --- How can you make sure that they are both the right technical fit and that they are going to understand your niche well enough to strategize with you?
Flip the problem on its head. Don’t evaluate their technical skills because, quite frankly, you can’t. Evaluate their ability to . . .
Understand your business and your goals
Know themselves & their own limitations
Learn from their experiences
The person who can do this will overcome technical limitations to execute for you. They will also opt out of working with you if you’re not the right fit (and hopefully point you in a better direction).
If those three things (you can find people, you don’t want a button clicker, and you are not a CTO) don’t line up with who you are, you probably already know what you need to do, and it’s not reading this blog post. Go do it!
Can They Understand Your Business & Your Goals?
Are they curious? Do they, unprompted, ask you about your goals?
And not just the problem you are trying to solve right now. But your goals for the business, for the future. What are the problems behind the problem? What are you really trying to accomplish?
If you are looking for someone to build the engine of your business, then they’ve gotta understand it at a deep level. And that’s not something you can force down on them from above.
You’re not going to think of everything you need to tell them right away. They won’t have complete context to build the absolutely perfect thing right after the first call. And, honestly, they probably won’t think of every question they need to ask either. There will always be gotchas and potholes along the way. Especially in a fast-moving startup.
So what do you do? You hire someone who is hungry for deep insights into your unique situation.
Green flags:
You get the sense they are genuinely trying to see the world through your eyes.
By the end of the first or second meeting, they are starting to fill in the gaps that haven’t been discussed. They say things like, “Oh, and then you’d probably want to do this? And then also this other thing?”, and your response is “Yes! I wasn’t even thinking about that, but that’s exactly it”.
Red flags:
They immediately jump into demo mode. This shows they are more interested in showing off what they can do than in learning what you need.
You just get a sense they are a bad listener. I have never succeeded at solving that problem.
Do they give you value right away?
Presumably, moving quickly is going to be important to you. You have a problem and you need it solved. That means whoever you hire needs to “hit the ground running” as is written in every job description on AngelList.
Do they give you new insights into a complicated problem? Do they show you how to use a new feature you didn’t know about before that you can implement right away?
This is all a really good sign that they are going to hit the ground running, because quite frankly they already are.
It also shows that they are selfless -- they are putting you, the client, first, and they’re not trying to make sure they get theirs first.
Have they learned from their past experiences?
What’s their plan for handling breakages?
Do they have a strategy for how to avoid errors AND fix the ones that inevitable come up before they impact a client?
Or before they affect an employee trying to do their job, the system, whatever is most important for you and your outputs.
Look, things are going to break. Apps go down, bugs crop up (even in no-code systems), and tools get used incorrectly.
If you need one tiny Zapier automation set up, then no worries. Go find someone who knows what buttons to click. But if you are trying to get to your next round of funding off of these tools, then having visibility on the system, and responding quickly to issues will be critical.
Everyone with experience will have their own answer to this. It’s an art that’s still being figured out, and it’s a little different for every setup. But they should be able to clearly and succinctly answer this question.
You can’t stop bad things from happening, but you can hire people who worry about it so that you don’t have to.
Do they pull out their trophy case of hacks?
This is going to get some flak, so sound off in the comments below: Hacking is bad.
If someone is really proud of the airplane they built out of toothpicks and bubble gum . . .that’s great, but do you really want to fly in that thing? Do you want to trust your growth goals to that setup not breaking?
Sometimes, hacks are necessary. You need to string two things together quickly to get a critical feature out the door, and it’s a little messy and chaotic, but it gets the job done. That’s fine.
But you shouldn’t be proud of it. And you should put it on the list to clean it up when you have some breathing room. Why? Because hacks break. And when they do, they’re really fucking hard to fix.
Before I wrote no-code, I wrote real-code for growth teams, and my mentor, Noah, the CTO of Teachable told me:
“You need to be twice as clever to fix a mistake as you were when you made it. Therefore, if you max out all of your cleverness when writing code, you’ll never be clever enough to fix the bugs that will inevitably happen.”
In other words, keep it simple. You’re never as smart as you think you are.
If you want to scale, your tech needs to help you, not hurt you. And I have seen too many times when a dev created something they thought was clever only for it to come back and bite them (and the entire company) in the ass.
The person you hire can hack on their own time. And, they should be curious about trying new things . . . but when they are working on your shit, everything they do needs to be well within their wheelhouse.
In other words, do they know their own limitations?
Do they know more than just their one tool?
Everyone likes to talk about the T-shaped skillset, and you should be looking for that in your hire.
Firstly, because no tool stands in isolation to itself. In my preferred toolkit, Airtable’s power is magnified by Zapier & Typeform.
But, also because they should be able to point you in another direction if their preferred tools aren’t the best for the job. You probably already have a software in mind when you’re talking to this person. Maybe it’s Airtable, maybe it’s Zoho Creator or Quickbase or Bubble or Adalo.
They should be asking you about your needs and determining if the tools you already have in mind and that they are (presumably) really good at actually make the most sense for what you are trying to accomplish.
Sidenote: This is also critical for when you outgrow your tools. It’s not necessary that this initial person is also the one who can help you transition on to something else when you hit scale, but it helps.
Ask them: Now that you know about us, what do you think? Iis X tool really the best for us? Why?
See what they respond back with. Can they articulate when someone shouldn’t use this tool?
Do they know what types of problems they solve well?
Just because someone knows a software doesn’t mean they are going to be good for your business. Do they solve every problem under the sun or do they have clear guidelines that they help clients within?
Can they articulate when someone should use their preferred toolset, but not hire them? Do they have other experience they are bringing to the table than just being a tech whiz?
If they seem desperate to work with you and claim they can do anything, then those are clearly red flags.
And . . . That’s All I’ve Got
Nothing is guaranteed in life, but I deeply believe that if you follow that approach, you’ll be a lot better off.
Cheers,
Jackson