VimGolf is my new favorite little toy. As time wasters go, this is probably the best. I pontificated on Twitter about whether or not there was a tool that would let you reverse engineer the results from VimGolf to teach yourself new commands.

VimGolf is my new favorite little toy. As time wasters go, this is probably the best. I pontificated on Twitter about whether or not there was a tool that would let you reverse engineer the results from VimGolf to teach yourself new commands.

I couldn't find one, so in typical engineer fashion, I made one.

Introducing The Magic of Vim. Maybe it will grow into something more. In the meantime, it's a quick lookup tool for Vim keystrokes that someone else blindly tells you to type.

I'll eventually get around to putting it on Github so that other's can contribute.

You need investment. Your startup will die without it. If you can’t convince customers to pay you, you need cash to build up your product or service so your customers feel comfortable paying you. Luckily, entrepreneurial ecosystems are everywhere, ready to provide bright entrepreneurs with what they need to succeed. The key to unlocking investment – and anything else your startup needs – is a simple analytical framework called Circles of Influence. If you understand this theory, you are 90% of the way to getting what you need.

Watching driven entrepreneurs try to function with no knowledge of this theory can be humorous, or even painful. I once met a founder who was painfully oblivious to this theory. He would target “investors” who weren’t in his sector. “All these investors are rich,” he would tell me. “They can personally invest in my project even if their investment fund isn’t related to what I do.” He would cold call them. He would drop in to their office. He would accost them in public with copies of his pitch deck, foisting a stack of papers into their hands just as they were about to go on stage at a public event.

This founder spent so much time trying to think up clever ways of getting his material into investors’ hands that he never stopped to figure out if they were the right people. One of the investors said to me, exasperated, “How can I make this guy stop? I don’t even invest in what he does.” You do not want to be that founder. You never want to have an investor say about you, “How can I make this guy stop?”

This framework was developed by the king of dealflow, Professor Tom Kosnik. He doesn’t just talk the talk. When I approached him with a request for a connection, he opened up a spreadsheet that contained the names and contact information of hundreds of investors with whom he was personally acquainted. Dr. Kosnik’s framework simply works.

Circles of Influence

You live in an entrepreneurial ecosystem, a place where people are excitedly making bets on entrepreneurs. An entrepreneurial ecosystem consists of players who have stakes and operate according to the code. All of this takes place within overlapping social and cultural contexts such as the Chinese-speaking biotech early-stage startup community in Singapore. Each of those elements, Chinese, Singaporian, biotech, and early-stage are a circle of culture that overlap.

Players

Players are the gears of the entrepreneurial ecosystem, and they make everything happen. As a founder, you are one of the key players. Investors at a venture capital firm are also a part of that ecosystem. Talented employees are players. Players are special because they have something that we need in an entrepreneurial ecosystem.

Stakes

Players have stakes which they bet on entrepreneurial ventures.Stakes are the elements of value that players bring to an entrepreneurial venture.

Investors are players. An investor’s capital is one of her stakes. She is also well-connected. She has some relationships that could really help your business. Those relationships are also some of her stakes.

Your lead programmer is a player. He has talent. He has passion. He has time. These are his stakes. You need all of these things.

A partner at a local law firm is a player. He has thousands of dollars of legal documents that he could let your business use. It would only take a few hours for his paralegals to put your startup information into corporation establishment documents, trademark applications, intellectual property assignment agreements, and employee contracts. His knowledge and his firm’s resources are his stakes.

There are unique players in each entrepreneurial ecosystem. In Seoul, Korea, large conglomerates known as chaebol are players. Everyone in the world knows Samsung, Hyundai, and LG. These companies offer a very unique set of stakes. I was recently at a hackathon where Lotte's MyBi Card stored value payments division offered founders unparalleled access to millions of commuters’ anonymized bus and subway travel data. Samsung’s CJ Group offered another startup access to thousands of hours of Korean dramas for use in creating their language learning software.

The stakes are anything of value that players can use to bet on your entrepreneurial venture. Your co-founder might wager her energy, passion, and knowledge of programming (or chemistry!). The director of a startup accelerator might offer you education or a work space. The government might offer you certifications of credibility through one of their startup programs. Your friends and family, might offer you seed money. They might offer you a place to live and work. Your well-connected uncle might also offer you an introduction to someone in his business circles, putting his reputation on the line to help you get your first customer.

