Stating the Obvious: Recruit Internally
Tealium has been on a steady state of growth for years and we are constantly looking for new talent on the developer side. While growth is a great problem to have, the challenge is how to sustainably grow a team. Should talent be developed internally or recruited externally?
Engineering managers in California have a number of options when recruiting developers early in their careers. These include the local State and “UC” (University of California) schools, local Code Academy “graduates”, and those submitting resumes online. Of course, the best place to find new hires is your own network, but a hiring manager typically does not have a large number of Junior-level contacts in his or her network. However, we do have an internal network close by that is a great place to find the next entry-level hire: technical members of your Client Services or Customer Success team.
Now, before I explain my reasons why I want to state a few reasons why not to hire internally from other departments. First, you want to build a diversity of perspectives on any team. And, hiring people who have no history with your product will bring in some great new ways of looking at the problems to solve. These external hires will not be content with the status quo. Also, if your company is small, taking a top-performing person off the customer-facing group too soon may not be wise.
If you do have systems in place to train new hires (to replace the ones that move out) and a plan to make sure there is no customer impact, then everyone wins when you can recruit internally.
The following are my top three reasons to recruit internally from the Technical Client Services team when building out your Engineering team.
(1) Hire A Known Entity
It is a risk to hire anyone, but that risk is reduced significantly when you hire a known entity. If an individual has a track record of being hard-working and bright, then you can be confident you are making a good hiring decision. This person has respect across the company and you are sure that this person is a good culture fit. Finding the right culture fit in an interview when you have no direct history working with someone takes some skill. An interview also won’t reveal how someone deals with stress or conflict.
(2) Keeps Someone Good Longer
It is not easy to compete against the green grass of the next exciting new software company that just opened up in a nearby town. This effort is worth it. Here are a few subtle reasons to keep your top technical support talent as long as possible through internal recruitment.
(2a) Better at Your Company than the Alternative
You can’t keep a talented person in Technical Support for longer than three-to-four years. Often, you are lucky if you get more than two years. By providing an internal career path you are retaining talent. This is a good idea even if for the simple reason you do not want your competition to benefit from the years of experience your employees gained in your space.
(2b) Internal Tools Have Extended Lifespan
Typically a customer success person who is successful in their role has also built some internal utilities in their “free” time. These tools make the jobs easier for others on the support team. These tools are likely to continue to provide value if their creator is still around and happy to maintain them.
(3) Customer-facing Experience is Invaluable for a Developer
While anyone can learn to code by reading books or taking courses, understanding the customer’s perspective takes experience. The majority of developers taking programming roles to crank out the latest UI in the latest UI framework often lack an understanding of what they are building and why they are building it. Spending just 6-9 months answering phone calls fixes this, but most developers did not spend years in Computer Science classes to get on the phone with a person complaining about a bug. Here are the three built-in skills that your Client Services team member will have automatically:
(3a) Knows How Things Should Work
Client-facing team members will know the most about what customers expect the product will do. And, they understand what “not-working-as-expected” looks like. This perspective, brought over to Engineering, will mean that you are much more likely to release the right thing the first time. The traditional Engineering mindset of ‘just get it out there and then iterate’ is fine, but it’s even better when your clients note that more than once, they have exactly what they were hoping for before they asked for it.
(3b) Understands Urgency
Anyone who understands the customer understands the benefit of releasing the right feature ASAP. Successful team members with years of experience working with clients are driven by their own internal deadlines to create a happy customer as soon as possible. That means you have client-advocates on the Engineering team wondering why things are not released yet. Their previous teammates are waiting for an important bug that needs to be fixed. They know what it is like to have to handle fifteen tickets in the same day on the same issue.
(3c) Can Train Others
An important part of being an effective trainer is knowing your audience. What will be confusing to this audience? What are the knowledge gaps that this audience has? The Client Services person has had to explain the same thing many times — and each time to someone who was hearing it for the first time. Developers need to train QA or even Marketing around what a feature does or doesn’t do. This is second-nature to someone with customer support experience.
I hope you find this perspective validating your own or inspiring you to find your next star contributor from somewhere close by. If you do recruit internally, be sure to: 1) communicate with other managers and agree on timing and transition plans; 2) set clear expectations on how long you expect your new Engineering hire to transition their old duties — protect them by getting all parties signing off on a clear plan (specific date) to cut-over to full-time developer; and, lastly, 3) make sure they are the best candidate by interviewing them exactly as you would an external candidate. It’s never a slam dunk, so your team should interview external candidates simultaneously for comparison.