Geoffrey Woo API
The purpose of Geoffrey Woo API is to specify expectations and guidelines on how I best operate as a collaborator and worker.
Author's Note: APIs describe how to utilize a resource, and this documentation is written and maintained so we can be as efficient and productive with our time together as possible.
I wrote this initially for internal use and helping onboard new collaborators. This has been so efficient that I decided to expand it and open-source it for anyone to better engage with me and to inspire the reader to consider incorporating for their own use. Better communication between people ultimately leads to a better world.
Business communication is about the efficient transfer of context, state, and knowledge. Business communication is not about “niceness” which can reduce the fidelity of information transfer.
The ideal form of communication is telepathy, as it’s a 100% fidelity information transfer — including the transmission of emotion, intuition, and vibes behind a concept. Telepathy isn’t possible yet, so the next best way is to speak and communicate in a clear, direct way in a way that’s comprehensive but efficient; warm and generous in spirit, yet direct and clear in content.
Requests & Their Types:
Request for Context:
At the start of a new project:
We will spend as much time as required to get to a shared initial state of a project goal and context. If we have no shared understanding at the start, there’s no way we will be able to progress and learn together to achieve our end goal outcome, so we get to fully shared context at inception.
Ask as many questions as possible and front-load all doubt and uncertainty. As the workstream progresses, I expect new data and information to come in regularly as we work, and we will establish a cadence in which we mutually update a shared understanding of progress.
Projects inflight:
I don’t like to be approached with tactical/implementation-level questions because it is likely you, someone else on the team, or the customer has the answer. Please confirm that you cannot answer the question yourself before approaching me with a tactical/implementation question. Especially for implementation questions, this is equivalent to asking me for direct contribution, which should be engaged per below.
That said: there are no “dumb” questions. I’d rather answer a “dumb” question, then let you flounder. However, these questions should generally be captured in pre-scheduled 1:1 meetings or project/team stand-ups that are the forum for collaboration. If we don’t have either rhythm set up, it may mean that I am not close enough on this specific project anyways, and you should ask these questions to your more direct counterparts.
Discussion and questions should be focused on strategy, approach, and in-flight learnings. Good questions and discussions are insightful and valuable as we update our own internal understanding of the question with new info and nuance.
My goal is to eliminate low-level interruptions that distract me from my own direct commitments. Use your judgement when to escalate issues to an interruption. However, by default, let’s be rigorous by enforcing a process of explicit pre-planning and regularly updating our mental models in pre-scheduled, designated work sessions.
Request for Direct Contribution:
I am available to take direct ownership and execution of workstreams e.g. directly leading customer or investor calls, pairing on product or copy, or brainstorming in a workshop.
Be precise on your expectations of my direct contribution, so I can make sure deliver to your expectation. If I cannot, I will make it clear what I can commit to or cannot commit.
Corollary: Don’t implicitly delegate tasks to me.
Deliver end work product and fully formed concepts for me to review and digest. I do not have time to review call recordings or interpret loose notes, and in this case, I would often prefer to do the direct work myself.
Cold Request:
I am overwhelmed with cold requests from friends, acquaintances, and strangers for investment capital, employment opportunities, sales leads or partnerships, and/or mentorship.
My policy is simple: one can always ask for anything at anytime, but please do reciprocate the courtesy for me to respectfully ignore and reject any and all requests that don’t fit my current interest areas.
When I ignore a request, it may be due to my not seeing the request or that we may not have an underlying introduction or connection in which that I can respond to your request in a meaningful way.
However, all my best friends and business partners were at one point strangers, so if you think we might share interest, please do reach out. I recommend stating clearly: (1) who you are, (2) what is your goal and how do I fit into it, (3) why do you have credibility and unique insight in your field, and (4) why do you think I would re-allocate my limited energy with my existing commitments to engage with your request.
Other Best Practices
Like any good API, I lean toward accommodating errors and exceptions on others inputting to me, but maintain a exceptionally high standard and stringency for myself to deliver quality work product output.
In that spirit, please do let me know the best way you work and the best way you are able to receive information and listen to feedback. I am more than likely to oblige to your preference, as I ultimately want the best output from you.