The Code

The Code is the set of rules that govern how you get players to give you their stakes. It represents the unwritten rules of a local entrepreneurial cluster. It is the particular local culture surrounding venture capital and entrepreneurship. It is the behavior and the etiquette expected of those in the ecosystem. For example, generally speaking in the United States, you need a warm introduction or to “be discovered” by an investor. Cold calls and random drop-ins are not considered good etiquette.

The Code is something you learn from interacting with people in your particular entrepreneurial cluster. People will forgive you for violating the code if you learn from your mistakes. Garrett Gee, for example, knocked on doors on Sand Hill Road, home of many of Silicon Valley’s oldest venture capital firms. This was a big no-no. Someone eventually clued him in. When he realized that he was committing a cultural faux pas – a violation of the code – he stopped. He learned. With what he learned he raised $7 Million. Garrett sold his company for $54 Million to Snapchat a few years later. He was humble enough to accept correction. When players gave him feedback, he listened.

Every culture has rules. Our behavior as humans is governed by the norms of the culture in which we live and work. Just as physicists have dreamed of a unified theory, a single equation that describes everything in the universe, you may have dreamed of a key to unlocking investment and growth for your startup. The theory of Circles of Influence is that key. If you can understand how Circles of Influence play out in your ecosystem, getting investment is a natural result.

]]>

You probably got this sent to you by someone who cares about you and wants to you be successful at your startup. They’re also subtly (or passive aggressively) trying to tell you to get out of the building and start selling. It might be a bitter pill, but stick

You probably got this sent to you by someone who cares about you and wants to you be successful at your startup. They’re also subtly (or passive aggressively) trying to tell you to get out of the building and start selling. It might be a bitter pill, but stick around and we’ll have plenty of sweet goodness to wash it down with later.

“The first principle is that you must not fool yourself – and you are the easiest person to fool.””— RICHARD FEYNMAN

You might be a "serial entrepreneur", but not a successful one. People will stop referring to you, using air quotes around the term, when you actually get paying customers for one of your ventures. All entrepreneurship is sales. Someone, somewhere must buy your product or service. Even if you are involved in an "impact" project where the measures of success aren't financial, someone has to "buy in" to your product or service.

If you've only ever had ideas, but no customers, please stop referring to yourself as an entrepreneur. You might have always been the idea guy. You probably had ideas before it was cool to have ideas. (It became cool to have ideas about the time that someone coined the loathsome phrase. “I have an idea for an app.”) Ideas do not make an entrepreneur. Ideas are less than 1% of the output of an entrepreneur. Having ideas, even the best ideas in the world, does not make you an entrepreneur.

If you've read "The Lean Startup", that doesn't make you an entrepreneur. Reading books doesn’t make you an entrepreneur. Creating new things and getting people to buy those things makes you an entrepreneur. Books can help you know how to do that, but merely owning books – even reading books – doesn’t make you an entrepreneur any more than reading a medical textbook makes you a doctor. Arthur Schopenhauer wrote: "That books do not take the place of experience, and that learning is no substitute for genius, are two kindred phenomena; their common ground is that the abstract can never take the place of the perceptive." A doctor must go through a residency, and an entrepreneur must also go through his or her own residency.

Besides, you didn’t actually read The Lean Startup. You bought it so that it could decorate your shelf and show that you’re an entrepreneur.

If you've tried an "elevator pitch" on an actual investor, you're getting closer to being an entrepreneur, but you're not there yet. If you tried to communicate your idea to someone, that’s great! You’re now in the top 20% of what Noah Kagan calls “wantrepreneurs”.

If you filled out a "Business Model Canvas", you're not an entrepreneur, but bless you for thinking about all of the components of a business model. Now you’ve considered what you’ve got to offer someone. You’ve thought about how much it’s going to cost you to make and deliver it. You’re asking how much you should charge. Perhaps most importantly, you’re asking why the customer wants this thing in the first place. You’re on the cusp of becoming an entrepreneur.

