A view from the trenches: A quick look at the unique beast that is Services within a Software company. In this post I’ll do my best to take a decade of lessons learned across successful and failed attempts to work within or lead services teams within start-up software companies. No one likes to admit that their software requires services to make it meaningful to a client, or that the enterprise requires expertise from outsiders, but both are absolutely true. Software needs to perform to meet the specific requirements of the environment and enterprises aren’t usually built around external vendor platforms. In between these concepts are the people who create solutions to bridge gaps and illustrate value by solving problems. The people that no one likes to admit they need and even fewer admit they love like their own.
After interview a few places and taking to people at various stages of maturity within their companies it occurred to me that there is more interest in these topics than I originally believed. It seems there are dozens of companies looking for leadership or at a minimum additional ideas on how to more effectively manage a services organization at their software company. I thought I’d share a few of my insights in hopes of pushing the conversation forward. In all honesty I’m hoping to learn even more from you as the conversation progresses.
In all cases the most valuable lessons presented here are from the opportunities I’ve had to learn something new along the way (read I failed at something and want you to avoid my failure if you can). I certainly don’t have all the answers or purport to say my view is complete. This is simply an attempt to shine a light on teams that don’t get nearly enough recognition for their contribution to their companies, clients or the marketplace in general. Thank you to all that have taken the journeys alongside me and have helped me learn about these topics and so much more!
… And here we go…
Roles and Goals
The stage of the company, the complexity of its products and dependant technologies, the experience of the clients solving similar problems, the team makeup and the overall market (does a market segment even exist yet?) all play key roles into helping you to decide the composition of the team that you need in order to successfully deliver solutions into today’s enterprises.
Sure there are some always applicable pre-requisites skills that exist:
- Ninja competency at task “x”,
- Jedi or at least the ability to levitate and/or control feeble minds,
- Foreign language proficiency,
- Sales/Pre-sales experience,
- Business development experience,
- Marketing experience,
- Previous start-up experience,
- Fortune 100 experience, etc
And of course all of these traits must exist and that’s even before we figure out what our clients will actually need help with in the field.
Imagine getting hired into a start-up company because of you previously managed IDS, Firewalls and deployed a log management system and are willing to try something new and love to travel. You get on-site with the customer and they want you to explain DB tuning to their DBA’s, explain economics to their CFO and help counter the ongoing compromise events that are plaguing their financial applications – all in one day? Who wins in that situation? No one does. There is a role to play as the vendor services team and as long as you understand it you can manage the situation more effectively (and hopefully with your company supporting you along the way). Communicating and deftly securing help when necessary are critical to being successful both personally and as a company.
Some Basic Roles:
Externally: Consultant - Trusted Advisor. The role is simple enough in concept listen and understand completely the problem the customer is trying to solve. Not just in terms of “I need my widget to spit out purple checkmarks” but learn “WHY”. Follow that thread as far back as you can towards its source. The more you can find out the more value you can add to the solution and the more value you can bring back to your company. With regards to the delivery in the client environment, set an expectation and deliver to at least that expectation. Don’t sandbag or sugarcoat. Earn respect for yourself, your company and the solution you are delivering. Communicate obstacles and accelerators!
Internally: Advocate for client needs by suggesting problems that can be solved not by suggesting solutions. Well unless you can work on them yourself in the field and bring them to dev for refinement and inclusion. You must accurately describe your observations about the team your working with, the problems they face the technical and political environments, obstacles and successes. Lack of communication on these topics means that the company is not fully aware of the value you bring to the table. Ideally you’ll have a management infrastructure that can turn your information into something consumable by any internal entity, but you should feel free to engage directly as well. Be a passionate and empathetic in your communications, understand that communicating a sense of urgency and being demanding are two very different things and that the same words with the wrong tone can convey either.
Whether on client site or in your own HQ - Always Be Present (mentally) and seek to understand and create solutions. As much as possible use the technology you’re supporting but overall solve problems and create a relationship based on trust and ability to support the needs of your perspective client(s). Understand your product isn’t able to solve every problem the customer has but perhaps it can solve more than you realize, bring back lessons learned on a task by task basis to Product management (if they exist), Development/Engineering, Sales, Executive teams. Field input should be presented along the lines of “what I learned about the client today” and certainly not as “we have to fix this crap feature now…”
“We The People”
The most valuable asset in the services organization is the team. Each individual has strengths that need to be used and they present opportunities for mentorship and refinement in other areas. The team provides strengh and scale, they are peers, mentors and sanity checks. They are there for one another at 3AM in Prague or in Cincinatti. These individuals travel all over the world, represent your company to both those feeling a technical pain and to those that control the budget. Their impressions (subjective and objective) of client needs should to be considered in depth by the company. Grow them, not artificially by creating roles that are meaningless or not transferable outside the organization but by creating a sense of mission and of team. Train them, equip them and most importantly care and feed them. I’ve learned that while I’m well suited to build a program from the ground up I can’t necessarily effectively care and feed 15+ remote employees (nor hundreds of them). I’m just not that good. Having a management team around me to ensure we can focus on all areas of development helped a ton.
Actively Solicit Input - If a request comes from the field and the default answer is “Open a ticket and PM will prioritize it” I’ll flatly say that your organization is failing to maximize it’s potential and is probably failing more broadly in other areas of communication. The answer lies in seeking to understand “why” from every interaction. Whether its PM, Dev, Support, Sales or Exec someone should be learning from every interaction with the field. If not then the services teams are not delivering on their end of the deal.
Perhaps in the end that is the measurement most valuable to the company – what changes have evolved, been refined, re-prioritized or been created by the field teams’ input? Or better stated How have we as a company maximized the utilization of our field teams vast reach, expertise and perspective?
When is the right time for delivery partners? Depends on your company is the easy answer. The details are pretty simple to figure out though. Does your delivery organization have domain expertise (and scale) in every vertical and geography your selling into (or targeting?). If not, find the right partner to help you get there. A small company, let’s say less than 200 customers, with 100+ partners is absolutely insane and counterproductive in all cases.
Target partners by problems they can help you solve. For example let’s say you don’t have enough cleared team members but aspire to deliver in Federal? Find ONE partner, internalize them as part of your team and go to market, add additional partners when necessary for major bids but manage this carefully ahead of time otherwise you’ll spend more time pruning your partners than cultivating them.
Spend time wisely with partners. The goal of every software organization I’ve seen is to have a Big 4 Partner pushing your product and becoming the part of their machine. Let’s be honest those guys are on the early adopter wave until you’ve reached a critical mass in the marketplace. Yes you should build relationships but it takes years and can absolutely detract you from current delivery if you focus too much energy there. The opposite problem exists for niche partners – best advice I can give is to make sure the deal is strategic enough to matter before you bring them into the fold.
Partner Competition – it happens and it shouldn’t but it does. For arguments sake let’s say that your organization is a finely tuned machine with every sales person aligned and sharing information about every deal’s status so that everyone in the company knows exactly where things are at all times. The odd’s are not in your favor that every one of your deliver partners will be at the same maturity level or that you’ll stay sleeping long enough for your dream to be reality. You’re not going to have oversight into every situation and there will be times where you go to a joint prospect with competitive quotes for services. This situation sucks – no one can win. Vendor wins and it puts a bad taste in partner’s mouth for stealing work, the partner wins and the customer thinks the vendor was trying to gouge them for more money.
I’ve had this situation happen with partner companies vying for bids and we didn’t even know they we’re partners with us yet. Think about that – you’ve got untrained, misaligned companies competing for deals in your backyard around your solution and winning… How does that happen? In our case it was motivated partner seizing and opportunity – it’s a beautiful thing if managed appropriately. We quickly pulled our quote, trained the partner and pushed them further. The more people delivering on your solution the better – once it’s reached the right level of maturity.
Measurements and Valuation of Contribution
Old and Busted:
You’re not Oracle or a Big 4 Consulting company, you’re not EMC or Cisco with dozens or hundreds of products to specialize in. You’re small and focused, hungry, nimble and capable – why follow a business model that doesn’t add the right value to your organization?
What’s not said is often the most important factor in this entire conversation. Some of you may notice that I’ve “failed” to focus on the core professional services mantras that exist in our field – utilization and margin. I’ve excluded them for a simple reason. They don’t matter.
Well that’s not entirely true but they don’t matter in the same way they matter to those companies. You’re selling a software solution. The company’s external value (to investors, acquiring orgs, etc) is based on software revenue and maintenance renewal revenue and of course profit. Services profit usually only accounts for 5%-15% of total revenue in software organizations. Anything more than that and the organization is seen as not reaching a broad enough scale or too heavily focused on services and the valuation depreciates significantly (multiples can reduce by 50%). Anything less than that and it’s not a viable play for the partners (and potentially the channel) because there isn’t enough value-add services that can be packaged around your solution to be compelling for them. You can’t win either your solution is so complex it requires professional services or it isn’t robust enough to build around. I’m not advocating that these stances are right/wrong simply that the perception exists.
With that in mind if you’re building a services company within a software company you must understand that you are building an business unit where the true value is more intrinsic to the company’s mission and can’t always be expressed as tangible bottom line numbers. How do you measure customer success? This concept needs to be constantly reinforced and expressed to your executives. If they buy in it becomes a market differentiator – every time!
If the first measurement your executive team asks about when trying to ascertain the state of PS is billable utilization you’ve failed to impart the true impact of your team to the company. At every point during the maturity of your organization you’ll need to understand the temperature of your team and adjust the thermostat to counter, but if your only measurement is billable utilization you’ll be missing out on the more important measures to the company. As long as the investment made in reaching the field is helping the company establish itself with your clients, or carve our a space in the marketplace or helping your to refine your solutions or create new ones in previously untapped areas, why do you care if your team was billing out at 62% last quarter? To borrow a phrase you’re measuring mice nuts when you should be worried about the entire zoo operation.