How To Manage Technical Workers Without Being Technical Yourself

While having technical experience is always an asset when managing technical workers, it’s not a prerequisite.

Management is a skill unto itself, and in this guide, I’ll cover four effective management techniques you can use to better manage technical workers even when you’re not a “technical person.”

But first, let’s review why technical people require special attention and a slightly different approach compared to typical employees.

Why Technical People Require Special Attention

The first and most important reason that technical workers require special attention is expense.

Building technology is expensive.

Employing skilled developers and other technical people is expensive.

And perhaps most importantly, there are no easy do-overs in tech. Having to start over from scratch is usually going to be a colossal, ludicrously expensive undertaking.

Your job as a manager of technical people is to communicate very clearly what you need done. Miscommunication quickly leads to compounding problems and may not be fully resolvable.

Additionally, technical professionals may have a tendency to avoid asking the important questions. Instead, they may make assumptions in order to speed up the process or to continue in a way that suits them rather than refer back to you.

By making the effort to pay extra attention and ensure lines of communication are wide open, you provide more opportunity for them to check with you first, and less chance for them to move ahead with a project down the wrong path.

Another reason to keep close tabs on your technical team is because you are less technical. This specialization is a total black box to many business owners, and by staying close to the work, you’ll have a chance to learn things and to prove your interest in and support for the team’s work.

Finally, and potentially the most pressing reason of all, is the fact that many projects are unsuccessful not because of bad developers, but because of sub-par managers. This is true across the board for all industries, and can have devastating effects for projects and team morale.

In fact, poor management is one of the most commonly cited reasons for employees quitting their jobs, so it can affect much more than the outcome of your projects.

pasted image 0

Our recent blog on hiring, managing, and retaining virtual talent offers pertinent advice for those managing workers out of the office, but many of the tips can also be used for in-house employees: proactively building relationships, paying on time, and making staff feel valued.

Naturally, giving your teams special attention — hearing them when they offer opinions and feedback, ensuring they feel supported, and showing interest in their well-being — can help to improve project outcomes, regardless of how much you know about the technical side of their work.

1. Make Sure You Fully Understand What You Want

Technical professionals can often seem like miracle workers with their impressive skills, but if you are looking to simply throw them into a project and reap magic as a result, you are setting yourself up for disappointment.

While intuition is a helpful quality to have in an employee, it’s not the job of an employee to guess what they are supposed to be doing or accomplishing.

An undefined target is virtually impossible to hit. This is why knowing exactly what you want is so important.

Don’t Assume. Explain.

I often hear stuff like:

  • “He should have known better.”
  • “Shouldn’t that have been obvious?”
  • “She should have done it that way by default.”

If this is your attitude, you are going to fail.

It’s your job to understand exactly what you want and communicate it.

One excellent way to do this is by introducing user stories, which can help teams understand the context of the features they’re developing.

A user story incorporates three simple elements: who, what, and why.

For example, an online banking customer (who), wants the option to pay exactly half a bill (what), in order to share an expense (why).

This quick and simple tool can help you explain what you need, and help your developers see the bigger picture, rather than becoming wrapped up in building features without thinking about why they’re doing it, or who will be using it once it’s done.

Make Use Of Available Tools

You might not have the technical knowledge to discuss exactly what you need from your team, but with the right tools, you may be able to show them.

Software such as Balsamiq can help you create a quick mockup of what you’re looking for, without needing to know the process of how to get there. By creating a visual reference of what you need rather than simply trying to explain it or write it down, your developers will have a clearer idea of the goal and won’t have to make any assumptions along the way.

It is also easier to have a discussion around something visual, so this tool works both ways, as your developers will be able to ask you questions and make suggestions with the help of a visual reference point.

Be Upfront With Your Budget

It may go against common management practice, but it can prove beneficial to be honest about your budget. Usually, business owners and leaders are inclined to avoid this discussion because they fear the developer might monopolize the money.

However, developers will not only appreciate your transparency, but will also be better placed to negotiate with you on features that can realistically be built with those funds, and within what time frame.

They will be able to let you know what they can accomplish for a certain price, which will allow you to judge the return on investment in each area. You can then decide to go ahead with features, scrap them in favor of something more useful, or opt for a second opinion.

This level of openness can therefore help you work together to ensure the budget is prioritized effectively, and to discuss alternatives that you may not have known were possible, or that you may not have considered.

You can also interrogate further to find out why something is so costly. This will give you an opportunity to use developers’ cost estimates to have an in-depth conversation about the best route to achieve your end goals and to learn more about budgeting for development of future projects.

2. Prioritize Effective, Two-Way Communication

Communication is always important for managers. It’s even more important when you don’t fully understand the work you are managing.

Prioritizing effective, frequent, two-way communication is the best way to bridge this gap and stay on top of technical projects and workers executing them.

Provide Quality Feedback

All workers should receive regular feedback, either to hear that their projects are going well and that you are pleased with their efforts, or that there are areas you think could see improvement.

