klinger-io

[klinger-io]

🙏

Over the years i met several people that left quite an impact on me and in many cases helped me along the way.

I tried to summarize one learning from each.

I split it in stages of my life. Growing up in Vienna; moving to London and Berlin, running my own companies, moving to SF to work on multiple companies there… etc. This list is otherwise in no particular order and misses about 1000000 people, most likely including you.

Vienna

Helge Fahrnberger - the power of social software, the possibilities of the internet and in general being my first mentor without him ever realizing

Edward Hartwig - you can be a nerd about literally anything, even immigration law

Frederik Debong - You got agency, and you can plug-in stuff into your body and hope you dont write bugs that kill you

Moritz Plassnig - every business needs a hustler

Lukas Fittl - do things the right way

Felix - you can engineer your life

Tosh - nerds. community. vision. that's all we need.

Juergen Hoebarth - you can predict the future by following the present‘s path

Michi Ströck - ADHD is a super power

Mimi - there is no task to overwhelming as long it’s on a to do list

Stephanie Cox - you can be an actor improving this world

Csongor Bias - help people to your fullest; no matter if you just met them or not

School

Klaus Coufal (IT Teacher) - the goal of every job is to make sure you are not needed (automate or hire yourself out of your job)

www.overclockers.at - my first community project

Reinhard Teischl - dont build communities; build cults

die.socialisten.at - my first company

Michi Kamleitner (Ex Co-Founder) - hard work and persistence is the only magic trick

Garmz.com - my first startup

Tamas Locher (Ex Co-Founder) - start with the best possible solution and – only then – work backwards to reality

Gilbert Wedam (Ex Co-Founder) - you are not finished until you have thought it through completely

Simone Ospelt - you can apply your skills to any problems, even if unrelated to your experience

Rafael Jimenez - humanity does not matter without art and culture

Rado (now CTO of Product Hunt) - being positive is a choice

Ves (now CTO of AngelList) - have people around you who always expect the best from you and call your bullshit

Petyo (now DoE Stream) - Nobody knows anything, don’t take yourself too serious and just do your best work

Sitar - passion is the most powerful energy source

Reshma - relationships are the only things that matters in the end

Berlin

Pmoe - there is only startup network worldwide and people who create the local uplinks

Giesbert - every object in this world around you has a story

Peter Henssen - you can always reinvent yourself without ever needing to change your core

Yanislav Malakhov - freaks will lead into the future

Christian & Margaux - trying to show me how to adult - i didn't learn anything though.

SF

Naval (Ex Boss) - for teaching me how he thinks about topics instead of what he thinks about them

Audrey Kim - creativity is source of energy

Onno - you always have agency

Graham (Best manager i ever had) - do the shit work, make your team look good

Alexis Ohanian - you can help a lot of people without ever meeting them

Roy Bahat (Bloomberg) - always create space for inclusion

Paul Davidson (ex boss; now Founder of Clubhouse) - being passionate and positive, shapes the world around you.

Nick Abouzeid - you can be good at everything if you want to

Pomp & Polina - personal brands are media brands and nobody can ever take them from you

Garry Tan - being kind is a super power

Marvin Liao - supporting people worldwide is possible

Riva - genius; creativity and craziness are the same things from different sides

Product Hunt

Jacq (Ex Coworker) - friends are family

Erik Torenberg (Ex Coworker) - you get far by just asking the right questions

Ryan (Ex Boss) - the core of communites are authentic people who give opportunities to random people (like me)

My Fund

Johnny Boufarhat (CEO of Hopin.com) - the fastet growing companies of the future will all be remote

Job (CEO of Remote.com) - there is no problem that can’t be broken down into small solvable parts

Marcelo Leub (CTO of Remote.com) - something about duplexing… it made a lot of sense… i can't properly remember. ;)

Joel (CEO of Buffer) - stay by your values even if the world around you constantly changes

Alex Torrenegra - honor your grandparents with your work

Sten (CEO of Estonia… or should be) - make bets on people

On Deck

David Booth (Current Boss) - there is no limit to professional growth

People i never met

Dale Carnegie (author) - for teaching me how humans operate; who would have known…

Arthur C. Clarke (author) - that you can predict the future through extrapolation

My Family

Annemarie (my mother) - there is always a solution

Wolfgang (my father) - you can create your own world and the power of entrepreneurship

Nico (my cousin) - family comes first

Susanne Knoll (my wife) - literally everything else i know ❤️

[klinger-io]

Joining hypergrowth startups 😬

I am writing this for a friend joining an early-stage breakout startup (year 2; $200M+ valuation). I wrote it as bullet points as it was meant to have an audience of one. He suggested that I share it here as well so that it is more widely available.

About this format: Normally, people write multiple paragraphs with stories and repeating examples to drive home "a point". In contrast, the format of this blog post is a bit more "raw". So please feedback me and let me know what you think.

Disclaimer: The advice is meant for anyone joining the early stages of a hypergrowth team (15-150 people; multiplying in revenue, investments and/or headcount). Usually in the first 1-3 years of a startup. Most of the advice I would not give in larger, more established teams. I also did not try to sugarcoat nor glorify things. It's just a download of my "recommendations" i would give in a 1on1 discussion.

Who am I

Worked for multiple hyper-growth companies in different stages

Was founding team at producthunt.com; led product & engineering project teams at coinlist.com and angel.co.

Currently leading the product engineering team at beondeck.com

Invested in multiple breakout startups of the last year

As always: Everything is IMHO & YMMV. 🙏

My advice to people joining hypergrowth startups

Your mindset

Say; Do

people rely on you; don't drop; don't backtrack

before you make promises take time to think about stuff if needed

speak up if there is an issue

Don't think in "roles"; but understand problems and apply skills

be the person everyone wants to ask to fix something

go in; fix/create/setup/improve; hire someone better; move to next

first in a weekly rhythm; then monthly; then quarterly; then yearly

Example: In my first startup, the job title on my business card was "CWTFO" because my job was to establish or fix areas of the company.

In reality, every job in a fast-growing company is – with different degrees of variance – a CWTFO role.

Everyone is in every role interim

the best early people will have ten defacto roles in 2 years

sometimes titles will sound lower; don't worry

hire better people than yourself; find something else you are impactful in

Example: Leaders should avoid throwing around titles but instead use comma titles

Instead of "Head of XYZ" – do "Operations Lead, XYZ"

Solve problems

You are hired to fix problems; not to point them out

most problems your company faces are not hard

there are just lots of them

you are not hired to point them out but to solve them

A half-fixed problem is a not-fixed problem

it's easy to implement the 20% of the solution

don't drop stuff there

make sure stuff gets adequately finished either by you or someone else

it's done when it's solved

Example: I frequently worked with people who were good at spotting problems, coming up with a solution, but then not pulling through.

You can barely reuse a 20% approach if the originator isn't leading it. You start from scratch

Nobody is hired to "point out obvious solutions" - most problems we face are not that hard - just too many.

Have default solutions

have a solution for every problem you bring

don't hand over problems upwards

bring solutions you want feedback on

Stress and Chaos

Stuff is stressful

but remember

stress is you losing control; not you working too much

you can burn out, barely working at all

being overwhelmed is ok; temporary; if you can stay in control

Example: managers frequently burn out people by letting them face the consequence of rapid changes without shared control over reasoning nor impact on them

Example: when you feel stressed:

regain overview/control

or decrease boundaries of authority/responsibility

Build order and structures

early stage can be chaos

bring process and structure

just as much as needed; not much more

improve as it's needed later

Example: Processes are not chains of bureaucracy.

They are expectations made explicit. It can be 1-step actions.

Processes allow you to scale as you don't need to discuss continuously one-offs.

Stuff is urgent, important, critical, stressful

know the differences and how/when to handle differently

stuff will go wrong; that's normal

risk mitigation is important

have paths to fix things

move forward

compare the cost of waiting

to how much better

or less risky

the future solution most likely will be.

Example: Can you revert your change? Can you avoid brand damage if it goes wrong? Is the potential damage manageable?

If yes: move forward

Your goal is not to work "a lot" but fast & effective

extra work time won't compensate for you not scaling yourself

Find ways to recharge

family, sport, hobbies, passions

whatever works for you

actively make time for those

fast-growing work and related problems will otherwise use up every crank of time you have

establish boundaries

Scale your work

Never wait; never get stuck

switch quickly between issues if stuff is stuck

make sure balls don't get dropped

never "wait"

consider if you can do a good-enough solution by yourself

consider what alternative thing is most impactful instead

Get autonomy through transparency

be publicly transparent in what you will do

docs, posts, tasks, etc

to make sure people don't need to feel they need to check-in

it creates trust; this creates autonomy

Acknowledge sync; solve async

people are nervous

acknowledge stuff asap; even on the weekend (early on)

do it async whenever you can fit it in unless urgent

Scale yourself

automate

hire

empower

Your Team

If you lead teams

hand problems downwards in your team to share authority

but you are responsible

every success is the success of people in the team

every fail yours

treat people like adults

give them information

trust them to make decisions

trust them even if you feel they make mistakes

ensure people have a fair setup

keep information and power differences in mind

[Sidenote: Management advice will be a separate blogpost]

Hypergrowth teams compensate half-done products with effort

no balls dropped when it comes to customers

extra effort whenever possible

early on, that's required

later on, you want to establish process, automation, and solutions to avoid those one-offs

Differ between frustration with a situation and a person

treat those separate

by default, you are frustrated with the situation even if it doesn't feel like it

typical exception: situations that happen repetitively

Your coworkers are not your therapists

never load your stress on "people below you"

avoid loading stress/frustration to people "beside" or "above you"

telling/sharing is ok

but "handing over to solve" is typically useless

they don't have the time nor competence

most likely, they just end up frustrated too

most likely, they do this the first time too

if you share also have a default solution to avoid "passing the burden"

get a coach

Your career

Do a tour of duty

you won't be there forever

people who fit in well early don't fit well later unless they level up a lot into top management (most don't)

most founders don't want to work for large bureaucratic companies

so they "instead" end up creating large bureaucratic companies by themselves

but it's a large company they have power in and can stay longer term

other early people not necessarily

plan 1-3 years of a strong learning experience

Optimize for equity

not because it's worth more

that too

but because its easier to get a salary boost later on

equity increases are hard as the company valuation increases

Disclaimer: This is only true for early-stage companies

Have fun

don't take yourself or anything else too serious

never sacrifice long-term health

never sacrifice family-time

you can't get back, neither

I hope this is useful to others as well

✌️ Andreas

[klinger-io]

ADHD 🧠

I want to preface this by saying that I have only a mild case of ADHD, eg I don't take any medication.

I get regularly asked about my recommendations regarding processes with ADHD.

Here what i usually recommend:

Dont fight it. See it as superpower. Create systems that ensure you don’t drop balls.

How?

In a perfect world, you only work on stuff that excites and focuses you. Try to optimize for that. Your distraction can be a spam-filter or search-engine for more interesting stuff.

You might live in this perfect world, most likely you are not.

The exhausting thing about ADHD is needing to remember stuff and not getting back into what's important once you got distracted. Find systems for that.

Systems

Systems to not drop balls / get back into correct topic:

Your goal is to be able to forget stuff (because you will) but have it in a system where it pops up once needed. Can be somewhere during the day or year.

Have weekly bullet journals for your tasks

I explained this here: https://yourstack.com/pro-tips/85-do-a-weekly-bullet-journal-for-todos

Have stuff that's further away in your calendar

Eg yearly reminders, todos that are a few weeks out. Add alerts. Add them so that you can forget.

Make it cheap to do stuff quickly

If you can do stuff instantly you don't need to remember stuff at all.

There is multiple productivity hacks.

My favorites are:

Optimize your email

https://klinger.io/post/71640845938/how-i-use-gmail-and-why-i-dont-understand-how-you

Use text-snippets for building blocks of common things you type (i got 20 of those)

https://yourstack.com/pro-tips/143-text-snippets-across-of-devices

I am always surprised how few people use this… Are you really typing all of this repetitive stuff all the time?

Add small products that allow you to do stuff you do regularly quicker

Eg add an international clock if you work in international teams

https://yourstack.com/pro-tips/86-if-you-run-a-remote-team-use-this-instead-of-the-normal-clock

Structure your decision making processes around important topics

eg how you hire, interact with your team, invest etc

eg How i make investment decisions

https://www.notion.so/How-I-make-investment-decisions-1f87a6171d284436a96fc54e64c0742b

Have stuff you write regularly as copypaste

eg this used to be copypaste.

Put stuff public

Stuff that you repeat too frequently for 1on1 copypaste you want to put on a public website

