Once every month we get together as a collective group of Web Chefs for a video meeting creatively called “Team meeting.” The purpose of this meeting is to have all-hands discussions or to share company news and announcements.
I lead this meeting and find myself contemplating the agenda about three days prior. It’s always a meeting I take very seriously – everyone’s time is valuable, so I want the meeting to feel purposeful. I also value the opportunity as the meeting’s leader to inform, incite input from, or inspire the team. In preparation, I think and rethink about the agenda and facilitation of the conversation a lot.
This past week was a bit different for me. I didn’t have the time to prepare as normal and found myself finalizing the outline of the conversation I hoped to have within half an hour of everyone dialing in.
I had three goals to achieve during the call:
- Encourage the team by sharing the progress we’d made against the company action items identified during our January retreat.
- Remind the team to contribute to and participate in the newly-created GitHub repository for action items associated with improving parts and pieces of the business*.
- Prepare the team for participating, as stakeholders, in an upcoming big conversation about solving pain points we currently experience as well as predicted pain points we may experience as we continue to scale.
To achieve the third goal, I revisited the notes from our January retreat which documented the conversations shared about solving current needs. It was a long list of ideas and action items. As I read the list aloud, reminding everyone of the work we have yet to do, my heartbeat got faster.
“Shit! You idiot! Here you wanted to have an encouraging conversation today, and you’ve just gone and deposited a turd in the punchbowl.”
In my lack of preparation, I’d not done a thorough job of identifying how best to wrap the meeting in a cohesive, honest and purposeful manner.
“Do I leave the turd in the punchbowl? Do I talk about the turd?”
What came out of my mouth next was off-the-cuff and real in that it was reflective of the deep thinking I find myself doing as I contemplate what it means to run a company like Four Kitchens**. I’ll paraphrase it here and expand on some ideas shared:
Having a long, ever-evolving backlog of company action items and problems to solve is not a sign of a broken company. Instead, it’s a sign of a business that is alive, lively and well.
It’s this reality that forces another: In order to be satisfied working in a business or doing a job that is otherwise-never-ending, one must enjoy the process of solving problems and identifying new ones. I think this applies to those in roles that are responsible for the business’ wellbeing as well as those which are responsible for creating code.
And, for me, if the to-do list is never finished, the experience of the day-to-day better be fun.
This makes me want to ensure I’m doing my part to encourage the balance at Four Kitchens of taking the tasks at hand very seriously (because without dedication and a sense of purpose at work, what’s the point anyway?!) while enjoying the ride. I’ve not yet figured out how I want to do the following, but I think it’s important to:
- Encourage levity and boosting of each other’s moods. I wholeheartedly believe there’s a place for silliness, playfulness and joy in the work day. Laughter and blips of lightheartedness bring relief to the body’s system, something we all need in the mix of stress management.
- Encourage good communication. Interpersonal communication challenges deflate the sensation of fun. I’d like to work toward encouraging mindfulness around others’ communication styles and having graceful, respectful conflict.
So, I guess the moral of the story is the turd wasn’t really that gross in the end; just a sign of a healthy digestive process. Doing well as a business, doing well as a contributor to the business, means having a living, breathing list of problems to solve and an appreciation of the problem-solving process. And for me, the appreciation of the problem-solving process is enhanced by actively enjoying those who I work with to solve problems.
- Anyone can identify a problem, submit it as an issue in the repository and move it forward through our decision-making process to reach solution. Here’s our decision-making process, a newly codified structure for the “how” in solving problems that’s helped us facilitate internal change:
- Identify the problem
- Define the owner, stakeholders, and deadline
- Propose possible solutions
- Get feedback from stakeholders
- Consider feedback and other input
- Implement a solution
- Validate success
- Iterate if needed
**Constantly. This is what I always think about.