Only Dead Fish

The Reality of How Marketing is Changing

Each year Scott Brinker's amazing work tracking and mapping the changing marketing technology landscape reminds us of just how much the discipline and function of marketing is changing. Last year's survey mapped more than 5,000 separate martech solutions and you would have been forgiven for believing then that the market must surely have reached its peak. Yet this year's survey is just out and Scott has charted no less than 6,829 marketing technology solutions from 6,242 unique martech vendors.

This explosion in marketing technology demonstrates a quite fundamental change in the discipline, and just how far marketing has broadened in scope and scale. As recently as 2011, when the survey started, there were only 150 vendors.

But in amongst the startling headline numbers, there were a few interesting points that Scott noted in his write up. As you might expect, ranking the vendors by valuation reveals a classic long-tail of thousands of smaller solutions providers but its notable that this long tail is also evident in the technology stacks that marketers are building (shown by an analysis of martech stacks from 'The Stackies', the awards that Scott runs).

So it's clear that marketers are becoming adept at augmenting larger CRM, marketing automation, social and CMS systems with more niche services that can integrate well. And as Scott notes, it demonstrates an interesting dynamic in the market - the very low barriers to entry on the supply side (cheap infrastructure, readily available open source resources, on-demand global talent) combined with this expansion of marketing scope and scale into customer experience, content, and an explosion of channels and touchpoints.

It was also interesting that predictive analytics which was represented as a separate classification in last years survey has now been integrated into multiple areas, reflecting how machine learning capability has now been integrated into multiple different services. The burgeoning category of Salestech is also represented on the graphic showing how deeply entwined sales now is with marketing - this widening scope to encompass what might be called customer experience or go-to-market technology where there is little differentiation between the old classifications of marketing and sales is what Scott calls the 'new reality of marketing'. 

IT is no longer the singular channel for technology acquisition and orchestration. Whilst marketing may have one of the largest tech stacks in a business it's clear that multiple functions are now spending big on technology with the average enterprise using over 1,000 cloud services. 

Combined with a renewed focus on data quality (not least due to GDPR), marketing functions are becoming more sophisticated every year in the adept combination and application of a broad range of technology solutions to 'evolve from fragmented silos to a more holistic digital architecture'.

This is no small change.

Marketing is changing forever.

And it's not going back.

Scaling Agile

Over the past year I've been working with a large global corporate that is rolling out agile ways of working at scale through the organisation. The 'a' word is becoming somewhat overused and it can often be misunderstood or misappropriated, and yet as I argue in my book the application of agile structures and practice has the potential to be the fundamental enabler to the transformation that so many organisations are seeking to implement right now.

Small, empowered, multidisciplinary teams working iteratively in a supportive environment can drive transformational levels of change, particularly when these practices are scaled more widely across the business. And there are now a number of notable examples of businesses (including ING, Bosch, USAA, Netflix, Amazon, Spotify, The Guardian) that have structured an operating model that involves a scaled application of these principles. Scale brings challenges however. As soon as you start to get past a limited application involving a few small teams, you begin to run into alignment and interdependency issues. 

A popular approach to scaling agile (but not the only one of-course) is to apply learning from Spotify's model of Squads, Chapters and Tribes. 

Squads:- these are your small, multidisciplinary 'two-pizza' teams (no more than 10 people). Co-located. Working iteratively in sprints. Focused on a specific customer problem or goal. Comprised of all the skillsets/functions needed to achieve the desired outputs and no more. Sometimes self-organising but always given higher levels of autonomy to decide how best to achieve their goal.

Tribes:- Squads are grouped together by business area. No more than 150 people in a Tribe. Environments that support intra-squad contact and regular gatherings for show and tell, shared learning. The Tribe leader is responsible for co-ordination across the different squads and with other Tribes, managing resourcing, budgets and inter-dependencies, establishing priorities.

Chapters:- groups of functional experts who do similar work (like UX for example) within a Tribe. The Chapter lead is a Squad member but is likely to be the line manager for other functional experts in that Tribe, and is responsible for performance review and people development, functional meet-ups to support learning.

