Barclaycard, London

After 5 years at PayPal, most recently serving as Chief Architect for PayPal Credit, I decided to move to London, having accepted the role of CTO with Barclaycard.

You might wonder why a techie with startup background would leave Silicon Valley to work at Britain's oldest bank.

The reason is simple: financial industry as a whole and consumer financial services in particular are undergoing a transformation, some might say a seismic shift, which is significantly technology-driven.

A wave of change disrupting the status quo presents a great opportunity for innovation.

I'm tremendously excited to join Barclaycard technology team.


Photo By Diliff (Own work) [CC BY-SA 3.0 or GFDL], via Wikimedia Commons

Investing in platforms

'Platform' is a word that one hears a lot nowadays in our industry, and it sometimes suffers from over-use. Here are a few thoughts on building platforms:

1. The art of being a platform is letting someone else be the product. I.e. platforms should underlie products, enabling diversity, not attempting themselves to be all things to all people.

2. Platforms are collections of capabilities, not baskets of features. Capabilities imply higher level of abstraction, enabling development of diverse feature sets without defining them exhaustively.

3. Platform business is hard. End users interface with products, not platforms. Most businesses compete on stickiness and profitability of their customer relationships. Catering to end users gives one greater scale, and so many businesses that begin by declaring themselves platforms eventually become very keen to own end-user relationships under their own brand, rather than letting third party product developers own them. Evolution of the Apple platform is a good case in point.

4a. For a product-oriented company of sufficient scale, factoring out underlying platform/capability set is key to scaling across global markets with their diverse requirements. Without a good platform foundation, feature flow demanded by differentiated global markets becomes more expensive, there's duplication of effort (and code), gradual accumulation of tangled dependencies and increase in brittleness.

4b. Exactly the same concern arises for SaaS companies that develop tailored solutions for anchor tenants of the platform and need to migrate to true multi-tenant platform.

5. However, a typical product manager is not incentivized to be platform-minded. Most corporate incentive structures are targeting delivery of specific, discrete, value-added features, not investment in broader capabilities that may yield dividends over the longer arc of time.

A humble proposal: 

For every investment, there should be an explicitly factored out portion that genuinely accrues to platform building (with the rest going towards feature flow). If it's 0% than at least it's explicitly 0%, not ambiguously implying platform investment or enablement in their absence.

Sometimes, making implied things explicit is all one needs to reach agreements or effect change.

Factoring and pipelining complex projects

We're all familiar with the concept of minimum viable product.

In fintech, those minimum requirements include a lot of regulatory compliance, legal and other complex concerns that can have significant ramifications on how every product feature is supposed to work. Throw in requirements from key partners and customers, and one can easily end up with an MVP with a large scope, and a lot of uncertainty and interdependencies among requirements/stories.

It's very easy then to start spending a lot of time reconciling it all together in attempt to arrive at a coherent picture all teams can align on in detail.

Finally, large investments are typically in the opposite of a skunk works/'fly under the radar until you've got something good to show' situation. Large investments imply commitments - in time as well as revenue. As in - in which quarter can it be delivered/ramped/booked. So for very good business reasons one ends up with a defined budget & timeline on one hand and a quivering mass of stories on the other. What to do?

The common mistake is to attempt to mitigate uncertainty by figuring it all out upfront in sufficient detail. Then everyone is spending most of their effort drawing and redrawing the complete picture and overall progress is very slow.

And, of course, every requirement/story has a product owner behind it, and no PO worth their salt will say 'uh, you know - the thing I'm responsible for - don't worry about it for now'.


Factoring:

In my experience, key has been to factor the entire whole into subgroups of mutually influencing requirements but with fewer fine-grained dependencies between these subgroups. Architecture can serve in leading or analytical capacity for this factoring.

Then decide by fiat which subgroup goes first and start cranking away at it. Yes, without other subgroups the 'MVP' won't see the light of day, and attacking other subgroups later doesn't mean they're less important (as their POs will be worrying about). But one has to start somewhere.

Pipelining:

And then, guess what - while subgroup 1 is being delivered, [C]POs, architects, dev leads and others with responsibilities beyond a single agile team or sprint can free up time to focus on subgroup 2, 3, n, n+1... creating a pipeline.

Seemingly simple, but requires persuading passionate people that being in n-th place in delivery pipeline doesn't imply being in the same place in terms of importance.