How do you deal with mental switching between projects/clients/areas?
What&#x27;s the outcome of this all?<p>I&#x27;ll talk about doing that in the context of a crisis and change the underlying problems of being on too many projects without a rewarding outcome.<p>Analyse everything. Figure out patterns. Remove friction. Track everything. Document everything. Disseminate information to everyone. Do post mortems. Fix underlying problems upstream. Don&#x27;t mop the floor, fix the leak in the pipe.<p>We&#x27;re a boutique machine learning consultancy. At one point, we had about ten projects. This has caused the CTO and co-founder to quit. A colleague and I stepped in to take over because we had meetings lined up. We had to go over everything for the projects. Emails, bottlenecks, blocking points, contracts, payments, invoices, legal. We were only on the technical side.<p>We scrambled to ensure continuity. I had to learn a lot of things and I documented <i>everything</i>. By everything, I mean how to write a cheque to pay taxes, where to write the amount, a picture of the cheque, where to take the form (GPS coordinates, picture of the building, floor, description to get to the right clerk). The first thing I did was to write an &quot;Operator&#x27;s Manual&quot;, so anyone can operate the business if I were to disappear. I took the most I could take of this process to enable my colleague to focus on the machine learning side because that made sense from a comparative advantage standpoint.<p>We examined all the things that were working and were not working and figured out why. For example, we did post mortems on all the people who quit or whom we let go and classified them into categories of &quot;went well&quot;, &quot;went poorly&quot;. We found that one of the issues was information asymmetry, and did everything to reduce that asymmetry to the minimum. I took notes for every meeting we took for every project, came up with a Markdown template (see below), and made sure everyone knew what was going on in meetings they didn&#x27;t attend. We set out to maximize information dissemination so people can get the full picture. We found out we were going over the same thing with new hires, and we wrote onboarding documentation to make it as smooth as possible, preparing their access rights, their machines, and making them successful on week one.<p>We systematically examined every aspect of everything we were doing, and we set to remove friction to getting things done.<p>I had a Markdown file with every project, who was on it, what its status was, what were the next actions, what was blocking, etc. Every day, we went through it sequentially. Talking with everyone on the team. Then had an alias for my todos, showed it to my colleague to track things which he adopted, then he found TaskWarrior and showed it to me, which I adopted. Tags, projects, due dates, etc. I push the files to a repo and have a script to export to Markdown to push pending tasks to a repository accessible by everyone.<p>That formed the basis of our knowledge base.<p>We shut down zombie projects. I didn&#x27;t hesitate to pull the plug on a project I was the main contributor on for almost two years that was going nowhere.<p>We examined every relation with every prospect and every client, and figured out patterns of projects that went well and projects that didn&#x27;t go well. We made decisions based on that not to pursue relations with certain prospects that didn&#x27;t fit a certain profile and changed the way we do business to detect red flags early on. For example, many of the prospects we talked with had a point of contact who had no decision power. We stopped doing that. Many prospects did not want to give us access to domain experts and only wanted their executives to be involved. We stopped doing that. Many prospects wanted us to do machine learning but did not provide with people who handled data, or did not want to talk about their problems with data. We stopped doing that. We mitigated that upstream by putting that on the table early on: get people with decision power to the table, get domain experts to the table, get the end users to the table, get the stakeholders to the table. We started explaining why it was necessary to do that, and we had a much, much, higher survival rate and conversion.<p>Then we looked at all the machine learning projects we have been doing, figured out the patterns and the problems that made them so slow and expensive, and we set out to build our machine learning platform to solve these problems.[0]<p>So, we&#x27;re talking with fewer clients and working on fewer projects, delivering value with fewer people, and the outcome is much, much better. Higher survival rate.<p><pre><code>  # 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&#x27;s timezone
  
  ### OtherCorp:
  
  - [ ] @oc: Expose API end points for user&#x27;s identity verification
  - [ ] @oc: Cache the results of the most common queries


</code></pre>
- [0]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25871632" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25871632</a><p>- [1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25244246" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25244246</a>