Software start-ups almost never build a technical support team when the company starts. The salespeople handle support and training at first.

As the company grows it will become obvious to everyone that the salespeople could sell more if they weren't interrupted so much with support and training duties. That's when the company needs me.

I know the tools and processes for starting technical support and professional services teams. I understand the software product lifecycle, and how customers' services needs change through those lifecycle stages.

The articles on this blog will cover the whole process of building and managing these services teams, over the whole product and customer lifecycle.

I know a lot, but not everything. Ask me your tough questions. Challenge my assumptions. I look forward to learning from you.

I am available for contract work, if you want to talk to someone about the specifics of your situation.

-Randy Miller | william.randy.miller (at) gmail.com

Wednesday, October 27, 2010

Management style

Question: What is the best management style for a services team?

Answer: I can't say what is best.  I can only say what I have done.  I had very low turnover and our customer satisfaction ratings continually improved--so what I did must have worked at some level.

I hire smart people.  I put them in a position to succeed.  I actively maintain the lines of communication with each person.  I monitor their progress and help when needed; but I stay out of their way as much as I can.  My job is to help and support them as they do their jobs.

I am tremendously committed to the old adage "praise in public and correct in private."

In my experience, these are the things I have found necessary to put my people in a position to succeed:
1. They must understand the goals and boundaries of their positions.
Goals are obvious.  I see no need to cover those here.

Every stated goal needs an anti-goal, too.  Anti-goals are the failure conditions.  It's not enough to say that the goal is to deliver their assigned widget within 3 days.  The anti-goal needs to say that widgets that are not delivered within 12 days will bring certain consequences.

Boundaries are less finite than goals, but also important.  The easiest example of a boundary is in procurement.  How big of a check can you sign?  Boundaries for services people usually involve situations where customers are unhappy.

For instance, in my support team the level 1 and level 2 CSRs do not have the authority to decide whether or not we will patch a given bug.  They have an escalation process for path requests.  If a customer asks them then they are instructed to say, "Building patches is a complicated process, and a decision cannot be made until a developer actually looks at the broken code.  I am working as fast as I can to get all of the necessary information to the right people so that decision can be made."  If the customer pushes they escalate the case.  But they do not have to be responsible for making that decision.


2. They must understand the company’s mission.
This seems like it should go without saying, but I've met many services people who could not articulate their company's mission.  It's not just that they will meet people and need to be able to do good word-of-mouth marketing.  They will be making many little decisions and understanding the mission will help them make the right decisions.

You should also remember that they constantly communicate with your customers.  They need to be able to support the company mission with everything they say.


3. They need the right tools.
I am a big believer in high tech gadgets like multiple monitors, bluetooth headsets, wikis, VPNs, etc..  Whiteboards are also tremendously useful for collaboration.  (Yes, I'm a committed early adopter.)


4. They need a reliable and efficient workflow process.

I am an INTJ.  I think in terms of processes and systems.  It's just how I'm wired.  This is the core reason I think of myself as a manager.  I'm sure that other personality types can be be great managers.  But in terms of process I have difficulty describing what I do because it comes so naturally.  But process is very important in services.

Services is 90% soft skill and 10% tangible deliverable.  What I mean is that the services team is usually delivering some tangible thing, like a software patch, or a configured piece of software.  But that thing is only about 10% of the job.  The other 90% is the communication about the thing.  And because services is so soft, it is very very easy to drop the ball.  Good process is all about keeping track of all of the balls that are in the air.  If the process fails and a ball hits the floor the staff member who touched it last will take the arrow, even though they are often not to blame.

The services processes have to ensure that no ball hits the floor, ever.  But that level of process can easily mushroom to become so much overhead that no one has time left to actually do the work--hence the need for efficiency.

My default strategy is to build the minimum amount of process to get by, and then to adapt it every time a ball hits the floor.  My mantra in this is "never repeat a mistake."  



5. They need plenty of warning before each change.
This is about keeping them motivated and happy.  Surprises at work are about as welcome as surprises at the dentist's office.  I understand the need to keep strategy secrets.  But whenever possible, warn your services people before every business change.  Even big scary organizational changes can fly by smoothly, if people are warned.


I maintain the lines of communication through these ongoing projects:
a. I take time to talk informally and privately with each team member.  When budget allows I take each team member to lunch once a month, or so.
b. I actively communicate company news to the team.
c. I regularly ask the team for ideas to improve their toolset and workflow processes.  When they have good ideas I attempt to implement them and give them credit.

I also engage the rest of the company on behalf of my team.  I make these two requests on behalf of my team:
a. When they receive a praise of someone on one of my teams, please share it publicly.
b. When they receive a criticism of someone on one of my teams, please bring it to me privately for resolution.




No comments:

Post a Comment