Modern Professional Services - Part 1 - Types of Consulting Organizations

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:

1. 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).
   
   
2. 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.
   
   
3. 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).
   
   
4. 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).
   

A fifth type would be an organization that does not have in-house professional services. The classic example here are Atlassian and Apple, arguably even Oracle, who always put self-services and partner network first, with their field engineers primarily being a glue between partners and internal engineering teams. In Apple's case there is also simply the product decision to not be customizable, so naturally field engineering is more like DevRel, evangelizing the ideas which are famously executed without considering the customer. Microsoft and SAP over the aeons oscillated between this model and type 1 above.

In part 2, I will talk about estimation, and how work is prioritized in Professional Services teams across those 4 models.

Letter to my future self 2022 edition

Reading my earlier “letter to my future self” from 2016 is interesting, because it still holds true, irrespective of how the pandemic changed the workplace: I wanted to work on delightful products with end-user impact, intelligent and intuitive products with a strong and clear vision. First class in technology, with information and technology as a “narrative”, meaning culture, and with a strong focus on operational excellence. Back then the SRE book had just not been released so it was hard to explain to classic “architects” what my role would be, yet I was keen to learn how to run things at scale. I wanted to be part of a global, distributed and diverse organization, a “swarm” with a focus on Asia, what I liked about consulting, not a manager.

All of that, and more, came true and I am grateful to Google for giving me this opportunity. I learned more about product development and excellence, customer empathy, tech leadership, reliability and eventually SRE than I ever expected - from the most brilliant and humble people I ever met. I was lucky to work on one the largest scalable, concurrent and low latency systems in the industry, diving deep into (data) observability and machine learning. Helping migrate some of them to Spanner I built up experience to help launch Cloud Spanner in Asia, and with that move from product technology management to strategic cloud engineering. I was again lucky to help integrate and migrate real-time streaming systems and data warehouses, and improve products like BigQuery, Dataflow / Beam and Kubernetes / Cloud Run. The only thing I couldn’t avoid was becoming a tech lead manager again - but I love building up teams and so I focused a lot on creating coaching, scaling (security and scoping), hiring, onboarding and culture programs, with a special focus on inclusion of diverse backgrounds and community and student outreach to make tech legible.

My Tech Interview style (and the Integration Engineer role) [backdated draft]

Note: This post is backdated to the date of the last draft (27 Dec 2021) as I changed my job and role and didn't want to bias / inform myself by that. It's an unfinished fragment of my thinking at that point in time that I just cleaned up a little and added references where necessary, but it's still rough and incomplete.

I've never been happy with the Tech interview process and burned by it many times - being under-levelled, in role I barely understood (a reason I launched the Tech Job Titles list), rejected for algorithm questions ("write a solver for Tetris but in n dimensions"), or simply not even screened for "no product experience". This form of gatekeeping in the tech industry is one of my pet peeves, but it's also simply unproductive and inefficient. It only works because of survivorship bias for people from top universities who are being prepped with special courses, books, test interviews and special coaching by tech firms - as such it functions more as a ritual than actual role fit and/or culture add. It is basically a code (e.g. speaking out loud during programming), and by knowing that code the interviewee signals the interviewer to be part of the same group ("likeability").

My interview style

I've done about ~250 tech interviews at Google and ~250-500 at Accenture, plus quite few in non-for-profit volunteering and my own startups - regardless whether the role was called programmer, engineer, consultant or architect. Instead of going into depth on what the current interview process is or what's broken with it (the list has a few pointers and there is great research by others), let me highlight what is important for me in tech interviews (leaving behavioural and hypothetical aside):

Tech Job Titles

One of the most common questions I get on career panels, mentoring or coaching sessions and after talks is to explain what my job, my role actually is. There is no easy answer, because it requires an understanding of the complex dependencies of roles in "Tech" (for lack of a better word, information technology product) firms.

Information Systems, Computer Science or Design Thinking courses or books for career starters typically focus on explaining the Software Engineer (SWE) job, sometimes the Product Manager (PM) and partially process-specific rituals and roles (e.g. in Scrum the Product Owner). But rarely do they mention the difference between performing the SWE role in non-tech industry (for lack of a better word - firms or public entities that primarily exist due to non-tech “hardware” products even though they might claim to "digitalize" afraid of disruption), in consulting (firms that provide services, usually to the former, to "digitalize") and tech (firms that sell “software” products and services to gain an advantage with speeding up "digitalization"), and within tech between startups and established firms. I've never seen any mention tech-adjacent roles that might have "engineer' in their title but are not SWEs.

With recent hypergrowth, a lot has been published on "upwards"* career management and manager roles in Tech. But I haven’t seen a good resource on the continued blending of these archetypes and roles and responsibilities - with a list of observations and this article as background reading I'm trying to do so. Maybe later I’ll do a variation for non-tech industry companies and consulting firms.

tl;dr I've created a GitHub repo "awesome-tech-roles" modeled after the "Awesome Lists" with the goal of showing typical clusters of tech-adjacent roles and references to good articles that illustrate the variety within the roles - for career starters in the tech industry. The links are examples, observations, not endorsements of my personal view. Given the bias towards SWE and PM roles I've tried to keep roughly the same number of references per role cluster and focus on established tech firms.

A view into state [backdated draft]

Note: This post is backdated to the date of the last draft (31 Jul 2021) as I changed my job and role and didn't want to bias / inform myself by that. It's an unfinished fragment of my thinking at that point in time that I just cleaned up a little and added references where necessary, but it's still rough and incomplete.

In principle, any stream processor could be used for materialized views

Kleppmann, 2017, p. 467

Martin Kleppmann recently gave a great keynote in which he summarized his ideas under a new framework of unordered vs. ordered events and mutable vs immutable state. In the accompanying paper he also gave an outlook on a new wave of tools that "abstract away" these consistency decisions in event-driven systems, in particular "Materialized Views" e.g. Materialize - a great overview on the different patterns is Jamie's article.

I've been a fan of this idea not only since the famous "database turned inside out" (1) quote but actually when I first worked with Spanner and saw firsthand how it turned into an SQL system which required a surprising amount of abstraction of internal (consistency) concepts. Most surprising was that fundamentally Spanner is a messaging system (in other words it is truly distributed and not built on replication paradigms), and could even be used as a queue by observing changes "inside out". In most databases those changes are row-based and often used (with CDC) as basis for event sourcing architectures, sadly mixing physical considerations with domain events. But I am interested in one level lower, of the changes within a domain event entity, and lineage, the reason why. This interest comes from Dataflow / Beam and its consistent view of temporal locality, something I've been keen on since agent-based simulation using Erlang's actor inbox (2). Beam doesn't use "wall clock" time but time in the sense of event-time, flow or an ordered sequence of events or the spacetime / promise-theory goal "to explain a process ... we need to be able to ... tell a story about its behaviours". I'm interested in exposing this state and making it legible and explainable.

Wouldn't it be great to have a database supporting per row state (consistency) metadata instead of state hidden in a stream processing system?