Positive feedback is an exceptionally simple method for encouraging continued good work and for sustaining positive morale, especially during stressful periods (which is often for developers).

Negative feedback is essential for making improvements, but it must always be shaped in a productive way to avoid demoralizing workers and making existing issues even larger.

This can be a challenge when you don’t necessarily know the technical terms for what you need to improve. Therefore, you must focus on the result you should be seeing, for example:

“I noticed this feature isn’t working as I had expected. I understand I may not have made myself clear enough when explaining what I was looking for. Can we have a brief discussion around that so we can bring this feature to where it needs to be, and so we can work better together in the future?”

This will open the lines of communication so they can offer honest feedback about what could have gone better. From there, you can provide your perspective, meet in the middle, and move ahead.

Most importantly, you should be giving much more positive feedback than negative. Not just “good job, you’re great.” Your feedback needs to tie together two major points. One, it should touch on what the developer actually values — what are they proud of? What makes them tick? And two, how do their actions actually make a difference to the company? This takes some genuine thought and personal understanding of your team.

For instance, if a team member doesn’t value money but instead loves knowing their work made a big impact, then explaining how their work made the company a lot of money might actually turn them off. But if you simply mention how happy the client was with the result, how they “couldn’t stop talking about it,” that might make their day, or week!

Meet Regularly

Meeting often doesn’t make you an overbearing micromanager. It makes you an engaged buyer of services.

So, don’t be afraid to book in regular meetings to stay up-to-date. It is a huge mistake to treat your project like it’s something you ship off and get back weeks or months later.

These meetings can be as simple as a quick daily 15-minute update covering the previous day’s work and what they should be working on today, and potential blockers and issues. When you ask for an update, try and keep them focused on the results of their work, having them list a bunch of tasks you can’t measure or latch onto may not be helpful.

Additionally, set aside a longer time period, such as an hour per week (or more depending on the scope or phase of the project), to discuss broader high-level goals and expectations. Goals can change and shift as projects move into new phases and as you add finer points to the plan. Keeping the team in the loop on the grander scheme can avoid future problems and miscommunications.

These meetings, daily and weekly, are your opportunities to ensure developers have everything they need to carry out their projects. It’s your time to answer their questions and offer your support and to make sure they feel comfortable coming to you with their ideas and concerns.

Without regular meetings, it’s easy to watch as workers mentally check out from their tasks, lose sight of the goal, and stop feeling invested in the broader company objectives.

Don’t Skip Meetings

In a busy work environment, meetings are often one of the first things to be omitted from the work day, especially if you don’t have anything urgent that needs addressing that day.

However, you still need to find a moment to meet, even if it’s only for a short time, as these meetings exist just as much for your developers as for you.

It’s not uncommon for developers to be reticent, so even if they have something important to bring up, they may not insist on meeting when you ask to cancel. In some cases, this can lead to important problems being missed or not being dealt with immediately, which can slow down progress and result in frustration for you and the developer.

Ask For A Recap

The true test of whether or not your developer understands what you want is if they can recap it in clear business language rather than technical language.

It may not be efficient to ask for a recap for every single task (but honestly, you should try). You can practice this strategy by asking for a written summary in language you can understand. Alternatively, sit down and keep asking questions until you’re satisfied that you’re on the same page. When you force them to follow an idea from the technical side all the way through to the business, you often uncover things the developer wasn’t actually all that clear on.

It may sound tedious, but this style of communication is a good way to identify and correct erroneous assumptions in advance. As long as it’s done in good faith, for the good of the company and your developer’s sanity, it will not feel like micromanaging. You’ll be a good boss and leader. I can’t tell you how many times I’ve seen project managers and business owners give up on a line of communication because their first or second attempts to get clarification weren’t working. When a line of questioning isn’t resolved, everyone leaves the conversation uneasy. “What was he/she trying to say or get at?” It leaves doubt and uncertainty. Your team may end up wondering if you trust them or if you’re not happy with their work, when really you just didn’t have the courage to resolve the questions you had. Do everyone a favor and just keep discussing it until all the loose ends in your head are tied up and they make sense. If you’re having trouble, feel free to say something like, “Hey sorry I’m being a little dense here, but it’s important we’re clear on this one…“ and try again until you’ve got it!

Stay Ahead Of Your Developers

It’s important that your technical staff can see the road ahead, not just the next three steps.

To do that, you must write specs and features well ahead of time. You’ll need to be extremely organized and have a clear idea of what you need further down the track.

Without this level of organization and a clear path ahead, developers may subconsciously slow down in their work, or worse if they are part-time, prioritize other client work and leave yours till the end. And if you’re only laying out their projects the night before, you may struggle to maintain a high level of quality across the board, thanks to making rushed decisions and unclear instructions.

Should a developer feel like you’re not putting careful forethought and planning into their projects, they may equally lose interest in the work and not strive for the same level of quality they would aim for if they knew you were making it a priority, too.

Of course, if you reach a stage where you would prefer to have their help in writing plans for specs and features, don’t hesitate to ask for their input, but make sure you pay them for that support.