One of the most widely scaled applications of this approach in a large legacy organisation is of-course ING who have effectively re-organised their business around this idea in response to the need to be more adaptive and responsive as an organisation. I wrote up a case study of ING's agile transformation here. 

In ING's case, they've applied this idea pretty comprehensively, creating a more fluid and responsive organisational structure. Squads (comprised of specialists in marketing, data and analytics, design, UX, product, tech) were focused on end-to-end ownership of a customer journey and Tribes (13 of them) grouped around business and customer proposition areas.

But it's important to recognise I think, that there is no one-size-fits-all solution to what good looks like. There are however, some common pitfalls and also some general fundamental principles that are useful to consider - here are some of my basics:

Start small, to scale fast:- change management is itself changing. Rigid, linear, top-down, big-bang transformation programmes do not work well in environments that are constantly and rapidly changing. There needs to be a compelling vision of the company that you want to be of-course, and commitment and enablement from the very top towards making that happen, but far better to start small by focusing on a number of critical business challenges or customer problems and scale fast and use continuous learning to adapt along the way. This enables the business to change in a way that is far closer to shifting contexts, and be adaptive enough with the operating model to flex into a fit-for-purpose structure. Most of the agile transformations that I've seen or come into contact with have started with a few teams focused on key problems, then expanded to a larger number of teams as progress is made and more nuanced or detailed customer problems are identified.

Balancing a dual operating system:- one of the key challenges (and realities) of change in a large organisation is the need to manage business as usual and short-term priorities and targets whilst also creating space for the new ways of working. Space is necessary to enable the new practices to grow without being stifled by corporate culture and entrenched processes, but there needs to be a good connection back to business as usual so that the wider organisation can learn. Balancing this dual operating system is key to making real change stick but again, every company has unique contexts and so needs to find it's own balance between traditional hierarchical structures and the areas of the business that are structured in less hierarchical, more networked, Squads and Tribes. That balance will also need to flex as needed. The only solution is be iterative and adaptive with the process itself. In other words the process of scaling agile should itself be agile.

Doing Agile and being agile:- in a dual operating system there will be the teams or Squads that are doing Agile (i.e. are working iteratively in small, cross functional teams), but there is the need for everyone in the business to at least be agile - that is to appreciate the values and behaviours that can support this way of working. If this doesn't happen you get tensions that can potentially derail the whole thing. Horizontal functions like HR, compliance, legal or procurement may not be working in the Squads but they will be needed at key points, and the business will need to adopt more agile approaches to governance, procurement, budgeting, performance review etc. You have to set the Squads up for success - there might for example be an operations team that gives the Squads the infrastructure and support they need to release code themselves. There might also be regular reviews of dependencies to reorganise work and prevent progress being slowed. Those who are being agile are no less important than those who are doing it.

Context is key:- I'm a fan of Simon Wardley's championing of the need for businesses to develop a better understanding of situational context - there needs to be more awareness of these kinds of contexts within businesses IMHO. But it's also important to stress that whilst agile ways of working are in general undervalued and under-optimised, this does not mean that agile is the default process in the business. Appropriate processes should map to specific contexts and jobs to be done. Businesses need to take a nuanced approach to the application of different methodologies.

There is no one methodology:- Some advocates are passionate about adhering to particular methodologies which may be fine for technology teams but in my experience when agile practice starts to scale more widely across the organisation it's actually better for the company to find it's own way and adopt practices which are suited to the unique contexts of that business. This may involve combining tools and techniques associated with different methodologies and even giving teams a degree of freedom in the selection of specifics. The bigger challenge is not which agile process is best, more the shift from years of entrenched linear and waterfall thinking. So it's important that there isn't a half-hearted adoption of the principles, or a drift back to old ways of working. There needs to be a good level of consistency and common approaches and processes - but don't make it completely rigid or prescriptive.  

