I am giving a talk at SRECon '22 APAC "Deploying Humans at the Edge of SRE". It's meant as inspirational, so I'm starting a 3-part series on Professional Services. The bigger context is the discourse on interesting career paths into tech, which I've been working on joining Google, particularly with my Awsome Tech Roles compilation (please contribute!).
A series on Professional Services
In this 3-part series I'd like to introduce "Professional Service" organizations in tech product companies. In times of standard convergence and consolidation, recession and and "cash is king", it's easy to observe product companies pivoting to offer services, usually paid, as a way to ensure success of implementation and provide additional value-add and thought leadership if products differences are minimal. But implementations can vary widely, and it's hard to compare how they work.
I'm excluding pure managed services, outsourcing and consulting firms and the traditional industry (in-house consulting, ops) here, same as in my Tech Job Titles List. Product implementation may be outsourced in some tech firms and therefore be relevant, but specifically in tech product firms is either internal effort based ("what can I get done with the SWE cycles I have") or covered by a "partner" organization who scopes projects in a similar way to what I am about to explain.
This series will be split in 3 parts:
- Part 1 on Types of Consulting Organizations
- Part 2 on Estimation, and Fordian vs Bayesian Timebooking
- Part 3 on Impact Metrics, including Cost
To be clear, this is neither driven by Stripe or Google, not represents Stripe's or Google approach. It is purely based on my observations when talking to my peers - and given I am not in Silicon Valley likely highly biased on not canonical at all.
Types of Consulting / Professional Services Organizations within Product Companies
When I say Professional Services I generally mean paid post-sales (post go-live / post-commit) services provided from the same company that built a product to the buyer or user of the product. That services goes beyond standard case-based support and troubleshooting or continuous customer success plans, and is defined by a project scope and business impact, not a product pipeline or effort SLA, and not billed outsourcing-style "time and materials" (like, say, an adoption-focused Customer Success Manager or Resident Architect or extended workbench).
Here is how I see the 4 extreme types of professional services organizations in tech product firms - this may sound negative, but the goal here is to show extreme cases, ymmv:
- Separate organization or profit center with completely separate P&L contribution, often even a different brand or subsidiary with different contracts and benefits. Usually these are product firms with very strong partner ecosystem, making sure their consulting arm stays "independent", often due to a strong license lock-in ("stickiness") and fixed-support-fee business that does not depend on a SasS / usage pricing model. In other words customer's success is not actually relevant post-sale, customers may even be forced to pay a maintenance fee which puts the professional services organization close to "customer operations". As separate organization, they may often do real implementation and delivery work. Therefore, individuals are often incentivized in their performance process purely based on P&L, e.g. chargeability metrics or thought leadership generating leads and opportunities. Due to this it is not uncommon this is actually a different entity with different contracts and employment plans.
IBM Global Services used to be the classic example, SAP Advisory Services and, until recently, Microsoft are others, but there is a general trend to blur the lines with the shift to SaaS and customer success metrics. Not even outsources prefer this model anymore as capacity planning is hard (more on this in the next post on estimation). - Separate team within a larger organization, usually either the Sales /
Go-to-Market or Support / Customer Success organization, aligned to
their goals but different methods. The lucky invariant is a prototyping, solution engineering or deployment engineering team, embedded in the rollout motion but connected to initial support. The less lucky invariant is an intermediate stage to (1), as the KPIs / metrics / OKRs need to be hacked to fit a fundamentally different culture e.g. via profit or revenue share in a value-selling approach. Therefore, individuals are often defined by roles rather than reporting lines, and incentivized in their performance process on metrics they have little control over e.g. product upsell or utilization. This may lead to frequent re-organization, strategy and leadership changes and associated employee retention issues.
Usually these are SaaS usage pricing companies that at the same time have lock-in potential and therefore see professional services as a retention channel. The classic examples used to be VMware, Salesforce and ServiceNow. Cloud providers may fall back into this as default or crisis mode (as they often don't have natural "stickiness" e.g. license leverage, at best commit contracts), and while aspiring to profit centers in reality often turn it into a cost center by discounting or waiving cost for services e.g. for migration. - Horizontal enabling team, role, community of practice or speciality organizations with fluidity and some fuzzy lines to presales / solution engineering, developer relations, evangelism or support. Usually these are SaaS / usage pricing companies with real long-term customer success vision beyond quarterly goals. Often for more experienced / senior individual contributors like principal architects; individual contributors who are ok with swarm-style loosely defined reporting lines and define their own specialization e.g. holocracy. In the extreme case a catchall for all work not otherwise clearly defined even to the extent of building unofficial tools and integrations. Therefore, individuals are often incentivized in their performance
process on metrics that represent this long-term vision like customer or partner happiness, public engagement, IP / asset generation or product enablement (e.g. sublinear support growth). In this model professional services may be close to developer relations or field engineering.
Often de-facto operated "cost neutral" as cost or investment center and therefore smaller than in comparable firms. Amazon with its very independent team, customer obsession and embedded roles is the classic example. And every provider claiming to do "Digital Transformation" pretends to be here (e.g. Microsoft is moving from 1 to 3). - A rare hybrid between type 2 and 3 are professional services organizations aligned to
the product feature engineering org, for instance combined with Product
Ops for customer empathy (also here) strategic customer advisory and lighthouse customer launch support,
or with DevRel to cover OSS tools and integrations. In the best cases these are actually rotation-based, starting with a residency program. Often they are smaller organizations where "everything customer facing" is grouped e.g. into Field or Deployment engineering.
Often these are data companies who build very specific use cases and can monetize their reuse, e.g. Palantir, Databricks and Looker, also Google used to be like this. A recent thread shows Color seems to do Solution Engineering this way (the right way). Seen as an investment or profit center but via product usage or adoption, not direct payment for services. Unsurprisingly all of these sound familiar to Team Topologies - this type would be the Platform Team, the closest to how SRE works, just on the other end of spectrum as maximum customer empathy team (often Professional Services sees itself as "spearhead" or the product).
In part 2, I will talk about estimation, and how work is prioritized in Professional Services teams across those 4 models.
No comments:
Post a Comment