If you bought a domain name and made a website, you're getting closer to being an entrepreneur. Good heavens, you’re in business now! It’s MyThing.com! People are going to flock to it! It’s the perfect name! If you used that website to make an offer, you’re standing right on the line. You’re on the border. You are mere microns away from entrepreneur status.

If, instead of making an offer on your website, you printed business cards and started handing them out, immigration is going to turn you back at the border. You shall not pass. No visa, no entry. How could you be wrong? How could you still be in Wantrepreneurstan? After all, you just found the perfect logo. You had to talk to twenty people on some freelancer site. You even paid for five of them to come up with some options. It took a few days, but you found the perfect one.

You didn’t even waste all that time waiting. You spent your waiting time coming up with the perfect tagline. It's amazing. It’s brilliant. You mentioned this tagline to a friend, and he suggested you pitch your tagline to the local angel investment group. After all, you're an expert in your thing. In fact, you’re Chief Expert at MyThing.com. Your business card says so.

You can’t be turned back now! You hired an employee! But, I'm sorry to say, you're still not an entrepreneur. You knew that you needed smart people to come up with great ideas to grow your startup, so you’ve been hiring. You’ve even gone out to two dozen meetings with outsourced product development firms. How is it that you’re being told that you’re not an entrepreneur?

Making someone sign a non-disclosure agreement doesn't make you an entrepreneur. Your idea is not this precious bar of gold that you must vigorously defend in case someone wants to take it from you.

Websites. Business cards. Logos. Company names. Ideas. Written plans. Employees. Non-disclosure agreements. None of this makes you an entrepreneur. All of these things are lovely when they are used in support of your entrepreneurship. Without the crucial elements of entrepreneurship, they are fake work. Just like fake news, fake work can captivate us.

I have seen hundreds of fake startups created by wantrepreneurs run for years at a time. Having an idea that won't go away doesn't make you an entrepreneur. It doesn’t matter if you are supported by government grants, paying half a dozen employees’ salaries, in a comfortable office in the middle of the city. It doesn’t matter if the government grant gave you money allocated specifically for t-shirts. It doesn’t matter how many people know your name. None of these things by themselves make you an entrepreneur.

Being an entrepreneur means you have convinced someone to give something of value to you in exchange for giving something of value to them. If you received something of value from someone but did not give something of value back, you are a charity case or a fraud. (Or both! You can be both!) If you gave something of value but did not receive something of value in return, you are running a charity. If you neither gave something of value nor received something of value in return, you are a wantrepreneur. If you gave something of value and returned something of value in return, you are an entrepreneur.

The timing doesn’t have to be perfect. Sometimes you deliver something of value and it takes the client some time to pay you. Sometimes you’re lucky enough to have someone with such a painful problem that they pay you in advance to solve their problem. Either way, you’re an entrepreneur.

Becoming an entrepreneur requires convincing people. You have to convince them that you understand their problem. You have to convince them that you have a solution to their problem. You have to convince them that you are the person to solve their problem. You have to convince them that your price is the right price.

Everything else you learn is secondary. Entrepreneurs don’t know everything from the start. You learn as you go. You are allowed to make it up as you go along and find other people to teach you as long as you are delivering something of value to someone in exchange for something of value.

The primary reason that you haven't been successful at your startup efforts is that you are not very good at convincing. All of the other work you do as a founder is meaningless unless it helps you to convince. This is a bold statement, but it is true. The principles of persuasion are consistent, but their application can vary wildly depending upon who you are trying to convince. As every good salesman will tell you, the first person who has to buy your product is you. You must believe that what you are selling is worth the price. You are the first person who you must learn to convince.

I go through online shopping phases. When I am in the United States there's not a lot of options for things with fast shipping and so I tend to default to Amazon. They make life easy, so I just go with them. Here in Korea we have options. Normally I would go with GMarket. Recently, a lot of our clients have been asking us to source hardware for them. I've spent a disproportionately large amount of time on Alibaba in the last few months. That means I find myself on AliExpress all the time now.

It isn't much bigger than your finger, but still has room for a SIM card. I doubt that the battery lasts for more than a few minutes. Then again, it doesn't have a screen to suck the battery power.

