Put yourself out of a job. Imagine you are dead, what will the person who'll replace you need to know and have to do. Write that down somewhere. Imagine you lose memory and have to rediscover your job everyday: write a manual for yourself.
A colleague and I had to take over when the co-founder and CTO of a company we had joined a year and a half earlier quit without notice. One day, he just called in sick and then he said he was no longer with us.
We took over in the midst of major ongoing projects we were involved in in a technical capacity. We had about ten projects with large organizations at the time, and meeting lined up the following days to solve bottlenecks. There were no processes, the accounting was ad-hoc, everything was in his head. We had to consume thousands of emails, documents, contracts, and go over everything, everything, to prepare.
I took everything I could off the plate of my colleague who was an expert in deep learning. The first thing I did was to create an "Operator's Manual". i.e: a handbook that would enable my colleague, and potentially anyone in the company, to run that company if something were to happen to me.
That was a repository on GitLab that contained everything. I listed all the things that needed to be done: bank transactions, taxes, accounting, etc. and distilled them into a system that allowed anyone to do that.
I used GitLab because it allows us to write Markdown and has version control to track changes even in the Wiki feature, and that's what we use for code so we leverage our expertise instead of adopting a new tool, but the "Job to be Done" is to have information dissemination and be truly async. You can use Google Docs if you're more comfortable with that.
Meaning I literally wrote guides on how to pay taxes, with pictures of a cheque, where to put the amount, where to sign, what form to send, where to go to pay taxes including the GPS location of the building, a picture of the building, which floor to go to, which office in that floor, which lane in that office.
Every single time I had to do something, I wrote it down so it could be done by me if I forgot, and someone else if I couldn't do it.
When we onboarded people, I'd notice we'd go over the same things, so that was put into a checklist of the things to do when onboarding a new member so you don't forget to create an email address before they come in to work, for example.
When having practically the same conversations with new hires, that went into an onboarding document explaining our stack, the books to read, why they are good books and what they will teach, which tools to master, what we need them for, how our workflow is structured, etc.
I listed the bank accounts, the companies we were involved with, their bank informations, points of contact, etc. I wrote down how to prepare the invoices, created a LaTeX template, found out the laws that regulated that. Everything I did was to be put there so someone else could just pick that and operate the company.
The way I do thing is for me to be able to die without impacting the team. If you get over the morbid nature of that statement, you start seeing a lot of opportunities of things you could automate or make truly async. Something there for others to consult.
One of the problems we worked on was information asymmetry. We made sure everyone had access to all the information to make better decisions. I wrote meeting minutes of all the meetings we went to, with all the details, and put them on GitLab and gave access to everyone on the team so anyone can read them whenever they wanted. They could read client meetings, investor meetings, etc.
Here's our template:
# Minutes of Meeting
--------------------
## Date: 2019-03-25
## Place: BIGCorp HQ. City, State.
## Participants:
### BIGCorp:
- John Doe (jd)
- MeMyself I (mmi)
### OtherCorp:
- Dilbert (db@othercorp.com)
- Dogbert (dg@othercorp.com)
## Topics:
- Scheduled information sending
- Information flow
- Architecture for Project X
## Details:
OtherCorp has raised some issues for the timeline of Project X...
Blah blah blah.
## Actions:
### BIGCorp:
- [ ] @bc: Send project X estimates by 2019-03-28
- [x] @bc: Send invoice and cheque for offices remodeling
- [ ] @mmi: Add different schemes for user authentication
- [ ] @mmi: Finalize migrations so we take into account user's timezone
### OtherCorp:
- [ ] @oc: Expose API end points for user's identity verification
- [ ] @oc: Cache the results of the most common queries
Here's an excerpt from the reply about keeping up with information:
====BEGIN===
There are a few tricks:
Todo/Note dichotomy:
--------------------
Doing away with "todo" and "note" dichotomy can be useful. I use TaskWarrior[0] to add "tasks", but also "notes". I have them organized in projects, tags such as +musing, +engineering, +read, +watch, etc.
I'm watching an interview of someone relevant and they mention a book?
task add +read "X book mentioned by Y in interview with Z: youtube.com/..."
The dump of these notes formed the seed of our company's knowledge base and it continues to feed it and refine it.
The tasks are in a `.task` directory that is a repo. I have an alias to push them:
function tupd() {
git -C ~/.task commit -a -m "Update tasks $(whoami)@$(hostname)"
git -C ~/.task push
}
I can pull in my tasks and notes from my devices. I can search them by tag, by project, by word or regular expression. You can set due dates, start dates, etc. So you set three or four important tasks for the next day. It will sort them by an urgency score. It is one of those tool you could get started with using one command, but you can do a lot of things.
If you're working on a project, you have a nice knowledge base consisting of book titles, articles, interviews, talks, remarks, ideas, etc.
I have a script that exports work related notes into Markdown and pushes to a temporary repository for all my colleagues to see. Then we transfer that into proper issues, or our knowledge base.
===END====
Again, I use TaskWarrior because it allows me to do things in the command line, and I push things to version control in GitLab, and everything is in plain text, but the "Job to be Done" is to quickly capture insights, knowledge, and tasks and disseminate them.
For the product we're developing, I regularly send updates to everyone that explain what we're doing, why we're doing it, what we'll do next and why, and why I believe this is the best approach given the constraints/tradeoffs/objectives. Everyone can poke holes in them or chime with their opinion, from our advisors on a strategy level, to my colleagues on technical or product input in case I missed something. This enables people to be clear on things and unlocks individual initiatives.
Management is tied to the person, really. Some get it right very, very, often. Others need a talk because they veer off.
One other way I look at it is that I'm firing myself. I'm putting myself out of a job as I try and make sure to capture everything I can there. This institutionalizes knowledge and anyone can do that eventually, and I can do something else. When we have hired for a person to deal with that, we have them the handbook and they didn't miss a beat. They knew what to do with practically no training. They've been augmenting it with the things we have learned, tricky transactions or export procedures, etc.
Here are a few things I wrote in here that could be useful. They are designed to improve remembering to do things, doing things, learn from doing things, make sure everyone knows what they should be doing, remember why we're/if we ought to be doing things in the first place, and doing the right things. You can skim over the "tech" replies and go over "making the most out of meetings, leveraging your presence", or "product development", "giving a damn", "If I disappear, what will happen", etc...
Also, a book I highly recommend is "High Output Management" by Andy Grove.
- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)
- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)
- https://news.ycombinator.com/item?id=22827841 (product development)
- https://news.ycombinator.com/item?id=20356222 (giving a damn)
- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)
- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)
- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).
- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)
- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)
- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)
- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)
- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).
- https://news.ycombinator.com/item?id=24177646 (communication, alignment)
- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)
- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)
- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)
- https://news.ycombinator.com/item?id=25922120 (researching topics)
- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)
- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)
- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)