Mal was neues und mal was auf deutsch. Mit HR-Experten Stefan Berndt hab ich mich unterhalten über jede Menge HR-Themen. Podcast Link hier.
Big insight of the day:
Be generous with everybody around you.
Somebody doesn’t do their homework on time, doesn’t show up to a scheduled meeting, has trouble prioritizing, maybe freaks out a little — let them off the hook gently.
This is not the time for six-sigma precision and micro-management.
And, this is important, that applies to you too. Feeling the blahs, need some sunshine, wondering if it’s too early to open that bottle of wine? Step away from your desk and take a moment.
Or two or three.
Second session. We covered the basics, nothing new, but mandatory tools that you shouldn’t go without. Sound quality pretty miserable, sorry about that.
“If we don’t want to hire any managers then we had better start learning a bit about management.”
I’m running an informal and improvised and slapdash and fragmented and your-mileage-may-vary management training program for some interested people.
Day 1 is about Tools & Techniques. Some simple, some complex. Four sections.
This section is about decision making, the importance of execution, distinguishing between reversible and irreversible decisions, and the advice process.
Some random issues related to working with other people and, more importantly, for working with yourself.
Discussing some favorite mantras that can be useful as the days go by and you keep coming back to the same topics again and again.
Tools that are powerful and scary. Not for the faint of heart. But if used well they can be transformative. The Amazon memo. The GV design sprint. V2MOM. OKRs.
The Good Old Days
There used to be a time, and I remember it well, when working in the software industry was straightforward and well-understood.
You had your categories of vendors (such as OS and database and development tools and big and expensive business applications and desktop productivity and utilities and so forth) and, per category, you and the market had a clear understanding of organizational architecture and price points and buying center and release velocity (or the lack thereof).
And if you were an engineering or a marketing or a sales executive you could easily hop from one company to the next because they pretty much all worked the same way.
Especially when it came to how the various markets structured their partner ecosystems.
So everybody understood what it meant to be a distributor or a VAR or an ISV or an SI or an MSP. A very clear and very specific understanding of who added value how and how much across the extended delivery chain.
O Brave New World
None of that really works anymore. The world has changed in many ways:
The tried-and-tested models for organising the value chain from software product owner to the end customer now break down, as serial handovers across the chain make any kind of agility very hard to achieve and the amount of diversity of talent required cannot be staffed redundantly in the various companies involved.
And so we look to the miraculous productivity and scalability demonstrated in a whole number of open source projects. And we start asking: Why can’t we have that?
On the face of it, the answer is simple. As a software vendor, we want to make money. Making promises to professional customers based on the assumption that some “if you build it they will come” open source project will attract hordes of committed and competent volunteer engineers is at best naive, if not downright exploitative.
For our customers, it’s much the same. They expect quality and service levels and they will gladly pay for it. They cannot run their businesses on stuff that might not work or disappear just because the hordes of volunteers moved away to the next adventure.
So if you’re a software product company, how do you structure an ecosystem of partners that can deliver agility, that orchestrates the full stack of expertise required for customer success regardless of where these people work, and that makes sure everybody in the value chain is paid more or less in accordance to their respective value-add?
The underlying assumption is of course that you do want to keep your organisation as compact as you can and that you do want to leverage a partner ecosystem to increase your reach and scalability and that you do not measure your success by counting the armies of people working for you. If that is not your basic assumption then you can stop reading and go back to dreaming about being Larry Ellison. Unless you are Larry Ellison. Hi Larry.
Acme
So let’s try a Gedankenexperiment and put ourselves in the role of a new and emerging software vendor. Probably a pretty specific business application, probably SaaS. Because that’s where all the innovation and momentum is in enterprise IT. Remember: “Every spreadsheet shared in a business is a SaaS application waiting to be built”. Let’s call our company Acme. As you do.
To make things more interesting, we assume that Acme is a startup attempting to create a new category of enterprise applications software. Think Siebel and CRM, think Successfactors and HCM. Because why not.
This means that we at Acme are free to decide how much of a value chain we want to build in-house vs. how much we want to orchestrate a partner ecosystems. It also means that we had better have a damn good business proposition for potential partners out there. Because they don’t know us from Adam and they couldn’t care less.
Now what? Let’s look at what kind of partners and skills and competencies we might want to orchestrate in our wider ecosystem. We’ll probably be looking at a set of diverse partner types who could be playing important roles in our value chain. Candidates include:
Development boutique:
A smallish (15-70 people typically) staffed with specialised software engineers. Typically focusing on a small handful of technologies or products that they concentrate on and where they are the go-to specialists for customers or systems integrators. Organizational structure and decision making pretty agile, so if they can allocate a small handful of engineers to a new topic and take it from there they get interested. Especially if they see the potential to grow that into a practice of maybe 15-25 over time.
This type of partner can be pretty easy for us to work with, provided that we (!) deliver the projects for them to execute.
Product boutique:
A company who has built or can build something that fits really nicely into our framework. This could be anywhere on the stack, but, to make things more specific, let’s assume that they have a special application that they want to add to or build on top of our platform. And that this application requires some kind of deep domain expertise that we do not have and are unlikely to develop on our own.
This type of partner looks easy to work with, if (!) we assume that our platform is sufficiently stable and documented to enable arms-length application development by a third party. That’s a big if for Acme, where our stack and structure and interfaces are all still evolving.
Things also get interesting when the combined solution set touches the customer: Do we sell the platform to the customer and our partner just sells their bit? Or does the partner resell the combined solution? Who provides support for the combined solution? What if that customer wants to do more with our platform and/or buy from other product boutiques?
And what happens if our stack isn’t yet where it would need to be? And the partner has to help us do some heavy lifting inside our own codebase before they can hook up their complementary software product? And how does this partner get access to our global customer base who have decided on our framework and might have a need for this additional application?
Big systems integrator:
A big to very big systems integrator providing soup-to-nuts for large customers and who hold those customers captive. Nothing happens there that they do not participate in. And we do want to work with them, because they have deep customer knowledge, strong trust, and scalable skills in technology and service that we could never dream of.
But when it comes to building strategic relationships with new emerging software vendors, the SI companies can be tricky to work with. Initially they will likely wonder if they shouldn’t just build it themselves with the large number of engineering resources that they own and that need to be fed. Then they’ll be wondering if our products are stable and secure and just generally good enough to be allowed into their captive customers. And they will be continually wondering if the joint business potential will ever be big enough to move their oversized needles. Not easy at all.
The Frameworks
So now we start looking at how we at Acme might structure a new kind of ecosystem for optimal agility and maximum scalability and optimal distribution of investment and return for the diverse parties within that value chain. And now we’d be looking at a variety of scenarios and trying them on for size. Such as:
SAP
I’m SAP. I’m big and strong and I have lots and lots of engineers. The best in the world. Engineers who don’t work for me are either not good enough or will end up working for me. But I am also an incredibly talented and ambitious software architect so I build something beautiful. Probably a services-oriented architecture. Where I decompose big systems into small modules and define clear interfaces and contracts between them. And where the modules can be released independently because nothing breaks as long as the contracts are maintained. And I call it Netweaver. And many other names.
And this helps me manage my own development efforts because I can reach a pretty good amount of decomposition. And it enables the definition of handovers and touchpoints to outside companies, who may have complementary skills to mine and who I want to bring into my overall solution set for my customer.
So I take the SDK that my own people use and make it available to selected external parties and I build a training and certification program and charge enough for it that it both funds itself and also acts as a filter for the external software developer, just to see if they’re serious and have thought about their business case.
The good news for me: From an architecture point of view, the external partner is not so different from one of my internal development groups. So there is not that much incremental investment needed, except in training and certification, and I will make the partners pay for that.
The good news for the partner: I am so massive and have so many customers that the partner will have strong hopes for increased visibility in the global marketplace.
The bad news for the partner: I might at any time decide to extend my own functionality and cut off their air supply. Sometimes without even meaning to. Oops.
The bad news for me: The services-oriented architecture requires a maturity of product structure that takes time to evolve. In the first several years of developing my complex software system I will not really know where to cut things apart and where to put them back together. And once I do know I will have to define and maintain the external interfaces for my components. Which immediately slows down any kind of rapid innovation or system-wide architecture overhaul. And, more often than not, the whole construct grinds to a standstill. Agile this is not.
Microsoft
I’m Microsoft. There are a couple of things I do really well. Tools and platforms and frameworks and databases and operating systems. I have absolutely no desire to go acquire deep domain expertise for specific verticals or business processes. Better leave that to the outside world.
So for something like my Sharepoint Portal Server I focus on the overall framework, such as user management and access control and a repository and a precise presentation layer etc. And I leave ample space for a whole universe of third parties to add value on top of that platform. I invest systematically in a well-managed and highly scaleable partner ecosystem, where VARs can add value by configuring and training and where ISVs can build their own products on top of mine and where SIs can deliver and operate custom deployments for their customers.
My partner machine is highly programmatic and has a strong infrastructure for training and certification, which accelerates partner recruiting and onboarding, helps in ecosystem quality control, and creates a job market for certified engineers. Partners pay for some of that, but that’s really partial cost recovery. Mostly this ecosystem is an investment, required to complete the last mile to the customer.
The good news for me: This is probably more efficient and more scalable than bringing everything in-house. There is talent and expertise out there that I can harness in the customer’s best interest. Everybody wins.
The good news for the partner: There is a clear value proposition and a fairly good understanding of where Microsoft might extend their own product stack and where they will definitely keep white space open for partners. Exceptions apply. Oops.
The bad news for the partner: They have to work with what they’re given. API-call missing? Need to change the storage substrate? And, God forbid, bugs in the underlying framework? Tough luck, thank you for your business, all our agents are helping other customers, your call is important to us.
The bad news for me: Again, this requires a mature software structure, a complete set of APIs, a mature documentation and training machine, and once it’s out there I cannot take it back. Agile this is not.
Also, as these ISVs and VARs and SIs sell independently into my customers and I really don’t know what they’re shipping I have essentially no control over quality and portfolio overlaps and channel conflict and the overall customer experience. So I end up adding a layer of key account management and strategic consulting to help the enterprise customer navigate through the solutions catalog and the partner universe and to ensure a positive platform experience.
Apple
I’m Apple. I provide platforms for experiences. Let’s call them MacOS or iOS. I want to harness the creativity of the developer universe. I want to create an ecosystem of application developers to ensure that the long-tail of customer needs can be satisfied on my platform. But I care deeply about the overall end-user experience for my devices. So I build a storefront and a process for developers to offer applications to my customers. I sell and invoice these applications and I curate the catalog and I make sure that there is no garbage in there and no overlaps and I quality-control every single app that is submitted.
The good news for me: This makes my devices and platforms provide infinite value to my end-users, because, no matter how long-tail their needs are, there will be an app for that. And I take 30% off of the customer invoice and that is a significant additional revenue stream. Especially as that is is potentially long-term and ongoing and therefore nicely complementary to the one-time payment dynamics of the original device sale.
The good news for the partner: This gets them massive distribution.
The bad news for the partner: The platform capabilities are controlled by me and they completely depend on my whim. And I may take ages to quality-control their software update. And I may reject their software update. Sometimes a big price to pay.
The bad news for me: I have to define the framework and freeze it (agile this is not). And I have to actively curate and quality-control the contents of the app store. Because everything delivered via the app store is part of my end-user’s overall experience. About which I care so much.
I’m Google. Actually, I’m Android. I understand the benefits of the open source tooling and process and framework. And I’m not afraid to use that where it makes sense and I’m able manage a fair degree of complexity. But it’s worth it. So I pull in a Linux kernel via GPL as a base OS layer. Then my engineers build a whole bunch of stuff on top. Which I pay for and I own. Nicely separated so no GPL infection.
Then I transfer the whole thing to a foundation as open source under BSD. That is my reference implementation for device manufacturers. In parallel, I build the Android brand and establish that in the market. Device manufacturers who want to use that brand (and most do) have to license that from me. And in that license agreement they sign up for a whole bunch of terms of what they can and cannot do. Pretty neat. Some people (e.g. Fire OS) don’t sign that license agreement but then they can’t use my Android brand.
And inside my massive Android system there are a varying number of components that have varying qualities of open-source-ness. So there may be component where I just pull in something from outside. There may be a project out there that is important to me so I staff some of my one people into that project. Or I may just pay some people in a relevant open source project. And none of that is cast in stone, as these subsystems may come and go.
Also I ship some proprietary software on top of the open stack (e.g. Google Play Services), so the overall experience includes essential parts of software that I have not open sourced or licensed to anybody.
The good news for me: I get a lot of the OSS qualities, such as transparency, faster learning curve for partners, partners can send me PRs for stuff in my code base that should work but doesn’t, orchestrating some arms-length OSS project so that it lines up with my own stack, etc.
The good news for the partner: They can look inside the technology. They can fix stuff that they need fixed and keep maintaining the fork themselves (bad) or get me to accept their PRs (good).
The bad news for the partner: The system and the stack are never ever stable. Releases happen frequently. And they need to keep up.
The bad news for me: I have to provide the bulk of the engineering and of the processes and tools required to make such a massive yet pretty dynamic piece of software not break down. That is a lot of engineers and a lot of overhead.
Elon Musk
And now, just to give it a try, I’m Elon Musk. Or some other maverick story-teller that can move whole markets with what is initially nothing more than hot air. So I don’t give a damn about the olden ways and the more I can break the better. What is all this talk about value chains and handovers and partner categories and business frameworks? Makes no sense to me. Time for First Principles Thinking, you know.
So I start imagining a worldwide community of software developers, all one big happy family, regardless of where they live and who they work for. And then I think of a value chain where the customer can pull in all the developers needed for their specific needs, including their own personnel (who usually have the real domain expertise), systems integrators for modeling and designing and deploying and supporting, special boutiques with business and/or technical skills, and ISVs with relevant product components that need to be licensed. And my own people, of course, since it will be a long time before my platform is so stable that critical customer projects can be executed without my participation.
And of course I am at the center of the universe, providing the technical framework in terms of platform products, as well as the process framework in terms of how to structure this value chain, as well as the business framework, defining the distribution of investment and return according to everybody’s respective value add.
By this time you probably start imagining a federation of Github-repositories, governed by some kind of modified MIT license. And you’re also imagining some kind of ICO currency that structures investment and rewards for all people and companies involved in the value chain, and the payment stream from the end customers providing the exchange mechanism for the virtual currency into real money.
Well, you’re thinking in the right direction. We’ll leave the rest as an exercise to the reader. If you’re Elon Musk, that is. Hi Elon.
Coming Back to Earth
So what does this all mean to us at Acme. Remember, we are a startup well underway to creating a new SaaS business application category and we are fundamentally committed to orchestrating a robust and scalable partner ecosystem. That has to be, first and foremost, truly agile in how it works internally and with customers. And where our tooling and technology may not be quite as mature and stable as we would like to be. But maybe it never will be stable and mature. Because then we’d lose agility.
Grabbing bits and pieces from the frameworks described above we might very well end up with something like this:
Our development process and tooling is all Github. Repositories and maintainers and contributors and reviewers and pull requests. The repositories will not be open, but customers and partners have access to our private repository and can read and lift code and fork away. Plus a really efficient and streamlined process for integrating, building, testing the overall system in sync with the release cycle. Both for our code and for any partner or customer code that may be integrated or dependent on our deliveries.
The license for the source code is a modified MIT license. It defines ownership and usage rights, defines what rights, if any, external partners have and who, if anybody, they can pass the code on to. And what rights, if any, people can claim if they build artifacts that are derivative of our code.
In those cases, and there will be many, where our product has missing pieces and capabilities that stand in the way of partner or customer success, this customer or partner may well decide to help out and contribute important code fragments just to fill the gaps and to speed things up. In most cases these developments will be submitted as PRs to us, because the external party will really not want to maintain their own fork, given our rapid release cycle.
If we accept the PR they become our property. Well, actually they were our property all along, because they are derivative works. This makes business sense as we have now also assumed responsibility for the ongoing maintenance and development of this code fragment. We do not have to accept the PR. But the rights the third party has to the fork are still highly restricted via the modified MIT license. These are derivative works after all.
From time to time we may, as an exception, provide some level of funding to the third party submitting PRs, subject to specific commercial agreements. As an exception, because the primary interest of the partner or customer was in filling the gaps, so they could go back to their original business case.
As the footprint of our technology grows in the market there may be an ongoing number of development projects that have potential for our wider customer community. These can be customer one-offs that turn out to be of wider interests or partner-led product investments.
In the case of customer one-offs, the likeliest scenario will be for the customer to transfer ownership of the code to us in exchange for ongoing maintenance and further development. We may, as an exception, provide some level of payment or revenue sharing on top of our assumption of the maintenance cost and responsibility, subject to specific commercial agreements. As an exception, because the TCO incurred for maintenance and support is typically a multiple of the original development investment, so the customer should be really happy if we decide to take over.
In case of partner-led product investments, the partner will likely stay involved in the maintenance and support of their product as it evolves. And we would want them to, as their products require their expertise.
This will have us replicating a lot of the “Apple App Store” mechanics, whereby we curate a storefront of certified partner solutions, let’s call them “apps”. The apps are proposed by partners, we decide what goes in the app store and what doesn’t, and our large customer will find a wonderful array of solutions to pick from and thus will find dramatically more value in their strategic commitment to our platform. From time to time we may also develop some apps ourselves and put them into the app store. Ditto for customer one-offs that they have transferred to us.
We may also replicate the quality-control mechanics of the Apple App store, as customers will see these apps as part of their overall Acme product experience and don’t want to worry about version control and incompatibilities. So partner apps listed in the app store all come together in our product packaging and we will build and test and integrate everything into one overall customer delivery.
This is independent of the invoicing chain. It might seem reasonable to not copy the Apple model and to allow the various ISVs to contract directly with the customer.
But then we would need to make sure we recover our cost for quality-controlling the partner app, via e.g. a program fee or a store-placement fee.
And we would also need to make sure that the relative value creation for the customer derives to a significant part from our platform capabilities. If our platform were to degrade into a lowly SDK then we would very much want to get a heavy margin on the apps sold in our app store.
The ISVs will also provide direct customer support for their apps to the customer. At best, our first-level support may route tickets to the respective ISV and provide a unified contact point to the enterprise customer.
Is that it?
What on earth is new here I hear you ask. Well, not very much. Which is exactly the point.
Remember our original baseline: How can we create a new category of enterprise software by orchestrating all relevant expertise, regardless of which company that expert works for. And make sure that everybody gets paid appropriately.
What we didn’t do is start from scratch and invent a new business model and prepare an ICO. Sorry, Elon.
Instead we took a whole bunch of stuff that the industry is very familiar with: Github repos and forks and pull requests and more-or-less-MIT-licenses and maintenance contracts and reassignment of commercial rights and curated app stores. Pretty complex, but look at Android. It can be done.
Currently working with several companies on their pricing. In general, if you are selling direct and not via a self-service website then this advice still applies.
But when you have to scale the sales force and/or sell via partner and/or sell via a self-service storefront then you will need a pricing scheme that makes sense. Which often means per-user based pricing. Nothing wrong with that.
But there are scenarios where that is not the right metric. And where you will need to introduce usage-based pricing.
The key is to find a metric that your customer will find easy to understand, measure, and forecast. People absolutely need to know how much they will pay and when you will ask for more for a frictionless purchase decision.
Two good examples are:
Mailchimp with three different value propositions (commodity vs. professional email list management vs. marketing automation) as primary axis and then straightforward volume bands as the secondary metric.
Both intelligently structured and beautifully presented. Well worth imitating.
Note to self: Spend less time reading year-end top 10 lists and spend more time reading. Or, at least, make your own top 10 list. So here goes. Note: These are books I read in 2016, most of them came out before then.
In no particular order:
Paul Theroux: Deep South. A travelogue going to places in rural and poor southern counties that nobody knows and where nobody goes. Deep and meaningful conversations with the people who got left behind and stick it out. Bonus: Great photography from the one and only Steve McCurry.
Stewart O’Nan: Sunset. F. Scott Fitzgerald’s life at Hollywood, trying to make it as a screenwriter. Brilliantly written and incredibly interesting. But of course you could say that about pretty much any book by Stewart O’Nan. He just keeps churning out one great book after another.
Danilo Di Luca: Bestie da Vittoria. Among the many dozen of cyclist autobiographies this one stands out. Because he takes you straight into the mindset of the athlete who has to win at any cost. Not a nice place to be, but brutally honest.
Yuval Noah Harari: Sapiens. Wow. Just wow. So much knowledge, so brilliantly told, and incredible nuggets of insights both in generally available knowledge as well as unique observation and analysis. Mandatory reading.
Elena Ferrante: Storia del Nuovo Cognome. Yes, you can believe the hype. The books in the Naples tetralogy really are that good. The emotional depths of the two heroines, the description of life in the Neapolitan slums, and the socio-economic development of post-war Italy make this compelling on so many levels.
Geoff Dyer: White Sands. A writer’s writer. Like nothing else. This collection of quasi-autobiographical essays is particularly rich.
Cheryl Strayed: Wild. Unputdownable. The combined description of personal and physical journeys is unique. Maybe a bit dramatic in places, but so authentic and raw that you come on board and stay there.
Wolf Biermann: Warte nicht auf bessere Zeiten. Somewhat embarrassingly I did not know his work. Still don’t. But this description of life growing up in the DDR and then getting kicked out is precise, authentic, often funny, and incredibly interesting. Mandatory reading.
Anne Garrels: Putin Country. NPR journalist covers life and people in a mid-size Russian city over twenty years and charts and impressive course from the breakup of the Soviet empire to Putin Country. Rich, authentic, and not quick to pass judgment.
Helen MacDonald: H is for Hawk. Oh boy. What a journey. You get sucked in on the first ten pages and then you’re in for the ride. Who ever thought a book (seemingly) about training a hawk could be so incredibly interesting.
Books that did not make the list:
David Millar: Racer. Very good.
Klaus Modick: 24 Türen. Not sure.
Marlon James: A Brief History of Seven Killings. Overwhelming.
David Mitchell: Slade House. Unputdownable.
Ragnar Hovland: Uber den Wassern schweben. Flott.
Walter Bernardi: Sex and the bici. Divertente.
Anthony Doerr: All the Light We Cannot See. Excellent.
Bill Bryson: The Road to Little Dribbling. Fun.
Amos Oz: Judas. Impressive.
Bradley Wiggins. My Time. Good enough.
Larry McMurtry: Roads. A pleasant surprise.
Brian Benson: Going Somewhere. Not quite good enough.
Alessandro Baricco: Mr Gwyn. Hhhhmmmm…
Reynolds: Slow Road.
Barnes: Noise of Time. Very good.
Stewart O’Nan: West of Sunset. Excellent.
David Grossman: Kommt ein Pferd in eine Bar. Sehr schwierig.
Seethaler: Ein ganzes Leben.
Di Luca: Bestie da Vittoria. Wow.
Stewart O’Nan: City of Secrets. Excellent.
Jens Voigt: Shut Up Legs: Fun.
Leta Semadeni: Tamangur. Schwierig.
Jan Cleijne: Legends of the Tour. Can’t remember.
Juliana Buhring: The Road I Ride. Good stuff.
Edward P. Sykes: Along the Med on a Bike Called Reggie. Can’t remember.
Hughes Kehlenbach: Long-Distance Cycling. Not so good.
Ketil Bjornstad: Die Unsterblichen. Stark.
Bjarne Riis: Riis. Good enough.
Geoff Dyer: Sheer Rage. Brilliant.
Dave Eggers: Heroes of the Frontier. Very good.
Leslie Jamison: The Empathy Exams. Impressive.
Emily Chappell: Unburdened. Not bad.
Jonathan Ames: Wake Up, Sir. Good fun.
J.D. Vance: Hillbilly Elegies. Expected more.
Ian McEwan: Nutshell. Brilliant and then some.
Robert Harris: Conclave. Good fun.
Keith Foskett: The Journey in Between. Pretty dull.
Keith Foskett: The Last Englishman. A bit better.
Jack Hitt: Off the Road. So so.
Rita Kuczynski: Mauerläufer. Da lernt man viel.
Manfred Krug: Abgehauen. Da auch.
Eva-Maria Hagen: Eva und der Wolf. Da auch.
Otessa Moshfegh: Eileen. Nasty and disappointing.
Ian Frazier: Great Plains. Good stuff.
William Boyd: The Vanishing Game. Great format.
Geraint Thomas: The World According to G. What a pleasant surprise.
Sabine Bode: Nachkriegskinder. Enttäuschend.
Josh Katz: Speaking American. Fun.
Rühle/Zekri: Deutschland extrem. Ganz interessant.
Tim Moore: The Cyclist Who Went Out in the Cold. Fun.
George Plimpton: Paper Lion. Pretty good.
Jonathan Safran Foer: Here I Am. Excellent.
Saul Friedländer: When Memory Comes. Remarkable.
Kjetil Bornstad: Erlings Fall. Solide.
MIchael Krüger: Das Irrenhaus. Toll.
Arno Surminski: Von den Kriegen. Schwierig.
Gerhard Jäger: Der Schnee, das Feuer, die Schuld und der Tod. Nicht schlecht.
William Boyd: The Blue Afternoon. Solid.
So “Andreessen in hot water for texts he sent Zuckerberg”. Some kind of collusion between board member and CEO.
Not sure if there is anything untoward going on here. That is for the lawyers to discuss.
What I do know is that it’s really good news that this kind of discussion happens via texting, as opposed to clandestine meetings or off-the-record phone calls.
That way they are on the record and all parties involved have a chance to reconstruct the information exchange and to then make an informed decision.
Wouldn’t it be great if all such communication in the past had been explicit and on the record? Then we’d have a much clearer picture on what may or may not have gone on at e.g. Siemens and Daimler and Deutsche Bank and Volkswagen.
Interesting article by Aaref Hilaly on “Why the next great SaaS company will look nothing like Salesforce,” distinguishing between Systems of Record (e.g. Salesforce, Workday, etc.) and Systems of Engagement. Where the latter take existing data and add value by making them available, integration, and analytics. And Aaref warns against trying to provide the next SOR and says that those franchises have been taken.
There’s a valid point there. Starting a new venture for e.g. wall-to-wall CRM would indeed be a bold undertaking.
But, and that is a big but, there are two wide open areas of opportunity here:
IT-poor environments that do not have the skill set to select and deploy a grown-up solution. They can benefit tremendously from a highly specific offering that gets the instant initial business value right and then grows footprint in a way that is manageable for the customer. Think of something like Shore, which starts out offering appointment management for very small businesses and then builds a more feature-complete CRM and analytics experience around that first, immediately valuable, functionality.
And while wall-to-wall SOR opportunities for the enterprise may have become limited, the game is wide open in those areas that have not been equipped with genuine SOR solutions. If you look in the e.g. HR, strategy, M&A, sourcing, planning etc. departments in the big enterprises, then 90+% of the IT stack is Excel and Sharepoint or some legacy ECM. There is a boatload of opportunity here for introducing new Systems of Record that support documentation, communication, and organization non-trivially. And where the products and companies that are successful will look a lot like Salesforce.
The rule of thumb here is: “Every spreadsheet shared in a business is an angel announcing another SaaS app still needs to be built.“
olivergajek 