I was shocked at how tiny this thing is. I wondered how anyone would even use it. And then I looked closer. It is an earpiece! A cellphone that you jam directly into your ear!

I'm sure that people who use it will get brain cancer. I'm sure we're all going to get brain cancer from our Bluetooth headphones and holding our cell phones up to our heads for the last two decades. But I'm also sure that the same principles that were used to develop this phone are the principles that will save us from that brain cancer when it comes. You, dear reader, are the person who will save us.

But we will get to that in just a moment.

Alibaba is the dollar store for technology. But it's more than that. It is the symbol of movement toward the freedom to give it a try.

For years I ran a software development agency. Plenty of people came to us and wanted to take a shotgun approach to building apps for the App Store. They wanted to develop five or six applications and let the market decide what they should pursue.

This is a difficult proposition because each app represents a startup. Each startup needs a certain degree of marketing before people will pay attention to it. Without a sufficient volume of traffic then you can't tell whether or not people care about what you're doing. It's just not statistically significant. It's just background noise. You might think you've produced a dud, when really you've only been speaking to people who aren't in your target audience.

There's still value in the shotgun approach. I'm fond of quoting the double Nobel prize winner, Linus Pauling, who said, "The best way to have a good idea is to have a lot of ideas". The shotgun approach isn't so much about letting the market decide. It's much more about letting the creator decide. It's an opportunity for the creator to fall in love with one of his or her own creations.

It's easy to do the shotgun approach in software. It's become much easier to do this in hardware. In media production, it's dead simple.

What if there was a way to do this for biotech?

Keep that in the back of your mind while we discuss why this is so simple in so many areas.

Andreesen Horwitz popularized the phrase "software is eating the world". All of the important parts of a software stack are now commoditized. You don't write your own programming language. You pick one that fits. You don't write your own user interfaces from scratch. There are toolkits, abstractions layered upon more abstractions. At this point, you don't even write your own hard algorithms. You train someone else's toolkit with your data. You let someone else's machine learning algorithms take the pilot seat.

Once upon a time there was a time when you had to write your own programming language. You had to write your own 3-D engine if you wanted to create a game. If you wanted to have users that were shared between instances of webpage and on a mobile app, you had to create your own server software. Now we just buy a license for Unity or login to Firebase.

It is easier now than at in any other time in human history to launch a software product that is cross platform, and has network functionality.

It's not just software. It's media.

I was at the Grand Canyon a few months ago. I was walking with friends and we saw a little girl who was talking to her cell phone. She was about six years old. We didn't think anything of it until we heard her say, "Be sure to click like, and don't forget to subscribe!"

The barriers are coming down.

I recently saw a documentary special where a gentleman wanted around the markets of Shenzhen. In just two or three hours he assembled a brand-new Android phone from components he was able to source at a market. There are markets in the world where you have easy access to hardware components, 3-D printing, and access to the know-how to put those together.

If you want to launch a new cell phone brand, you can. Your flagship phone can rival that of a flagship phone from four years ago, you can. Recently, when traitorous individuals decided to sell technology secrets they had stolen from Samsung to Chinese companies, a newspaper reported that Samsung had a nine month lead on display technology over Chinese manufacturers. They said nine month gap represented approximately a $100 billion gap in development.

We measure market advantages in months, not years. Everything is moving very quickly.

The barriers are coming down.

What are the barriers in biotech development?

Certainly there are regulation barriers. Software companies focusing on bioinformatics, sometimes known as gold biotechnology, push up against these barriers -- CMS regulations and HIPPA. Pharmaceutical companies, focusing on red biotechnology, have to deal with the FDA.

Knowledge barriers are a major problem. To be able to do much of the research and development connected to biotech, you need to know quite a bit of medicine, chemistry, and various fields of biology.

Access to tools is a major issue. If you want to experiment with an ultrasound, that will set you back tens of thousands of dollars.

Or will it?

I recently had an inpatient ultrasound done at a hospital in Seongnam, just south of Seoul. The ultrasound was a handheld diagnostic tool that connected to an iPad mini. It was a mere fraction of the cost of traditional computer-on-wheels ultrasound devices.

Some of the barriers are coming down.

