How to manage developers and other tech-savvy specialists

As Frank Zinghini and I discuss in episode #5 of our video series, “Go Digital or Die,” there are some tricks to hiring and managing tech-savvy specialists. And given that we are all in the midst of digital transformation, and business is becoming “all” digital, this is an important topic. Here’s some advice on how to how to hire developers and how to manage developers. 

How can a business manager assess a technical person?

Hiring the right person is about character and relevant experience. I’m sure we all have ways to test for character—such as checking references, asking a lot of questions, and letting more than one person interview the candidate, in case they catch something you didn’t. 

But how does a non-technical business manager evaluate a technical candidate? 

First, we have to be aware that today’s workers are used to getting instant answers via Google, watching how-to videos on YouTube, and learning how to present themselves after watching zillions of other people present themselves.

There are consequently a lot of candidates who can talk a good game, but after they’re hired, it turns out they work inefficiently, know less than you thought they did, or, frankly, the work they turn out just isn’t very good. 

Here’s some advice from Frank and I about how to evaluate technical types. 

Rather than just looking at examples of their work, If possible, try using an app or site they have developed, as they look over your shoulder (in person or via a shared-screen meeting). Go through the program(s) or site(s) they’ve built, while they explain what they did and why. 

As you do, think about the app or site as a customer would. Does it make you want to do business with that company? Is the navigation obvious? Does the app or site look fresh and modern, or old and stale? Are the main concepts clearly communicated? 

While you are going through the app or site, pay attention to how the developer talks about the work. Is he open to going through this exercise, or is he reluctant and defensive? Does the person care about the company he worked at and/or created it for? Did he understand the objectives and meet them well? 

Those who are excited about their work, and happy to explain it, will be the most passionate about doing a great job. Those who are defensive and complain (“I wanted to do X, but they made me do Y”), will not work well with the team and will be difficult to manage. 

Here’s some other advice:

Don’t let them talk you into leaving them alone. A lot of programmers have a “don’t worry your pretty little head about it,” attitude toward their bosses or clients. “Leave it to me, I’m the expert.” This is a very dangerous position for a manager to be in, and both Frank and I could rattle off dozens of real-life horror stories involving trusting business managers who thought the tech stuff was “over their head,” and so they just left the techie alone to do the work. 

You don’t want to be like one company manager who was $100K into a development project and then got the word from the development team that, contrary to their assumptions, they wouldn’t be able to integrate the agent reservation system with Outlook, the email system all the agents used. 

You need to keep checking and asking questions until you understand exactly what is going on. When it comes to apps, the gotchas can really get ya, causing you to have to move to a completely different platform and start all over. 

Meanwhile, the problem you were trying to solve doesn’t get solved. 

Diagram, diagram, diagram. Before anyone starts writing code or setting up a new system, make sure you diagram the elements the app or site will contain, the data that the app will send and receive, functions that the app or site should perform, and triggers (such as the user taking an action, or another program sending information) that will cause the app or site to react with an appropriate bit of information or another function. 

This part is so important. If you don’t do this, you’ll be building a house and then realizing partway through that no one thought about installing the wiring. 

Know that there is no such thing as a perfect app. Even though we’ve all been using software for decades, applications still have a long way to go. I’m sure you’ve experienced that in your own work; personally, I am finally seeing task management software coming to a point where it more closely resembles how people actually work. But there are still apps lagging; try finding a good shared whiteboard program, for example. 

Assume that mistakes will be made. Tech is quirky. One misplaced slash in a string of characters can keep you from tracking visitors to your site; another small command used improperly can keep Google from indexing your site. These are real-life mistakes made by real smart people. It can, and will, happen to you. 

When it happens to us, we just keep moving, using the “Find It, Face It, Fix It” method. 

Know when to provide the right kind of help. As Frank mentions in the video, company owners have three roles:

1. Manage: Give specific instructions about what needs to be done. 
2. Mentor: Teach the basics, and then help the individuals get better as they put them to work.
3. Lead: Provide inspiration and vision. Be a good example. Be clear about your goals. 

You also need to be aware that, as the boss of many different types of people, each type needs to be managed differently. An engineer or finance guy suddenly in charge of a team of artists or writers will find it challenging to manage and lead. Engineers managing engineers know what those engineers need to get their jobs done. A graphic designer or writer will have a whole different set of requirements. 

The best way to solve this problem is to sit them down and ask them outright what they need. Don’t expect an immediate cogent answer; the question will surprise them. Give them a day or two to think about it. Based on our experience, they do need structure, but they also need the freedom to approach the task from a fresh angle. Giving them the right balance of structure and freedom will be a challenge, but it can be done. 

Be agile, but also be procedural. “Fail fast, fail often,” rings true in today’s fluid, fast-moving business environment. However, as with all other management endeavors, striking a wise balance is the key. It’s great to try new things; in fact, it is necessary in order to stay competitive. But progress can’t be made without the support of processes; certain procedures assure success and need to be followed. 

The trick is knowing when to be agile and when to be rigid. A good leader can do both.

Listen, then decide. Lastly, every worker and every customer wants to know they’ve been heard, are respected, and will be supported. This was true before tech took over, and it’s true now that we are all immersed in tech. It’s the core determinant of business success.