Then and now….
Back in the pioneer days of the internet when everything and everyone were all about agility and innovation, we threw new websites on servers without rules or review and without any customer evaluation and education. Those were exciting times: The world of innovative developers and hackers, the world of extended work hours and downtimes. It was the best of times; it was the worst of times. But times have changed…
How and why did this change?
Over time, Operations and web site hosting matured along with the rest of us. Security, stability, and availability became at least as important as innovation. The reasons for this are obvious. However, innovation never stopped just because the hackers got smarter and the viruses made you sicker. And innovation certainly didn’t stop when Operations’ performance reviews became tied to the site availability numbers. The charter of the customer continued to be not only innovation, but date driven innovation.
Where does that leave Operations hosting of web applications?
I can tell you where it doesn’t leave Operations: Our job is not to stifle innovation. How do you stifle innovation? At its worst, Operations can stifle innovation by erecting barriers in the form of rigid standards, policies, and unbendable rules. Standards, policies, and rules arose out of the best of intentions and they addressed real and ever present dangers and sometimes even downright evil. However, rules are not intelligent by themselves. That’s what we’re here for: not so much to break or bend the rules, but to apply situational intelligence to their enforcement and to creatively find ways to abide by the spirit of the rules while at the same time enabling customer innovation and creativity. In such ways (and others) does Operations get to flex its innovative and creative muscles.
Who are Operations’ customers?
Microsoft.com Operations customers are typically other Microsoft organizations, employees, and/or vendors from all over the world. Their sites and applications are hosted on www.microsoft.com and other infrastructure managed by Microsoft.com Operations. Customers include website owners, site managers, program managers, developers, and testers. To break this down a little more, Microsoft.com customers fall into the two following very large, general buckets.
Customers within the greater Microsoft.com organization.
If these customers are internal to the Microsoft.com organization, roles are clearly defined in project v-teams. Operations is part of the project v-team and is typically aware of product, architecture, development, testing, and release from the time of the project kick-off meeting. Indeed, Microsoft.com Operations is such a close partner in the project v-team, that we are in a strong position to influence architecture and to help the customer solve some of his design and technology problems. Depending on the scope of the project and the project lifecycle, Operations engagement in that lifecycle may take anywhere from several weeks to several months. Check out the diagram that shows the Ops Requirement Checklist & Timelines as mapped to the Software Development Life Cycle (SDLC).
Customers external to the Microsoft.com organization:
Customers external to the greater Microsoft.com organization are Microsoft employees or vendors hired by Microsoft. These customers work for a number of organizations and product teams. They frequently represent the worldwide Microsoft organization, residing in time zones other than Redmond and often speaking and writing English as a second language. Microsoft is very active globally and the subsidiaries are not Redmond-centric; their sites are localized and content is targeted to those countries and regions. Most frequently, the customers external to Microsoft.com have sites hosted on www.microsoft.com, such as http://www.microsoft.com/india or http://www.microsoft.com/japan.
Why do customers need on-boarding assistance and is documentation enough?
In the more “mature” Operations teams, the role of customer on-boarding is assigned to specialists who have a diverse skill set. At a high level, the skill set required is such that it may not be deep, but it is broad. The people assigned to this role have an engineering past and for the most part, hands-on experience. In Microsoft.com Operations, the role of customer on-boarding is assigned to the Application Hosting Team. The charter of this team covers a multitude of tasks, but customer on-boarding is a critical focus for this team.
Most large Operations teams have a team responsible for customer and application hosting; however, many Operations teams do not have the staff to break out the role and similar roles to dedicate to a specialized team. In the past and today in many organizations, customer on-boarding was covered by the systems engineers themselves. This is where I learned the ins and outs of dealing with customers. Most of the same rules apply to whoever fills this role in an organization.
Good, up-to-date, well organized documentation describing the customer on-boarding process, timelines, deliverables, and other information useful to the customer is essential, no question. However, you’ll never be able to document yourself out of the job for a variety of reasons.
1) There is potentially a lot of documentation and the customer may overlook something important because of this.
2) All customers are not created technically equal. This makes effective documentation for a diverse group challenging, to say the least. Less experienced customers may require more technical and process-oriented input to successfully enter and use the environment.
3) Just when you think you have seen everything, customers will find ways to surprise you, meaning that the documentation doesn’t cover every possible situation.
4) Once you have documentation, be prepared to say “please read the documentation” as some people will rather ask you than read. This is important to save time, ensure those new topics make it into the documentation, as well as send a consistent message to customers.
5) At some point, you’re going to need to look at the customer’s application at some level with your own two eyes. I personally couldn’t have slept at night had I not given some attention and scrutiny to application designs. Operations policies, standards, and best practices don’t necessarily rank as high on the customer’s priority list as they do on yours, depending on a number of factors, which may include schedule and business pressures from other quarters.
What skills are required for someone in the customer on-boarding role?
Technical skills typically come from past experience in the trenches of hands-on systems engineering. If past technical experience was specialized, there is likely some catch-up involved in acquiring broader technical knowledge. This newly acquired knowledge is by nature pretty shallow in comparison with that of the hands-on systems engineers directly using this knowledge. However, it can be quite useful and it can inspire customer confidence when used in the context of systems architecture guidance. The wise engineer in the customer on-boarding role knows when to bring in the specialists and SMEs (subject matter experts) for consultation and when to provide his own guidance to the customer. If experts are too frequently consulted or if such consultation is not organized as a unified and consistent message, there is a possible loss of confidence on the part of the customer, not to mention a poor and annoying use of the experts’ time. Although this is not an exact science, experience and practice will eventually hone these skills, along with clearly defined roles within the Operations team.
Good communications skills are an absolute must in this role. Not that they aren’t useful everywhere else, but this really is a communications centric role. These skills should translate to all communication types used in the job: meetings, phone calls, emails. I can’t stress this skill enough; I have seen as many careers held back due to poor communications skills as to poor technical skills. If you’re not sure how strong your communications skills are, ask someone you trust to tell you the truth.
Negotiations and cross-group collaborations become more important as you climb the food chain; however, they come into play for anyone who interacts with customers. These skills are particularly useful when you are striving to get what you want or need and are at the same time trying to make the customer happy. You can get what you want if you are holding the cards, but if you don’t make the customer happy, you will look like a bureaucrat or a bully. If you work where customers have a choice of hosting, you’ll lose your customers. If the customer is holding some of the cards (and they often do), you need to be able to negotiate if what you want is good for the team, the organization, and the company. Presumably, you and your customer are working for the same company, so at some level, the needs of both sides should be compatible. Sometimes, the trick is to find this compatibility and solve the problem that is causing the conflict or disagreement. If you are ultimately unable to agree on common goals and solutions and that there is no basis for alignment of interests, it’s just possible that you have found something that is not meant to be. If you are negotiating with customers external to your company, it gets more complicated, but the default assumption is that your interests and the customer’s interests do have common ground. You just have to find it.
Passion for technology is pretty much required for all engineering or related disciplines, especially in a company like Microsoft. I’ve worked at other companies and in technical roles outside of Operations and passion for technology is a theme running through all of those roles.
Good interpersonal skills are important in life in general, but in dealing with customers you have an edge if people like you. If you are naturally likeable, good for you. If you’re like most of us, you’ll need to work on it. It’s pretty obvious that people who are rude, uncouth, and have bad table manners are going to be avoided. I thought about not stating the obvious, but this isn’t always obvious to everyone.
There are many more qualities which can help in dealing with customers, but I want to point out something interesting about the list I provided. The attributes span the entire brain (both left and right sides). Most of us tend towards one or the other, but the beauty of customer on-boarding (other than satisfied customers) is that the role develops skills highly useful in business, technical or otherwise.
Making order out of chaos (short recipe for success or avoiding failure, if this is your attitude).
Should I consider playing this role on an Operations team?
Job satisfaction: This role is very satisfying if you like people and also like variety in technology. If you are interested in only one technology (SQL Server, for example) or in a very limited number of technologies, this role may not be the best for you. This isn’t a bad thing: the company needs gurus and experts. It should be obvious that large chunks of time are spent away from direct contact with technology, so if hands-on floats your boat, consider carefully. One of the absolutely greatest things about the job is the proximity to experts and gurus for a variety of disciplines. I confess that I really like smart people and some of my greatest moments on the job are gathering a bunch of technical gurus in a room (always with good reason). If I were a specialist working in a silo, I wouldn’t have as good an excuse to do this or at least not as often.
Career growth: The returns aren’t all in on this one; the Application Hosting role, including customer on-boarding, is relatively new for our team. However, I don’t think learning something about all the technologies we use (and some that the competition use) is a waste of time, career-wise. Moreover, advertising yourself is always a good thing, provided the advertising is attractive to others. There’s plenty of opportunity for advertising to a wide audience, including management, in this role. I think we’ll see this type of role in Operations teams more, because there is a definite need for the role and the skills. It may not always be called the same thing, but the skills acquired will translate to several job titles. Someone in this role could easily move into a program management role as well. A really technical program manager is a very special thing. And of course, you can always go back to hands-on engineering, because you are keeping up with technology.
Company benefits: I don’t know how Microsoft.com ever got along without the focused attention this team gives to customers, applications, and projects. What’s good for Microsoft.com Operations is good for Microsoft.com is good for Microsoft, or it damned well better be. And it’s all good for the customer.
As a Release Manager, I find that the Application Hosting folks are vital to the success of projects. We rely on the App Hosting team members assigned to our projects to ensure that the Operations deliverables in the SDLC are carried out, and to identify and engage the necessary engineering and infrastructure support from within Operations onto the projects.
This is especially important when a development team wants to adopt a new technology that has not been used in the MSCOM environment before.
can you elaborate more on the concept of v-teams?
it sounds intriguing
Project v-teams(virtual teams) are temporary teams which come together for the duration of the project and often for the entire life of the application. These teams include representatives from all disciplines needed to plan, spec, develop, test, release, and support the application. The teams meet on a regular basis, usually weekly during the life cycle of a product version. All disciplines must sign-off on deliverables for project milestones, for example, reviewing and signing off on the specifications for the design phase. Exit criteria for each phase of the SDLC (software development life cycle) are defined and each discipline in the v-team has a role in producing deliverables and signing off (approving) before the next phase can be entered. I've described the classic waterfall approach to product developement, but v-teams often exist for the agile and rapid prototype models as well, . The SDLC will be addressed in more detail in future blogs.
If anyone is familiar with satisfying “needs of the moment,” it’s your local Operations team…application...
If anyone is familiar with satisfying “needs of the moment,” it’s your local Operations team…application