OK, so you want to know more about me. Here is a manual on how to work with me. Keep reading.
During my last years in multiple companies, I found the following principles to help me navigate and guide product development, especially focused on growth and early success. It shows in a nutshell how I operate:
When there is a complex problem, I simplify it first - break it down into multiple sub-items. If the smaller problems can be clearly defined, are worth solving, and have enough data to back us up, I move forward with problem-solving and defining success.
I also understand that there are cases where data can't be collected, or data is biased. For those cases, I prefer to move forward with a quick decision that addresses the immediate problem while providing more light on the problem. A better fix can be applied in the next iteration armed with a deeper understanding of the problem.
I would in almost most cases prefer to launch a series of hypothesis tests, to validate it, before a asking development team to code a solid solution.
Soon...
Soon...
I'm always on Slack and am responsive in that format to anyone who needs me. I will send emails with Google Docs for complex topics or where more documentation (i.e. decision making over communication) is necessary.
For things that require response (as well as my expectations of response speed from others), correlate with the following: Call —› Text —› Slack —› Email —› Google/JIRA doc comment. If you need an answer and I haven't responded, ping me again.
I prefer to be pinged immediately in whatever way is convenient when I can speed something up, remove a roadblock, provide a tie-breaking vote, or share some knowledge from past research/features that might be helpful. I bounce back from interruptions quickly and provide the most value when removing obstacles for my team as efficiently as possible. My favorite type of 1:1s are those that let us bang out a set of decisions or topics in a short timeframe, whereas covering them in a group would be less efficient. I don't need to know the topics in advance unless you want me to think about them more deeply before the meeting, and I am fine with just a bulleted list without a ton of detail - the whole point is to move things along.
I also get value from periodic "check-in" meetings to find out what is going well and not so well for my team so that we can adjust our work styles to help everyone be happy and productive. I love to help people and will find a way to meet with anyone anytime that could be useful.
For group meetings, where some people co-located join from the same room while others only work remotely, it harms productivity and team dynamics. I prefer everyone to join remotely if key players are remote, but I recognize that that is generally impossible in the offices.
I am somewhat dismissive of the idea that we must meet in person frequently to be effective, and I will never say no to a request to be remote for pretty much any reason. I expect people will maximize the value of times when we can be together in person by using that time strategically. I consider periodic whole-remote-team meetups to be critical to the success of the company for retention and engagement, but also for alignment.
The larger the meeting, the more critical it is to have a set agenda, game plan, and expected outcomes. I am fine if that is not shared in advance as long as it exists and can be clearly communicated in the meeting and followed up on.