Autonomy and ownership are key:- Squads (or cells or pods or whatever you want to call them) should have end-to-end responsibility for achieving a client-related objective (in one agile transformation that I was involved with for example, there was a mix of objective with some teams focused on optimising / innovating an end-to-end customer customer journey and others focused on innovating new customer propositions to solve customer problems). But the Squads should always be enabled by a high level of autonomy if they are to move fast. Close, top-down control simply does not work in this scenario. Leadership should frame the problem to solve and then leave the team to identify the best ways to solve it. Resourcing in the team may flex as the tasks that the team needs to complete change over time. The team may disband entirely and resource be reallocated if the objective is fulfilled and task completed. 

An enhanced role for Product:- Product owners are usually members of the Squad and take responsibility for managing the backlog and the priority setting and so helping to coordinate the Squad activities but they don't tell the other Squad members what to do. More generally, Product functions and disciplines in many organisations need to take on a more significant role in working with senior stakeholders to align business strategy with product strategy, and ensure that the objectives and outputs of the Squads focus on delivering not only what the customer needs but also what the business needs.

There's a ton of other stuff that sits around this, but these are some of the fundamentals that in my experience can really make a difference.

The Rise of Zero-Based Budgeting

Zero-based budgeting feels like one of those trends that is potentially pretty significant but which few people are talking about. I seem to be coming across it more and more. It's no doubt sprung from the increasing pressure that marketers are under to demonstrate the value of their investments, and the increasing accountability that comes from better data and analytics capability.

Rather than using more traditional budgeting methods in which previous performance, sales, revenues or costs are used as a base to extrapolate future budgets, ZBB starts from scratch with a zero base and no assumptions, and effectively involves re-evaluating and therefore re-justifying every line on a budget. Programmes or activity which have been justified then form the basis for the budget, rather than an incremental increase from last year’s numbers, and it assumes no expenses to be pre-committed or balances to be carried over.

ZBB is seemingly a response to pressure for growth and efficiency, and the need for organisations to examine every financial investment with scrutiny, but it carries with it some notable advantages and disadvantages.

On the plus side, ZBB might be regarded as a more accurate and efficient way to allocate resources, particularly in the context of rapidly shifting environments. Using last year’s budget as a base can often lead to hidden assumptions and inaccuracies, and a failure to properly take account of changed circumstances. Since ZBB effectively questions the need for everything, it forces marketers to re-evaluate all expenditure and assess the value of every piece of activity, ensuring that surplus, low value or unnecessary spend is identified and cut or re-allocated. It might also lead to the discovery of more efficient ways to achieve goals, prevent unnecessary budget inflation and it involves staff in the budget process.

One of the main disadvantages of ZBB however, is often cited as the amount of time and resource that can be dragged into the process. Since it ensures that every budget line is considered, ZBB can be a highly time and resource intensive process, and potentially lead to staff feeling as though they need to repeatedly justify every element of expenditure. This can be somewhat frustrating if not done in the right way.

This feels like a significant shift, and the fact that ZZB is a growing trend in many organisations and marketing teams means that the impact is also potentially widespread. It could mean that suppliers find it harder to secure longer-term relationships when the value that they bring is questioned so regularly. It may also mean that it's more difficult for marketers to protect long-term investments and in some circumstances, it could potentially lead to projects or innovations being killed off too early because they have yet to demonstrate sufficient value. But then the counterpoint to this is that when things are moving so quickly questioning everything that you do is not necessarily a bad thing.

Either way, I'm surprised that there's not more debate about this potentially significant shift.

N.B. I'll be talking about ZBB in my latest Digital Shift trends webinars for Econsultancy, scheduled for Thursday 19th at 9am and 4pm UK time.

Image source

Internal APIs and Service Oriented Architecture

It's commonly believed that there are three types of API:

• Open, or Public APIs which have no restrictions on access
• Partner APIs which are made available only to strategic partners
• Private or Internal APIs which expose systems or capabilities internally, and which are most often not open to external use 