Software and hardware innovations are eating away at the previously impenetrable research and development barriers to entry held by incumbents.

Skyrocketing medical costs in some jurisdictions are eating away at the legal regulations that formerly defended incumbents.

Young biology students have greater access to wet labs, provided by forward thinking venture capital groups. This is democratizing access to that which only corporations, hospitals, and universities could provide.

Quietly, coalitions of venture capital, governments, forward thinking hospitals, and the truly innovative corporations of the world are forming. They are beginning to build the frameworks on which a generation of entrepreneurs will build abstractions.

These hospitals know that the end is coming for their traditional systems. They know that disruptive competitors are about to eat their lunch. They are looking to ride the first wave democratized startup creation in biotechnology.

There's plenty of open space in which to build these frameworks.

What is the biotech equivalent of the Unity game engine? What are the tools that will allow college undergraduates to build novel and useful medical devices easily and rapidly?

What is the biotech equivalent of YouTube? What is the tool that will allow high schoolers to experiment with protein folding, and run computational drug design simulations?

Innovation is coming, but there's certainly plenty of space for you to explore even now.

]]>One of the first companies I founded was built around university students. It was built on the premise that I could pay university students a little bit less in exchange for job security through their undergraduate career. I would also help them to make a worry-free transition to their first]]>http://www.lorenzoswank.com/your-employees-are-going-to-leave-and-product-hunt-will-kill-your-company/5c3213e048d9100a6f16e1b5Tue, 11 Dec 2018 12:00:00 GMT

One of the first companies I founded was built around university students. It was built on the premise that I could pay university students a little bit less in exchange for job security through their undergraduate career. I would also help them to make a worry-free transition to their first post-graduation job. They had no need to be stressed about finances or work while they were waiting for their first offer letter from a brand name company.

The very premise of that business model was that your student-employees are going to go away. That had to be a part of everything we did. We were lucky enough to partner with a highly-ranked university, teaching computer science and design. We taught and poached some very bright students. Bright students are meant to go places, which means they don’t really want to stay in any one place for too long. These are the kinds of people who leave high profile jobs at Fortune 100 companies to start the next big thing.

My students wound up doing interesting things at great places. They were on the Docs and Firebase teams at Google. They went to Facebook and Oculus. They went to Amazon, Microsoft, and Adobe. One even wound up on the compression team at YouTube, an impressive feat.

Teaching was great for my business model, because I received a steady supply of outstanding students. I would train them, and then the older students would pass the baton to the younger students. I didn’t have the luxury of holding on to students for more than three or four years. If I was going to build any sort of institutional knowledge, that had to be built into the DNA of our company.

Building Institutional Knowledge

Tribal knowledge is information that belongs to people inside of a company. It’s in your head, and it’s in my head. It is the accumulation of our wisdom and experience. It is our education from the school of hard knocks. Institutional knowledge is the collective knowledge and wisdom of members of the company, past and present, accessible in a form that is independent of those who learned the lessons.

Tribal knowledge gets passed from generation to generation in the way that knowledge has been passed down for most of human history: storytelling. If someone tells you the story, you learn the lesson. If someone leaves before they can share all of their stories, that knowledge is gone, forever.

Institutional knowledge, by contrast, stays around forever. It is the building block of scalable companies. It’s not a magic bullet, but it has many advantages over tribal knowledge.

In our first software company, there were a couple of great things we did to make sure that the tribal knowledge started to be integrated into institutional knowledge. We had traditions such as a weekly internal lecture series and “Free Food Fridays” to help ensure that more of the tribal knowledge got passed down quicker. We also had a series of software tools that we used to capture information and turn it into institutional knowledge.

Traditions Can Accelerate the Spreading of Tribal Knowledge

Some sort of passing of the baton is important to make sure that lessons learned don’t evaporate when your senior employees leave. Not all knowledge needs (or even should) be recorded in a retrieval system and deemed institutional knowledge. Many things, including elements of company culture, simply need to be passed from person to person.

We had our own internal lecture series. We would do lunches together on Fridays, and someone would give a presentation. The staff nicknamed them “Free Food Fridays”, because I was paying for their food. I was willing to pay for the food and a working lunch because it was the number one way to promulgate company culture. Not only was it a time to laugh and to enjoy good food, but it was definitely storytime.

