Have you ever felt insecure when starting a project? Usually, I feel excited, as it means a new challenge that I will face with other Lullabots. However, last year I had my first experience flying solo on a client project and, this time, I felt nervous. My main worries were:
- Do I have the required communication skills to transform client requirements into tasks?
- How can I avoid missing or forgetting things that the client says?
- How do I know if I am meeting Lullabot's expectations managing the client?
- How do I know when to say No to the client?
Being diligent in my note-taking and email communication would ensure nothing was lost in translation or forgotten so I could check off the first two concerns on my list. But the last two items on my list were more about me feeling that I needed external support; someone at Lullabot who could oversee my notes and tell me every once in a while "this is great Juampy, keep it up" or "Juampy, perhaps you could handle this in some other way."
Writing is something I love to do: I like to document my code, I like to describe my pull requests, and I like to take notes on kick-off meetings. Not only does this help the project, it helps me in the future because I have a bad memory. When I am in a cafe, I see waiters taking mental notes and, on their way to the bar, taking even more notes, nodding, and getting it right! I admire their memory. You can ask them "what are the orders?" and they tell you what every table ordered, with all the details. I can't do that so I take notes of everything that I do, or have to do, and then I turn that into tickets, calendar reminders, or TODOs.
In the following sections, I will share with you some of the benefits that I discovered by keeping a journal. Throughout, I will refer to some examples from the journal that I kept while I was part of the Module Acceleration Program.
Starting the day with a plan
When I start working, I spend the first minutes gathering notes from what happened while I was away by reading email notifications and chat logs. I also look at yesterday's notes to see if there was anything that I did not complete. With that input, I make a list of tasks like the following one:
Once I have a list like the above, I feel that I have a set of things to complete by the end of the day, which motivates me immensely. If I manage to complete them all (plus whatever else may arise), then it's time to celebrate. If I can't, then I will leave a comment underneath the remaining tasks that describes their status. I may also copy and paste these statuses into their respective tickets so the client knows my progress. The next day, I will continue working from there.
There are days when I don't get much done. With the journal, it is easy to go back and remember why—that something else happened such as "one of my teammates got stuck with a bug and needed help" or "we suddenly had to jump into a video conference that took too long." With these notes, I can see where the time is going and make future adjustments in how I manage my time.
Ticket writing
Countless times I have closed a tab by mistake while I was typing something and had to write it again. While there are some ticket systems and browser plugins that can restore your draft, others don't. Besides, some systems like Jira seem less natural and break up your writing time when, for example, you need to paste a screenshot (no, you can't just hit Ctrl + v). Both Dropbox Paper and Google Docs are great for writing a journal because you can copy and paste screenshots, add links, create TODO lists, etc., in a more seamless way.
While working on tickets, I suddenly started to write my findings and paste screenshots in the journal (especially on the tricky ones). Then, if I completed the ticket, I would use this material for my pull request to ease peer review. If I had to work further, I would copy my findings from the journal and paste them in the ticket so the team could see my progress. Here is an example from my journal, with some annotations that describe how I will treat the notes:
SCRUMs / Stand-ups
With the journal, it is very easy for me to share my status as it is just a matter of reading my notes out loud. I also use it to take post-SCRUM notes in the journal, which I use as follow-ups for my next tasks. Here is an example:
There have been times where I offered myself to lead a meeting since I already had some material in my journal that could serve as the agenda. In these cases, I shared my screen with everyone and took notes that could be seen and discussed in real-time. This approach proved to be a way to structure and provide leadership for a meeting.
Keeping your peers up to date
Betty Tran, Sally Young, and I did an on-site last year for a potential client. By the end of the on-site, we had two weeks to write a document that contained our project proposal. During these two weeks, there were many emails and shared documents sent by the client with data that we had to classify and filter to use it in the proposal. It was crucial to keep everything organized in an efficient way so I asked Betty and Sally to subscribe to my journal, where I would keep a log of all the events that happened every day with a link, each item linked to its respective document. Doing so allowed them to focus on writing the proposal and use the data without having to skim through email threads. Here is an example of how a day in that journal looked like:
Management likes it
My managers at Lullabot, Seth Brown and James Sansbury, realized that keeping a journal was a transparent and effective way to monitor projects. By subscribing to my journal, they get an email every day with my latest changes. Furthermore, I can mention them, and they will get an immediate email notification to help me by posting a comment. Therefore, they encouraged Lullabot Architects and others doing solo work on projects to start writing a journal.
For example, I subscribed to Dave Reid's journal, who is currently working on a project with me. Every day, I get an email like this with his updates:
This gives me a chance to support him and keep up to date with what he is working on. If I want to add feedback, I can open his journal and write a comment.
Conclusion
Try it for a week using a writing tool that feels natural to you. The less that you need to think about the tool, the better. Leave it open at all times and take all your notes in this one location. Eventually, you will either experience some of the benefits that I mentioned above or realize that you are like one of those waiters with an elephant's memory that I admire so much.
Thanks to Seth Brown and James Sansbury for your feedback while writing this. Also thanks to Adam Balsam for letting me share the journal that I kept while working at the Module Acceleration Program.
Hero photo by Barry Silver.