How to Lead a Top Class MSP Engineering Team

Here’s a question I often ask myself…. I’m not an engineer. Why, then, am I a successful manager of engineers?

1. First, I know what I don’t know, and I trust them as subject matter experts.
2. Second, I trust but verify. While I may not be trained as an engineer, I have years of experience listening to engineers, managing IT for a variety of industries, managing complex IT projects, and managing IT engineers. Therefore, I’ve developed ways to partner my knowledge with theirs. This is key when it comes to leading engineers

In a nutshell, you don’t necessarily need to have the same level of technical expertise of people you manage to be an effective manager and leader. But in this article, I’ll explain what you do need to know.

How to Lead at a Technical Level – An Example

Let’s talk through this on the basis of an example, that of a new project. Below are some considerations and a working process as you lead your team through a technical process.

Where does a project conversation begin? With the customer’s needs, of course, and a solution recommended by a salesperson or an engineer (depending on your business structure). Next, a subject matter expert, aka, an engineer, needs to verify the solution and fill in any missing pieces. The steps I would suggest and are below.

1. Review lessons learned on previous projects. Maintain a database of projects by industry, operating system, application, and more, or a collection of project plans – including closure documents – to use as a reference. Project plans, meeting agendas and minutes, and timesheets should tell us where we met, went over, or were under budget. Change Orders should inform us of additional questions to ask and potential hurdles that may need to be overcome. This is required reading. Should someone declare “that won’t happen with this project,” they must be able to tell the team why. That answer may spark yet another angle that must be explored.
2. Ask the engineer to draw the solution. Ensure there is a line item on the project plan for every step and an hours budget to complete each. The hours budget should not be limited to completing the work; include prep (creating new or updating existing documentation of current environment, backing up current configurations, OS or application upgrades, for example), completion of the work – including after-hours cutovers if required by the customer – and then creating or updating environment documentation.
3. Ensure the project plans of newer engineers are reviewed by seasoned veterans. Even if the veteran hasn’t completed this exact project (rarely, if ever, are two IT projects the same), their field experience will prove valuable, either in the form of suggestions or in simple verification that “it” will work.
4. There is more than one way to complete every task. Encourage dialogue. That we all think differently is the best way to ensure we’ve approached the project from every angle we can conceive, individually and collectively.
5. If you haven’t done so, already, begin to document successful, standardized installations. These, used alongside your project library, will provide you with the framework for not only this project, but your next one, as well. Continue the dialogue around this standard with each engineer who builds this environment, modifying as operating systems and applications change, and as new lessons are learned. These standardized installations should include a suggested budget for each phase. Spending the time documenting this knowledge, now, will make your future planning more efficient and your projects more accurate, increasing not just customer satisfaction but the satisfaction of your engineers and your company, as well.

How to Lead an MSP Team at an Inter-Personal Level

While the above is a good example, it’s more procedural and process-driven, right? It’s likely stuff that you’re doing already (or should be doing already). Thus far, I’ve outlined only how to communicate with engineers on a technical level. But how do you communicate with engineers as people? This is where MSP leadership becomes an art and less of a process.

To start, It’s important that you believe your team comes to work each and every day desiring to be successful.

• Ensure you are meeting with them on a recurring basis both as a group and as individuals. I find success meeting with my team monthly during the lunch period, providing their lunch (and giving them the opportunity to decide the food.) Sometimes I have an Agenda (corporate updates, rumors to clarify, goals to set, input needed), and sometimes we simply talk about what is on their minds. Yes, we take notes (but no one has ever asked to see them.) I encourage free, respectful dialogue. Planned in advance, most of the time, the billable work can be scheduled around these meetings, ensuring the entire team can attend, in person, together. This is important because it is rare that IT teams are sitting at their desks all at the same time with opportunity to work as teammates.
• Working at an MSP is stressful work. Multiple client demands, more work than time to complete it, unexpected outages…all of these can weigh heavily on engineers. If an engineer feels there is no one to share the responsibility, it can lead to burnout. If the engineer knows s/he has a team to rely on if/when needed, job satisfaction (and, therefore, retention) is higher.
• At each meeting, I ask them to share something they’ve recently learned. And even though they are salaried, I respect their right to a duty-free break and encourage them to take an hour for themselves before or after our lunch meeting.
• I schedule quarterly conversations with individual members of my team. (More about this follows.) by meeting with them individually and as a team, I am able to discern the difference between an individual concern and a concern shared by the team. This helps me know where I need to focus my efforts in supervising and supporting engineers.

