I was away for quite some time and did not post anything. But I am back and I intend to cover a less controversial topic this time.
The topic this time would give you a peak in to the different parameters that I am considering while devising support offerings. These offerings are intended to be like an additional package that a sales guy can use while striking a deal and make support a revenue point. This also benefits the customer as they get to choose a support offering that suits their business needs better. Above all this affects the support team the most as it has to prepare itself for the different customer needs and it is a contractual obligation now.
More about it in my new post.
For those who are interested : I have now moved to Chicago and am a Senior Consultant. I did manage my first ever promotion :-).
Monday, May 24, 2010
Monday, December 28, 2009
Leadership and Team structuring
I have been working as a Support Engineer for almost 5 years now. I have worked in a team which was tightly hierarchy bound and now I work in team which is completely flat. This indeed was a big and a very cheerful transition. Now having seen both sides of the coin, if I were a manager/team-lead I would like to follow some best practices while structuring my team and defining the work flow:
1. Have trust and respect each of your team members. Trust and respect play a very important role in development and growth of any team. Often I have seen that respect usually comes with your experience, which I totally disagree with. A person who contributes to the team and to the organization deserves the best irrespective of experience. Well in hierarchy based companies this is mostly ignored.
2. Maintaining knowledge base. This is the most basic requirement of any support team. A knowledge base helps people to understand and fix known issues faster. It also helps in knowledge sharing which is very important. Transparency in the team is critical. I have come across people who try not to share their trade secrets just to be in the limelight. This kind of behavior is disgraceful and against the team. Such behavior can be easily identified and must be curtailed. I would give equal marks for an innovative resolution and addition of knowledge base items.
3. Using the right tools. Tools should be easy to use, such that it is not a burden on the team. Also there should be provision in the tool, to define a distinct workflow. One should not try to track an insane number of parameters through the tool mainly because, it makes the tool unusable and leads to confusion. We just switched from IBM lotus notes to Zendesk and it has made life more comfortable.
4. Distribution of work load. Being in support would mean that you have some real tough days or days where you don’t have any work. This also means that you can use time the way you want. I have a seen a lot of problems around work load balancing in teams, as load is very subjective. Priority of a issue, complexity, volumes can all be parameters defining work load. Daily-Stand-ups is one way of introducing the transparency in a team. Now what does a Daily-Standup involve?
Members of the team huddle up and talk briefly about the following:
1. What did they work upon the previous day?
2. What they plan to work on today?
3. What are the blockers they might have?
Having such a discussion gives the team insight on what is happening and all remain on the same page. This also gives a TL/PM a clue of any critical blockers which might blow up and hence a chance to act upon them.
5. Review of issues is the next one. At my previous job, we had a one hour ticket review session which at times involved the manager. It is really funny how my feeling about this session changed with my experience. During my initial days, I hated this session. Reason being, my tickets were always non-compliant or had some wrong troubleshooting. But as I grew in experience I enjoyed this session, as I could notice similar mistakes by new guys coming in. In my belief this was becoming a pattern for everyone. Now why would you allow a new guy to come in and commit mistakes and then later in the week waste your time reviewing the mistakes? If one follows the Dialy-Standups and maintains KB, mistakes can be avoided in the first place. Unfortunately some people find more pleasure in finding mistakes in others and in that way trying to establish their importance. Also some teams do not believe in review of tickets, which is again a very bad trend. Tickets need to be reviewed to assure quality and track SLA's.
6. Responsibly and ownership are two important qualities that the team should develop to deliver in a reliable manner. In an unhealthy team, you would always notice the baton being passed around. While in a healthy team, people standup to these. This is something which is purely driven by leadership. If as a TL/PM, you express confidence in a particular individual and then entrust him with a responsibity, the chances are that he/she will deliver. Where as in a team, where responsibility is just dumped on you because of a shortage in staff, results are hard to come by.
7. Escalations. This is very controversial topic. How much access should a support team be given to the development team? I will be discussing this in my next blog post.
Last but not least, as a leader of the team, one should always try to set aside their egos and be as neutral as possible. Treat everyone with respect and dignity; after all we are in a corporate environment and not in a war.
1. Have trust and respect each of your team members. Trust and respect play a very important role in development and growth of any team. Often I have seen that respect usually comes with your experience, which I totally disagree with. A person who contributes to the team and to the organization deserves the best irrespective of experience. Well in hierarchy based companies this is mostly ignored.
2. Maintaining knowledge base. This is the most basic requirement of any support team. A knowledge base helps people to understand and fix known issues faster. It also helps in knowledge sharing which is very important. Transparency in the team is critical. I have come across people who try not to share their trade secrets just to be in the limelight. This kind of behavior is disgraceful and against the team. Such behavior can be easily identified and must be curtailed. I would give equal marks for an innovative resolution and addition of knowledge base items.
3. Using the right tools. Tools should be easy to use, such that it is not a burden on the team. Also there should be provision in the tool, to define a distinct workflow. One should not try to track an insane number of parameters through the tool mainly because, it makes the tool unusable and leads to confusion. We just switched from IBM lotus notes to Zendesk and it has made life more comfortable.
4. Distribution of work load. Being in support would mean that you have some real tough days or days where you don’t have any work. This also means that you can use time the way you want. I have a seen a lot of problems around work load balancing in teams, as load is very subjective. Priority of a issue, complexity, volumes can all be parameters defining work load. Daily-Stand-ups is one way of introducing the transparency in a team. Now what does a Daily-Standup involve?
Members of the team huddle up and talk briefly about the following:
1. What did they work upon the previous day?
2. What they plan to work on today?
3. What are the blockers they might have?
Having such a discussion gives the team insight on what is happening and all remain on the same page. This also gives a TL/PM a clue of any critical blockers which might blow up and hence a chance to act upon them.
5. Review of issues is the next one. At my previous job, we had a one hour ticket review session which at times involved the manager. It is really funny how my feeling about this session changed with my experience. During my initial days, I hated this session. Reason being, my tickets were always non-compliant or had some wrong troubleshooting. But as I grew in experience I enjoyed this session, as I could notice similar mistakes by new guys coming in. In my belief this was becoming a pattern for everyone. Now why would you allow a new guy to come in and commit mistakes and then later in the week waste your time reviewing the mistakes? If one follows the Dialy-Standups and maintains KB, mistakes can be avoided in the first place. Unfortunately some people find more pleasure in finding mistakes in others and in that way trying to establish their importance. Also some teams do not believe in review of tickets, which is again a very bad trend. Tickets need to be reviewed to assure quality and track SLA's.
6. Responsibly and ownership are two important qualities that the team should develop to deliver in a reliable manner. In an unhealthy team, you would always notice the baton being passed around. While in a healthy team, people standup to these. This is something which is purely driven by leadership. If as a TL/PM, you express confidence in a particular individual and then entrust him with a responsibity, the chances are that he/she will deliver. Where as in a team, where responsibility is just dumped on you because of a shortage in staff, results are hard to come by.
7. Escalations. This is very controversial topic. How much access should a support team be given to the development team? I will be discussing this in my next blog post.
Last but not least, as a leader of the team, one should always try to set aside their egos and be as neutral as possible. Treat everyone with respect and dignity; after all we are in a corporate environment and not in a war.
Thursday, December 17, 2009
Presales support VS Postsales Support
Let me briefly describe the nature of job and the teams that I worked with and am working with at the moment.
At my previous job i worked as a part of strong 10-12 member team operating from India, with the specialists operating from the US. The support we did was completely post sales and were not involved in any interaction with the customers before purchase. Also we had to follow fairly strict SLA's.
At my present job, i work with a small team of 4 people with one guy working from the US and the rest from India. The job does give you opportunity to get actively involved in presales demo's and helping out customers in the initial configuration of the tools. And again get involved in post sales support requirements.
The difference is the 2 jobs is a result of being in different industries , different domains and dealing with different volumes of customers.
So why is that people prefer doing presales support over postsales support. I pondered over this and could come up with the following reasons:
1. Being in presales means you are among the first to be in touch with customers, following the sales guys. More customer interaction more experience.
2. It also gives you a opportunity to directly contribute to the revenue in the way of converting deals.
3. It helps you become a domain / product expert . As a Presales engineer you are always looking for innovating and are staying up to date with industry trends.
4. It also gives you a glance in the world of sales.
Now what might be the drawbacks:
1. You dont really care about technology as long as you can demo/ configure the product for your customer.
2. You lose out on understanding customer issues and usage pattern, which being in post-sales support is a routine.
3. Lastly, the most fun thing of being in support, you miss troubleshooting issues.
Having discussed both the pros and cons, I still favor being in post-sales. Solving problems and not selling is my strength.
At my previous job i worked as a part of strong 10-12 member team operating from India, with the specialists operating from the US. The support we did was completely post sales and were not involved in any interaction with the customers before purchase. Also we had to follow fairly strict SLA's.
At my present job, i work with a small team of 4 people with one guy working from the US and the rest from India. The job does give you opportunity to get actively involved in presales demo's and helping out customers in the initial configuration of the tools. And again get involved in post sales support requirements.
The difference is the 2 jobs is a result of being in different industries , different domains and dealing with different volumes of customers.
So why is that people prefer doing presales support over postsales support. I pondered over this and could come up with the following reasons:
1. Being in presales means you are among the first to be in touch with customers, following the sales guys. More customer interaction more experience.
2. It also gives you a opportunity to directly contribute to the revenue in the way of converting deals.
3. It helps you become a domain / product expert . As a Presales engineer you are always looking for innovating and are staying up to date with industry trends.
4. It also gives you a glance in the world of sales.
Now what might be the drawbacks:
1. You dont really care about technology as long as you can demo/ configure the product for your customer.
2. You lose out on understanding customer issues and usage pattern, which being in post-sales support is a routine.
3. Lastly, the most fun thing of being in support, you miss troubleshooting issues.
Having discussed both the pros and cons, I still favor being in post-sales. Solving problems and not selling is my strength.
Thursday, November 26, 2009
ME: Life of a support engineer
Its a myth in software industry that a support engineer is less technically proficient and usually one adopts this profession not by choice. Well the later is true is my case. I always wanted to code as i enjoyed coding. Never made it as a developer and I still regret it. However having said that I have always enjoyed my life as a support engineer.
I initially started working for a semiconductor firm where in I was involved in providing phone / email support to customers across the globe. And at this job , unlike the call centers, you never needed accent training and never needed a fake english name. Nor could people even remotely get closer to abusing you. You had to work in shifts but the pay was very encouraging ( 30K plus). Now that is where the positives stop. You were in the most advanced industry and being a support engineer meant you were always under pressure. Time was indeed money here and a small mistake would be worth a 50k US $. Plus the training particularly did not help.
I think the intention of the management was always wrong (give less, extract more). Well this does not work in a industry as advanced as this where in you need specialists. When the support team first started, I have been told, they got first hand training for six months. Well that was a good way to start. But this did not continue for later batches. When i joined , it was the 5th batch and we were just given one month of what i would call diluted training. But we got off not particularly bad. After spending exactly 3 years at my job, I did learn a few important but very basic things. But technically , the job did not help me greatly.
Now what are the things that i did learn and how is that important.
1. Being customer focused and using the STEPS method of troubleshooting issues.
2. Being a team player, trust me this helps in a team where the knowledge base is not that particularly well maintained and all the knowledge you get is based on how good you are to people or how bad the situation is.
3. Prioritize work and negotiating quick fixes.
4. Last but not least, understanding the business impact that support can make.
I quit my job exactly after 3 years and joined a Product company as a Product Consultant and I am still continuing there. I am gonna be posting more on dynamics of support teams and the challenges they face , as I have seen them.
I initially started working for a semiconductor firm where in I was involved in providing phone / email support to customers across the globe. And at this job , unlike the call centers, you never needed accent training and never needed a fake english name. Nor could people even remotely get closer to abusing you. You had to work in shifts but the pay was very encouraging ( 30K plus). Now that is where the positives stop. You were in the most advanced industry and being a support engineer meant you were always under pressure. Time was indeed money here and a small mistake would be worth a 50k US $. Plus the training particularly did not help.
I think the intention of the management was always wrong (give less, extract more). Well this does not work in a industry as advanced as this where in you need specialists. When the support team first started, I have been told, they got first hand training for six months. Well that was a good way to start. But this did not continue for later batches. When i joined , it was the 5th batch and we were just given one month of what i would call diluted training. But we got off not particularly bad. After spending exactly 3 years at my job, I did learn a few important but very basic things. But technically , the job did not help me greatly.
Now what are the things that i did learn and how is that important.
1. Being customer focused and using the STEPS method of troubleshooting issues.
2. Being a team player, trust me this helps in a team where the knowledge base is not that particularly well maintained and all the knowledge you get is based on how good you are to people or how bad the situation is.
3. Prioritize work and negotiating quick fixes.
4. Last but not least, understanding the business impact that support can make.
I quit my job exactly after 3 years and joined a Product company as a Product Consultant and I am still continuing there. I am gonna be posting more on dynamics of support teams and the challenges they face , as I have seen them.
Subscribe to:
Comments (Atom)