We shared stories on every conceivable topic. We talked about great interviews and horrific interviews. We shared mistakes that we made, and we celebrated wins together. It was a forum for informal project postmortems, and it was a place where we could pick up on early warning signs that someone wasn’t feeling included, welcomed, or nurtured inside the company.

As a way to keep our older employees still engaged, we would let them lecture on topics that were interesting to them. We had lectures on mathematics, encryption, unique programming languages, and mathematical recreations. At times, the more senior employees would use it as a soapbox opportunity. “Hey, this is what you guys keep screwing up. This is what's making our life difficult in the company. Do these things that the old guys know how to do, and everyone will be happier.”

It was a remarkably productive time, and easily 100x more productive after we moved the venue from local restaurants to our conference room with a full catered meal. As our team grew, it became impossible to get everyone seated within earshot in a restaurant. Inside the office, all around the big whale table, and with catered food, we had a quiet, controlled environment.

Perhaps somewhat counterintuitively, catered lunch was easily a quarter of the cost of our dine-out lunches. That was probably the second best decision we ever made while running that company.

Knowledge Management

Knowledge management tools are where the rubber hits the road. You can have an oral culture where you pass information on as much as you want. Without written records, however, your company cannot advance from the Castle Age into the Imperial Age. No trebuchets for you.

We’ve built companies where that has worked very well. We’ve also built companies where knowledge management has been a complete disaster. When you only have two or three people, real-time knowledge sharing matters more than consolidated knowledge management, but both are necessary. There are seven mistakes that companies make when they try to introduce any knowledge sharing or management tool.

Mistake 1: Too Much Fiddling Around

We have made this mistake far too many times. Tools are cool! Product Hunt is an awesome website! We know. It’s great that software is eating the world and that the barrier to entry for creating a new software tool is so low. If we are not careful, however, we get wrapped up in the never-ending quest for something incrementally better. This leads to one problem:

A culture of fiddling with tools destroys your ability to get anything done with those tools.

It takes dedication to a single tool to be able to use it well. You have to have a critical mass of content and adoption in order for anybody to really use that tool. The single most destructive habit we had in any of our previous companies was to introduce a new tool every couple of months.

People are just getting used to the previous tool. Then you throw something new at them! It takes time for employees to learn a tool. It takes even more time for employees to integrate that tool into their workflow. If people don't know which tool provides the right information, they will resort to their own systems.

If you're always changing systems and tools, your employees won't feel secure putting any data in any tool. After all, the boss is just going to find something better in a few weeks and abandon this one. This spells death for any tool.

You may have enthusiastic staff members who go to a lot of trouble to write up a bunch of documentation and put it in a local wiki – or whatever the flavor of the week is for you. If your other staff members have already been conditioned not to rely on your ever-changing repertoire of tools, they will never use this new tool, and you will lose the cooperation of the very people you need to drive adoption of the tool.

Mistake 2: Not Integrating the Tool Fully

Even in very small startups, there are network effects. The more people are using a tool, the more people will read content in that tool. The more people read content in that tool, the more people will write content in that tool. The more the tool is embedded into the workflow of employees, the more it will stay embedded.

As tools become deeply entrenched, these exchanges become more common:

“I have a question for you about X.”

“Did you check the company wiki for X? Because I wrote the answer to that question there.”

Or my favorite:

“I noticed X wasn’t in the wiki. Can you teach me, and I’ll write it up?”

It’s a beautiful thing when data lives in the tools, when processes’ critical steps are tracked in the tools, and when status reports are merely a button click away.

None of that happens until people are living in the the tools you choose.

Mistake 3: Picking the Wrong Tool

Of course, those things are only possible when you pick the right tool. You’ve already committed to fiddle less and integrate more, but you aren’t going to be able to avoid the siren call of new tools quite yet. That’s fine. Let’s learn a simple taxonomy of tools so you can name the problem more accurately.

There are two types of knowledge tools that you will want to be concerned about. There are static tools, and there are flowing tools.