Eg this blogpost.

But not only this post, any stuff that I commonly need to talk about. That way I sent a link instead of talking people to death.

Engineering and Codebase management

https://klinger.io/post/613532774806192128/code-management

Hiring

https://klinger.io/post/613135057119592448/quick-tips-for-hiring-remotely

Switching to remote work

https://klinger.io/post/612591504694919168/close-your-office-now-how-to-operate-your

and a ton more…

Read this book:

Last but not least…

https://www.amazon.com/Driven-Distraction-Revised-Recognizing-Attention-ebook/dp/B005GFII62/

hope that helps ✌️

[klinger-io]

How I think about Code Management

You might have the worst codebase in the world.

It was written by people who had no standards or didn't care about code quality.

Here my POV:

I bet you don't have a problem with code quality. Not even with technical debt.

Your problem is how you manage your code.

I bet this sounds obvious, but you couldn't guess how often i talk to teams who don't think this way.

Code Management 101

As an engineering team, your main job is to make sure you provide your customer value and help the company make money.

Your second job is good code management to be able to do the things above.

You can split code management into two tasks:

Reducing complexity

Increasing confidence

And you do both over a continuous process.

Every advice you will ever read about improving codebases falls into either of those two categories.

Let's jump into this.

Reduce complexity

If you are unsure what the difference between complicated and complex:

Complex means many interconnected parts

It's the opposite of simple

Complicated means high threshold to solve

It's the opposite of easy

You solve complex problems by breaking them apart into smaller easier problems.

You solve complicated problems through eureka moments.

Almost everything you encounter in software engineering is complex problems. Let's be honest: The truly complicated problems you usually outsource to specialized libraries.

I highly recommend this crashcourse on complexity theory by Scott E. Page

How do you reduce complexity?

You want…

Fewer parts

Fewer interconnections between them

You can do this in two ways.

Concepts with better boundaries

You can create fewer parts and fewer interactions by combining concepts into fewer abstractions with clear boundaries.

You know this.

Almost all abstraction concepts in any programming language are meant for this: namespaces, modules, inheritance, etc etc.

You create a better abstraction encapsulating a concept with a clear interface for it.

You switch this…

to this…

Example: The classic rails approach to this is to create namespaces that handle concepts and have a namespace level API - eg Notifications.send(for: …)

A general rule of thumb is that you should be able to write down the concepts in your app in simple English sentences. And you should be able to point at the specific representations/abstractions for all nouns and verbs.

Remove code

The other way to have fewer parts and hence less complex code is by removing code 🤷

Additionally to simply deleting:

Functionality that is provided by industry-standard libraries instead of own code does not (knock wood) need to be managed by you.

A quick note on extractions

You want to manage primarily code relevant for your specific domain logic.

This is why we all like to extract generic auxiliary functionality into our own standalone libraries with their own test coverage or into microservices.

Why are those things sometimes great and sometimes horrible?

Viewed via complexity theory:

Microsystems that are tightly coupled (means many interconnections) create hard to manage complexity.

Let's get to part two…

Increase confidence

Confidence does not mean "ego". It does not mean "being fearless".

It means when tasked with a request you know how to solve it. It means you can make estimates without running into "unexpected problems" and you know how to approach problems and solutions.

How to increase confidence?

Streamline

Minimize the ways things can be done

Make those ways obvious

Make sure those ways work

Automate anything you can

Introduce explicit processes for anything you can't automate

Leave notes for things where you can do neither

Ensure the new code you add is better than the old one

How to ensure new code is better?

You ensure new code is better through the same principles.

You streamline

You automate

and you introduce process

The magic trick:

And you quantify your code quality expectations and enforce them

Autoformatting and Code Complexity Analysis is your super-power here.

Have your linter enforce below certain complexity code metrics. The classic one is cyclometic complexity scoring but there is multiple others.

This tooling helps your team to get automatic feedback and increases confidence.

But there is more to this…

Single Player Mode

A person working alone at a random hour should be able to know how to decide, where to find what they need and how to implement a solution – on their own.

Your end goal here is that engineers on their own can work productively. A concept that our folks at Product Hunt call Optimizing for Single Player Mode. I explain this in detail in this video.

A continuous process

"We really need to refactor this when we got time for it."

~ Person who will never have time for it

You need to do two things:

Understand which technical migrations you have

Create time

Technical migrations

Ideally you have one way to do one thing, and your code represents the clearly the concepts of your domain logic.

But usually stuff is not ideal.

You have old code, old systems, bad implementations, previous pviots, old libraries or frameworks.

Once you introduced a new way how you do something you started a migration of the whole codebase to this.

Consider this before introducing new ways to do something. Sometimes global coherence is better than local perfection.

Taking inventory

Have a list of every migration in your codebase.

What is the original state

What is the ideal end state

Have a decision/plan for each migration

Eg, migrating from framework A to framework B. Which features and parts of the codebase does this involve.

I wrote a longer post on refactoring codebases

But the gist is around:

Make it explicit (ideally in code)

Eg by leaving notes in the code or isolating legacy code by Prefixing it (e.g. LegacifyNotifications)

Create time

We all want to add chore tasks to JIRA standup discussions. But let's be honest. If your team needs to move fast, this is rarely possible.

You might be able to justify the value of a large refactoring project if it's impossible to get anything done in that area otherwise. But how can you justify removing the last parts of your (e.g.) redux usage just to get rid of a library dependency so that your webpack setup is more straightforward?

Refactoring projects in my experience sometimes work for the first 80% of a migration. Usually the parts that were attached to a critical feature. But rarely for the last 20%.

Before you know it, you end up with dozens of migrations that are at their last 20%, and stuff gets in your way all the time when you need to do horizontal (system-wide) changes.

Some of them are even half-done migration that happened after other half-done migrations about the same problem. E.g. multiple javascript frameworks/approaches/libraries in the same codebase.

You got into this by death through thousand cuts - you won't get out of this by one large effort.

My recommendation: Introduce Fix-It Friday

Engineers know the migrations, know what's important to your company right now.

Let them work on what they think is useful. Recent or old features, bad or good code. Their call.

You should see improvements within weeks, if not months.

Having it on one fixed day creates peer pressure within the engineering team and authority towards other teams and deadlines.

TL;DR

You have two jobs:

Reducing complexity

Increasing confidence

And you do both over a continuous process.

hope this helps

– @andreasklinger

PS: LMK how to improve this article

[klinger-io]

Quick tips for hiring remotely

You are most likely already experienced with hiring so think of this more as a quick FYI focusing on hiring remotely...

What issues do you face when you hire remotely?

You have more people applying

Your team is multiple locations

You interview people with different cultural background

Let's go…

How to handle inbound:

If you do your job well you will have a lot more inbound for remote roles. This is good because you have more people to choose from, this can also be bad because it might overwhelm you.

Have dedicated people for sourcing and screening

Explain the role really well so that people know when to apply and not to apply

Have a questionaire as part of your onboarding

Zapier is doing this imho best - Example

Cultural differences

Be aware of cultural differences.

People from different regions are used to present themselves differently.

The engineer from California might be chirpy and super excited while talking tech like a pro.

The engineer from Eastern Europe might be reserved, almost annoyed and not giving advice unless you ask for it.

Some of this might be personal style, some cultural differences.

Under-index on interviews. In many cases they are just a "how good can this person talk shop" and you will just prefer native speakers from tech hubs if you do this.

Get them to do real work asap.

How to evaluate

I focus here on engineering, because it's my background, but you can adapt this to other parts of the company.

Do normal screening calls and a hiring manager call for general fit and process

Have a take-home challenge

Do a pair-programming session

Your Take-Home Challenge

No brainteasers

Do a simple version of your application (or the feature this team works on)

Ideally the application features real world problems that are not part of the challenge to see how they treat those

(eg technical debt, broken tests, spelling mistakes, etc)

Ask for a small simple change that shows basic understanding of tech and product

If your take-home is more complex and timeconsuming consider paying a fixed fee for this.

Your pair-programming session

With the hiring manager

One hour via video screen-sharing

Give the candidate now a bit more challenging task

And work together on it

They can ask questions

Keep in mind that they are nervous os help them

But avoid helping too much as you might accidently confuse them

A good pair programming task could be solved in a way that's too long for the session or in a shorter approach

Picking a "good enough for now" solution is part of the evaluation

The same is true for testing - are they adding high impact tests or get lost in details already?

Synchronize

Consider having and ATS solution – eg Lever – to streamline your process.

If you want to have your interviewers become better over time and want to make sure you are aware of internal biases/problems/etc in your hiring funnel consider getting a tool like Metaview.

Contract-to-hire

Whenever possible i recommend contract-to-hire for remote teams.

Get them on for 1-2 weeks on a specific project. This will tell you more about them than any whiteboarding tests you will ever do.

I know teams that rely mainly on team-fit interviews, one take-home and then a contract-to-hire period.

How much should the freelance rate be?

The contract rate should not be their normal freelance rate.

Their freelance rate is considering no-work time. The goal of this is a fulltime job.

Agree on a yearly salary - divide down to the weeks - add a little multiplier to keep things fair if you disagree to continue (eg 1.3)

Hope this helps

Let me know if you have improvement ideas for this

-- @andreasklinger

[klinger-io]

Close your office. Now. How to operate your startup under lock-down.

What a week.

The US declared the state of emergency. Many leading startups closed their office. And I expect that all startups in the tech hubs will have their offices closed by the end of next week – if they haven’t already.

You might not live in a hot-zone of COVID-19, and might be unsure if it’s too early for to do so as well. You might be based in a rural America, LATAM, India, Europe – in a region or city where it’s moderately safe right now.

No matter where you are based: I think you should

Close your office. Now.

Think of it as a test-run.

Most likely you don't need to worry about COVID-19 too much. You might not worry that it could get as bad as in Italy, maybe experts overreact or you are just lucky because your city has no cases and team is young and healthy anyway. But you should worry about being not fully operational in a phase that could be critical for your customers. You don't want your most important people laying sick in bed while this happens.

If everything goes well you have a week of experience with a wfh-setup that you can fallback to. If things continue to escalate, you ensure that your team and business stays healthy. And most importantly, you might help slow down the spread of a pandemic.

Close your office. Now.

In this blog post I want to share my minimum recommendations I think you need in order to continue functioning as a startup, and what you need to watch out for over the next several weeks.

I want to keep this document evolving so please send me your feedback and suggestions.

First up: We are the lucky ones

If you are reading this there is a high chance that you are working in a tech startup – maybe you even live in a high density tech hub. The majority of people like us are able to work digitally, safely from home.

It's worth reflecting that we are the lucky ones – this is a pure luxury. Many people worldwide aren’t able to stay at home to work, and will need to risk their health and personal safety moving forward.

While I want your your team to be set up for success during this time, I want you to also consider reaching out to the hourly workers that help you in your office. Your security, cleaning staff, cafeteria personnel, and anyone else who enables your office to sustain an environment and culture that employees want to work in. Continue paying their wages and see if there are other ways you can help them.

Let's get started…

As a team leader you have the following todo list

Right now:

Understand the situation

Own the moment and communication

Working from home - Help your team to optimize their daily routine

Remote work - Set your processes up to function remotely

In the next weeks:

Get ahead of the problems you might face next

Create confidence & focus by going the extra mile

Understand the situation

The current situation we face is not about “remote work”.

Right now, we face forced isolation and forced work-from-home during a global pandemic.

There is no point in sugar-coating this. This is stressful for everyone – including you and your team. Especially now in the first weeks.

Many countries will manage it properly, other might create a complete mess. But in any case this requires you to change how you operate as a company for the next few months.

Remote teams have years to optimize their internal processes, and everyone who joined them did so with a prior understanding about this work setup. Your team doesn't have this luxury right now.

Your goal right now is not to become a fully functional remote team overnight.

Your first goal is to establish an emergency work-from-home setup that sustains your productivity.

Own the moment and communication

Together with your HR and people team, figure out the right process for your startup. You want to tackle this head on and get ahead of the situation. Even if you are “just” a 10 person startup, this is a moment where your team is looking at you for leadership.

My Recommendation:

Read about the internal processes of other startups

Skip all the in-between steps and directly go to the most drastic approach

Close offices, stop traveling and introduce mandatory work-from-home for everyone

Then…

Put your HR/people team in charge and make this a CEO/COO issue

Implement a test week in which everyone works from home

At the end of the week decide if you want to continue like this (you should)

Expect this to last 2-3 months and allow planning accordingly

I hope this document can help with this

Working from home - Help your team to optimize their daily routine.