3. Monitor Closely & Manage Your Risk

There’s a phrase I like to use for the mentality you should bring into hiring and managing technical workers: “be all in until you’re out.”

Hire fast, monitor closely, communicate well and be supportive, stay 100% positive and fire fast when the problems aren’t being fixed.

Know When To Cut Your Losses

Being a good manager is all about working with developers, being positive, trusting one another, and being there to offer support and answer questions.

However, there’s also a line, and once it’s crossed, it may be time to cut your losses.

For example, if you have been working with a developer and continually have issues such as lack of quality, missed deadlines, and too much opposition to your plans, the first step is to work to improve the relationship and the product. You need to be patient and helpful the entire time, it never pays to be so frustrated that you back them into a corner with phrases like, “man this still isn’t working?? How many times have we tried to fix this??”. While I understand the sentiment, it never fixes anything, in fact it likely makes your goal less likely and destroys good will and confidence in your developers. It can permanently damage the relationship.

But if things do not noticeably improve after your best efforts, it may be time to cut ties.

While it’s possible that issues will arise due to your lack of technical skills, it is almost always possible to work around this obstacle through good management and high emotional intelligence on both sides. If problems can’t be improved with constructive feedback, you may be better off starting afresh with a new developer.

Always leave on the best terms possible, if they can’t be successful with you, help them be successful somewhere else. Other developers on the team are watching how you handle yourself in these situations, and they also talk amongst themselves. If you don’t handle it properly, you could destroy loyalty in other team members as well.

Retain Control Of Every Aspect Of Every Project

In order to mitigate risk, it’s important that you retain control of all areas of your projects.

For example, it is best if you create the accounts for each service, email, API, code repository, and project management software. If your developer needs to sign up for something, have them ask you to do it for them.

You can easily share passwords or create user logins for your developers, but it can cause problems if a developer is able to essentially lock you out of the system by not sharing passwords with you. And trying to map out and collect all this information when the relationship is not going well can be a very painful or uncomfortable experience, and if they just leave, you’ll be in a very tough position.

Instead, you can quickly shut developers off from a project should the need arise. You should be able to cut off access to your developers within a few minutes if you need to, starting with their email, APIs, code repositories and so on.

Employ A Senior Advisor To Check The Work

In a normal manager-employee environment, the manager would be able to perform quality control on the work of the employees. However, when you can’t check the work yourself, it can be a solid investment to hire someone who can.

A senior developer or advisor will be able to review the code itself, not just the end result, both to ensure quality and offer constructive feedback.

This strategy is good for your developers as it provides them with on-the-job training and the ability to improve their skills. It is also beneficial to you as it ensures the team is up to par in areas you can’t check yourself, and it will help you to leverage junior and mid-level developers at a lower cost.

Create Clear Documentation

Clear documentation will help everyone have a coherent, definite path to follow.

As a result, developers will find it easier to work on your project as they know what is expected of them at each phase. They can refer back to this information at any time, and start thinking ahead before they even begin.

It’s also good to have a folder of documents where you can file all of your important items, including plans, specs, artwork, accounts, APIs, and services, so you can access them quickly when needed. And again, if you do need to switch developers for whatever reason, this will drastically make the process easier.

You’ll also need to make development environments easy to set up, test, and deploy code to help your developers work more quickly. If your system is hard to use, it can become frustrating for your developer, and costly for you. When you hire a developer, ideally they should be able to sit down, find the background information on the project, find the tasks you want them to do, and easily get up and running.

4. Never Miss An Opportunity To Learn

Just because you don’t know much about the technical side of your team’s job doesn’t mean you can’t pick up a few basics. The more you learn, the more tools you will have to manage technical workers.

Ask questions, learn the acronyms and common terms, and pay close attention when employees explain what they’re doing, probe, ask questions. You’ll be surprised at how much you can pick up just by working with them each day, and you’ll earn their respect for it.

Every developer appreciates a manager who can speak their language, and it’s especially helpful when you’re explaining what you want and when they share issues and ideas with you.

Your eagerness to learn shows a level of respect and care, and even though you won’t walk away from the job knowing how to code, anything you do learn will offer its own rewards.

Final Thoughts

You don’t need to know how to code to manage a team of technical professionals, but you can’t be on the sidelines either. You do need to know the tricks of managing a team of technical experts without having any technical experience yourself.

Fortunately, with a commitment to strong management, communication, planning, and decision making, you can successfully manage a team just as well as you would if you were able to write code in your sleep (and when you hire coders you really can write code while you sleep!).

If you’re still looking for more information on how to predictably build technology and manage developers confidently (while saving money and moving faster, with predictability down to the dollar and day), I prepared a FREE in depth video training on the subject Please Click Here To Watch.

Happy building!

Share on linkedin
Share on facebook
Share on twitter

Learn about internet marketing, digital product innovation and agile business processes

How To Build
Digital Products
That Scale

Build A


Sales Funnel