Workflow

Introduction

This post discusses my daily workflow. I am sharing it in case it is helpful for others to read.

Starting the day

• Read unread emails and unread Slack messages. Respond to everything.
• Check personal goals and their progress for the year.

Gutcheck work

• Review each project's motivation, goals, "secret sauce", current status, and timeline to finish. Do they make sense?
• Heilmeier Catechism
  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?
  • What is new in your approach and why do you think it will be successful?
  • Who cares? If you are successful, what difference will it make?
  • What are the risks?
  • How much will it cost?
  • How long will it take?
  • What are the midterm and final "exams" to check for success?
• Writing papers
  • What problem are you solving?
  • Why is it an important problem?
  • What are the existing approaches? Why are they not sufficient?
  • What is your approach? Why is it more effective, efficient, novel, etc?
  • How do you implement it? Why is that a good and practical way?
  • How do you evaluate your approach and system? Why is the evaluation fair and realistic? How do the results support the goals and claims of your approach and system?

Coding

• Work on code for each project.
• Automate linting and unit tests via Github actions.

Write Proposals

1. Create an overview diagram of what the system will look like. What happens first, second, third, etc. in the pipeline. What is the input? What is the output?
2. Write & submit an abstract describing the solution.
3. Fill in the front and back matter on the proposal. Now you know how many pages you have to work with to write the technical content.
4. Create a real-world motivating example (1-2 paragraphs) you will use throughout the proposal.
   • This is a framing device to go back and talk about how the solution will handle each challenge in the motivating example.
5. Split the system into components (which should already be apparent by the diagram) and assign engineers to tackle each part.
6. Make sure you include the exact metrics the BAA is asking for and say your solution will accomplish them.

Leadership

• Break each project down into 2 or 3 parts, and assign each person one part to own.
• For each project, have an end-goal in mind and an end-date. I.e., what specifically do you want to accomplish by when?
• Everyone self-updates their progress for you to present at status updates, as well as allows you to ask and answer questions there (an internal Google Doc).
• For each status update, create slides and meeting meetings (shared with the client). Have action items they agree to (ranked by importance) for the next meeting.
• For each status update presentation, create ~6 slides to share with the client. That way, it is easy for them to track your progress over time.
  • Agenda
  • Running list of Insights and Contributions
  • 2-3 updates (visual/graph/numbers of results)
  • Insights for each update -- What did I learn? What is novel/interesting?
  • Next steps -- From what I learned last week, what will I do this week?
• If you are away on leave, assign someone to lead in your place, and notify the client who the lead contact will be until you get back.
• Overspend on the front end of a project, so you can get far enough along that you can divert your attention if needed (e.g., a proposal needs your attention or you have meetings/trainings/other responsibilities to take care of later).
• Every time there is a problem or something does not go according to plan, ask the Five Whys (from The Lean Startup book). Ask "why" 5 times, and you will usually identify the root cause of an issue. Fix the fifth (final) "why" first, then fix the other "whys" if they pop up again. Blame the problem, not the person. If someone makes a mistake, it is our fault it was easy for them to make that mistake.

End of the day

• Work on the draft of academic paper or client report
• This is an up-to-date version of the final draft. The weekly meetings serve as snapshots of the final draft, so you can track the evolution of the project.
• The story for the project (motivation)
• Outline the evaluation (how you will measure success)
• Fill in results as you get them each day (if you were successful)
• Working on the final draft of the paper or report helps you not leave things until the last minute
• Save filling in the rest (introduction, related works, discussion) until the week before you submit
• Two days before the deadline, every co-author should have read the final draft and made comments/edits
• Leave at least 30 minutes at the end of the workday to read blog posts, papers, and saved Slack messages.

Fridays

• Read academic papers.
• Do various trainings and plan lunch-and-learn presentations.

Retrospective

• After each project is finished, do a retrospective for lessons learned.
• What went right? Why did it go right?
• What went wrong? Why did it go wrong? What will we do to prevent this in the future?