Day one this will be perhaps the biggest issue that your employees will face.

My Recommendation

People will realize how bad their internet at home is

Tell them to upgrade

Their home setup might not be useful for daily work

Create a stipend they can use to buy proper chairs or desks

Tell them to get equipment from the office (if it’s safe to go there)

Normal apple headphones are fine, fancy headphones are great

External monitors are a game changer

Advise people to have dedicated work and non-work areas at home

If possible with a door in-between

It's worth rearranging furniture to make this work

Recommend morning and evening routines

Eg walk around the block

Encourage them to have regular calls with each other (see below)

Create a slack channel in which your team can share with each other work-from-home-tips

This is not only a good source of information but also gives the people on your team, who have worked remotely before, a moment to shine and become the “go-to person” for private discussions

I highly recommend reading Benedikt Lehnert's omgwfh.com

Remote work - Set your processes up to function remotely

To minimize any initial shock:

Get a zoom and slack team license

Encourage daily calls for smaller teams (standups) in the beginning

If you notice that people don't pay attention switch to daily text updates instead

Consider having a #hibye channel

People check in and out and greet each other

If it doesnt work for your team stop doing it

Encourage video meetings

Have a video-on policy

Experiment with meetings that dont require people to be muted

But make sure to mute people who have loud background or bad mics

If you notice this to be a problem switch to muted by default

On the long run you will try to minimize meetings and synchronized processes but for now this help people to accommodate

Once you feel comfortable:

Set up one central place for all documents

I recommend Notion but you can use whatever you are used before

The goal is to have one place where people expect to find documents

Write every process down that you expect more than one person to follow more than once

Manage slack

Reduce channels so it’s clear where communication happens

People will otherwise feel anxious about missing stuff

Encourage public discussions instead of private chats

Ensure that complex topics/decisions are discussed in collaborative documents, not in slack

Run more efficient meetings

Have a lead for each meeting who prepares beforehand an agenda and documentation

Make sure that you write down decisions and tasks resulting from each meeting so that less people feel like they need to join it

Make sure that each team has at least one meeting per week so that ad-hoc meetings and long slack discussions can be avoided

Measure output (instead of time)

Make sure you communicate clear expectations around goals

Involve and trust your people

Resources

Make sure to read the recommendations from the best remote teams out there:

GitLab's “Remote Work Emergency Plan”. Darren Murph wrote a condensed version of all their learnings over the last years.

Doist’s “So You’ve Been Told to Work From Home. Now What?”

use.fyi’s remote work tips – Marie and Hiten did amazing work here

And there is a lot more. Go read the advice from the experts - everyone is trying to help right now!

Feel free to stop reading here

Focus on the parts above. Once you feel comfortable in your strategy come back here and continue reading. The following paragraphs mainly focus on how to get ahead of the problems you will face next.

Forced self-isolation and the feeling of loneliness

Over the next several weeks’, your employees might be worried about leaving their home and overcompensate by barely leaving at all – or if they do leave , experiencing high levels of stress while doing so.

Buffer and AngelList did the 2020 State of Remote Work survey. One of the biggest drawbacks even to successful remote teams is loneliness.

Given your team is not used to working from home, coupled with the added pressure of unclear semi-broken work-processes, this feeling of loneliness might become more prominent, sooner.

To minimize any initial shock:

Ensure they leave their house from time to time

Educate your employees about hygiene measures that should be taken, as well as how to behave safely when in public spaces

Encourage breakfast, lunch or evening walks outside

Crowdsource ideas from your team

Consider implementing happyhour-/lunch- or even cooking-zoom calls with no agenda

Start casual slack channels (Photo channels work very well)

Organize Online videogame tournaments or "show your pet/hobby/flat" shows

Being worried about family

Team members might have spouses or family members that work in hospitals, or parents or grandparents who aren’t healthy even on good days.

How you can help:

Evolve your 1on1s from pure functional discussions to focus more on the human side of work. Move the functional discussions and project updates to your team calls

Get to know the people reporting to you and what this crisis might mean for them

Allow taking time off now to get their stuff in order

Schools will get closed

Many people on your team might have kids, their schools will get closed or they might be forced to take them out regardless anyway. Help them figure out how to create time to focus while being a full-time parent.

How to help them

Offer to pay for any online courses or entertainment channels that kids can take during this time

If they have an option for private childcare (eg a babysitter) offer to pay for this as well (even if it’s a relative)

If your employees live close together, consider setting up a small-group Microschool so that education can go on and the burden of keeping their kids entertained while working gets shared

Have succession plans

You don't want your company come to a halt because your DevOps person needed to get into a hospital. You don't want your company to run into troubles because you are sick in bed.

Make sure decisions and todos are transparent

Have passwords shared in 1password

Have documents that explain what to do in case of problems

It should be obvious who jumps in for leadership decisions if someone drops out

Thanks to Rolf Veldman and Susanne Knoll for this one

Nice-to-haves

Consider this part as nice-to-have. If you are reading this blogpost for the first time feel free to skip this part.

Your goal: Create confidence and focus by going the extra mile

My Recommendation:

Organization

Set up documents that outline and explain all information they might need over the next several weeks regarding their health benefits and plan

Link to every provider you use and outline what to do in which situations

Make it clear who they can reach out to if they have questions

Spend extra time staying up to date with everyone’s productivity and mental health

Set up a temporary emergency budget to cover budgets we mentioned above

Add online mental health counseling and online sport classes to your benefits if you haven’t already

Match donations to COVID-19 related foundations, or your local food bank or to the WHO

Send care packages consisting of the most basic and typical needs of your team

This could be hand sanitizer or simply someone’s favorite drink from the office in bulk

Management:

Sign up for Running Remote's Remote AID a free conference on all topics remote work

Optimize your engineering team for “single player mode” as i describe here

Ok, we are done… What next?

Once you have the short term under control focus on the long-term.

People will get worried about the economy and their jobs. Change the discussion from short-term crisis management to long-term strategy.

An extreme way to see this: Companies that try to keep the status-quo alive while the market goes down will go down with it.

Show that your company is here to stay

Don’t delay quarterly planning or ambitious projects

Create the vision that shows the WHY of your company

Your customers might need you right now

Your company might build the tools people rely on to continue their business.

Your services might help customers ease the burden of a potential upcoming recession

Or you might create the apps for a much needed distraction right now

Whatever your company's vision is. Make sure to continue thinking long-term

Thanks for reading

This document sounds a bit dramatic. I know.

I hope 90% of what i recommend won't be needed and this will all blow over without much fuzz.

Note that most of the suggestions in this blogpost are temporary and fairly cheap in comparison to your payroll but will leave a lasting impression. If your team's budget is more limited consider what you can do without breaking the bank. Not every good idea has to cost money.

COVID-19 will be over in a few weeks or months. But your team will always remember how you prioritized their safety and put in the extra effort to facilitate a healthy, comfortable, and productive environment for each and every one of them.

This is your moment to step up as a leader.

You got this.

PS: Please send me your improvement suggestions for this article

Thanks for reading Andreas ✌️

[klinger-io]

#fyi: How founders can avoid drive-by-management

Suggestions by founders, managers, or anyone with authority in a startup, might often be misunderstood as directions or decisions. Even if we didn't intend this to happen.

Example: A team discusses something in Slack and the founder of the company reads this for a second and replies that they like option B. Now option B is the most likely contender.

What if option A was an idea someone thought through in detail, prepared and pitched? What if the project lead knows B is a obvious but wrong idea? What if this project lead just joined the company and doesn't know the founder well enough to say this was meant as suggestion or strong push and option A has some sort of a longer history in the company?

The founder sharing her thoughts might have caused more harm than help here. Without her even realizing. After all this was just 5 seconds for her.

Here is an article about a feature that [competitor A] just released. Didn't we also discuss something like this? We should maybe reconsider this feature...

The founder drove by… gave management instructions (without even realizing) and is leaving the team before anyone could properly react. Drive-by management at its worst.

We all know to avoid drive-by management (getting involved without knowing enough and removing authority of project leads) but in the examples above this was completely non-intentional. The founder simply wanted to give feedback or interesting ideas they found. "Well i can't stop talking to my team…"

The key in avoiding this, is being explicit.

I am sure - whenever you share articles in your team chat - you already add a short line how this is "just an idea" to every message. Maybe you even add full disclaimer paragraphs to those suggestions.

But even these explainers might mean very different things in different cultures.

In remote teams this problem is usally worse. A Calfornian might have "just an idea" which is actually a "very polite" (read: direct) push. But for a german person "just an idea" might be something the other person didn't even put longer thought in. [All examples are fictious and have no historical background in the life of the germanic author living in California]

So what to do?

There is a useful method for this

The concept is developed by Dharmesh Shah of Hubspot and used by a few teams.

I got to know it via Wade of Zapier.

The core idea is the following: The team (or founder) establishes a specific code internally. Each keyword has a particular meaning, it is explained in their team-internal wiki. There it is evident to everyone what each of those statements means. And also every other manager or team member can pick this code up as well if they want.

Here is Wade in his own words about the keywords they use:

#fyi: something interesting. An article and podcast, etc. I thought you might like it. But if not no worries. Nothing to see here.

#suggestion: a passing thought. I sometimes have good ideas. You might like to hear good ideas. If I'm in your shoes, i consider it. but I'm not in your shoes so do what you'd like. A friendly response if you don't go with the suggestion is nice, so i make better suggestions over time, but is by no means necessary.

#recommendation: I've thought a lot about this. Perhaps even lost sleep. I've invested deeply. I think this is a good plan. You can still disagree and go a different direction, but walking me through why you are doing this is kindly requested.

#plea: We don't have a lot of mandates at Zapier, but this is one. Please do this. If you disagree enough that you can't go along with it, we should both reconsider our roles here. It's that important.

i use #fyi and #suggestions all the time. #recommendation much less so. and #plea is almost entirely unused.

Establishing an explicit code around this might enable you to be more precise with the reaction you hope for and it might become a habit internally that also other people can pick up.

Example #fyi: i found this article about how founders can avoid drive-by management.

As always - if i can help feel free to DM me questions me on twitter.

[klinger-io]

Refactoring larger legacy codebases

This article is based on a comment of mine to a HackerNews question. Thought it might be useful to explain it here a bit more in detail.

Questions i am trying to answer here:

How can you be productive in larger codebases?

How can you improve legacy codebases?

The #1 rule of managing legacy codebases is "code that doesn't get touched dies" - so you want to "touch up" important code as often as possible and get into a habit of small improvements.

Here a few thoughts about how to approach this…

1) Get the team on board

If multiple people are working on this codebase, you need their buy-in and support for whatever approaches you together choose to implement.

2) Plan for "health by a thousand small improvements."

Legacy code was created by "death by thousand cuts".

You won't be to fix everything in one big step. You won't be able to stop working and "refactor everything". And more importantly, you shouldn't do it. It never works out.

This refactoring will be an iterative approach over a longer time. Your goal is to refactor parts as you go.

3) Don't assume different = bad

People who worked on this codebase might have done differently in the past. Those might be different than how you would do it. Invest in understanding their approaches and consider using them. Consistency beats beauty in codebases. Codebases get bad if multiple people try doing various different approaches. Don't be one of them, whenever you can.

4) Create space

Consider introducing a Fix-it Friday.

The rule of Fix-it Friday is simple: unless your current project is on fire, use Fridays to invest in little improvements. Let engineers choose on their own what they work on. Try not to take the "fun" out of this by micromanaging. Some will try out new libraries. Some will remove bugs from the backlog. Both are fine. Try encouraging a balance of tasks.

Encourage these improvements by summarizing them (eg weekly in Slack) and maybe use them for quarterly peer reviews.

5) Create non-blame culture

Stuff will break if people risk improving things. Avoid shifting blame to them.

Those things can be subtle. Example: bug trackers might ping people individually, consider pinging the whole team instead.

6) Automate whatever you can automate

Introduce linters, auto-formating, code-mods, ci/cd tools, danger.js, code complexity analysis, etc. Use tools like (eg) lint-staged to encourage step by step improvements on new code.

7) Introduce tests

This one is the most annoying parts, but worth doing: whenever you improve a feature try adding a test. Do this step by step. Consider the tests a form of documentation explaining what the functionality should do.

A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do… well… this try it. I always found the iterative approach more realistic as you can also do feature work while refactoring. I also was usually never able to add tests unless i worked actively on a feature. But you are not me, try it maybe it works for you.

When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the "unit" contains critical or complex logic).

Your goal is to know "that you broke something", it's ok not to know exactly "what you broke".

8) Acknowledge tech debt

Not everything needs refactoring.

