What they can learn from us and what we can learn from them

1. Startups & KM:
What they can learn from us
and what we can learn from them
Andrew Gent
January 2018
Copyright 2018 by Andrew Gent

2. 2
Disclaimer
• The following presentation is based
on personal experience.
• It does not attempt to be scientific,
objective, or representative.
• It does tell a story and aims to see
what can be learned by observing
knowledge management “in the
wild” as a volatile early stage
startup grows into a sustainable
business.

3. 3
Agenda
• Understand the role of KM in
startups
• See what they do well and don’t do
well
• Determine where in a company’s
evolution KM becomes a “thing”.

4. 4
Our story begins...
• I joined a startup eight years ago as
the ninth employee.
• I was hired as a technical writer and
information architect, not as a
knowledge manager.

5. 5
The environment
• Small agile startup
• Inside larger, older startup.
− Startup A: 9 people
− Startup B: ~60 people, 5 year head start
StartupA
StartupB

6. 6
First discovery
• Half of Startup B did not know what
the other half was doing.
• But I did.
• How could that be?
StartupA
StartupB

7. 7
Questions
• At what point in the lifecycle does a
company need to think about KM?
• Where do knowledge “gaps” come
from?
• How do you (or can you) avoid
them?

8. 8
No answers
• Not a scientifically significant sample (1)
• Not complete (8 years, 9 40-50 people)
• Observing small companies is easier than
evaluating large, complex corporations.
• They teach you surprising things.
But...

9. 9
Stage 1: Startup
• Few people (1-15)
• Everyone involved in everything
• Knowledge sharing is everywhere

10. 10
Stage 2: Growth
• People: 20-30
• Roles emerge
• Division of labor
• Sharing evolves
− Email
− Chat
− Meetings
− Wiki

11. 11
Stage 3: Business Focus
• People: 30-50
• Roles & titles
− Engineering
− Marketing
− Sales
• Physical separation
− Locations
− Offices
− Meetings

12. 12
Stage 4: Drive to Profit
• People: 50-???
• Organizational separation
• Knowledge separation

13. 13
Implicit KM: Pros
• Low resistance
• Trial & error
− Willing to try anything
− See a problem, solve it
− Simple is best. Don’t boil the ocean
• Willing to change horses midstream
− 2 email servers, 3 messaging apps (Aim,
HipChat, Slack), 3 code libs, 3 forum
solutions, 4-5 web CMS…
− (Last one is exception to the rule: expensive)

14. 14
Implicit KM: Cons
• Impediments:
− Division of labor
• Logical/physical separation of organization
• Different goals, expectations, needs, language
• Different definition of knowledge, artifacts, formats
− Physical separation
• Geography
• Offices
• Floors
• Walls
− Good news
• (I’ll get back to this)

15. 15
Implicit KM: Surprises
• Geography is not a major
impediment. Floors & walls are.
• Like agile development, simple &
focused is best.
• Go with what works.
− Don’t be afraid to change
− Accept multiple technologies
• Exception: marketing website
(but that is a separate story)

16. 16
Observations
• On the Positive Side:
− Proactive communication
• Monthly/Quarterly company meetings
• Personal intros
• Clubs, activities
− Fast decision making
• Focus on one problem at a time
• Multiple competing technologies are OK
• Design-as-you-go
• Change directions quickly

17. 17
Observations
• On the Negative Side:
− Loss of history
• Employee turnover
• Changes in strategy
• No one remembers why X happened
− Stale data
• Abandoned processes, abandoned data
− Good news is a bad thing (for KM)
• Plan: Communicate from each organization
• Result: Urge to give a good impression
• Outcome: loss of “real” info

18. 18
2018, 0%
2017, 15%
2016, 14%
2015, 17%
2014, 12%
2013, 14%
early, 27%
2018
2017
2016
2015
2014
2013
early
Example: Wiki
• Old Data:
− Approx. 1400 entries
− 70% more than 2 years old
− 27% more than 5 years old

19. 19
2018, 4%
2017, 28%
2016, 4%
2015, 4%
2014, 4%
2013, 4%
early, 52%
2018
2017
2016
2015
2014
2013
early
Example: Wiki
• Top-level:
− 25 topics
− 64% more than 2 years old
− 52% more than 5 years old

20. 20
Example: Wiki
• Old Data: Orphan or Archive?
− 2015 Holiday schedule
• Admin/marketing now uses DropBox
− Example apps
• Links to old, deleted, repository
− Draft blog posts
• Pointers no one maintains
− Design & Planning
• History of what was built, how and why
− Infrastructure
• Current state and how to setup & maintain systems,
accounts, etc.

21. 21
Example: Wiki
• New Data
− What’s New In…
• Current development plans
− Retrospectives
• Record of work done
− New Developer Intro
• Instructions for new employees
• Why?
− Tied to existing process:
• Planning and Review meeting output
• Each new employee updates the intro

22. 22
Conclusions
• Communicate, communicate,
communicate
• Tell the truth: good and bad
• Keep it simple/focused
• Don’t be afraid of change…
• ...or multiple technologies
• Tie data to existing processes

23. 23
Conclusions
• Watch out for small changes
with big impact
− Organization structure
− Seating chart
− Kitchens, etc
− Floors and walls

24. 24
Suggestions
• Don’t say “KM”
− Yet another organization
− Separates knowledge from work processes,
ownership
• Proactive leadership
− Not just sponsorship
− For small orgs, leadership is key

25. 25
Suggestions
• Catalog of knowledge
− Each org lists its information “sources”
− Example:
Engineering Wiki, github
Admin, Marketing DropBox
Sales SalesForce (restricted)

26. 26
What Next?
• Still haven’t answered the question:
when does KM become a “thing”?
− 100 employees? 200?
− When CoPs break organizational boundaries?
• How to break the job/role barrier?
− Division of labor is necessary, but also divides
knowledge and communication
− To bridge that gap, must tackle differing
perspectives, terminology, goals, locations, etc…
− There may be a simple solution. (Seating?)

27. 27
Questions?
Contact Info:
Email: ajgent@yahoo.com
Blog: http://incrediblydull.blogspot.com/
Website: http://www.radiopoets.com/
Twitter: http://twitter.com/AndrewGent