All three are interesting but for me internal APIs particularly so since they are far less talked about and yet enable an organisational operating model to be built around a Service Oriented Architecture (SOA) where individual teams and functions can make data and resources available as a service to other teams that might need them. Whilst this approach is not without its challenges (including discovery, managing demand, and support), it has the potential to support far greater agility by making more data and capability available on demand as and when it is needed. Think about how frequently in a large organisation one team requires information, resources or numbers from another team and just how slow that process can be through manual processes and email. Most organisations have grown up with multiple systems that don't share data or talk to each other meaning that breadth of access to relevant data becomes difficult.

Amazon were of-course the first scaled organisation to realise the potential of APIs to enable a truly innovative operating model that has given them (and continues to give them) considerable advantage. It all began with a famous mandate from Bezos as far back as 2002 which went something like this:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn't matter what technology they use.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired.

This resulted in the business transforming internally into a SOA where every team interacts through APIs,  defines what resources they have and makes them available through web services. But it also meant a business that thinks of everything in a services-first way. This was then taken to a whole new level through the successive externalisation of capability (services like AWS, Fulfillment by Amazon, Amazon Connect and so on). This approach means that Amazon gains greater leverage and learning through scale, services have to compete on the open market ensuring greater efficiency, and in affect that Amazon becomes Amazon's largest customer.

In this scenario teams become partners of each other, loosely coupled but able to draw on copious resources at will. Given that the need for horizontal collaboration and agilty (along with free-flowing access to data and resources) has never been greater, I'm surprised that we don't see more of this potentially transformational approach.

Reflections on Writing a Book

I can hardly believe it but last week marked the one year anniversary of my book being published. Happily it seems to have done really well since launch, selling a lot more than I'd ever anticipated (it's very difficult to gauge what good looks like in this context of-course but the publisher seems very happy, and so am I). It's also elicited some exceptionally positive feedback, and dareisayit become something of a definitive text for digital transformation in some organisations that I've come across. But it wasn't all easy. So I guess it's a good time to pause and, in no particular order, write a few reflections one year in:

• Writing a book is energising, enthralling and an education. I learnt so much from the process, and from what has come from it since publication. To be honest this was an unexpected benefit. I guess I'd anticipated it being more about assimilation of my own (and others) thinking but then I'd forgotten about my own reason for writing in the first place (duh) which is to learn of-course
• Writing a book is hard. Frequently really hard. If I'm honest it sometimes felt like a marathon that just carries on indefinitely. I have to admit that for me the biggest challenge was probably fitting it in around existing work. So go into it with your eyes open.
• Don't do it for the money. Or at least not the money you make from the cover price. It's a nice bonus of-course but the real benefit comes from the follow up work that it brings. It's hard to quantify the exact payback that it has brought me but I know for a fact that it has secured me a number of larger scale projects and contributed towards me being chosen for many others. It also really helps with speaking gigs.
• Write it because you need to write it. I often think that you can tell when a non-fiction author is really passionate about wanting to get across their point of view and when they're perhaps just going through the motions. It comes through in the writing. This was a book that I not only wanted to write but also needed to. It felt like I was saying stuff that needed to be said and that's a good basis for undertaking any writing project.
• Putting it through a publisher does make a difference. I'd thought about self-publishing several times but I'm glad I went with a known publisher in the end. Somehow that has seemed to make quite a difference with a lot of people I've met since it came out.
• It's a physical manifestation of your thinking and your credibility. And for someone like me who runs their own business and for whom reputation is everything that can mean a lot. There's something about taking a physical book with you to a meeting that you just can't get from sending a client a link.
• It marks a moment in time, but it's like being in departures rather than arrivals. One of the weird aspects of writing the book was that I kept wanting to add to it, and build on it even after it was published. I guess that's the blogger in me. As part of the marketing for the book, I continued to write about the themes it covered over on the Agile Business Medium publication. This has been valuable not only in bringing the book to a wider audience, but also enabling me to take some of the ideas I talked about in the book even further. There's over 50 posts on there now, and a year's worth of writing.

Would I do it again? Well, as I say, it's no small undertaking but on balance I would, yes.