If it's not critical, or nobody needs to improve its functionality in the next months, or it's just too complicated, consider acknowledging it as tech debt.

Add larger notes above the problematic areas and explain why you aren't refactoring it, explain things that might help the next person understanding the code better, etc.

Whenever you leave comments, remember that comments should explain "why" not "what" the code does.

You should notice improvements quite quickly (a few months in).

Good luck!

If i can help somehow feel free to send me a DM via twitter!

[klinger-io]

A model that’s mental

Maybe…

This anxiety isn't anxiety it's just your raw excitement that you are misunderstanding.

This creeping imposter syndrome just means you are challenging yourself.

This slight panic before you show your work means you care a lot about quality.

This dreadful feeling during meetings to come up with something smart to say means you are with the best possible people for you.

This anger when things don't work out or people live up to expectations is just hope and passion being a bit too loud.

This feeling of wanting to scream and run through any wall means… well… i don't know… maybe get that checked out. ;)

This feeling of being sometimes overwhelmed means you push yourself to move fast.

Maybe you are not too weak or too crazy.

Maybe this is normal. Maybe you are normal.

Maybe everybody has those feelings. Sometimes more, sometimes less.

Maybe you challenge yourself, and that's good. If you wouldn't challenge yourself, if you wouldn't care, you wouldn't have those feelings.

Maybe try to see your fear, acknowledge it, appreciate it, thank it, and know it's just your attention being awake.

Maybe try to see your worries, acknowledge them, appreciate them, thank them and know it's just your love for detail.

Maybe knowing this, you keep going on and you realize you can manage this and all tasks in front of you. And once you get good at them maybe go and challenge yourself with something else.

But maybe… no not maybe… definitely… yes definitely… make sure to look back from time to time and see what you already achieved. All the steps you did, all the fears you faced, all the anxiety you felt and embraced and then learned to love; all of it became the excitement you needed.

Then when you are done with looking back, look forward again, smile and keep trying harder. Keep challenging yourself.

Written for us both to remember.

Why i wrote this post:

This is not meant as medical advice whatsoever - and anxiety is different for many people. I am also not saying "push through no matter what". I am just trying to share what helped me.

I struggled with anxiety after my first startup crash landed. I had a burnout. It led to me overthinking and being afraid of every decision. I remember vividly being invited to a friend's dinner where everyone was supposed to bring a salad. I freaked out because i didn't know what salad to bring. Fruit salads are easy and people like them. Right? RIGHT?? But I couldn't decide which fruits to use so i bought them all. The bowl ended up being huge. It was so much that we used the leftovers for several bottles of smoothies.

A bit later things got better, but i noticed that i still had anxiety in situations that should have been… well… exciting.

It got a bit into my way. I messed up situations, that i shouldn't have messed up and blocked potential paths for me that i would have loved to take. I got angry about this, which helped neither, as you can guess.

I tried multiple things. Pushing it down, breathing, meditating, binge-watching, whatever. Nothing helped. If I situation was too much: Light anxiety! Once i realized it: Hello big anxiety!

At some point I tried a different approach: I started to tell myself that anxiety is just misled excitement.

I don't know why but it felt right.

And more importantly, it let to a rethinking of my situation. Instead of being angry at myself for being anxious i started to be thankful for my body trying to help me. I began to appreciate this feeling, maybe giggled about the weirdness, loved it for making me happy with giggles and moved on with this little unexpected newly found excitement bump.

Nowadays when stressful situations arise, i notice how i have honest excitement. Maybe it's due to this method, perhaps i just got over the burnout, but no matter which of the two it is, I hope reading this article helps you too.

Because…

Maybe…

This anxiety isn't anxiety it's just your raw excitement that you are simply misunderstanding.

[klinger-io]

Managing Remote Teams - A Crash Course

Hey folks,

I haven't been blogging for quite some time, so everything is a bit rusty for me, but i thought this article might be useful for a few more people, because about 1-4 times per week i get approached with a question like:

"Should we do remote?"

"How did you remote work for your team?"

"Our team struggles with engineers who are remote…"

The post got a bit longer than i planned to, because i tried to cover the outline of all aspects that might be useful for you when you approach this topic. In this article, i will go over the different kind of setups of remote teams, why and how remote teams work differently, when you want to work remotely and when it's better not to and lastly a few tricks that worked for the teams i was involved. Thanks for reading and thanks for sharing. 🙏

For those who don't know me and just stumbled into this post by accident: I am @andreasklinger -among other things - I helped to build up Product Hunt as a fully distributed team. Btw… yes, they are awesome, yes, they hire internationally, and yes, you should consider applying.

COVID-19 Update: I wrote a second article focusesing on how to setup an "emergency work-from-home" scenario that many companies need right now because of COVID-19. You can find this article here.

So here without further ado… here… we… go.

Remote teams - a crash course

Different setups of remote teams

There is a bunch of different setups people call "remote teams".

Satellite teams

2 or more teams are in different offices.

Remote employees

most of the team is in an office, but a few single employees are remote

Fully distributed teams

everybody is remote

Remote first teams

which are "basically" fully distributed

but have a non-critical-mass office

they focus on remote-friendly communication

When i speak of remote teams, i mean fully distributed teams and, if done right, remote-first teams. I consider all the other one's hybrid setups.

Why does the distinction matter?

They are actually something entirely different and need different solutions.

Process needs

As a remote team, you have roughly 5x the process needs as you would in a co-located team.

Example: Meetings

Everybody loves meetings… right? But especially for remote teams, they are expensive, take effort and are – frankly – exhausting.

If you are 5 people, remote team:

You need to announce meetings upfront

You need to take notes b/c not everyone needs to join

Be on time

Have a meeting agenda

Make sure it's not overtime

Communicate further related information in slack

etc

In contrast, if you are 5 people co-located you just stand up and say: "everyone over there - we talk now". Once a co-located team reaches 20-25 people they definitely need to do the same steps. But before…

You can't just "get up and talk with everyone all the time" in a remote team… you simply can't. People might be offline, might be sleeping, might be deep focused on other work.

And this is not only about meetings. Meetings are just a straightforward example here. It's true for any aspect of communication or teamwork. Remote teams need 5x the process.

You need to systemize communication and expectations

When i say processes, i don't necessarily mean heavy-handed workflows, piles of paper and someone using a giant stamp confirming every action. I mean "systemized communication and expectations made explicit".

This can be as simple as: "We do check-ins every morning…" "Please before you do X always do Y…" These simple explicit agreements allow other people to expect those actions to happen and avoid unnecessary communication loops.

But… i am sorry to say… this is work… you need to act like a larger company than you actually are… you need to be stricter about best practices, and you will run into communication problems… a lot of them.

These communication problems are often what people complain about when they discuss if they should switch to remote teams or hire remote engineers. So they consider hybrid setups…

Hybrid setups are hard to do

Imagine you are the only person remote in a small team. You have entirely different process needs. You will suffer.

Being the one poor soul remote in a co-located team is hard… you have "5x" the process needs… People will continuously forget to involve you in discussions or decisions, you will be the person not knowing what is happening why - you will suffer.

Similarly problematic are satellite offices. The bridge between the offices has 5x communication needs, but people in each office act like co-located teams. Unless the offices can work mostly autonomously, this communication bridge between them will suffer.

Establish processes for communication needs for these kinds of setups are hard. Because they are against human nature… I will just discuss things with you while getting water in the kitchen… I won't repeat what we discussed in slack because i am… well… as all humans… damn lazy!.

Default remote or default non-remote?

I have tried all the models described. Personally, I'd recommend you avoid hybrid approaches and act as distributed as possible - or just don't do remote at all and be co-located. Both are fine.

If you need a small office, make sure people in it don't have a critical mass in projects and communicate remote-friendly.

In these situations, the question is often "Are we default-remote" or "default non-remote" if it's the first, having a small office might work out for you.

Questions to ask yourself:

Why do you consider doing a remote team?

Are those advantages worth the effort for you?

If yes what would need to change if you would commit to it?

How often do you want to meet in person?

If you need a small office how can you communicate more remote friendly?

Example: Would it be weird if all people in the office would join team calls with their own laptop?

Why would a team want to work remotely?

A lot of people mention costs. "It's cheaper to hire people remotely". This might be sometimes true – and it's definitely true if you are used to San Francisco salaries – but… international talent usually expects international salaries… so you'd be surprised how much many people expect. If you want cheap outsourcing, this "remote thing" won't work for you.

Overall hiring remote is about four things - being able to hire, the best possible people independent of where they (or you) are - optimizing for the quality of life - tuning your personal performance - having long-term team retention

"Our startup is amazing, people will want to move to X"… Some will… some won't. All the "won't" are a lot of people you are missing out.

On the other hand with a good remote-team pitch, you can even (often, not always) approach Silicon Valley top talent: "Hey considering leaving the Bay Area? Google might have an issue with it, we don't - work with global talent on a project that matters – wherever you are. Shall we talk?"

But (imho) what most people are missing… is not the costs… not the untapped talent… nor the ability to optimize your quality of life and own performance. It's a simple fact: talent retention. Ask remote teams how long their people stayed with them. It's years longer than in co-located companies.

Iteration vs. innovation

One thing you will quickly realize is that a lot of human nuance gets lost when discussing things via Hangout or Slack. This nuance is important. Especially if you work on critical, creative work.

Imagine you need to pivot your product. You make a long passionate speech about what the team needs to do to win the market, just to be followed up with a "Sorry Sarah, your internet connection dropped for a second, what did you say?"

"Innovation" is more natural in person. It's better when even the quiet person in the back can pick up a marker and explain something.

But once you agree on something it's about individual performance… This is usually easier remote.

Iteration easier remote

Innovation easier in person

So even if you work remotely, you will need to define how often you want to meet. I recommend once per quarter or twice per year as a team and whenever required by the individual project teams.

Loneliness

A lot of people mention loneliness as a problem in remote teams. Personally, i never had this an issue be for me, but i saw it with friends and fully understand why people are worried about this.

As company-lead it will be your responsibility to make sure people are happy and healthy. Here is what helped in our team:

Don't work from home but a shared office (coworking spaces tend to be too distracting)

Make sure you meet non-work friends

Meet regularly in person

Optimize for iteration - Optimize for single player

In remote teams, you need to set up in a way people can be as autonomously as they need. Autonomously doesn't mean "left alone" it means "be able to run alone" (when needed).

Think of people as "fast decision maker units" and team communication as "slow input/output". Both are needed to function efficiently, but you want to avoid the slow part when it's not essential.

Questions to ask yourself:

How can you…

… define strategy clear enough that people can formulate their own decisions without going off-track?

… set goals clear enough that people can benchmark themselves or their decisions?

… setup decisions hierarchies in a way that only non-reverse-able important decisions even bubble up to you?

… create confidence? (speed comes through confidence)

When is it enough that you hear about it and when do you need to involve?

How can you make sure that you are only involved in every 10th decision and only "manager-override" every 100th?

… set up your environment/processes that they can act even in emergencies on their own?

If you hired smart, talented people, why can't you just "let them do their job"? What's missing? Did you hire the wrong people? Did you not communicate clearly? Are you (yourself) uncertain about strategic elements? Solve that instead of micromanaging them.

Apart from these company-wide questions, you will want to ask similar questions also for each specific vertical.

Digging deeper: managing remote engineering teams

Here a few example questions for engineering teams (but you will know similar ones for any kind of function):

How can you or someone in your team…

… troubleshoot alone when it's in the middle of the night for everyone else?

… enable new developers to be able to learn by themselves?

… guide coding best practices?

… avoid making pull requests a slow process?

… prevent meetings that don't create value?

… enable developers to make product decisions on their own?

… avoid worst case scenarios?

And again: How can you increase confidence? (speed comes through confidence!)

At Product Hunt we thought a lot about this! Here a few answers that helped us:

Have a clear strategy and high-level goals

Let engineers take ownership over teams and projects

Let them take ownership over the product they build, but also the goals they commit to (strategy goes top-down, execution bubbles bottom-up)

Making it clear what scenarios require multiple eyes or other people's feedback (e.g., stack changes, security concerns, etc.)

Have strong onboarding documents and employee handbooks

Have new employees improve those onboarding documents

Be explicit in communication

Be explicit which are expected rules and which are not.

Wait for problems before you introduce solutions (esp. processes or infrastructure)

Friday's employees can work on what they think creates value (unless their project is on 🔥) - fixing tech debt, improving UX, trying out new libraries, refactoring infrastructure,…

Share recorded videos instead of live-demos to explain something (e.g., UX prototypes)

Have a strong (but not too big) test suite (focusing on integration for features, unit tests for risky parts)

Focus on reuse of standard components instead of pixel-perfect layouts

Enforce linters for any language you use (even, e.g., HTML/CSS)

Enable autoformatting (to avoid code style discussions)

Enforce complexity scoring in linters (⬅️ biggest win)

No production console access unless for (logged+alerted) emergencies

Make it easy to recreate a production-like state in development (sanitized)

Have one-step-to-reinstall development environments

Have defined times for pull request reviews (first thing every morning)

Make Pull-request +1's a "polite thing to do" but not a "required step"

Enforce pull request +1's for parts that are security risks (via danger.js)

Write comments about why not what

etc. etc.…

Let me know if you think it would be useful for you if i'd wrote a larger blog-post going into detail here. For now, there is a lot more detail about we worked at Product Hunt in this first presentation of mine: https://www.slideshare.net/andreasklinger/engineering-management-for-early-stage-startups-97402850

TL;DR: The ultimate goal of this setup is that an engineer can figure out, on their own, if they are doing things right or wrong. Have low-level feedback coming from automation and that it's clear when high-level feedback is needed from team members. And most importantly you treat them like capable adults.

But… these are not problems of remote teams

The problems i mentioned are not unique to remote teams, and the solutions are the same thing good co-located teams do. But they don't need to be as strict about them because they face them later of can just monkey-patch around them. Their engineers might not like the typical "let's all get over there and talk…" But i tends to work… so people do it anyway.

co-located teams monkey-patch their process problems with more meetings and micro-managing people.

As a remote team - because of the higher process needs - you just end up facing these knowledge worker management problems earlier and more intentionally.

Because meetings are expensive for you, you need to think about systemizing processes actively.

Because you cannot watch over your employees' shoulders, you have to find ways and boundaries you can fully trust them.

Because you cannot micromanage them, you need to define strategy and goals and treat them as competent adults who make decisions for you.

Aren't you already working in some way?

We can discuss the pros and cons of remote work, but let's be honest…

We are all already working remote… You might be checking your emails on your weekend, you might be reading papers on your way to work, you might finish some project in the evening at home. You already work remote, the question is only how often and how much enabled you are to do so.

The question is no longer if you work remote but how much.

Remote work is the logical evolution of digital work. And the best-practices of remote teams are often learnings for all digital knowledge work teams.

The end

Let me know if this is useful… And if you have experience with remote teams, tell me how i could improve this article! Also last but not least: Please share this article if you think it's of value!

PS: I haven't been blogging for years… I was very nervous about starting to write again and asked for early feedback. Over 100 people offered their help, more than i can mention here, i am still at awe about the fantastic feedback i got. The offer to help means a lot to me. Thanks to everyone.

If you want to help me by feedbacking early drafts of my blog-posts please subscribe here. Thanks in advance

🙏 @andreasklinger

[klinger-io]

The simplest and most important dashboard for early stage startups.

This blogpost is part of a small series of posts that cover the basics of startup metrics. My personal goal is to help early stage startups more effectively, but also avoid repeating myself too much in mentoring programs.

If you are working on a software product in early stage of its lifecycle this series might be useful for you.

Other posts in this series.

A primer on startup metrics. Which tools to pick

Easy, but easy to f*ck up. How and where to integrate Analytics goals

Startup Metrics: A Love Story. The Slides Of My 7h Workshop

If there are special topics you'd like me to cover please ping me via @andreasklinger. Also if you consider them useful please be so kind and tweet this article.

Early Stage Startup Metrics

One of the most common pieces of advice is that in early stage you want to focus on retention. Because retention - in the end - is a function of customer happiness

retention = f(customer happiness)

It’s simple: If people are not happy with your product and/or gain no benefit by using it they will most not continue using it.

And automatically cool visualisations like retention cohort tables come to mind.

While those tables look nice and give you this nice fuzzy feeling of doing something useful with your time, they are unfortunately usually a bit useless until you get to the point of optimising on-boarding conversions of new users.

Please don't get fancy too early.

This kind of visualisations are great when you have too many users and need to get a bird eye view. When you need to an abstraction. B2C mobile apps often have this problem already in early stage. But most SaaS companies (or companies still in beta) i worked with don’t have this problem until they reach product market fit.

20% changes with 20 customers won't tell you much apart of the basics of standard deviation. A personal relationship to this customer will tell you his story. Keep them close.

If you treat your paying customers like percentages and meaningless numbers they will do the same with you.

The one “dashboard” i recommend almost all early stage startups is one they already have. Let's start using it.

As long as your customer list fits on one or two pages, you should have a list of all those customers. (And i am pretty sure you already do have this in your backend)

Add activity information to this table. Core KPIs that tell their activity level (or at least their last login date). Color highlight it based on activity. And put someone in the team in charge of making sure everyone stays on green.

dummy mockup is dummy

Seriously? That has nothing to do with metrics, or?

"That's the kind of advice gives someone who charges money for consulting? Make him draw complex graphs or bring the pitchforks."

This dashboard so embarrassingly simple to implement, i was even scared to publish this post. But it is - and keeps being - my most common recommendation for a custom dashboard.

I don't know about you. But I don't necessarily need numbers. I need information i can act on. I want product insights - simple ways to use my database information to create actionable insights.

Most abstractions like graphs, retention cohorts, aarrr funnels and so on are great to aggregate information as soon as you have too much of it. Before that they just do one thing, create an abstraction layer.

For myself i found out this is even useful in a bit later stage: If you have only 0 - 100 new signups don't hide them neither. It's the same game on a higher level. Their first month is the one month that decides if you will keep them or not. Keep someone in charge of making them stay green.

Put one person in charge of keeping all customers on green. Most likely that person is you.

Your job as a product manager/founder is it to keep in contact with all those customers. And as soon as someone moves to orange contact them via email or skype.

Find out what’s going on. Now they are still in their decision process. Now you still can convince them to stay. Now you might even get useful information for product changes.

Churn is not happening when a user unsubscribes from your service or stops paying you. This is just when you notice it. Churn happens when a user stops using your product. You want to jump in when a customer is at risk, when he might stop using your product.

As long as you have a few dozen paying customers you can contact each one personally. There is no excuse. Don’t treat them as numbers, if you don’t want to be treated the same way.

Customer Happiness Index

If last activity of your customer doesnot mean much for your product (eg login might not mean that he found/did something) you might want to focus on deeper core activities.

Usually people create a Customer Happiness Index. A single number that combines all done activities to a sum, while giving each of those activities a weight.

By doing that you can eg. say that logins are less important to you than purchases. You can even aggregate those numbers in groups and through that see problems in certain segments of your user-base.

But to be honest, as fancy this is, i hardly ever need this.

Not until i need to aggregate those numbers. Eg show the customer happiness of a certain customer segment.

But until then - in my personal experience - i usually only see 1-3 core activities in a product. (eg in a project tool - number of projects/total, todos-closed/week, active-team-members/week) And normally i tend to simply recommend adding those numbers to the table and be done with it.

Commercial break.

One product i want to highlight at this point is Intercom. They basically offer this as a service, but add manual and automatic messaging. Additionally they write one of the best startup product blogs out there

But as long as you need/want to save a bit of money. The table mentioned above is only a few lines of code away.

until then, get your product moving,

Andreas

[klinger-io]

Easy, but easy to f*ck up. 3 Rules to Setup Analytics Tools correctly.

As a consultant for analytics i see a fair share of integrations of analytics tools. One of the most common mistakes is how people actually track events and conversion goals.

Very often a lot of data is rendered useless because it is confusing or contradicting to each other. If people use several tools. This problem even amplifies more.

The rules for good analytics actions/goals:#1 As few actions as possible#2 Same names in every tool#3 Triggered by the same logic in code

— Andreas Klinger (@andreasklinger) November 26, 2013

I summarised my personal opinion in this tweet above. People asked me a few times to go into details - so here are some quick notes.

Btw if you look for a bird-eye view on the whole topic of metrics tools check out my ebook-as-a-mega-blog-post: A Primer on Startup Metrics.

Rule #1: As few actions as possible

You want to add as few events as possible.

"But we need to track so many things"

If you starting out, do yourself the favor and ignore everything that "might be interesting" (optimisation) and focus on the ones that define the core aspects of your product (accounting).

Things will break, the less moving parts you have the more certain you can be that they actually still work and provide meaning.

Protip: use a prefix for temporary events. I use "test_"

Rule #2: Triggered by the same logic in code

The most common mistake is to have analytics events triggered in different parts of the application.

Eg. Google Analytics might receive the event when the user presses the button or visits some page "that should come afterwards" and your custom dashboard pulls the data from the database.

This sound reasonable in the beginning but very soon your application will change a few times, new validations will require more complex forms, etc, etc. Very quickly you have a mess of interdependent logic that will lead to stuff breaking.

My recommendation: Create a analytics helper function that you trigger at the place the actual event happens. Eg in case of a user signup AFTER the user is saved. If you send your data to your analytics tool through javascript it's the job of this helper to make sure the frontend receives the needed information. (eg in rails use gon or flashes - watch out for 301s)

Rule of thumb: If data change happens the event should be triggered at the place the data change happened.

Rule #3: Same names in every tool

One of the biggest mistakes people do is to use different names for kinda-the-same things when they use different tools.

Use the same name, make it the job of the helper to make sure every tool receives the information in the format they need.

Eg Google Analytics might expect "User", "Signed Up" and Mixpanel might expect "User - Signed Up"

Btw Segment.io is a wrapper for your analytics calls and highly recommendable (they additionally offer features like history import to new tools, etc).

Rule #3.1 Event Names: Be understandable

I - as somebody who has not implemented your events - should be able to understand what each event represents AND in which context of your app it is most likely triggered.

Rule #3.2 Event Names: Be explicit

If a user has been created - this happened If a user just clicked a button - this happened

Eg Newsletter Submitted is not the same as Clicked Newsletter Submit Button

Nothing is more horrible than ambiguous event names.

Btw In almost all cases you will want to use past tense.

That's it

New post, b/c it's always the same mistakes "Easy, But Easy To F*ck Up. 3 Rules To Setup Analytics Tools Correctly" http://t.co/S3QerEbEuu

— Andreas Klinger (@andreasklinger) February 19, 2014

I hope this primer helps you to set up your events correctly - if you have any questions please feel free to reach out to me via twitter If this post is useful for you please tweet and share it. Thanks

Until then, track on

Andreas

[klinger-io]

A Primer on Startup Metrics – Which Analytics Tool to pick.

As a analytics consultant I am working with a lot of startups and help them in the topics of metrics, analytics, retention and growth. Most of the questions i get are based on a few misunderstandings.

Eg. What kind of analytics tools you should use depends what you are trying to do with those tools. They have (more or less) specific purposes.

Disclaimer: This post focuses on web products - but you could apply the same concepts for mobile.

The Segmentation of web analytics

So let's get into this…

First: Please lower your expectations

If you are hoping to add one tool and be ready to go, i need to stop you right here. Please readjust your expectations.

There are a few hard truth facts we need to accept:

All tools are good for a few things, but tend to suck for most of the other - the trick is to know what you are looking for.

Also: Any tool you will integrate will most likely be: not optimal for all of your usecases, not specific enough, most likely be broken or incorrect a good amount of your time and contradicting every other tool you have.

But that’s ok. If you know how and what to use them for.

Let's roll…

I personally split usage of analytics into two axis:

exploration / accounting.

external / internal

Exploration vs Accounting

Exploration are those ad-hoc questions.

Exploration are all those quick questions people come up with and are very often related to some intuition we have.

eg “What feature is most used?”

or “Are users who use feature X more likely to upgrade to plan Y?”

Conversion Rates, Landing Page Optimizations, Funnel Optimizations, Viral Loops, Quick questions and insights are they typical examples of usecases of exploration.

Accounting are the metrics we track over time.

FYI the term accounting was coined by Eric Ries as innovation accounting covering more metrics than the typical product metrics, but the term kept sticky in normal web analytics as well.

If you have ever kept record of KPIs in your excel sheets (eg for investors) that’s a typical report we want for accounting.

But it also includes reports here we tend to use several times a week.

Cohort Retention Tables, Customer Happiness Reports, Traffic Referral Reports or Revenue Reports are typical examples for accounting reports.

About Data integrity

In case of exploration it usually doesn’t matter too much if we have only little historic data, or that we need to jump through a few hoops (aggregate from several tools, export to excel/R, etc). We need as much data as we need to invalidate or validate our hunch/gut-feeling or current objective. Very often this insights can and will be challenged by the team and need further verifications.

These insights usually lead to experiments (eg a/b tests).

In the case of accounting it is very important to have historic data and data integrity is very important - we can’t really tolerate too much noise in the data we are using for accounting. We can’t really tolerate broken reports nor can we have our team not trusting those reports.

This insights usually lead to strategic decisions. (eg switch sales focus)

While it is very useful to distinct between these two areas we need to keep in mind that in reality the lines are a bit blurry.

The second axis i tend to look at is external and internal analytics.

External vs Internal Analytics

External Analytics covers all public facing pages and all passive actions by users (eg views).

Internal are all actions done by (persistently hopefully) identifiable users, that potentially reflect if your product provides value to them.

When people speak of "product insights” they tend to mean that internal view of your product.

Many product have a very clear distinction between external and internal - eg. SaaS tools provide a value that i need to register for.

Sometimes it's a bit blurry - Some products provide usecases to non-identified users as well - eg. content pages like pinterest or 9gag where a huge amount of the product is public and most of the visitors value is provided passive.

In a nutshell

Which Tools

There is roughly a million of analytics tools out there. I will focus in this article on the most common ones for web products: Google Analytics, KISSMetrics and Mixpanel.

Google Analytics:

GA is great for everything external. Especially traffic analysis and referral optimization work perfect in GA.

I am a huge Google Analytics geek and to cover it properly would be at least 3 own blog posts.

If you are new into it here are three blogposts i would recommend you to read:

Set up Goals for your main conversions (eg newsletter or signup button):

Use custom variables to “mark” users that registered

Fix your bounce rate (esp important for content marketing)

Learn to use weighted sorted

and how to use segments

The most common usecase for GA is referral optimization. It enables you to understand what sources bring you the most valuable traffic and where you should double down (as said above learn how to use weighted sorting).

If you use GA for all external stuff you will be very happy. For product internal insights GA tends to be useless.

The main reason is that GA doesn’t think in users and events. It thinks in visits and sessions.

You can force GA and focus more on visitors, you can segment down to the pages that are product internal, people that are registered and you could look mainly at events. But even if you do all of that then you will have a hard time using that data.

GA wasn’t made for product insights in first place.

GA is awesome for product-external exploration and very good for a lot of product-external reporting/accounting (eg weekly referral/traffic/seo reports).

But it stops being spot-on useful where most products actually start. (activation/engagement)

Ad Mobile: I am speaking obviously mainly about GA for web here. The GA team currently pushes their mobile analytics tool. Everyone who has used will notice this weird feeling that the tool wasn’t meant for this originally in first place. But given their current development speed I wonder if i will need to come back here in half a year to update this part.

KISSMetrics and Mixpanel

Both - KMS and MXP - come from the same main concept. They think in “people” and “events”.

Both tools are great and to cover them well would need several blogposts by themselves so please excuse my brevity.

At first they look very similar and i am pretty sure you could substitute every feature of the one in the other. But to me they both tend to have a bit different focus. They have been build by teams with a bit different values.

Mixpanel is awesome for product-internal exploration and good for product-internal reporting. It’s the tool i would pick if i focus more on product improvements (eg engagement). Personally I also have better experience with its stability.

KISSMetrics on the other hand feels like it has one foot in the product-external world.

It’s revenue tab makes it very easy to see what sources brought customers of what kind of life time value. You can easily see what your customers where doing and so on.

Of course MXP is catching up and offers a revenue tab as well. But nether the less KISSMetrics would be the tool i'd pick if I would focus a lot on revenue improvements (eg through content marketing) while trying to improve the product itself (especially as a SaaS startup)

Actually KISSMetrics fits so well as a hybrid between product-internal and external usecases - especially for content marketing - i wouldn’t be amazed if they come up with a specialised content marketing tool or somehow else integrate with Google Analytics to have a easier angle to the market.

Specialised tools

There are a lot of really good specialised tools and again not possible to cover all of them here. My personal four favorites are

Custora for eCommerce (Highly recommend)

Totanga for SaaS

RJMetrics for eCommerce

Flurry for mobile (Highly recommend)

And of course there are many more.

The advantage of specialised tools is that they understand (or expect) enough of your product internals that they can provide value insights right out of the box.

The big problem with all tools

Most tools are integrated through push events. Basically your site will send an event through javascript or your backend and let their service know.

There is a big problem with this approach.

Data Integrity

Sooner or later your integration will break for a day or two. Because someone on their or (more likely) your site made a mistake.

Sooner or later you will change how you track certain events and your comparison with your historic data will no longer work.

Did you ever see different numbers in different tools? Eg different amount of registrations between MXP and your database? or Revenue in KMS and in your stripe dashboard? Well that’s what i am speaking about.

In case of exploration this usually tends not to be a big problem. Anyway the data i work with tends not to be optimal (sample noise, dataschmutz, skewed, variance etc) and I am just looking for anchor points for future experiments.

In case of accounting this is a big problem. We cannot really have our revenue reports incorrect. This is unfortunately where the fun ends.

And there is a other problem…

Focus on product internal aspects

Very often product-internal reports tend to be quite specifically tied to your product.

If you run a market place you want to report improvements on both sides separated.

If you sell not to people but to companies you want to aggregate your users into those company buckets.

If you have different levels of users you might want to treat them different (eg drill down your best paying or engaged segment)

To figure the right metrics is a blogpost by itself but to in a nutshell you want to tie your product assumptions to quantified results.

All of the mentioned segmentations above are doable in some tools mentioned, but it will require you to jump through several loops.

And given the fact that very often data integrity tends to be a problem the logical conclusion is to sooner or (if possible) later build those highly specific reports by yourself.

Work with your database for accounting

When it comes to accounting i would highly recommend to work with your database.

As a rule of thumb: The more you need to zoom in - the better you work based on your own database.

Depending on the level of complexity you need you can:

Export to excel

Run a script that sends the most important numbers

Build a simple dashboard

In most cases i would recommend to start with the first one and do it for the first months. And then start step by step automating the most time consuming report parts to scripts and from scripts you will move to a simple dashboard view over time. Usually i would recommend stopping here.

If the dashboard itself turns out to be too time consuming (eg most likely because you put too many expectations into it) try using a tool like chart.io

If you pre-run into performance problems move the analytics to a own server and run the scripts only once a day.

Doing that you can introduce reports like Customer Happiness Index and Health Dashboards (red/green lights (or kpis) per customer or segment)

Disclaimer I am not advising you to build your own analytics tool. I not recommending to measure non-logged-in data. I advice you to segment your existing database data for reporting. There is a big (costly) difference.

I won’t go into dashboard design right now - but if you are interested in this topic please let me know via twitter happy to write a blogpost about it.

So to answer the question – which tool would i recommend

These are the swiss army knifes. Depending on stages i would recommend other tools additionally or instead.

If i have to decide between MXP and KISSMetrics i would - usually - go with Mixpanel (but as explained above it depends a bit on the specific product).

Hope this blogposts helps you a bit to get clarity about metrics even though i couldn’t cover all aspects nor all tools.

If you are still unsure which tools to pick i would recommend using Segment.io as a wrapper for your API calls. That way you can simply replace your tools whenever needed.

If i can help you anyhow with your analytics setup - let me know - i am doing weekly open office skype sessions - feel free to hit me up on twitter

Until then - measure/build/rock

Andreas

[klinger-io]

Don't drown in email! How to use Gmail more efficiently.

I usually I blog about Angellist, Startups, Founders, the Future and especially Metrics but I have shown this "lifehack" to so many people that I thought it's worth it's own blogpost. Hope it's useful.

If you struggle with keeping on top of your emails in Gmail you want to maybe try my setup. It's hard for me to lose track and trust me - i am easy to distract

This is how i use Gmail since 2010:

GTD - Getting things done

An easy to manage, usually empty inbox on the left

All "todos" in the first box

All emails "awaiting a reply" in the second

All "delegated" emails in the third

All emails related to meetings, flights, etc easy to find in the fourth

All done with 0 plugins, using only standard gmail features

It's hard to lose overview using that setup

I couldn't even imagine using gmail any other way. No seriously. I see those messy priority inbox tab inbox systems and I am just scared. Scared that google will someday force me to use those features.

Btw: This approach is not particularly new. I learned it from a person (forgot name) at LeWeb 2010 and it was mentioned on a blogpost which was called "Gmail Ninja" (couldn't find the link).

How I manage daily work

An email comes in

Handle those you can instantly

The others mark as todo

If you want to keep track of them when you replied, you mark them as "Awaiting Reply" or "Delegated" (that way you can always quickly find them and follow up)

You archive all emails

You inbox on the left is empty again

All important ones are in the special boxes ones the right

Example:

Received an email

Was able to reply instantly (if i wouldn't have had the time i would marked it as yellow bang (Todo))

I replied

Marked with "awaiting reply" (question mark)

Archived the email

The email is no longer in my inbox but in my "awaiting reply list" on the right side

His reply will come into my inbox (and we start over with replying instantly or marking as action)

Archive - Inbox Zero

That's it! You are done.

Hope fully that workflow also helps you.

Interested? - It takes about 15minutes to set up…

… but might change how you work with email forever ;)

In a nutshell it's

Multiple inboxes

Special stars

The multiple inboxes have searches matching the special stars

Several filters to avoid repetitive tasks

Step by Step guide

Add multiple inboxes

Go to Settings (you will find it under the cogs icon on the top right)

Go to Labs

Enable Multiple Inboxes

Choose right side layout

Choose the correct special stars

Go to Settings > General

Scroll down to Stars

Add the stars you will want to use

I use:

Yellow bang for Todo

Red bang for Important Todo

Question mark for emails I expect or await a reply. (so i can followup)

Orange guillemet (double arrow) for emails i delegated to someone but expect to be done. (so i can follow up)

Purple star for any arranged meeting, flights, event tickets, call or anything else related to an event where i might need to find that stuff quickly.

Filter the inboxes to match the stars

Go to Settings > Multiple Inboxes

Switch to right side layout - the option is in the bottom (!)

Add the filter rules you want for your inboxes

Here is the list of all names of the stars:

has:red-star

has:orange-star

has:green-star

has:blue-star

has:purple-star

has:red-bang

has:orange-guillemet

has:yellow-bang

has:green-check

has:blue-info

has:purple-question

You can btw also do more complex filters by adding OR, AND or basically anything else you can use in search. Eg. I use OR to show both important and VERY important todos.

Note on mobile: If you use the mobile Gmail App a lot i would suggest to use the normal yellow star for todo. That way you can at least mark todos in mobile. Unfortunately the other features won't work as well because the gmail app doesn't support them.

Enable the inbox layout (aka kill the tabs ;) )

This part is a bit annoying - basically you need to disable a lot of fancy default features of gmail. If the new multiple inbox layout doesn't appear in your inbox after you finished the guide you might have missed some step here.

Go to Settings > Inbox

Switch to "default"

Turn off any configuration you might have regarding tabs

Turn off any configuration regarding priority, important emails or filters

Go to your inbox

Click on the cog and click on "Configure Inbox"

Remove everything

And while you are at it: Switch layout to "compact"

Now reload

Getting to inbox zero the first time

Let me guess you got a lot of emails in front of you right now or? I had several thousands the first time.

You need to get from several thousands it to Inbox Zero. And this needs to happen now. But it's actually quite easy.

Go through the first two or three pages of email.

Mark everything that is a todo with a todo icon (in my case yellow bang).

Every thread where you had the last email and await a reply mark with your awaiting reply icon (in my case question mark).

The same for your delegated and events emails.

When you went through the first two or three pages and you have the feeling nothing (still) important appears anymore do the daring move.

Click select all (the checkbox on the top left)

Confirm that you really mean all 6523 emails

And click on archive

Now your inbox should at zero and your right areas full.

More Gmail Workflow Tips

If you like the suggestion above you might be also interested in my other gmail workflow tips:

Robot the majority of your emails

I am pretty sure you receive dozens of newsletters, groups etc.

Unsubscribe what you don't need

Filter what you only need if you search for it (i do this eg for follower updates etc)

Filter everything that can be automatically processed (eg all my invoices get a label, all my commercial invoices get a label and are forwarded to my assisstent who will then use it for bookkeeping)

By now i have over 100 filters and i only see new emails if i really need to see them.

Keyboard navigation

Enable shortcuts in settings

Learn them

Most important y for archive, r for reply, a for reply all, s for star

Auto advance

Choose auto-advance in Settings so you can cycle through your new emails in the morning really fast

Undo sending

Enable Undo send in Settings > Labs

Wonder for the rest of your life why this is not a default feature

Merge your email accounts to one

Screw multiple logins

Fetch all your email to your main gmail account

Be sure to use the "smtp" feature to avoid the emails being send as "on behalf of"

Choose to always reply from the email you got the message sent to

Ideal if you have private and professional emails coming now to the same inbox

Install rapportive. But i am pretty sure you already have done so. ;)

Update:

A few people mentioned that they suggest using labels instead of stars. Labels are accessible in the mobile app and also in other apps.

Personally I prefer the stars because they are quicker to access. But if you are looking for a way to have the same workflow also accessible in your mobile - labels might be the solution.

That's it.

I hope this workflow helps you as much as it helped me and several people i showed it too - If you want please tweet this article. And also feel free to hit me up on twitter if you have any further questions or suggestions how to improve my workflow: @andreasklinger

Until then, lifehack the planet,

Andreas

[klinger-io]

Why Lean Startup sucks for startups.

If you go to Lean Startup events you will find first time founders, consultants, accelerator managers, r&d people, enterprise intrapreneurs, people of the government and a lot of people running meet-ups around the topic of Lean Startup. But you hardly meet people who are doing startups successfully or people who are in their nth startup. Why?

Also a lot of people mention more and more than Lean Startup is moving more and more to Enterprise. And that's plain obvious to see. But why is it happening?

All of those are merely symptoms. The underlying fact for that is quite simple.

Lean Startups "sucks" for startups

Disclaimer:

I am not bashing Lean Startup in this article. I critisize it in its current iteration. Lean Startup will look different in a few years from now. And hopefully incorporate my concerns.

The problems i mention could be blamed on those who practice, or those who teach. But honestly it's a problem with in-difference and loosing touch to startup reality.

It comes down to one thing: treating enterprise and startups the same and a cargo-cult like process by 3rd tier experts (like me) who increase the negative effects of this anti-pattern.

Many experts (incl. book authors) are giving processes and tools to enterprises and startups without truly understanding their different context and needs. And there is a reason why Lean Startup works best in enterprise and education (right now). Because that's were those tools work best.

Let me explan…

Upside Validation vs Downside Protection

Startup life is about protecting your head and not your ass. Because your are running head-forward in the dark.

The goal of a startup is not to validate as much as possible to be sure that you are on the right track. The goal is it to validate as little as needed.

Startups are not about validating you do the right thing. Startups are about validating you are not doing the wrong thing.

It sounds very similar but it is fundamentally different.

Validating every step to get more certainty makes sense for some - eg. people who work in enterprises. But not for normal startups.

And unfortunately most people and most techniques in Lean Startup tend to ignore this different context.

Too many consultants approach this problem indifferent…

And honestly if you could measure loss of lifetime because of mediocre advice, many Lean Startup consultants would be serial killers.

Validate as little as possible

The next time someone asks you "did you validate this?" - answer "how much is it worth to validate this?"

The problem is quite simple:

The time and effort it costs to validate something is usually higher then the pay-off

It is usually easier to validate that you are on the wrong track. Than that you are on the right one.

In many cases it pays off to move on if you are certain "enough". Because most likely more (noisy) information won't lead to more certainty.

Example

Let's say you have the doors A B C or D to go through.

In a perfect world we could now evaluate all four doors (eg through interviews or experiments) and then try to make a educated choice. We could easily argument afterwards why we picked a decision. We did the right thing.

In theory this sounds like the right thing to do. Gather more data than you can cheaply acquire. Validate your decisions based on data.

Or we could pick the one we believe the strongest in (given the information we could timely acquire) and try to figure if it's the wrong one.

This sounds like a suboptimal option, because maybe one of the others would have been the better option.

What i notice is that many people try to pick the first option, but end up with the same level of decision quality as in the second option, plus a bunch of fluff non actionable data, gathered by suboptimal methods that pseudo-justifies their decision.

In theory startups are about finding the right door.

In reality your own subjective bias combined with very noisy information will make it impossible to get to the information quality you hope for.

In reality you have huge risk associated with your cost of delay.

In reality you are happy if the door you will pick is not a death trap and you want to verify that.

In reality there is no-one questioning you apart of you - so all your steps should just happen to make sure you can convince yourself and that YOU do not lie to yourself.

If you are unsure what i mean with cost of delay or in general want to read about product management i recommend these slides by Don Reinertsen - here is a good summary

There is no point in trying to validate just to get the affirmation to move on. If you are already convinced most likely you will bias the output and waste time. No-one will ask you if you fail anyway. You want to make sure you are not doing the wrong thing and move on as fast as possible. And wait for the real risks to test.

Lean Startup calls it picking the riskiest assumption first. But leave it there. For startups "pick only the riskiest assumptions" might be a better formulation. It comes as said down to a mindset:

Good teams don't use the tools of Lean Startup / Custdev as a navigation systems. They use it as a headlight to make sure they don't kill anybody or get of the road.

You can easily argue that the behaviour I mention above has nothing to do with Lean Startup but the way how people apply it. Which is true.

Which leads me to the second big problem Lean Startup has…

Processes vs Principles

To explain this to people less familiar with Lean Startup. There are two approaches to Lean Startup:

Understanding it as a strategy, so to say as a process to follow.

Understanding it as a principle, so to say as a toolbag to use.

Similar to church members it depends to whom you speak - this definition of Lean Startup will range from that loose principles to a concrete process. And similar to lessons in the bible people tend to pick the side and lessons based on their church they belong to and the argument they are trying to win.

Btw from my talks to Eric Ries i would put him definitely into the second group. People who look for the underlying principles and evolve processes over time.

But the problem is that there is a huge cargo cult around Lean. A cargo cult of consultants and Lean Lurkers. A cargo cult that focuses on processes.

Lean Startup tends to attract people who like to be told what they should do next. And people who like to teach people that process for money. – Bjoern Lasse Herrmann, Startup Genome

People follow motions instead of understanding why they actually use certain tools.

When you don’t apply critical thought and strategy to your startup and conversations, you’re just going through the motions: replacing the hard task of strategy with the lazy solution of following someone else’s process. - Rob Fitzpatrick

Many teams become what i called above Lean Lurkers.

Teams that use complex terms and slow processes they borrow from Lean Startup to hide, and even excuse, the fact that they have no traction. No traction is no traction. No matter what you did to (not) get it.

Following Lean Startup step by step sucks for startups, but that's ok

There is a space where you need to explain why you picked a decision. A place where you need to justify and cover your ass. A place where you want to show your updated business model canvas. A place where more data, proof and validation that fundaments your previous decision is good. The enterprise corporation.

And i mean this without any disrespect towards large corporations.

Lean Startup is one of the best things that happened to enterprises.

Because Lean Startup can help enterprises remove mid-level management decision. The moment someone outside of a project needs to touch or decide upon a project either quality or speed goes down. Lean Startup provides a framework where (in a utopian) company, opinions and politics can be reduced through data aggregation and validation to the point that they are no longer relevant.

And there is a space where you need to go through motions for no other reason than to go through the motion and be questioned at each step and learn the skills. That space is called education.

Lean Startup is a perfect vehicle for accelerators and universities to teach tools of entrepreneurship. It's perfect to increase the contact surface with different approaches and provides an optimal framework for high paced learning experiences.

And coincidentally these are the spaces where Lean Startup currently fits perfectly.

Just to clarify:

Both problems i mentioned above - unnecessary upside validation and blindly following processes of "opinion leaders" - have per se nothing to do with Lean Startup. Lean Startup even promotes the idea of quick (potentially wrong) decisions and going for the riskiest bits first in its core.

But an undifferentiated approach to Lean Startup by treating enterprise and startup context the same leads to startup teams looking for validations only enterprises and education spaces can effort.

So if you wonder why Lean Startup moves to enterprise?

That's the reason. In it's current form it fits best to enterprise. It's current leaders focus on enterprise.

The reason simple: Many people doing those workshops lost themselves in theory and forgot about the practice.

Enterprise consultants will only develop tools for enterprise people. And if you look around in the Lean Startup scene, all the current opinion leaders make their money with enterprise consulting.

Lean Startup lost a part of its core.

The problem Lean Startup has currently is (imho) that it lost the attachment to a good part of it's core.

It used to be about the experience and best practice of startup founders. It used to be about taking that startup founder learnings and abstracting them and sharing them to more people. Founders are the ones developing new entrepreneurial tools for startup founders, not enterprise consultants. And that's why many founders replaced their Lean Startup books with Hackernews articles.

That leaves learning opportunity for new learnings on the table. That being said - try to join the next Leancamp in your neighbourhood. We try to escape consulting land and focus on things learned by founders. Most of them come btw from other fields than lean.

What will happen with Lean Startup

I personally see two things possible to happen. Lean Startup might cut the corner and regain credibility within the startup founder scene. Which is still possible because i personally strongly believe in Eric Ries' point of view of an evolving tool for entrepreneurship and his marketing skills to get the right people involved again.

Or not...

But even if not...

One thing I realised this year at the Lean Startup conference after speaking with Eric Ries and Ash Mauraya… It would be ok if Lean Startup doesn't make it back to the startup scene.

Because Lean Startup itself moved on. It hit the mainstream. It became a synonym for high-paced, iterative, high-potential entrepreneurship. It became a framework for other industries to understand "how the kids in software tech do it". It helps governments. It helps people pushing entrepreneurship.

In any case it did important big steps for entrepreneurship. And no matter if the next steps will have the same branding or another new shiny one. Lean Startup moved entrepreneurship forward.

What are your thoughts about this? Am i right? Am i wrong? Hit me up on twitter

Until then, push learning forward,

– Andreas

[klinger-io]

AngelList is the NASDAQ of our generation.

It's fair to say that Angellist is the most exciting (web/mobile) tech startup in 2013.

Even before they launched syndicates, earlier this year, they were already heavily integrated into our startup ecosystem. They were (and are) mapping all relationships in an ecosystem that heavily relies on leveraging its social networks. Relationships like investor introductions, teams, jobs and even applications to accelerators. Needless to say this is already very big.

But since the launch of investments and syndicates there is no more stopping them. Right now it is hard for me to even imagine the potential ceiling that Angellist could face in the next years.

We are living in exciting times.

Investments changed in the last years. From long and slow processes to pitch event focused accelerators to single page applications like Kima15 of Kima Venture.

In the next years early stage investments will be closer to APIs requests or figuratively speaking going to an ATM than it is to our current investment processes, which very often still look like later stage VC/risk investments.

The future of early stage investments:

Application through Angellist, automatic due diligence through APIs, background check through social connections, in face meeting via hangout - boom money, here we go.

And Angellist is in the heart of all of this.

Angellist is the NASDAQ of our generation.

"The private market is at the stage the public market has been in the 80/90s" – Paul Singh.

Right now we are just seeing the beginning. Syndicates make it effective for investors to join the best rounds, and more importantly **syndicates make it easy for the upcoming waves of me-too angels to join the game. **

There are a few logical implications what might happen next. Here are my three predications.

1) Secondary markets

Sooner or later, given the legal complications – AL might transform into a real stock exchange. Why just buy your equity of startups. Why not sell it as well?

We have currently two interesting problems in startup investments:

Companies are pushed to exits (IPO, acquisition) to provide liquidity for the stock holders. And those exits often cripple the product ambition of a startup.

Not all of the startups of our generation will be optimal candidates for IPOs and exits. Leading to the need of alternate returns (evergreens eg). For some investors this fit. Some might want to leave a bit earlier.

Obviously (speaking as a laymen) this needs a few changes how we address stock of private companies or other special legal regulations.

But if there is a company that has the best position to make this happen it's Angellist. Angellist is the NASDAQ of our generation.

When will this come:

Given the legal complications and the fact that AL is still just a very small team i wouldn't be surprised if this will need a bit more of time or might come through a partner in the beginning. But me for me personally this is where i see AL's main role in a few years.

2) Onboarding of new me-too investors

There is a huge wave of late-to-the-game/me-too investors/wanna-be-angels coming to the market right now. These people need education and access to knowledge/experience, because – frankly speaking – there will be certain changes in investor types.

The "hollywoodization of startup investments" (coined by Paul Singh) creates an environment where the public persona or the social following of the investment leaders will be a more important factor than their investment experience. To normalize this, we need to education and onboarding of me-too angels. Accelerators for angels, Lean Startup Books replaced by Lean Investment books.

Currently I imagine a front-page explaining how startup investments work in reality and which syndicates or investors they should back for what reasons.

When will this come:

I don't believe AL will or even should build this. This would be sub optimal. They should offer affiliate/provisions to people referring investors and spawn an ecosystem of tools of this kind.

If you are working on a startup in this space - let me know - I am happy to add you here.

