How can we achieve diversity and excellence while hiring new employees and building great teams? Listen to this fantastic discussion with Jeff Johnson and Edward Stull. While we often talk about mentoring developers from the software developer’s perspective, we haven’t talked much about what it’s like from the hiring manager’s side of things. Have you ever wondered what the hiring process was really like behind the scenes? Learn the answers to many of your burning questions in episode 23. Arsalan Ahmed hosts a panel discussion with two of the tech industry’s finest, Jeff Johnson and Edward Stull concerning team building and the hiring process.
Happy Learning!
Arsalan: Today, on our discussion panel we have Jeff Johnson and Edward Stull. I’m really excited about this discussion panel because it’s going to be about building a team and doing the hiring, but from two different perspectives. Jeff is on an upward trajectory but is still fairly new to the industry. Jeff has the experience of being a startup CTO and hiring in that context, as well as being on the other side and being hired several times in the last few years. We also have Edward Stull who is a user experience expert but he has been in managerial positions. He has managed teams and hired a ton of people. So here we have two different perspectives, which is what the thought show is all about.
Arsalan: So, right off the bat, I want to ask both of your general impressions about building a team and hiring. Is that something you both enjoy?
Edward: I really enjoy hiring because it ends up setting the success of what your everyday life is going to be. If you have a good team, work can be a real joy. If you have problems with the team, then it can be like a bad relationship. The job of hiring folks is probably the most important task you can do. Teams are echo systems. So, you want people to be happy and like they are doing good work. But, the introduction of new people into that echo system can make that team either happier or less so.
Jeff: I totally agree. It is such a core piece. When you’re looking at developing a product, the team is almost the product in and of itself. The growth from line 0and the person to the point you reach as you tack on more team members and libraries become more of a comfortable, natural progression.
Arsalan: If you need to grow and build a team, how do you approach that task? Do you need to think about it, form a strategy, or do a mass hiring, or just get whoever you can get?
Edward: Having a strategy for your hiring process is definitely beneficial. At a larger company, people have requisition orders to staff folks. But, sometimes you just have an acute need. Knowing what you’re getting into with that hiring is not only good for you but also good for the person you’re hiring. Knowing what you’re getting into is definitely good practice.
Arsalan: In my experience what a lot of companies end up doing is saying they have the budget to hire two warm bodies. So that usually means they need to go out and push for resumes from recruitment companies or put job qualifications and requirements on job websites, to recruiters, or whatever. Then they get back a bunch of resumes, interview the candidates and choose the two people from the candidate pool. What you think, Jeff?
Jeff: I think that’s a big part of the perception in a bigger established environment where you’re working with these business constraints that say this is our budget. We want our team to be as good as it can and we want our team to be filled, and with the right people on it. If your manager can look at you as being beyond just a resource, and say, “Here’s how your career looks here and here’s a growth opportunity that you could have here if you chose to proceed with certain steps on your own.” I think it’s possible to define a good trajectory for a person even if on paper they are a resource.
Edward: I often use the term “trajectory” as well. This is especially true if you hire someone who’s young and they are within the first couple of jobs that they have ever had. You have to be especially careful with hiring younger folks because even as the hiring manager, you could really mess up their career because their perception of work and their boss affects their craft. So, that trajectory comment that Jeff was making is really important. Ultimately it is the person’s responsibility, but your contribution to that as a manager can be huge to folks.
Jeff: I think that it is a really good point that it can go wrong. I think it’s really a good company’s responsibility to acknowledge that they are going to fill a role, but know how they are going to develop the situation and what the expectation is of where it’s heading. I think that ties well with the fact that you really ought to have a hiring plan beyond “two bodies.”
Arsalan: I hope people are able to detect my sarcasm in my last expression. I think that using the word resources works because when you are building an invoice it’s easier to list out your needs in the form of a resource. You can’t throw money and people at a problem and expected to automatically solve itself. Applications and software have some science to and engineering to them. This is another thing that people like to use the term “engineer” when they hire developers, and it’s kind of disingenuous because we are not really engineers. Engineering is a disciplined set of activities that you do to engineer a product. It’s well known, well understood, and doesn’t change often. A developer has to use something that you can’t really point to. As a team, we sometimes feel like developers are interchangeable because they are not really adding anything valuable to the product. They’re just doing the mindless work.
Jeff: I definitely see where you’re coming from because you sometimes get these teams that end up taking on the role of a kind of spec execution programmer. Those are teams where it’s not an area where you get to use some of the creativeness that a lot of software developers got into the field to do. You’re not going to get the best out of that team, either, and I don’t think you’re going to see that kind of growth. A big requirement for that role is identifying how to mix that art and the engineering together to identify folks who have the kind of passion for pursuing that. That’s why it’s difficult to assess a software engineer by having them do a test or create a sample widget for a pass/fail grade. It’s not that simple because so much more goes into it.
Arsalan: It is hard to figure out how to create a team because you don’t really have a bullet list to follow. As an industry, we don’t really know how to filter people and find the right person. When you are a CTO for a startup, what was your product about?
Jeff: it was and still is a web application for scheduling and payment processing for leisure class studios like dance or yoga. It’s “Class Bug” if anyone of you out there is looking to start a yoga studio.
Arsalan: I hope you’re still a shareholder and still get a cut out of it.
Jeff: I’m still committing code just not to the degree of the 24 hours that the startup world can be sometimes. We are web-based, but there’s no way that you could put out a list and say which specific programming languages, and other skills you need. It’s not that easy.
Arsalan: So, my question to you, Jeff, was this. When you have to hire people because you have more work than you can handle, how do you list the qualifications, come up with a list, and how do you communicate the list of what those new people need to have? What are those qualifications? What comes to your mind, Jeff?
Jeff: I would say that for me, it’s easy to start with the tech stack. For me, the qualifications that stand out are the things that would make a great team working experience. They seem like fluff in a lot of cases, but they are core components that you do want to assess when you agree to meet someone.
- The ability to schedule and manage their own work
- The ability to manage a project from either side of it
- The knowledge of understanding a system as a whole
- Communication
Communication is really important. It’s not just about being able to read and write well. It’s also about being able to seek out others if you have a problem or question. It’s also being able to ask for help before that problem becomes a bigger issue.
Thanks for Listening!
Do you have some feedback or some advice for us or our audience? Please give us a review on iTunes, Spotify, Google Podcasts, or Stitcher and share your thoughts.
If you found this episode useful, please go ahead and share it with your friends and family. You can also listen directly and give your feedback on the website.
You can subscribe to Mentoring Developers via iTunes, Stitcher Radio, Spotify, or Google Podcasts.
Podcast: Play in new window | Download
