How to build a simple system around a soft objective
The Neosavvy team recently made the mid-year’s resolution to attend more events in the vein of networking and community development. Sometimes, when you’re steering the submarine, you forget to come up for air. We’ve been a little like that with our work. “Community development can wait.” That is, until you have no community in which to grow.
If you ask most software developers what they like best about their jobs, I think software community(ies) would register as a notable bullet point. In-person networking has always been my favorite. Software developers also build great relationships through digital channels, open source projects, educational hubs, and comment threads. It’s hard to find a field of work where your implicit connection to a larger group is so guaranteed.
The Community Goal
We developed the accountability floor of one community event per month, per teammate. To date, everyone has outperformed that goal. It’s no secret that New York has a wealth of great tech, business, and interest-group events. Like restaurants, you could spend your life trying to visit every one.
Our team is spreading out and visiting different events each week. Ideally, one team member per event. This constraint forces us to talk to new people and get out of our skin. When you travel in a pack it’s much easier to stay that way.
To get started, we had Sushindhran Harikrishnan compile a list of Meetup groups that appealed to our business and our interests. From there, anyone is welcome to join additional groups that fit their schedule or interests.
Consumers < Contributors
As a practical matter, we’ll learn more if we can actually contribute. Not only do we have knowledge to share. We also want to practice public speaking, training, and creating presentations.
If not actual presentations, we’re happy to provide an environment where junior developers can meet us in a low-risk (read: non-interview) environment. My career was shaped and directed early on by a few kind souls that gave their time and wisdom. Software interest groups are well tailored for those newest to the field to develop a network in a venue that is much more supportive rather than interrogative.
The big question: Where should we contribute? It’s not an easy answer when there are hundreds of meetup groups available. How will my teammates know that I just attended a really great presentation on subject X? How will my teammates know that I just attended a really boring event around subject Y? How do I know if my teammates have recently attended groups I would like for subject Z?
What we need: a system
The Rating Survey
Adam Parrish had the bright idea to make a standard post-event survey. Although you can choose any platform you like, Google Forms worked very well for us. Google Forms is great for this kind of data collection. Form surveys are easily exportable to spreadsheets. Spreadsheets are helpful for sorting, filtering, sharing, or expanding our use case. As the archive grows, it will help us to answer questions for teammates for business development goals. For instance:
“I need to geek out on some cool stuff for an evening, any recommendations?”
“I’m working on a new presentation, would love to practice it and hone the talk.”
“I’m pretty tired.”
We’ve solidified the metrics that are important to us. Different things may be important to you. The exact mix of metrics are not what’s important. It’s that you’re actually collecting them. It’s that they’re meaningful to you or your organization.
We’ve standardized the ratings to 1–5 scales and Yes / No questions. The exported spreadsheet is much easier to sort and filter. The survey is fast enough that we can fill it out on our phones before leaving the meeting.
Our objective
Soft objectives are great, but they’re also the hardest to manage. “We should do more community events.” Sounds like: “I’m trying to lose some weight” — “I’m trying to quit [INSERT BAD HABIT HERE]” — “I’m planning to take more time off work.”
People need systems, accountability, a way to measure the things that they actually want to do. New things are hard, that’s why it’s easier not to do them. Doing new things with no goal, no accountability, or no retrospective tools ensure that you will not do them for long.
We wrote no code. We spent no money. We got everything we wanted.