3) Spawning an ecosystem of market analysis software

If Angellist is the NASDAQ of our generation. Who is the Bloomberg? A lot of companies try to answer this question.

Most of them aggregate public data and try to generate information/indications out of it.

There a lot of companies in this space and also a lot of VCs build their own in-house tools.

But most noteable here are Mattermark and Indicate (Indicate was previously known as dashboard.io).

One might argument that Compass.co (by the guys of Startup Genome Project) belongs into this list. I personally would disagree with that assumption (Disclaimer: I am working with the team). The focus of Compass is to provide benchmarks and insights to the startup teams themselves and to provide aggregated (anonymous) information to the ecosystem. Which itself might be an even bigger opportunity (but this is another blogpost).

Mattermark, Indicate and co pluck into Public APIs like:

Traffic rankings (thus estimated traffic) from Alexa, Compete

Social activity from Facebook, Twitter, etc

Appstore rankings (thus estimated downloads)

Investor interest via funding informations from Crunchbase or Angellist

Press buzz based on press releases and media mentions

and other similar sources

But let's be honest… The data they currently access is very limited. And even more important - what kind of information can you really infer out this data?

"Yay, they gained 20 followers. Let's invest" – Said no good investor ever.

But it's not about exact information. It's about getting as many signals as you can. In a path of darkness even a small light in your hand is better than nothing.

And truth be told, while most of us people who work with analytics worry about accuracy or precision. In the case of monitoring private companies we are still in the situation of "any data is better than none".

If this doesn't convince you - here are a few reasons why i believe there is a big space for opportunities:

Reasons why these tools are useful: Analogy to public markets:

The images above is a service created by UBS - they monitor (eg.) Walmart's parking lots and by that estimate Walmart's customer traffic (and thus revenue).

This is not exact information. But hypothetically speaking if you would be interested in investing in a retailer - it would be good to know rough ranges of visits they have. Paul Singh has an excellent presentation on this you need to read

Reasons why these tools are useful: Social Signals:

Also there is more information in public data than one would expect. Eg the social signals in the interaction with startups is a good proxy for buzz. As an angel investor would you be interested if Jeff Clavier all of a sudden started tweeting about a startup that fits your target list? Well i would be very interested. Plus there is opportunity in comparing the patterns of buzz of early stage companies with historic data of successful ones.

Reasons why these tools are useful: Alerts:

For me personally the imho most interesting service is automatic alerts about new startups. "A new wearable tech company appeared in CEE. Their angellist account is two hours old. Their CEO used to run a bigger division at Nike and their Lead engineer has a strong arduino open source following on Github. One of their early followers on twitter is Tim Ferris." If you are into wearable tech you might want to take a look.

If you are interested in this be sure to subscribe to Nick O'Neill's awesome Startup Stats newsletter. He features the best kickstarter/indiegogo projects.

And there is a lot of more potential in this space.

Stronger focus on social signalling

Proprietary data sources

Monitoring crowd financing pages like Kickstarter and IndieGogo

Should you completely base your investment decisions on this kind of tools? Oh god no.

But it's a good way to compete with VCs who have an army of radar boys employed.

When will this happen:

It's already happening. Mattermark is currently leading this upcoming market. Indicate is catching up fast.

The main difference is that Indicate offers their insights/data for free and only monetizes on add-on features. This is a leap-jump, given the fact that any company that monetizes on access of information sooner or later gets disrupted by the Internet. On the other hand Danielle is top of her game and thinks far ahead.

The big obvious scary elephant that no-one talks about - is of course the fact that sooner or later Angellist might extend their Traction feature.

Asked at the Startup Stats Summit this fall Naval said clearly that he sees all tools as partners in this ecosystem. Well… We will see.

4) And many more predictions for Angellist…

I could name many more predictions for Angellist - like regional offices worldwide for Angellist, API Integrations for due diligence and verification, various of additional ecosystem players around etc etc - but I think you get my point. Angellist as a platform is the epicentre of an exciting market.

We are just at the beginning of this journey: Public fundraising, transparent startup markets, market analytics.

"Everyone in AngelList is on a 6-year vesting schedule" – Naval Ravikant

We are in phase one of the most important platforms of our generation of startups.

About my predictions

As with all predictions please take them with a grain of salt.

Example: After the launch of FB platform I predicted with 100% confidence that FB would introduce a currency and maybe mobile payments through their facebook mobile clients. And that skype will die. Several years later FB still sell ads and just to annoy me, they even partnered up.

Personal lesson learned: my prediction tend to be a bit too far fetched.

So don't wait for my "Early stage investment like an ATM" prediction to happen any time soon. ;)

That being said i would love to know your predictions. And I am sure you got good ones. Where do you see the meta-market of startup investments going to? Where do you see Angellists biggest opportunities? What could kill them (apart of the government)?

Would love to hear your thoughts - hit me up on twitter: @andreasklinger

Until then, continue being awesome and thanks for reading

Andreas

ps: This is written for a friend.

[klinger-io]

Drafting your first investment round.

The topic of investing is omnipresent in our startup world. Sooner or later most startup founders look for external funding. And it's great that there is already a lot of great advice on this topic out there.

The advice I want to focus on is a bit more fundamental.

It's about getting to your very first investment round.

Disclaimer: Like any advice, this advice here is just personal opinion based on subjective experiences put into some half-baked context. I would like to encourage you to peer-review this post and send me your change suggestions using this link on Draft or simply comment in this thread in Hacker News.

"Looking for angel investors"

The most common mistake I notice is that startups often begin looking for "angel investors". They go to networking events, local media, ask other entrepreneurs in their area . They ask around and try to see who in their direct or indirect network fits the criteria of an "angel investor" - people who have a track record or reputation of investing into startups.

Out of this shortlist they pick their favorites based on public success stories and reputation, and quickly start approaching/pitching them. If this doesn't work they lower their expectations and look for other wealthy people they know or at least know indirectly.

I acknowledge the tricky situation every fundraising entrepreneur is in, but the truth is that this approach values proximity and availability over quality and purpose. You need to be aware of that when walking down that path.

All of a sudden mobile-health startups have CEO's of marketing agencies as investors who - even if they are highly skilled business people - cannot create provide the most meaningful input possible apart of supplying cash in exchange for (very valuable!) control.

The method above also enforces a behaviour where the local "super angel" of your city gets approached by nearly everyone. Again, for the wrong reason.

A lot of people have money. However, this doesn't necessarily mean they are the best possible investors for your startup.

That being said it is advisable for the entrepreneur to go the extra mile and bang those doors, he knows he needs to get in, even harder.

I got the following advice from an investor in our last startup, and I have been sharing it ever since:

Draft your round

When you start raising your round, before you reach out to investors - sit down, and do the following to find the profiles of the best possible people to join you as angel investors:

First of all, split your company into its main aspects.

I usually take a pen and paper and draw a rectangle made out of 4 boxes. In each of the boxes write one of the core fundaments of the business.

Let's imagine you run a P2P yacht rental Airbnb-like startup. Rich people rent their yachts to other rich people

I am making this up on the fly. Sorry if it is either complete bollocks or, by accident, your startup ;)

Or let's imagine you are a "private cloud" hardware business and sell ready-to-go servers that provide Dropbox for local networks.

Your 4 core boxes would be:

Or imagine you run a mobile health business that measures your blood-pressure using the iPhone vibration sensor while you sit. (again... making this up the fly. But wouldn't be surprised if someone at Singularity University is already working on this.)

Fill the boxes:

At least one of the boxes should reflect a old-economy (or older internet generation) version of your business.

E.g. Car rental if you do uber. Ebay if you do mobile ebay.

One of the boxes should be related to your engine of growth. Think Community, Sales, SEM, etc - What is the core aspect of your growth.

I usually prefer to have one of the boxes to be a "startup experience". The person filling this slot will be someone who has done a few successful investments and can help the other investors with guidance and also back you up if the other angels, who are not so experienced with startups, are turned off by your strategies. Also this person will be very useful for your follow-up rounds, assuming you get to that stage.

Digging deeper

Let's define each of the fields in a bit more detail.

What characteristics do the perfect people have in those boxes? What kind of business person are they? What's their background, what kind of tasks did they achieve. Did they build the company? …or the mobile product? Did they do the Europe expansion or the R&D of the core product?

Sometimes you need innovators sometimes executors. Sometimes you want the old-school business guy, sometimes the crazy new product guy. But be specific about what characteristics the role needs.

Who would be the best people for your boxes? We are looking for the right people - globally.

Think TED talks, think universities, think nobel prize winners, think household brands, think old-school businesses that kinda did that one aspect but offline, look for established startups that are similar in that very aspect.

Hint: Look for companies that reflect the boxes you just named above without being potential competitors. People run into conflict of interest if your startup's product is too close to their own affiliations.

Advisory board

If you think that this is very close to a board of advisors than you are right. Your perfect first round of angels are people you would actually want to have as advisors.

Be careful with Strategic Partners

It is very tempting to get a very strong potential long-term growth partner as an angel. But usually this turns out to be a too strong commitment in a too early stage. Most properly you will pivot and no longer need that channel. Look for people and skills, not single ressources.

The goal of the angel is not to provide their distribution network, but to give you the insight and help needed to create your own.

Shortlist

Now start shortlisting the top10 people in each of those boxes. Look for people you would be honored to work with. Even if - in the end - you cannot reach those people, they provide a great mental picture, a benchmark of what you look for.

Reaching out

There is a the common saying:

If you ask for money you get advice. If you ask for advice you get money.

Therefore your first step is to meet them for skype or coffee. They are expert and feedback is all you can ask for.

After some time a mentor or advisor relationship might establish.

But even if it stays within this relationship of "just advice" - that's great.

Think that way: Even if they in the end don't invest money, their feedback and introductions will be worth a lot.

Look for people who help from Day 1

In my experience: If someone is overly protective about his skill/network or support he might not have enough of it to offer.

The right people provide value from Day 1. The right people help and network you from Day 1. The right people know they have enough value to provide and are very open with their support.

The round

In a perfect world you have a few weeks or month you work with those people before you open a round with a "lower" valuation, where they can participate.

The perfect round is with advisors willing and capable to help your business and have a downside if they don't (their investment).

Unfortunately we do not live always in a perfect world. But try to keep this as a guidance. Your goal is to close a advisory round, which benefits everyone.

Hint: Traction and scarcity closes rounds.

As with everything in startups, funding rounds are also defined by their traction. Try to have several of the alpha investors already committed before you open up the round to everyone else.

Hint: Valuations

Every experienced founder will tell you the same. In case of doubt pick the right people over the right valuation.

people > valuation.

Accelerators

In general I would recommend every first time founder to participate in an accelerator. They help avoid the most common mistakes and introduce you to an already built network of the great people.

Remember: Your goal as first-time founder is not to optimise potential. It is to optimise probability of success.

As with everything in the startup world, try to go with the best - ignore the rest. I dare to say that, in this power-law driven game: non-focused B,C,D or F-level accelerators can hardly provide any of the value they promise.

What about VCs?

Personally i would not recommend working with Venture Capital before you are getting closer to product/market fit. But opinions differ here.

There are two kinds of money

Money for proof (to find product market fit)

Money for scaling (to repeat customer acq.)

Venture Capital by tradition is the second kind of money. I would actually even go further…

I tend to think of VC capital as rocket fuel.

If you are ready the help you reaching the skies. If you are not it might as well blow up your company.

When you are not ready, they cannot play their strongest cards and their misaligned power and expectations can become straight forward destructive for your startup.

If you want to take VCs into your round, make sure that they also fit one of your boxes mentioned above. Look especially at the background of the partner working with you - VCs are people too. Additionally take a look at their other portfolio companies and make sure that there are synergies in experiences and competences needed.

Be careful with new funds. They are startups themselves, but don't know it.

Hint: Be careful with miss-understanding VC interest.

VCs want to invest as early (low valuation) as possible. Which from their point of view means as late (last possible moment, lowest possible risk).

A VCs needs to see you performing over time to make a real commitment.

The first time I meet you, you are a single data point. I invest in lines. -- Mark Suster

Summary

Never put proximity and availability over quality or purpose. Find the optimal people for your startup. Or approximate them as closely as possible. If you get people in just for the money no-one will profit in the end.

I hope this article is useful to you. If you have any questions please contact me via twitter. Also as mentioned this is article meant to be a peer-reviewed source for early stage founders. Therefore I would highly appreciate your change-suggestions via Draft or comment in this Hacker News thread.

Until then, all the best. @andreasklinger

PS: Thanks to @tamaslocher, @lfittl and countless others for adding their feedback!