Results 1 to 10 of 10

Thread: Managing staff

  1. #1

    Managing staff

    As we've grown, I've found that managing staff has become rather difficult. It was so much easier when it was just 2 or 3 of us and I was involved in nearly every support ticket or issue. What makes things even more difficult is that we don't all work in the same office or even at the same time.

    I think one thing that hurts me here is that I started this company when I was 23 and I had very little experience working in large teams before this - and even though I was a "manager" in other jobs, it was over small teams and for a relatively short period of time. So I'd love to hear how others have approached this and what worked/didn't.

    To me, managing employees is more than just breaking things down to how many tickets they answer per shift or how fast they respond, etc. Life would be so much easier if it was. But there's projects, research, documentation... and so much more that needs to be done and tracked.

    How does everyone track employees, keep them motivated, on task and happy? I hate micromanaging but at times feel I need too.

    Oh and outsourced support companies, please don't spam me with your awesomely low rates per ticket. I'm not interested. Thanks.
    Fully Managed Fast Hosting
    In Vancouver & Toronto
    Canadian owned & operated
    ezp.net

  2. #2
    Join Date
    Nov 2009
    Location
    Victoria BC Canada
    Posts
    93
    Quite simply, management of people is an art form. Trial and error.

    I have managed people over a decade, and have had my fair share of learning experiences. There is a great book that I have read more recently The Leadership Challenge by Kouzes and Posner. It really helps differentiate leadership vs managing, leadership is about providing a vision and guiding people, where managing is about managing tasks.

    As a leader, you need to ensure that you keep an eye on what is going on, inspect what you expect as they say, but sit down with people and be clear and articulate what you expect of them and what they are accountable for. What people hate is when they do not know what you want of them, open the conversation up about what they need and want from you, and what you need and want from them.

    Be personable, friendly and approachable and keep an open mind and not judge quickly. Ask lots of 'whys' when someone does something wrong, understand them and what motivates them. Be a curious individual.

    I also really like looking at operations, and where people need to interact with eachother, who they report to, and where the roadblocks are. The team can give you much better authentic details as to their roadblocks and barriers to doing their job better.

    I have always been a very hand's on manager, and when teams grew and I was responsible for more and more staff, it really becomes about trusting others to do the right thing, and that can be a really hard thing to let go of.
    FullHost.com PRETECS NETWORKS INC.
    Shared Hosting | Reseller Hosting | VPS | Managed VPS
    24/7 Support
    Servers in Toronto & Vancouver, Canada

  3. #3
    Join Date
    Aug 2010
    Location
    CPU
    Posts
    2,187
    The challenge I have is to see myself to my employee; meaning them to do exactly what I want and how I do things. However, you need to remember that these are different people. You need to give them sometime and watch them doing things on there on. Maybe it will ended up that they have a better solution or efficient shortcut to some task.

    If you're in one location, meet them more often and let them speak or express themselves. Ask them for ideas or suggestions. If they are outsource or working in another location. You need to double your effort to make sure that they will deliver. Maybe some incentive program or rewards. However, you need a constant / regular monitoring on these guys to ensure that your company is still providing quality service.
    Ask for Server IP & Nameservers IP to check if your reseller provider truly provides 100% white-label.

  4. #4

    dotudi Visigoths,

    We grew from 2 staff to having one of those original staff members manage 4 programmers - not a lot I know but still a big jump!

    We found the most useful thing was involving the programmers in the strategic direction of our business. We meet with them every month and go through financial projection, marketing plans, business direction etc etc. Sure you think your technical people don't care about this - but our turned out to care a lot. It gives them direction, gives them knowledge about where the business is going and keeps them engaged. We also had four more minds to give ideas on our business!

    To our surprise they also told us they felt more "emotionally" connected to the business when we took their ideas and opinions on board.

    I'm not sure if you are in a position to do that sort of thing but we found it worked wonders. With staff more emotionally loyal to the business they are easier to manage!

  5. #5
    Join Date
    Apr 2009
    Location
    OnTheWeb
    Posts
    2,397
    @ lostmind. The key to your question is based on Trust an Delegation. Think of your organisation as a pyramid with top level management (directors) , middle level management (managers , supervisors) and then lower level management (Team leaders, Lead designers , Senior Sales and Support Reps) and the ordinary staff afterwards. You need to group your employees accordingly so that the management and the people or tasks being managed is equally proportionate to your business model. You would need to ensure that no one manager or supervisor , has too many people to handle. You would also need to hold meetings according to your business's schedule. For eg, if you know that major events happen just about every 2 weeks, you may need to hold weekly meetings to ensure you stay on top of what is going on and when. Also, please do not try to get involve in everything because you would not be able to. That is where the trust comes in. You need to trust your managers to make the right decisions for your business or organisation. Do you think the Directors of Coca Cola knows the names of most of the supervisors in each plant or distillation? NO! They do not have the time! They may have statistics about the strength of the work force ie 10000 cleaners , 5000 supervisors, 50 managers but beyond that they may not know who is who within the organisation the lower down the chart you get.

    You need to work on your business system and not necessarily on trying to control or know everything. You need to draw out guidelines of conduct. have a manual on proceedures to undergo when a particular situation presents itself and so forth. That way, every employee can be trained to suit your business.

    There is a lot more to know but you need to really read books, get a mentor and do some trial and error processes of your own to get it right.
    If you're the smartest person in the room then you're in the wrong room

  6. #6
    Good day, lostmind:

    If you don't have one already, I strongly recommend an employee handbook documenting all policies, procedures, etc. for a manager, an employee being managed, etc. to follow.

    Depending on the job, employees should have some means of documenting what work they have accomplished as well as what's on the table. Some jobs like accounting might be as simple as this is a list of what needs to get done by the end of the week; and then let you know what didn't get done.

    There should be regular communication between a manager and the people being managed.

    Any praise-based action should be as company public as it fits.

    Any disciplinary action or action where there needs to be some form of correct must done privately.

    Where possible, managers should take the time to work alongside an employee to relearn the pros and cons of the job, to show the employee the manager can do it not just talk it, etc. This is better done face to face, in person vs. remotely; but with tools like Webex and the like, remote is doable.

    Part of the employee relationship building is finding out what motivates each employee as an individual (whenever possible). Some people are only motivated by money, others by praise, others by time off, or others by gifts.

    Thank you.
    ---
    Peter M. Abraham
    LinkedIn Profile

  7. #7
    Quote Originally Posted by dynamicnet View Post
    If you don't have one already, I strongly recommend an employee handbook documenting all policies, procedures, etc. for a manager, an employee being managed, etc. to follow.
    Absolutely. I would recommend reading "E-Myth Revisited" in order to learn more about why this is absolutely essential. I got done reading that a couple of months ago, and it's already made a huge improvement in my business, and more importantly, where the business is heading.

    You can't delegate work unless you trust the person to do it correctly, and you can't trust someone to do it correctly if they have no idea how. Someone has zero chance of knowing how to do something correctly if you haven't explained what needs to be done for it to be considered correct. It's hard to explain what is "correct", and hard for people to commit to doing things "the right way", if "the right way" is not documented.

    It sounds pretty simple, but the ramifications are huge:

    1) Your processes and procedures need to be something that is consistently repeatable by someone with a minimal level of skill and training. A great procedure produces the same result every time. A bad procedure is one that produces a perfect result but only when a specific person with expert level skill is doing the work. If you don't follow rule 1, your business cannot grow beyond the workload that your expert staff member can produce.

    2) These processes and procedures need to be documented, and your employees need to be trained on them, else you will have no consistency of performance. This goes back to point 1, that if you're the only person who knows how to do a job correctly, that job with either only ever be done by you, or it will be done incorrectly. Either case is unacceptable if the business is to ever grow.

    3) People often won't do what you ask them to if they don't know why they're expected to do it. Documenting the "whys" of your business is at least as important as documenting the "whats" of your business. This is because the "whys" are what allow others to change your procedures while staying true to the vision of the business and the goals of the organization. Without documenting the "whys", you will be the only person capable of deciding on and documenting the "whats" of the business, which is just as serious of a bottleneck as failing on items 1) and 2).

    Start at the top, why are you in business in the first place? What specific beliefs do you have about conducting business that cause you to make the decisions that you make about how you've decided to run your business? Then drill down. Why do you have procedure X? What goal is procedure X intended to achieve? What problems is it intending to avoid? For the goal of procedure X, is it obvious how it relates to your company's core beliefs and larger strategic objectives? If it does relate but it's not obvious, you should document why the goal relates to your larger objectives. If it doesn't relate to your larger objectives, the goal of the procedure may need to be rethought, and therefore, the procedure itself. Next, does the procedure itself do a good job of achieving the goal of the procedure? If not, it should be changed to something that does. For those who want to change a procedure (and that will inevitably be anyone who interacts with that procedure), knowing the goal of the procedure provides a valuable benchmark to decide if a proposed change takes you closer or farther away from what you should be trying to accomplish. Without documenting the goals of a procedure, everyone will suggest arbitrary changes to the procedure that you will have to either veto or give in to, seemingly arbitrarily. When the goals of both the organization as a whole and the procedure specifically are documented, your decision to approve or reject a policy change can be firmly rooted in the goals of the organization.
    Last edited by funkywizard; 02-17-2012 at 04:51 PM.
    IOFLOOD.com -- We Love Servers
    Phoenix, AZ Dedicated Servers in under an hour
    ★ Ryzen 9: 7950x3D ★ Dual E5-2680v4 Xeon ★
    Contact Us: sales@ioflood.com

  8. #8
    Dynamicnet & funkywizard.

    Great points. I have just recently read the e-myth revisited myself, but find it hard to implement nearly all of the takeaways I got from the book in this biz/industry. Mostly because, well, most of the job is not routine repeatable operations.

    All I've managed to do so far is basic basic general guidelines. This is why we're in business, these are our goals, this is how we intend to accomplish our goals.

    But the actual day to day procedures? Only a few things are routine. The rest requires staff to make judgement calls all day long.

    I suppose one could say I've documented (most) of the why's of the business. The what's of the business are where I struggle.

    I suppose it's easier to see how one would apply this to someone else's business because I'm buried neck deep in mine - can't see the forest for the trees or so.
    Fully Managed Fast Hosting
    In Vancouver & Toronto
    Canadian owned & operated
    ezp.net

  9. #9
    Join Date
    Jan 2011
    Posts
    669
    Managing your team is tricky as the team grows, you have to learn the trick of the trade simultaneously. You can offer incentives to get them to work and show their maximum output to be able to get those incentives.

  10. #10
    Quote Originally Posted by lostmind View Post
    Dynamicnet & funkywizard.

    Great points. I have just recently read the e-myth revisited myself, but find it hard to implement nearly all of the takeaways I got from the book in this biz/industry. Mostly because, well, most of the job is not routine repeatable operations.

    All I've managed to do so far is basic basic general guidelines. This is why we're in business, these are our goals, this is how we intend to accomplish our goals.

    But the actual day to day procedures? Only a few things are routine. The rest requires staff to make judgement calls all day long.

    I suppose one could say I've documented (most) of the why's of the business. The what's of the business are where I struggle.

    I suppose it's easier to see how one would apply this to someone else's business because I'm buried neck deep in mine - can't see the forest for the trees or so.
    That's obviously a huge challenge, but one that needs to be resolved if you want to grow while offering consistent service and quality. Nobody said it would be easy

    The big thing about E-Myth is to get you thinking in this direction, because if you don't, it's easy to form habits that are non-repeatable, non-documentable. To a certain degree, your focus on managed services makes it extremely difficult to construct a training manual that would actually be useful for troubleshooting customer problems. On the other hand, just giving up entirely is really not an option.

    Here's something that's more actionable:

    Look through your recent tickets, and pick a kind of issue that's come up a few times recently. There should be three phases of the problem: The cue (how you determine you're dealing with this particular problem), the work (what process you go through to troubleshoot a problem like this), and the conclusion (how to tell if you've finished working on the problem, and what to do when you've reached this point).

    Say I've got someone who says "Sometimes I get poor performance on this server. How do I know if a disk is failing?"

    So in this situation, you'd start with your procedure "troubleshooting poor server performance", and because the customer has given you a hint as to what they think is wrong, skip to first work on the subsection "troubleshoot poor disk performance".

    So the first step here is to look at iostat -x 10 10 and see what it says.

    I happen to know this customer is using the server for minecraft, so I'm fairly aware of the expected disk usage patterns here (lots of random writes and not much else). I also know what kind of performance you can expect from a typical disk drive (about 150 random i/o/s).

    Looking at my results, I see that the server is doing around 100 or so random writes per second, which is a solid % of what you can expect the drive to be capable of. The util% reported is pretty low, under 25%, so these two combinations of statistics tells me that the drive is operating at its expected performance level; the drive is almost certainly not failing.

    The next thing I look at is await, the average wait time of a write operation. In this case, it's 100-150ms, which, because of the way minecraft writes to disk and updates clients, can often cause lag. For whatever reason, a MC server even with the disk util% well below 50%, can lag pretty badly if the await is high. Combining the 100 i/o/s out of an expected maximum of 150 i/o/s, along with a high await and a low util%, I can safely say that this drive is working fine, and that you can fully expect that occasionally it will not be running as well as you would like (games will lag sometimes).

    Because I've found the answer to the customer's question, I report my results and make my recommendation (either live with the problem or upgrade to an SSD). I then ask if there's anything else I can do to help. This concludes the ticket.

    Now, ok, let's say you document this experience and write a procedure for it. This is a fairly common case and therefore can be used pretty often, but certainly there are any number of other things that could have happened. Disk i/o and util% could have both been low, in which case it's not a hard drive performance problem at all, and the drive is probably fine. Then you have to look elsewhere for the issue. Disk i/o could be low but util% high, in which case there's a strong possibility of the drive failing, and in any case, it's definitely a drive performance problem. The read / write pattern could potentially not have matched what is expected for his use case (minecraft server), in which case it would have been appropriate to find out why there was so much unexpected disk activity. Or any number of things really. But certainly how this played out was the most likely thing to have happen, and it is a problem we deal with frequently, so by all means it would be useful to document how to handle it. And then the next time something similar comes up which ends with a different result, you document how to handle this new scenario, almost like writing a choose your own adventure book.

    If the above sounds like a heck of a lot of work, it definitely is. As a managed host, you are responsible for fixing a wide variety of problems, and if you want to make sure that those problems are fixed in a consistent manner, you need to document your procedures. Because there are so many kinds of problems and solutions, the manual can get pretty big just documenting the most common cases.

    Ideally you'll want a ratio of Junior to Senior Technicians, maybe 5 to 1, and the key to doing that is by making 80% of the work routine that can be handled by anyone who has read the training manual, and the other 20% can be exceptions where an expert can simply apply the company philosophy and guidelines but doesn't have exact steps to follow. Your job is to figure out what 20% of work situations account for 80% of the actual work, and document how to handle it.

    Sometimes this will mean trading perfection for consistency. Doing something perfectly 50% of the time and very badly 50% of the time is much worse than doing something adequately 95% of the time. Part of your job is to identify a different way of looking at a problem so that you can make a policy that can be consistently enforced. For example, our IP allocation policy used to be "if Gabe thinks the person is going to waste ips, they can't get any more ips". The upside here is that if I'm really good at figuring out if someone is wasting ips, I can provide ips more in line with our goal of giving ips to people who need them and not to people who will waste of abuse them. The obvious downside is that it relies on someone (me in this case) to make a judgement call. What if I'm not available? What if I want someone else to assign ips today? Can they be trusted to make a judgement call? Even more importantly, will my customers be able to rely on me to make the same kinds of ip allocation decisions every single time? Maybe someone signed up because they thought that their use case, which requires a certain number of ips, would work fine, and then they come to see that I or someone else on my staff makes an arbitrary decision that felt like the best idea when it was made, and now the customer is stuck. They expected one thing and got another, so they made plans and worked around a situation that they couldn't rely on.

    So instead I make a policy: up to 8 ips for general use, up to 32 ips for VPS or game servers, beyond 32 requires detailed justification, and if you want more than 8 and you're not doing vps or game server, you need manager approval. In no situation is email or SEO or proxies a valid justification for getting more than 8 ips, and in no case may you ask to swap out an existing ip with a new one unless the ip was 'broken' when we gave it to you. In no situation will we give out more than 4 ips per 1gb ram no matter what the justification is.

    There's only one situation above where a judgement call comes in: someone needs more than 8 ips, for a reason we haven't specifically excluded as unacceptable, but for a reason we haven't expressly permitted as acceptable. The reason this is an exception that requires a judgement call, is because it doesn't come up often enough for us to know what our policy should be here. In fact, if we get a lot of these requests, then the use cases / justifications that come up most often will either end up in the "acceptable" or "unacceptable" list, and over time the percentage of cases that require any judgement at all will decline quite a lot. So it's a policy that doesn't achieve perfect results, (someone could lie and say they're doing game hosting when they're not, or maybe they should get 16 ips maximum but we allow them 32 without detailed justification), and it's a policy that's not automatic and consistent 100% of the time (as there is a situation present that requires a manager to make a judgement call), but the policy does achieve our goal most of the time, producing fully acceptable results in most cases, while providing consistent results in most cases. Compare that to the previous policy of "if Gabe thinks the person is going to waste ips, they can't get any more ips", and you'll see this is clearly a step in the right direction.

    The point is to know what direction is the right direction, and to purposefully head in that direction. Don't expect to ever get there, but always work to get closer.
    IOFLOOD.com -- We Love Servers
    Phoenix, AZ Dedicated Servers in under an hour
    ★ Ryzen 9: 7950x3D ★ Dual E5-2680v4 Xeon ★
    Contact Us: sales@ioflood.com

Similar Threads

  1. [HIRING]GameServer Support Staff And Sales Staff
    By neXolt in forum Employment / Job Offers
    Replies: 7
    Last Post: 01-24-2005, 12:24 AM
  2. managing VPS, managing dedicated
    By zinneken in forum Dedicated Server
    Replies: 1
    Last Post: 04-18-2004, 12:00 PM
  3. Sales staff and also Support staff needed!!!
    By jonmck1234 in forum Employment / Job Offers
    Replies: 2
    Last Post: 11-03-2003, 02:28 AM
  4. NEED IMMEDIATE RESPOND FROM Ev1 Staff or WebHostingTalk Staff!
    By jrianto in forum Shared Hosting Offers
    Replies: 9
    Last Post: 11-27-2002, 03:04 PM
  5. Three Part Job Positions. SysAdmin - Night Staff - Day Staff
    By Sean in forum Employment / Job Offers
    Replies: 6
    Last Post: 08-10-2002, 04:48 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •