Ten years ago, on this very day (November 2, 2006), I sent the following email to email@example.com:
My name is Guillaume Lerouge, I am a french student on Erasmus year (3rd year exchange) in London. I am currently studying business and international marketing. I have a DUGEAD (ex DEUG) from Université Paris 9 - Dauphine.
I've been interested in wikis for a while and started writing my own blog on the topic (http://wikibc.blogspot.com). I feel quite comfortable on the subject and have been thinking about offering consulting services about the potential use of wikis, but as a student this is not easy to start from scrap. I would be really interested in working with your company for it looks like the competences you need and the skills I have to offer match pretty closely.
I am fluent in both french and english. I'll be back in Paris by june 2007, and until then I would be interested in remote working. I'll be in Paris from mid-december to mid-january if you'd like to meet me.
Looking forward to get in contact,
The reply was prompt:
When do you want to start!
Ok we need to talk first... But we are very interested.
Merci pour l'anglais... On parle très bien français dans le bureau à Paris.
Ce qui me paraît tout à fait interessant c'est déjà de voir ce qu'on peut faire sur le marché londonien d'ici juin 2007.
Ensuite il y a des choses très interessantes à faire au niveau marketing chez XWiki à Paris pour developper la stratégie marketing.
Roughly translated, it said that French people speak French very well, merci, but they'd be happy to chat with me. This was how I got my first job - a job I ended up keeping for 10 years. 10 years is a long time, yet it feels like it was only yesterday. I started as a 19-year-old intern, then an apprentice, then an employee, then a manager. In that timeframe, I also became a husband and a father (though not at the company!).
During the course of those 10 years, I learnt so many things that I'd be hardly pressed to list them all. How to hire someone. How a great product is built. The value of constructive disagreement. How to build a (very) simple web application. Why it's so fucking important to fix your messes *right now* - debt accrues fast, whether it's organizational, managerial or technical. How to sell anything - an idea, a project, a solution, a mission. Most important of all, I learnt the value of trust. Trusting that your colleagues will deliver under an impossible deadline. Trusting that your clients will keep believing in you even in tough times. Trusting that whatever happens, your boss will do the right thing.
Some lessons I learnt the hard way. What it's like to lose a deal that seemed set in stone. What happens when an irreplaceable employee decides it's time for them to look elsewhere. The year-long consequences of a bad product management decision. How it feels to let someone go - the burning in your stomach, the thought that maybe there's still a chance, the days that pass in indecision before finally making up your mind.
Towards the end, a question kept popping up in my head: should I stay or should I go? Am I still contributing enough? Am I doing my part? Am I living up to the expectations the company has of me? Those of you who went through similar motions know this: once you start going through these motions, it's probably too late already.
Ending a 10-year-long work relationship isn't easy, but Ludovic understood. I've done it in private, but I'd like to thank him one more time, publicly, for everything he's done for me over the years. He got me started when I was but a random Erasmus student getting in touch out of the blue. He trusted me with increasingly important missions, all the way from intern at an 8-person startup to the executive committee of a 45-people company. He was never afraid to point out my mistakes (and oh boy! the mistakes I did) and remained supportive all the way. I wish him and XWiki the best in their path forward!
Deciding what to do after such a long stint wasn't an easy thing. I was the man of one company. As I told Vincent, XWiki's CTO, when he asked me what I hoped to do next: "I spent ten years at one company, now I'd like to spend one year at ten companies". I had dabbled with short consulting missions towards the end of my time at XWiki, helping young startups define their go-to-market strategy and assumed I could do this full-time.
However, one thing quickly became clear to me: helping startups as an outside consultant is complicated. You have no skin in the game. Your fees are always too high for their constrained resources. You need to be on the inside. How could I reconcile this with my wish to work at 10 companies in one year?
In hindsight, the answer was simple: 2 weeks ago, I joined La Javaness, an up-and-coming French startup factory. I couldn't have hoped for a better place to pursue my career. Our worldview is simple:
- Several technological revolutions are currently sweeping the world (Blockchain, AI / Machine learning, Virtual Reality...).
- B2B tech startups are emerging in this space, but they have a hard time cutting through the noise and getting noticed by large corporate partners & potential recruits.
- Big companies are looking for innovative ways to embrace these revolutions.
Our mission is to bridge the gap between startups, corporate actors and tech talent. We do this in the following ways:
- We built a team of world-class experts in the fields we identified as the most promising - machine learning in particular.
- We developed a strategic partnership with Eurogroup Consulting in order to get access to the largest companies in France and help them make their digital transformation projects successful.
- We incubate promising B2B startups, giving them access to tech talent they would be unable to benefit from otherwise as well as corporate partners they wouldn't otherwise be able to reach.
My job at La Javaness will be to help startups and corporates build innovative projects together.
Effective today, I am also taking over the organization of Startup Grind events in Paris. Looking forward to meet you there :-)
On to the next 10 years!
What we’ve learned is that group chat used sparingly in a few very specific situations makes a lot of sense. What makes a lot less sense is chat as the primary, default method of communication inside an organization. A slice, yes. The whole pie, no. All sorts of eventual bad happens when a company begins thinking one-line-at-a-time most of the time.
We’ve also seen strong evidence that the method and manner in which you choose to communicate has a major influence on how people feel at work. Frazzled, exhausted, and anxious? Or calm, cool, and collected? These aren’t just states of mind, they are conditions caused by the kinds of tools we use, and the kinds of behaviors those tools encourage.
Based on these discoveries, I’ve put together a list of the positive and negative impacts of group chat on an organization. If you’ve gone chat-first, or you’re considering heading down that path, I encourage you to review and consider these impacts on your own organization.
An absolute must-read if your company is considering using Slack, HipChat or Skype for business. We've been using Skype internally for as far as I can remember at XWiki. I couldn't see us running a distributed company without it, but the associated cognitive costs are real and should not be underestimated.
Continuing in the vein of yesterday's post, here's another great article from The Macro. This time it's Michael Moritz from Sequoia, sharing advice on how to build a company that achieves success over a long period of time (think 40+ years):
Yesterday is irrelevant
How have we done it? It all sounds very, very mundane. You can read a book about the principles of high performance, or great leadership, and it’ll all sound very straightforward and rudimentary. The difficulty is doing it every day, doing it every week, month, quarter, year, and keeping that beat up.
That was one of the great things about Steve Jobs, it’s one of the great things about Larry Page, it’s one of the great things about Jeff Bezos, or Reed Hastings. These are leaders who are capable of doing it. How do they do it?
They want to make sure that their product is fresh, that it changes with the times; that they never rest on their laurels, or get complacent; that they always have an element of insecurity about feeling that they can always get eaten by a competitor, and that past successes don’t mean all that much.
Which is part of the reason we don’t have all sorts of lucite blocks commemorating this or that anniversary of some company hanging around the office at Sequoia: Because all of that is yesterday, and it’s irrelevant to the future.
Achieving success once isn't hard. Sustainable success at the highest level is.
So how did Oklo, formerly known as UPower, start?
Jacob : At MIT, I’d met my co-founder Caroline Cochran, who was also in nuclear engineering and had a background as a mechanical engineer. We started really digging into how would we do something advanced in nuclear with a startup. But we didn’t want to be technology pushers. We wanted to follow what people wanted, what people needed.
We had a series of conversations with friends and contacts who were working in power development for remote communities – for projects like mining and gas. They’d talk about how much a pain in the rear it was to get power to these remote places they were working on. The common thing to use is diesel, but it’s a big problem: There are often no roads to deliver the fuel, it’s quite unwieldy, the weather can be so severe that it will freeze, and so on.
These people would say, “Well, diesel is the most energy-dense fuel we know.” But nuclear is 2 million times as energy dense. We’d ask them, what if there was a small enough reactor that you could bring out on a job site? They all said, “Whoa, who makes that? We would buy that in a second. As many as you could make.”
And that's how you get started building the nuclear reactor of the future!
The New York Times Magazine ran its Work Issue last week. The first article from the issue shares learnings from project Aristole, a Google initiative to understand what makes team click. The Google People Ops team had actually published findings from this issue back in November 2015.
They found that psychological safety was the most important among 5 key dynamics experienced by successful teams:
Psychological safety was far and away the most important of the five dynamics we found -- it’s the underpinning of the other four. How could that be? Taking a risk around your team members seems simple. But remember the last time you were working on a project. Did you feel like you could ask what the goal was without the risk of sounding like you’re the only one out of the loop? Or did you opt for continuing without clarifying anything, in order to avoid being perceived as someone who is unaware?
Turns out, we’re all reluctant to engage in behaviors that could negatively influence how others perceive our competence, awareness, and positivity. Although this kind of self-protection is a natural strategy in the workplace, it is detrimental to effective teamwork. On the flip side, the safer team members feel with one another, the more likely they are to admit mistakes, to partner, and to take on new roles. And it affects pretty much every important dimension we look at for employees.
While this doesn't come as a big surprise, it's still a good reminder. As a manager, your behaviour and attitude can be interpreted in (very) unexpected ways, and making sure that you're not sending the wrong message to co-workers and that they can express themselves freely without feeling that they're being judged is extremely important.
Tom Tunguz has a great article on professional services:
As the next generation of SaaS companies achieve maturity, they have begun to serve larger and larger customers, who in addition to demanding a great product, often request services. Professional services, as they are often called, entail training and customization. For product driven startups, the decision to offer professional services is a tricky one.
On one hand, the customer is always right and services often enable substantially larger contracts. On the other hand, selling hours to drive revenue decreases the efficiency of the business, by hiring more people in order to grow revenue linearly. In addition, many businesses operate their services divisions at a loss. But not all.
Professional services are a subject close to my heart. As an open-source software company, XWiki SAS derives a significant part of its revenue from professional services. The ideal we're striving for with our new XWiki Collaboration Suite offering is to find a way to enable customisation according to client needs while keeping upgrades as seamless as possible.
What we've found aligns closely with Tom's observations: the larger the client, the more likely they are to have custom requirements that you'll need to fulfil in order to close the deal. When applicable, product roadmap sponsoring is a great way to bridge that gap: your client gets the feature they need and your product keeps progressing.
It’s really tough. I think part of what you have to do, unfortunately, to survive early on is you kind of have to toe that line. And you have to always go back and say, “What we’re building is a software product that is going to be scalable, that’s going to be used by multiple companies.” But it also depends on what part of the market you’re selling into, what types of customers you have. If you’re selling $100k enterprise deals, you’re going to bend a little bit more to make sure it works for Oracle or some huge company, versus Bob’s Pizza Shop.
But it’s really delicate. I think we may have taken too stern of a line early on and said, “No thank you” to customers, where we said, “Here’s our vision of what the future is going to be, you need to agree with us.” And over time, maybe as we grew the engineering team, we grew our capability and we could ship features or variations more easily we tried to open our arms a little bit more and bring people in.
But you never want to be truly doing things that are one off. You want to say, “Is this going to be useful for the next 20 customers?”
How do you handle professional services at your company?
When the product was first coming together, Butterfield and his co-founders returned again and again to Paul Buchheit’s now-famous blog post, “If your product is Great, it doesn’t need to be Good.” Known as one of the creators of Gmail, Buchheit has a simple thesis: If you do a few things incredibly well, the rest doesn’t really matter. [...] Buchheit’s words strongly resonated with Butterfield and his team."We don’t cut corners, and we try to focus on the few things that are most important to our product vision."
For Slack, those three most important features are:
- Search [...]
- Synchronization [...]
- Simple file-sharing [...]
These may not be checkbox features, or buzzworthy new concepts, Butterfield notes; they may not even be things that users think they’re looking for in a solution. But when it comes to a successful go-to-market strategy, perhaps the most important decision you can make is to build a product you believe is different from everything else out there, and an important change for the audience you're going after.
“We had a lot of conversations about choosing the three things we'd try to be extremely, surprisingly good at,” Butterfield says. “And ultimately we developed Slack around really valuing those three things. It can sound simple, but narrowing the field can make big challenges and big gains for your company feel manageable. Suddenly you're ahead of the game because you're the best at the things that really impact your users.”
Blue Ocean Strategy talks a lot about the need to create a differentiated value curve. It looks like that's exactly what Slack did, by focusing on a set of key things that they had to do much, much better than their competition in order to stand out from the crowd.
I would say that since this interview, a fourth pillar that emerged is the ease fo creating integrations. Being able to very simply send pieces of information and content from apps to Slack channel is a killer feature for many teams, and something that other chat products didn't really do well before.
David Cummings has some interesting insights about the future of productivity applications. He argues that we will more and more see apps that focus on a specific job, with one application of record per job function:
Phase three is new vertical-specific SaaS applications as well as more specialized solutions that represent portions of more complicated products. One way to think about it is that there is an application of record for each job function (that is, a product that people in that job function spend a large number of hours per week to perform their job). [...] What job functions currently use a generic solution, but would be better served by a more specialized solution?
One specificity of such apps is that they will guide the user on how to do their job well, moving towards prescriptive solutions:
One of the biggest trends for SaaS over the next five years is new products that offer prescriptive solutions in place of general tools. What I mean is that there are a number of well-defined categories like CRM and ERP that are essentially customizable front-ends to specialized databases (e.g. CRMs are mostly contact management databases). These new products are still going to have the specialized database behind the scenes, but the front-end is more of a business process management system that actually tells the user what to do next.
This also corresponds well to the "First SaaS explosion" as described by Clément Vouillon:
As SaaS penetration grew (businesses of all sizes are ready to buy SaaS now) and as the technological barriers kept going down, many verticals saw an explosion of new players. These new startups very often focus on a more specific part of a vertical and offer products with better UX/UI than what the bigger players can do.
It's going to be interesting to see whether this leads to further fragmentation down the road, or whether big players will just gobble up smaller ones in order to beef up their offerings (the way Salesforce did it with Eloqua and Pardot in the marketing automation space).