By now, you are asking yourself, “when am I supposed to fit in all of these meetings?” You already are. But the time you are spending is probably reactive, rather than proactive. I work hard to schedule and plan the conversations with my staff, rather than make the time for conversations that must happen because something went wrong. Here’s how.

Running Effective Meetings with Your Team

Team (lunch) meetings – Pick a day of the week likely to have the least impact on billable time. Pick a week of the month. Send a meeting invitation to your team, including a conference room and any administrative staff necessary to make this a success, for a recurring meeting, 12 months at a time. Mark your calendar 3 months ahead of the last meeting to re-evaluate your day of the week and week of the month and create (and share) the new recurring meeting (or continue as is, extending the end of the recurring meeting.) Create, for yourself, a recurring calendar item a few days before each meeting to order lunch, call for Agenda items, and create the first draft of the Agenda. Create a recurring calendar item immediately preceding the meeting to finalize the Agenda, set up the room and manage the lunch delivery.

Meeting with individuals – On the first day for a new hire, I schedule a follow up within the first week; another follow up after a two-week span; another follow up three weeks later; then monthly for the first 6 months. After that, the individual meetings are quarterly, falling in line with their hiring date. These are easy to calendar in advance. If something has to change, the engineer needs to reschedule with me (or me with the engineer). Don’t let the unknown prevent you from scheduling. Get it on the books now, and you won’t overlook it. Current staff are scheduled to meet with me for their evaluation the month of their hire. They are also scheduled to meet with me quarterly. Create a spreadsheet with the name and date of hire. Document the corresponding dates by quarter. Send meeting invitations. When this is a habit, the meetings become pretty short, as a rule.

This is the agenda I’ve used and would suggest. These questions are embedded in my meeting invitation, so the engineer comes to the meeting prepared.

1. Do you LOVE your job?
   1. If yes, what specifically do you love?
   2. If no, what prevents you from loving your job?
2. What are 3 things you are proud of having accomplished since our last one-on-one? (Keep in mind this should never be longer than a 90-day window if you’ve followed my directions, above.)
3. What do you need from me to succeed?
4. What do you need to do to succeed?
5. What has it been like (again, looking at the last 90 days) to be supervised and supported by me? (Because my job as the lead Project Manager took me out of the office often for months at a time, this question was super important to me as it allowed me to adjust my ‘level’ and style of management as needed for the engineer or for the team.)
6. What do you wish <I usually insert the name of our CEO, here> knew? [If I sense dissension in the ranks with a VP, or a sales guy, or another member of our company, it is that name I insert here.]

I don’t require engineers to love their job, nor do I require them to appreciate me as their manager. I don’t record these meetings. The only notes I take are those items I need to guide myself to improve or continue, should there be something in my management toolbox the engineer finds beneficial. But this open dialogue works. It makes it easier for me to supervise and support, as few things sneak up on me and take me by surprise. I feel informed – not an easy task those months I spend only 1 day/week in the office. And we feel connected, which means retention is high. Should an engineer decide to leave, I tell them I will support them in their staying, and I will support when they choose to leave the company, but they must make a fully informed choice, either way. If I’ve done it right, that is exactly what happens.

Final Thoughts

A bonus of this method of supervision and support is I find engineers become comfortable dropping in my office as needed, because they think of me as a collaborator, not just as their boss. And they know there are times I will just listen. When an employee asks if I have a minute or simply appears in my office, and it appears there is something on his/her mind, I ask if they are here to vent or if they need help solving a problem. Their answer dictates how I listen. When an employee comes in to vent, s/he is looking for my courage and reassurance. If s/he is looking for help in solving a problem, I need to respond using my skillset and experience.

Is my system infallible? Not by a long shot. I’m pretty good at reading people but when I’m wrong, I’m really, terribly wrong. It hurts to be blind-sided. But I learn. And I don’t quit trying. Neither should you.

What about you? Have you tried some of these management styles? Do you attempt something different? We’d love to hear! Let us know in the comments section below!

Looking for some more leadership articles? Our article on industry certifications is a great one when it comes to working with your engineers on what to study on!

Thanks for reading!