If you want something to happen, write it down. One of the underrated skills that I have learned over the years of my career has been that if you don't write things down, chances are it will just be an ephemeral conversation you had in Slack or a meeting.
I will go through some examples of how writing has helped me, hoping to give you the value of writing from few different perspectives.
Writing for growth
The first type of writing I'd like to mention is for you. You are the author and you are the audience. It's like talking in the mirror.
I learned this from a mentor who shaped my early career (thanks Flo).
Write down point-in-time "development plans" for yourself. Don't wait for your lead, just write it down and put it on your wall.
In order to write a good development plan, you'll need to do some work:
- Gather feedback from your lead, your peers, your sister, and whoever else can give you valuable feedback.
- Put all of the feedback in a master doc. Highlight the parts that you find useful.
- Reflect on your feedback, read the highlights many times and discuss them in a 1-1
- Then write down the most important themes and what you would like to accomplish next.
- Print it, put it on your wall, and read it every time you lose track of "how should I grow".
Why is this useful?
- It gives you a roadmap for your growth
- It captures the expectations between you and your lead
- It records valuable conversation that you can refer back to (for performance review and what have you)
Can you share an example development plan? Yes, just send me a message or email
Writing to make things happen
The second type of writing I want to touch on is "vision documents". Author is you, audience is a team.
The book Making Things Happen has really great insight on how to write one of these:
- "Good vision documents never shy away from their core ideas. They avoid prefaces, disclaimers, and introductions, and they make no attempt to hide from the key (and perhaps controversial) decisions that will define the project"
- "Many poor vision documents I’ve read were large volumes that were intimidating not because of the sheer brilliance of thought they expressed, but because of their physical size. The intimidation worked: no one read the document"
- "If the end result cannot be visualized—even as just a sketch, a mock-up, or a chart—then I’d argue that the vision is not clear. If you can’t find any visual representation of the impact of the project on the universe, be afraid that it’s directed toward something the world doesn’t need, or that it isn’t well defined enough for you to be successful"
My personal take is that you need lots of practice to get good at writing technical vision documents. Some notable things I remember from my technical writing course at school:
- Use a decision matrix when in doubt about a decision
- Learn to do napkin math
- Get familiar with the basic of software project management (requirements, specifications, milestones, ...)
- Do your research - a good document is the result of carefully done homework
Writing for change
Lastly, I wanna touch on a type of writing that is useful for aligning people on what either you, you and your manager, or a group of people collectively think or want to work through. The inspiration for this type of writing came to me while reading the book The Everything Store, which gives an account of Jeff Bezos' business and management style. Jeff has called these writings "the smartest thing we ever did at Amazon".
To replace the PowerPoint presentations, Bezos created a new way to hold meetings: Meetings start with each attendee sitting and silently reading a “six-page, narratively-structured memo” for about the first 30 minutes of the meeting. [The memo is] supposed to create the context for what will then be a good discussion,” Bezos said. (source)
I've found that not every meeting needs this, and certainly not the exagerated "30 minutes of silence".
It's a special tool and there's appropriate times to reach for it. Some examples where I've found it useful for us:
- Snowballing individual thoughts into collective thought through a series of meetings
- Discussing a complex issue with your manager or a group of people
- Transferring historical context to a new manager, your skip-level