Delegating, Managing & Letting People Go

Introduction to Execution Cadence

A managed IT company needs a steady management rhythm. Client issues arrive every day, engineers work across many environments, and small delays can become outages. Without a clear cadence, the owner becomes the help desk escalation point, project work gets missed, and the team spends its day reacting to messages.

An Execution Cadence gives the business a repeatable operating rhythm. It normally includes short daily coordination, a weekly service review, and quarterly planning. The goal is not to hold more meetings. The goal is to make ownership, priorities, and problems visible before they damage clients or cash flow.

A daily service huddle might review major alerts, overdue tickets, scheduled changes, client risks, and engineer capacity. A weekly leadership review can cover service-level agreement performance, billable utilization, project margin, client satisfaction, and hiring needs. Quarterly planning should set a few clear priorities, such as reducing after-hours escalations or moving all clients to a standard backup platform.

Delegating Effectively

Delegation in managed IT means transferring ownership, not simply handing someone a task. The owner must define the result, the deadline, the limits of the decision, and the evidence that the work is complete. The person receiving the work should know when to act independently and when to escalate.

For example, instead of telling a senior engineer to “handle onboarding,” the owner can assign ownership of the new-client onboarding checklist. The engineer is responsible for creating user accounts, enrolling devices in the endpoint management platform, confirming backups, documenting network details, and reporting completion by the agreed date. The owner reviews the result rather than performing every step.

Start delegation with repeatable work: new-user setup, Microsoft 365 license reviews, backup verification, firewall change requests, quarterly business review preparation, and project status updates. Give responsibility to the person with the right skill and capacity, not only to the person who has always helped the owner.

Managing with Metrics

Good management uses a small set of visible service and people measures. These numbers should help the team improve, not create fear. Useful measures include first-response time, tickets closed within the SLA, reopen rate, documentation completion, project tasks completed on time, and the number of escalations that reach the owner.

Review metrics by person and by process. If one engineer has a high ticket count but poor documentation, the answer may be coaching or a better checklist. If every engineer misses change windows, the change process may be weak. Numbers should lead to a specific action, owner, and due date.

A service dashboard can show that 92% of tickets met the SLA this week, but six urgent tickets were escalated to the owner. That tells the manager to examine the escalation rules and engineer training rather than celebrate the SLA number alone.

The Importance of Firing

Keeping the wrong employee can be expensive in managed IT. A technician who ignores security procedures, leaves poor notes, or treats clients badly can create risk far beyond their payroll cost. Before ending employment, set clear expectations, provide coaching, document missed standards, and follow applicable employment rules.

Do not confuse a skills gap with a character or reliability problem. A junior technician may improve with mentoring and a runbook. Someone who repeatedly skips required MFA checks, hides mistakes, or refuses feedback may not be safe to keep in a client-facing role.

A fair decision protects clients, the team, and the employee. If improvement does not happen after a clear performance plan, act promptly. Make sure access is removed, passwords and tokens are rotated, client information is protected, and responsibilities are reassigned without blaming the rest of the team.

Real-World Application

Consider a 12-person MSP whose founder approves every firewall change, reviews every proposal, and takes every difficult ticket. The founder introduces a daily service huddle, assigns a service manager to own ticket flow, and gives a senior engineer authority over standard changes. The team reviews SLA results and owner escalations each Friday. After two documented coaching cycles, a technician who repeatedly failed security and documentation standards is released.

The founder now spends less time in the queue, engineers know who owns each decision, and clients receive more consistent service. The cadence did not remove accountability; it placed accountability at the right level.

Conclusion

Delegating, managing, and letting people go are connected leadership duties. Build a regular operating rhythm, assign complete ownership, use service data to coach, and act when a person repeatedly damages the business or client experience. A strong MSP does not depend on the owner being the smartest technician in every room. It depends on clear standards, capable people, and consistent follow-through.