In static tools, you put knowledge in, and you can find it later. You can search for it. It's there. Wikis. Spreadsheets. Databases. Enterprise Resource Management tools. Customer Relation Management systems. A company address book. These aren’t static in the sense that they are fixed and unchanging – far from it – but merely in the sense that they have some sort of roughly static data structure that we can map to when we are thinking about the tool.

Address books have entries, with names, and a general set of data associated with those entries. Kanban boards like Trello have stacks and cards, associated with whatever data belongs to any given board structure. CRM tools have leads and clients in various stages of nurture and education.

Flowing tools are like a stream where the data is always passing by. In the postmodern era of massive data collection, we save everything from the stream for search and analysis. We build massive data warehouses or data lakes and pray that someone will come and analyze our data for us to unlock massive insights.

But, we’re not there yet. While we can infer some structure from data through semantic processing and natural language processing, this isn’t something that is going on for you, in your company, right now. That’s the domain of the future.

As such, flowing tools are like a firehose (or stream). Data keeps coming, only lightly structured, if that. Twitter and Slack are the biggest example of this. It's a flow of information and you dip into the stream a little bit. You're not there all the time. If you try to be, then you, too, can suffer from Slack-induced Post Traumatic Stress Disorder.

A never ending flow of unfiltered information is unequivocally bad for the human brain. We need periods of downtime to filter, sort, and discard information. When choosing flowing tools for your company, be careful that these tools 1) supplement human interaction, not replace it, 2) have settings that allow users to enforce downtime requirements, and 3) do not force users to search in order to get value out of the tool.

In our companies, we opt more and more for tools like voice and video conferencing, instead of text chat. We also enforce strong etiquette rules about expected response time for different forms of communication.

Mistake 4: Not Having a System For Introducing New Tools

When you’re building a company or an organization from scratch, you find the most energetic, forward thinking people you can. They excitedly put all of their energy into providing you with solutions to your problems. They take initiative.

They spin up Slack instances. This is a problem.

You can't simply say, “Oh, I put up a Slack instance for everybody! Sign on! I invited you!” after you reach a certain size and after a certain amount of time passes. (This is why tools like Slack get adopted at the team level in companies more readily.) You need a plan. You are doing things that interrupt people’s workflow.

This is when we return to the era of “RFCs”.

A QUICK ASIDE ON RFCS

Back in the early days of the Internet, bright engineers would circulate proposals for new technologies. These proposals would make their way around the fledgling inter-tubes for others to discuss and debate. These proposals were called “RFCs” or “Request for Comment” documents. Someone had what they thought was a brilliant idea, and they wanted to make sure that the other people who had a choice in how they were using their energy were willing to get on board with these new ideas.

If you’re going to have a plan, you have to have success criteria. You will want Key Performance Indicators (KPIs). You will want a plan for what you do if things succeed, and what you will do if things fail. These KPIs don’t have to be difficult to track. Let’s say you are adopting GSuite. You have access to a whole set of statistics about user utilization of the tool. You can see who is using which tool.

The value isn’t necessarily in the plan. The value is in communicating that you have a plan to the other stakeholders. As knowledge workers, we love it when we can focus on our work, and when the rest of the world is in a predictable state around us. Having a plan and communicating the plan generates confidence. It also allows people to determine how much time and energy they will invest in integrating the new tool into their workflow.

One way you might think this is comparing it to a very, very miniature startup. Your co-workers or employee---those are your customers. Ultimately, their decisions rule the day. They will vote with their time, their effort, and their knowledge. Without those elements, your new tool is dead in the water.

Mistake 5: Not Having a Tool Evangelist

I love the term popularized by Steve Blank, ‘earlyvangelist’, a portmanteau of early and evangelist. You may have a plan in place, but people in the company still need to buy into the plan. They need to put their time, effort, and knowledge into the system in order for it to be useful.

Can we get people to use the new tool? Most importantly, whose responsibility is it to get people to use the tool? Surprisingly, most of the time choices about these tools are not being dictated from above. Most of the time, the tool choices spontaneously arise from strong personalities and a predilection for experimentation. It's very rarely, “We've decided that we're going to implement Salesforce company-wide and you are forced to use Salesforce.”

