Camping out: engineering intelligence for teams

On Saturday Nov 22, Ted and I had the pleasure of attending Boston Code Camp 39, which Flux sponsored. In their own words, from the Boston Code Camp website:

Boston Code Camp is a day of presentations by and for the Greater Boston and regional technical community. The Code Camp organizers encourage presenters to share a diverse set of technologies, and submissions by a range of presenters from new to highly experienced, and local to regional and national.

Because we sponsored, I was at our table for most of the day talking with people of all technical backgrounds, and then had a chance to give a talk during lunch (full talk below if you’re interested).

Dev-oriented events like CodeCamp are great. They remind me of small versions of developer community-organized, “by the developers, for the developers” events like PyCon US, or user groups like Boston Python and Google Developer Groups.

• People share real-world expertise: Talks are focused on things that matter to the participants. Everyone, including us as sponsors, are meeting folks where they are. Attendees are there to connect, learn from others, and hear the messiness of real life.

• They break up routine: Whether you’re working remotely or have been working with the same team/company for a while, it’s great to get outside your usual routine and have face-to-face interaction with people who understand your challenges. Every time I attend one of these events, I’m amazed by how non-unique my challenges are (whether technical, managerial, or strategic).

• They’re diverse: The event had a healthy mix of senior, mid-level, and junior folks. There was even a group of students from Curry College. It was fun to see folks from all different levels of experience interacting: asking questions, sharing what they know. This is all part of the “inclusivity by design” that’s part of the DNA of these kinds of events.

What did I learn through conversations at the table?

• Once I mentioned that we’re a small startup company, folks really opened up. They liked that we’re engineers building a product for engineering leaders and their teams, and that we’re in a stage where we’re able to listen and iterate quickly. This reinforced that authenticity and accessibility matter: people want to work with companies that understand their problems firsthand and can move quickly on feedback.

• We’re building Flux as a platform for engineering managers and leaders… and also their teams. Conversations at the event reminded me why we’re building Flux the way we are. It helped reinforce that codebases move forward thanks to the hard work of developers. They are indirectly entering data that we use in our analysis and evaluation—so they’re important stakeholders. We continue to focus on engineering leaders, who we believe are underserved in tools that directly benefit them, but we must keep building Flux to benefit the entire engineering team. The takeaway is that tools that only serve leadership can create friction; tools that serve the whole team get adopted.

• Toward that end, the developers I spoke with really got excited about our demo. They asked good questions about Flux’s purpose, and got particularly interested in the PR analysis/categorization because it surfaces issues like tech debt automatically, based on their actual work (the code) rather than the project management representation of it (e.g. Jira). Again, this matters because developer buy-in is critical—if ICs see value in what we’re building, they’ll become advocates instead of skeptics.

• The “building from the code up” nature of Flux really resonated with people. They’re familiar with tools that primarily pull from ticketing and planning systems. They liked that Flux starts with the code as the source of truth, which was especially evident in some of our more recent features like the estate-wide views. Starting with code means that we’re measuring what actually happened, not what was planned—and engineers understand and trust that approach.

• Generally, the conversations we had with folks validated the need for better engineering intelligence for teams. I heard the same “we do this, but we calculate it manually and it’s not updated often enough” refrain that I’ve heard in sales calls. The validation is motivating: what we’re hearing in sales environments is what folks are experiencing “in the wild.”

All in all, it was a great event. Check out my talk, and if you’re interested in learning more about what Flux can do, email info@askflux.ai to set up a call or explore our zero-setup sandbox environment.