Core tech as a cinematic experience: how Mavenlink’s platform team stays on target while having fun.
“Our goal is captured by our motto: we’re giving superpowers to our other dev teams.”
— Alan Wong, Software Architect
While developing product capabilities for customers, engineering teams also need to nurture their own productivity. Whether built, bought, or downloaded, the technologies used by dev teams have substantial impact on how well they can serve their customers.
While evolving our technology is a team-wide effort at Mavenlink, we’ve also — like many engineering organizations — established dedicated teams chartered with advancing cross-cutting technologies. The team affectionately known as M7 is one such team, mainly focused on our server-side tech.
Today we’re talking with three core members of M7: Senior Product Manager Nate Gilbertson, and Software Architects Alan Wong and Shirish Pampoorickal. Together, they discuss the goals of the team, how their work impacts Mavenlink’s R&D organization at large, and how to make a gripping movie about upgrading Rails.
JB: Good to talk with you guys today. You’ve all been core members of M7 since its reforming just over a year ago. Tell us a bit about the team — what are your goals, and what’s the team’s focus?
Alan: We have a team-driven, collaborative approach. Our goal is captured by our motto: we’re giving super powers to our other dev teams.
For M7, our customers are other developers. We work on cross-cutting technical issues that impact multiple teams. We identify pain points that other team members surface through various channels, such as surveys, or our weekly cross-team forum meeting. We gather these items, regularly discuss and prioritize them, and find ways to work on them ourselves.
We also find ways to work alongside our product teams, working with them to evolve and upgrade common infrastructure.
Nate: Adding to what Alan was saying about giving our engineers superpowers, we want to take on projects that maybe wouldn’t fit with a typical product team — maybe because it is large and cross-cutting across the application, that means it is something that we as a team are going to be able to take on.
But we work on projects both as our own team, as well as collaborative projects with product teams to get their expertise on a specific area as well. So there are cross-cutting projects, as well as product-team-specific projects, that we execute collaboratively with a product team.
Shirish: M7 is a cross-cutting technically-focused team. We avoid being prescriptive. Our goal is to partner with other teams to develop a robust, reusable, maintainable and flexible technology stack. We look for opportunities to pair in with other teams to either build a new framework or leverage an existing framework with a hope of expanding its functionality and usability. So it’s a very collaborative process.
Our primary goal as a team is to increase developer productivity, and that might entail upgrading frameworks and libraries every now and then. Even though upgrades can sometimes be a painful endeavor, it is all about enabling our teams to use the latest features we get from these upgrades.
We also keep an eye on security issues. If there’s any security issue that arises from either our frameworks or libraries, we are on top of it. We try to fix it so other teams can focus on building features and they don’t need to specifically worry about that stuff.
“We put together a video that’s just a train montage, playing on the theme of ‘Rails.’ We had one of our team members narrate it, and we all collaborated to put together the script in order to communicate the value externally outside of the R&D organization.”
— Nate Gilbertson, Senior Product Manager
JB: That sounds great. Platform teams sometimes earn the dreaded “ivory tower” label, and end up building architecture-heavy tools that maybe aren’t really what their organizations need. How are you ensuring that the work you’re doing meets the real needs of our engineering team?
Alan: We strive to stay in touch with “real world reality.” We put the needs of our product teams front and center, as opposed to going after cool projects that don’t align with real needs. We explicitly aim to avoid “ivory tower-ness” and the resentment from other teams that can come from that.
We drive collaboration through feedback from other team members, with a sense of collective ownership. We’re not the sole place where “tech work” gets done, and we’re not the only ones with ideas.
We include other R&D members in decision-making, and ask them to bring their problems to us. It’s just like our product teams working with our customers to identify their pain points. Our collaboration with our product teams determines the items that end up on our roadmap.
JB: How do you do that? What are some of the approaches you take to get the input that guides your work?
Alan: We host weekly forums where ideas propagate. We send out surveys on a quarterly basis, to allow team leads and other members of the teams to raise issues or pain points. We embrace Mavenlink’s pair programming culture, and pair not only within our own team, but also with our product teams. We’ll use whatever work is on their roadmap that’s driving a feature upgrade, or a feature request that’s coming through, to take advantage of any improvements from upgrades. For example, what we’ve seen with our Rails 5.0 upgrade and our upcoming Elasticsearch upgrade.
Nate: I think another thing around the ivory tower and that concept, and looking at kingdoms and how they rule, typically you’d see the same people in the ivory tower time after time, and they would have a long extended rule there. To avoid that, we’ve been intentional about regular rotations of engineers from other teams onto M7. We’ve had probably four to five engineers rotate onto the team over the last year, getting the ability to have additional ideas, concepts, thoughts, and overall implementation there.
That also supports Mavenlink’s pair programming philosophy. We know that we’re going to come up with better ideas and strategies by getting additional inputs into the work that we’re doing.
JB: Thanks Nate. Shirish, how have you been thinking about involving the wider dev team?
Shirish: We sort of team source all of our projects — the priorities on our roadmap are sourced from what the other teams need. We conduct fun prioritization exercises to decide which projects are the most important and beneficial to the wider organization.
M7 does not have a set roadmap for the next two years. Our team is a little different. We are much more fluid in terms of our roadmap. Every two to three months, we can reprioritize our projects based on need, and how much of an impact it can have on other teams. This helps us be agile, but also be flexible. That’s one of the things that differentiates us from other teams, and it’s also very beneficial because our goal is to remove any barriers as soon as possible for other teams to succeed.
JB: You mentioned working alongside other engineers. Can you tell me, what is a “green dot project”?
Alan: A green dot project is actually something that, I think, JB, you helped us coin. At some point we were whiteboarding our team dynamics, and we drew core members of M7 as red dots. We’re the ones primarily leading and anchoring our work. Product team engineers we drew as green dots.
Green dot projects are where M7 engineers work directly with the “green dots” — the engineers on our product teams. We tackle issues they’re facing or features that they’re building, and while working with them, we spot opportunities for us to help them.
An example of this is with our upgrade to Elasticsearch 7. As we’re doing some of the backporting and performance work, we want to make sure our product teams know how to take advantage of the upgrade. As we help our product teams with implementation, we teach them about the new capabilities of the upgrade. Collaboratively, we can come up with solutions to take advantage of that change.
“We try to approach system upgrades like airline upgrades. It’s a delightful experience that people enjoy. When we do the same thing for our software engineers — deliver upgrades in a way that feels like they’re flying first-class — then they’re able to do better work and deliver better software.”
— Nate Gilbertson
JB: Nate, you’re product manager for M7. You’re also product manager for one of our core product teams. What have you found interesting about serving as product manager for a technology-focused platform team?
Nate: I think it’s definitely been a learning opportunity for me to up level my technical abilities and understand what we’re doing. Whereas on a product team, I’m understanding the business needs that our customers might have, and then I can communicate that value to the engineers.
Our M7 engineers understand the needs of our engineers on other teams, and they help me understand that value as a non-engineer. Together, we want to understand “Why is this valuable? Why is it something that we’re prioritizing? Why is this something that we’re spending our resources on?” And then I can communicate the value that we’re looking to deliver there.
JB: In addition to your technical work here, you’re also very talented filmmakers. Tell us about the movie you made.
Nate: That was a team effort. We made a movie to communicate internally about our Rails upgrade to people that aren’t a part of the R&D organization, and to show the value of the work. We came up with a script together to say, “Well, if someone knows nothing about Rails and what that means, what do we want to communicate? What are the value-adds? Why are we looking to do this? We’re doing it because we want better security around our platform. We want better tools for engineers to be able to use.” Those are things that people outside the R&D organization can understand.
We put together a video that’s just a train montage, playing on the theme of “Rails.” We had one of our team members narrate it, and we all collaborated to put together the script in order to communicate the value externally outside of the R&D organization.
JB: Is there going to be a sequel?
Nate: Yes. The Rails 6.0
Alan: It’s coming.
JB: It sounds like system upgrades are really glamorous. [laughter] Question, maybe for you, Shirish, what’s some of the other work your team has coming up?
Shirish: Recently we’ve focused on improving our public-facing API. There’s some really exciting projects coming up on the API front. One of the projects that I’m very excited about is building, as a team, is an onboarding framework in our API, which will enable all our customers to transfer their data from their existing third party vendors onto our system in a very quick fashion, almost an improvement of 60–80% in terms of onboarding time. That is very exciting.
We are also building an event-based API, which will support WebSockets. We’re really excited about that on the product front. We’re working on improving our workflows around publishing the latest API documentation. We will be automating our API documentation updates so that every deploy programmatically generates and deploys our API documentation, which will be pretty cool.
Another project that can have a massive impact on our API is updating our very own API presenter library called Brainstem. We’re working to make it faster and more flexible. We’re also building an adapter that will allow us to interface with GraphQL to leverage all of the benefits that GraphQL provides. Those are a few things that I’m excited about.
Nate: JB, I know you mentioned system upgrades. They’re not typically glamorous and super exciting, but I think it’s the way that we’re able to frame what we’re doing, what we’re working on, and why we’re doing it. It’s going back to giving superpowers to our engineers. We try to approach system upgrades like airline upgrades. It’s a delightful experience that people enjoy. When we do the same thing for our software engineers — deliver upgrades in a way that feels like they’re flying first-class — then they’re able to do better work and deliver better software.
JB: Is there drink service in the upgrade club?
Nate: Yes. [laughs]
JB: Alan, anything else to add about some of the interesting work we’re doing technically?
Alan: Yeah. Rails is an ongoing focus. We completed the Rails 5 upgrade early this year and for Rails 6 we want to at least get ourselves ready and primed to go.
We’re also focused on an Elasticsearch upgrade, which is very much in line with what Nate said of actually being a “pleasant upgrade”. Elasticsearch 7 provides extra capabilities, including fuzzy search, performance gains, and years of security updates.
I think that there are a lot of benefits that come with that in terms of supporting product needs, and just give our engineers a more delightful experience when it comes to building search capabilities.
“Recently we did some music retros and GIF retros. It was a new take on retrospectives. During this pandemic, we’re trying to do things a little different so that we keep it feeling fresh.”
— Shirish Pampoorickal, Software Architect
JB: I know you guys have made it a priority to make the team feel fun, make the team feel inclusive — the movie is an example. What are some other things you’ve done to have fun while building relationships?
Nate: Before quarantine, when we were able to meet in person, we went out and did a VR experience to celebrate the upgrade to Rails 5.2. We all had our VR goggles on and were able to fight off some aliens, and we defeated them. We could get into the VR military at some point.
We have also, now that we are quarantined, being able to play Jackbox TV together and have game time, as well as we do our weekly retro where we’ll talk about what’s working well, what can we improve on, what do we want to continue to do, and set goals as well.
We also did a Salt Lake tour, where we got to visit our team members in Salt Lake and get to just understand what they’re working on, what they’re doing, and build those relationships as well.
Shirish: Our team members are spread across different cities (Salt Lake City, San Francisco, and Irvine). We try getting together as a team at least once every 3 to 6 months and have some fun team activities planned out. We had people flying in from SLC and Irvine to SF, and we hung out and had a lot of fun. We had feature sprints and roadmap prioritization exercises, which were good to whiteboard and discuss as a team. A little bit of business goes with the fun.
We did something similar in SLC, where we went to a gaming arcade together — that was great. Recently we did some music retros and GIF retros. It was a new take on retrospectives. During this pandemic, we’re trying to do things a little different so that we keep it feeling fresh.
Nate: Don’t forget about Korean barbecue too — we need to make that happen again, hopefully. Once things get back to a little bit more normal.
Alan: Yeah, we have a lot of food adventures as well, just to keep events different so that it’s more than just going out to bars or playing games.
JB: Awesome. Well, Alan as leader for the team and looking at the period ahead, what are your hopes and plans for M7 the next six months or so?
Alan: We are hoping to finish the current upgrades we have of Elasticsearch and get ready for Rails 6, so we can finally go and make that movie sequel, because I know everyone’s on the rails to see what’s going on with the next one. [laughter]
As Shirish brought up, we also have some exciting ideas of how we can continue bringing API front and center to all developers. I think that it is an exciting six months ahead with those two projects. I sound like a broken record, but they’re going to make some monumental efforts in terms of what we’re able to do with both search and performance which is why I keep bringing them up!
We might also look into ways we can bring in new capabilities with webhooks and looking into the related infrastructure we can improve there. And again, we’re also leaning on the rest of our engineering team and encouraging them to let us know what other gaps we have too, because those are projections that we’ve come up with collaboratively from their feedback before. However, there’s always stuff that comes up and we want to be able to make sure that we can continue to address the needs that they have as well.
JB: Last question for each of you. If M7 was a plant, what would it be?
Alan: I’ll go. I would say — and I’m going to thank Anne Nichols, our designer, for this because she’s been the one who has been teaching me about plants — I’d say we’d be a Monstera plant, and those plants can scale and grow big, and I think that M7 is going to definitely be a team that, as we grow, we’re going to scale and grow big in a similar manner.
Nate: I know when we first formed the team we said if M7 was an animal, what animal would it be? That point in time I picked chameleon because I feel like we need to blend in in different places. So, if M7 were a plant, I would say we’re the spider plant. The spider plant is said to be one of the most adaptable houseplants. They can grow offshoots in different ways, based off of how they need to grow to get light and receive water. They’re a good newbie gardener plant as well, and I think that we’re a really adaptable team, as Shirish mentioned, where we don’t have a roadmap that’s two years out, we’re looking to continue to look at what’s the most pressing issue that we can solve for and work on. So, spider plant.
JB: Shirish, I hope you know some plants.
Shirish: I have absolutely no clue what plant to say. You put me on the spot, JB. After some quick googling, I’ll settle for the Yarrow plant. It’s a good companion plant that has both beneficial and protective characteristics.
JB: We can give you an animal.
Shirish: I would describe us as an eagle. The way I am thinking about this is in terms of looking towards the future. We’re working on behind the scenes improvements for the future. We can see what is coming up, and we are working on projects that will enable our teams to achieve their goals by being, not nearsighted, but farsighted in terms of infrastructure. But let’s say collaborative eagle. [laughs]
JB: Collaborative, eagle-eyed vision. Okay, very good. Thanks guys.
Nate: Awesome. Thank you.