In our companies, we put the burden of new tool adoption on the person who proposes the tool. If the person making the proposal can get a critical mass of early adopters, then the tool thrives. There is one other positive benefit that comes from having the suggester write things up. Chronic tool switchers now have one more barrier to imposing their indecision on others.

Mistake 6: Thinking of Documentation as Static

This is a question of both refactoring and documenting.

Documentation is living. Changes have to a be a part of the workflow. Documenting evolving processes is a bit like documenting the process of developing a new technology. There’s this big unknown thing that you're grappling with. You've got a huge possibility space. What are we going to work on? Is this going to be hard or easy? What exactly are our goals here? What does “finished” look like?

One of the great things refactoring and documentation have going for them is that they are more linear, more predictable. In an industry where you often can't really provide an estimate, the “maintenance” tasks of paying down technical debt generally have much more predictable timelines. They’re safer choices, in that they’re very unlikely to just kind of balloon out into a huge nightmare.

The problem, though, is that you do those things to prevent disasters and to speed future development, but they don't drive sales, or get users, or any of those great things – at least not by themselves. They’re analogous to cost centers, if you look at technology development through an accountant’s lens. They need doing---but not too much.

The knowledge in your company is always changing and evolving. You can't approach this with the idea that “We’ll do this one big refactor and then we're done,” or, “Let’s document everything, and we’ll never need to do it again.” Instead, the way you have to approach it is in a bang-for-buck kind of mindset. You must think in terms of, “We have this much time available. Given that, what's the best way to get the maximum return on the time available?” You will get better outcomes focusing on the effort involved, rather than the final result. There is no final result. You’re never “done”.

Think about the last time you had to dive through an unlabeled filing cabinet or unlabeled set of boxes. Would it have taken effort to label all of the things before you put them in the cabinet or box? Of course so. Is an additional five seconds per item an acceptable cost for finding things easily in the future? Sometimes the answer is clearly “no”, but in business, sometimes the answer is a resounding “yes”. If the answer is “no”, don’t document those bits. Only do it when there’s a clear advantage to documenting something.

Mistake 7: Not Understanding Who Should Be Documenting Systems

It has been a big trend among entrepreneurs in the last 10 years or so to read books like The E-myth or Work The System. The argument is that if you only had solid “Standard Operating Procedures”, or SOPs, for everything, then you could hand all of those tasks over to someone else and be free.

That's true to a first approximation. Unfortunately, a lot of the beliefs surrounding this theory of documentation put the entrepreneur in the seat of authoring all of these SOPs. The myth is that you can hand off these tasks to someone in a low cost-of-living area and arbitrage for the win.

If your business is complex enough that there’s a meaningful difference between “senior” and “junior” employees, life is not that simple. If you are spending your time writing these procedures down as a founder, you're wasting your time. Particularly so the bigger and more high level your company has become. Could you imagine the president of GitHub or the founder of Uber writing down some SOP for a driver or an inspection agent?

Keeping your knowledge base updated – whether that be as simple as code comments or as complex as a network of wikis – should be a company-wide endeavor. Both line and management should be making contact with their knowledge repository in the course of their normal work day.

Ship of Theseus

The Ship of Theseus was a logical paradox the Greeks posed. In the story there was a famous ship. Over time it had every plank replaced, one or a few at a time. The question they posed was this: Now that every piece of the ship has been replaced, is it still the same ship?

Our companies in the postmodern era are in a similar place. Our companies must reinvent themselves, piece by piece over time. Companies that fail to do so wind up weighed down by legacy policies, procedures, and methods. A corollary for this from the programming world is the concept of technical debt. The idea is that I, as a programmer or an architect, made a decision that was expedient at the time to get something going. That decision is going to have consequences for me later unless I do something about it.

Our businesses sit in a marketplace that is constantly in motion. Our ship sits in the harbor aside Theseus’ ship. Over time, the planks in our ship may decide that they want to be somewhere else. They may fall off into retirement and declare, “I’m done here. I’ve had it carrying this load. It’s time to float off to the Bahamas.”

When that day comes, one of two things will happen. Either we will smile and bid those pieces a fond farewell, knowing we have prepared well, or we will find out we lost a piece of us critical to seaworthiness, and we will panic as the water starts pouring in.