ao

This week was about reviewing how I handled multiple ongoing projects before. I don’t know if it’s mom-brain or aging, but I can’t seem to access memories of how I could keep track of up to 12 web development projects day-to-day, or orchestrate work across four build squads 😅

Based on my analysis, though, some current factors:

• Remote work relies on pure documentation, unlike in-person work that has “ambient” or passive knowledge transfer
• High-velocity/ Growth-stage start-ups function differently from conglomerates and legacy corporations.
  • Some stark differences (I’ll just contrast these two types, first)

	Conglomerate	Early-stage start-up
Rate of market/ directional change	1x / 2-5 years	1-2x/ quarter
Communication target audience	75% leadership (of varying levels); 25% working team	90% working team; 10% leadership
Communication goal	Buy-in and awareness	Action and day-to-day operations
Format	Presentation-leaning, with some tables, but ideally simplified	Long-form and spreadsheet-based
Scope of projects	Multi-business unit; multi-layer; multi-stakeholder	Facets of a complex process/ product that cohere into a service experience

What did my review bring up for me?

Documentation styles

The high-level Gantt chart: My earliest form

• Heavily inspired by working with product managers
• Also the most basic
• Info architecture: Clustered by Product category; and split into the development components
• Team type/ style: Assigned project managers to individual build projects

Experiment roadmap: Mandate/Team with a discovery bent

• Challenge here was to somehow convey decision opportunities, and emphasize that direction is for validation (experimental)
• Other considerations: Also needed to be simple enough to communicate to a team that was trying to absorb a more experimental mindset, and lightweight enough to maintain
• Info architecture: Goals and assumptions, experiment -> timeline
  • with “experiment cards”: What are we trying to learn; what are we watching out for + eventual result

Product-stage tracker: Likely the least effective – from a corporate comprehension standpoint, though one I personally liked (Which is a lesson in “You are not your user.”)

• The point I was trying to make here was that there were 7+ workstreams, where I wanted to emphasize — not the timeline — but the stage-goal we were working on
• Data points: Product/Functional component, Stage, Latest activity/ Highlight
• This was definitely more qualitative. Theoretically, I wanted people to know the “real state” of the product on one page, and not just a date, or signal. But, I don’t think that worked for a team that was familiar with/ was probably subliminally expecting a Gantt chart or traffic light chart
• Lesson learned: Meaningful is fine; but don’t make the goal a blocker to comprehension.

Comprehensive but high-level status tracker: An attempt to have holistic information

• At this point, I was dealing with less workstreams, but in a faster-paced environment with quicker “status” changes throughout
• We made this more time- and stage-based.
• The best version being one that showed “stages” rather than weeks, and each stage could “light up” or be checked off, once it was hit, per product line
• For a few quarters, I attempted to add metrics and scale/ coverage

Do I have a conclusion?

If I were to draw one now, it would be to just use the most straightforward one, and use it as a tool for discussion or further documentation.

My impression from reviewing everything I had tried was that I was attempting to convey many points at once – which can be nice for “info visualization”, but not for actionability.

Originally posted on Ghost as Weeknote, June 21: Cross-project monitoring, a mobility workout, and my favourite career inspo blog post.