Mavenlink development teams achieve success by aligning over shared values and strengthening cohesion through open, empathetic communication.
Collaboration is key to any effective agile software development team, but one team at Mavenlink takes a cutting edge approach to cross-team collaboration by pooling the collective resources and responsibilities of the team members to new extremes. This team creates an environment where all members–both developers and non-coders alike–feel empowered to contribute outside the typical comfort zones of their roles. By approaching their roles with a team-first view, they are able to develop and deliver features in a manner that is rapid, innovative, and highly effective.
“In this environment where we’re safe and we all have empathy for each other, we can move so much quicker, because we can be our true selves and not worry about all of that other stuff. We can get on the same page and kind of move in the same direction together”
— Katherine Scheer
This team, uniquely dubbed as MSYNC (a cheeky nod to the Y2K-era boy band), is tasked with pushing Mavenlink’s technical capabilities toward new boundaries of what is possible. It is no surprise then, that the progressive manner in which this team operates is equally focused on unlocking their own potential for success by challenging the standard processes and expectations one might set for a team like theirs. From their consistently open and empathetic team communication, to their unique and inventive methods for approaching the iterative development process, MSYNC has found ways to enshrine concepts like psychological safety into their culture as a team, resulting in a highly effective and cohesive unit. Recently, Andy Mavenlink’s Vice President of Engineering Andy Leavitt sat down with members of MSYNC to find out what sets this team apart from their industry peers.
Andy: Let’s introduce everyone on the team. Katherine, why don’t you kick us off?
Katherine: Okay. I am the product manager, and what I do is I try to align the business needs, what outcomes we’re trying to drive, and then how to best deliver that value to our customers on the product side. I view myself as representing the users of our market. My goal is to focus on outcomes, and that the outcomes are the business outcomes, not one specific customer’s need.
Andy: Jason, you are the team lead…
Jason: I feel like my role is to take what Katherine thinks is important, and then put everyone together in a room to solve the problem.
Katherine: In a lot of companies, the product manager’s job is to solve the problem. It’s like one person trying to do the hardest part, when you have the smartest people in the room. They should be solving the problem, because they’re the smartest! I’m just supposed to identify needs and attempt to prioritize, but I look to the whole team to help me with that too. I can say what pains my users are feeling. What we’re designing is such a developer product, so we all represent the customers. We’re a very democratic team. We all kind of wear all the hats.
Andy: Love it. Tiffany, what is your role?
Tiffany: I’m a quality assurance tester. As our team is building the product, I test it to make sure it’s doing what we intended. One important part of that is seeing if I can break it; seeing if I can find bugs before it gets released to our clients. Also, I provide a sort of first user experience feedback. As I’m using the new product, I’m saying, “Does this make sense as a user? Is there anything I would rather see?”, and giving that feedback to the team, and sometimes we make adjustments based on that.
Andy: Paige, what is your role on the team?
Paige: I am a senior product designer at Mavenlink on the MSYNC team. My role on the team is to help better the life of our users through challenging and questioning, like what are we doing and are we doing the right thing, and really trying to rely on our team as a whole to answer that question.
Andy: Ethan, you are one of the engineers on the team, tell us about your role.
Ethan: I think we kind of deal with the intersection of the code, where the code is, and where the code needs to be. We have a much broader role than software engineers at a lot of other companies. At Mavenlink, we have a huge focus on being full stack engineers, but then on this team I think it goes a little bit further. We interact a lot with the clients, and we have a lot of the prioritization conversations within this team.
Andy: Jacq, go ahead and introduce yourself.
Jacq: I’m a technical writer. I have focused largely on writing for the various integrations teams, as well as API documentation and things. All of this (outside of the QuickBooks and Google integrations) technically falls under the M-Bridge umbrella. It’s a lot of work that I find challenging in a fun way. MSYNC in particular loves to think outside the box a lot, and keeps me on my toes in about as many ways as you can think of. I only wish there were more hours in a day to do it all, except for the part where 2020 has more hours.
“As a team, rather than focus on what’s the perfect process or the perfect solution to this problem, we try to think, ‘What’s the best thing that we can do next?’, and then we worry about that instead of trying to worry about everything at once.
— Jason Larsen
Andy: Awesome. So, what makes MSYNC unique as a team?
Katherine: We’re very outcomes focused, and we’re very much into solving the problems. The whole team is trying to solve those problems together, so everybody is very much understanding what it is that we’re trying to do. It’s not just, “Here’s the PRD, and here’s my user stories”, throw it over the fence, and then the engineers start developing. We are all very much understanding what the goals are, what outcome we’re trying to achieve, and then as a team, we have the freedom to solve it however we think best. Sometimes, it might not even be with user facing code.
Jason: When you have a problem, you can either shape the problem around your team, or you can shape your team around the problem. We try to come to a problem as a group of peers who all happen to have different skills, but we have to wear a lot of different hats. Maybe my hat that I’m most comfortable wearing is a backend engineer, but sometimes I might need to be a frontend engineer, and sometimes I might need to pair up with Paige on design. We all bring different skills to the table that we can use to round out the team and tackle a problem. I like to think that when somebody asks someone on our team, “What do you do at the company?” that their answer is, “Oh, I’m on MSYNC,” rather than identify as their title first.
Andy: The team has a slogan, “We are all MSYNC.” What does that mean?
Ethan: To me, that means that we take most seriously our humanity, and as actually our first value, a value document that we’ve put together. I think we did that in one of my first few months on the team. Just the act of putting that document together, and then living up to it and continuing to refer to it has made a big impression on me. I think one of our main priorities is that we try very hard to recognize and respect each other as people first, and to create an environment for all of us to thrive.
Paige: The only way the team works is together with every member. We operate on a level of being peers. Really, our motto is that we all sink or swim together, and we all have to figure this out together.
Katherine: We have created such a safe space. It’s really important. 20 years ago, when I worked in corporate America, I was very careful to remain guarded, and not say anything stupid. I had my work personality and my home personality. I was always trying to present my best, worried about making mistakes, as they could cost you your career. In this environment at Mavenlink, where we’re safe and we all have empathy for each other, we can move so much quicker. We can be our true selves and not worry about making mistakes. Mistakes are okay, as we have a learning culture, and a better product is created when we try new things and learn. We can get on the same page and kind of move in the same direction together much quicker without fear. Bringing our whole selves to work allows for better innovation and more importantly a more satisfying work life.
Andy: I think we’re touching on the concept of psychological safety. What does the team do to promote that sense of empathy, understanding, and awareness of each other?
Paige: I’ve had many moments of kind of feeling unsafe or worried, which naturally happens. We move fast. Also, when I was new to the team, there were lots of scary things. Jason has created a really great culture on our team of communication. He holds lots of one-on-one’s and encourages me to talk to other people. I really think the communication helps with that.
Jason: One thing that I was thinking about was the idea about being okay to make mistakes. We bring our whole selves to work, and it’s okay for us to maybe say something that we might be embarrassed about later, because we know that each of our hearts are in the right places.
We have a much broader role than software engineers at a lot of other companies. At Mavenlink, we have a huge focus on being full stack engineers, but then on this team I think it goes a little bit further.”
— Ethan Ransom
I think another part is, as far as the product, we’re okay to make mistakes. We’re trying to iterate really quickly. We try to shape our team around the problem, but the problem is always changing shape. Our team has to change and adapt all the time, and that can be really uncomfortable. It can cause friction. As a team, rather than focus on what’s the perfect process or the perfect solution to this problem, we try to think, “What’s the next best thing that we can do?”, and then we worry about that instead of trying to worry about everything at once.
Andy: It sounds like the team is able to move forward and make that next step because the team is generous with one another. How does that play out day-to-day, and how does it play out across roles? Are there examples where this generosity and this safety has been expressed in a way?
Tiffany: I can talk about that a little bit from a QA perspective. I’ve found that doing testing on this team requires a lot more communication than some other teams, because this team relies so much more on collaboration. So I ask a lot of questions if I’m not clear about what the team decision was or why we decided to do it that way. But I think that’s just part of the team dynamic, and I never feel like I can’t ask a question, so that back and forth happens all the time. Everybody on the team is really willing to help me out when I need clarification on something.
Ethan: I think I see collaboration as a theme from my perspective too. I think on previous teams, in theory I’ve had a designer and a product manager, but I’d basically never interact with them. There’s this wall that things get kind of thrown back and forth over. Just to have the opportunity to interact with those other roles is unique and enjoyable.
Paige: One of my favorite times is pairing in with engineers, and I’ve recently tried to start doing pair designing, so inviting the engineers or anyone on the team who wants to see I’m doing. I think that really speaks to, again, our collaboration. It does mean more meetings, but I feel really lucky to be able to contribute to dev discussions sometimes. I think that helps our team.
Katherine: We have a good culture of experimenting, and I think that’s really important. An example of this is we used to do the traditional PRD, and we used to do the traditional inceptions with the iterations like, “Okay. You have a one week iteration, and you have the section where you set your goals,” but then we’d get to the end of the week, and anything that we didn’t finish got pushed to the next week. We weren’t happy with that.
We’ve been experimenting with this concept of “adventures,” where we talk about what the problem is, bringing subject matter experts to discuss the problem from their point of view, and then it’s almost like a fun bartering conversation as to how we solve the most important parts of the problem, what is critical vs nice-to-haves.
Then I’m like, “Okay, I’m willing to spend two weeks of time on this.” The team puts their head together in an inception to figure out how to solve that problem knowing the two week constraint. At the end of the two weeks, anything that we didn’t do, we throw away. It’s gone until the pain is high enough to revisit it again. When we’re not seeing those pains or needs as high as other priorities, it allows us to pivot.
Paige: I think the reason why we are able to experiment as a team is because we have that psychological safety. We value each other’s humanity. If we didn’t have that and we tried to experiment, it would blow up so hard. It definitely blows up sometimes, but we can recover from it and learn from it.
Katherine: Yeah. I have never seen anybody play the blame game on this team at all. There’s never been where you’re covering, trying to deflect, or it’s very much, “Okay. What’s going wrong? Here’s what we’re feeling, this pain folder here. What do we need to do next?” Even in postmortems, we get into just really meaty, good conversations. Some retros in my past have been just like, “Yay for this,” and nothing really where you’ve got real action items and real cathartic conversation.
Paige: I think we can’t even play the blame game, because we all make decisions together. I don’t think there’s ever a decision that one person makes on the team.
Andy: Let’s go back to this concept of adventures. What are they? What problem do they solve?
Jason: Every team has so many different things that compete for your attention, but ultimately there can only be one thing that is “most important.” We can try to multitask so that everyone does a little on a few different priorities at a time. This mostly results in several things done slowly, and in fragmented knowledge and silos. I prefer to throw all our team energy against the next most important thing. As the great philosopher Ron Swanson said, “Never Half-ass two things, Whole-ass one thing.” The hard part about this is that we really have to align as a team on what the next single most important thing is. But it’s worth it.
Adventures are the way we try to model and talk about that next “most important” thing. They are basically the same as an “Epic”, or “Project” in other contexts. “Adventure” is just some fun inner-team branding we put around it to make it feel more creative and playful, and to disassociate it from these sometimes loaded words.
Katherine: Jason hated that we had to do this iteration deck. I kept saying, “But I need to be able to go back and piece together what all we’ve done!” Just for all the pull request type stuff, like when we do roadmap presentations. It’s just handy to see how we move through all of our features. And Jason was like, “Yeah, yeah, yeah, but can’t we do that in a different way?” I’m like, “I’m okay. I’ll do it whatever. I’ll try anything.”
Paige: I remember that! When we finally got Katherine away from her iteration deck. [laughter] “Adventure” is really just another term for a sprint, except it’s a little bit more squishy. I think we intentionally made it a little bit more squishy. It allows for growth and exploration together. Some pieces of the adventure are already solved, but a lot of it is unsolved. That’s where our collaboration comes into play, and really why we’re making decisions together and we can’t really play the blame game. That’s what I would say it is. I think Jason is modeling it after Ryan Singer’s book Shape Up, I think?
Katherine: Yeah. That’s right.
“I love pairing in with engineers, because it’s kind of the flip side of all of that. They challenge me to think about all the technical limitations but also possibilities, so for me to see the structure of how the software is built helps me in designing things that will be great for the engineers to actually build but also for our users to use.”
— Paige Kulson
Andy: So what’s the process for MSYNC’s adventures? How did you get it started?
Jason: We used to show up to our Monday planning meeting with a bunch of tickets that had already been written and the solutions had been designed. It didn’t feel collaborative — it felt like we were turning the team into ticket takers, rather than using our collective skills to tackle the challenge together. The tickets also felt isolated and it was hard to understand tickets in the context of our teams’ priorities and objectives if you weren’t in the room where it happened.
To make our solution team-driven, every Adventure starts with two things: First, a problem statement. Second, the “appetite” — how many weeks we are willing to spend trying to solve the problem.
We discuss as a team what we think we can put together to solve the problem in the allotted time. We document together at a high level what our solution will look like. We also document what things we are not going to do right now. We then break out as a team, write stories, and get to work.
To help ensure we deliver our solution, we try to break down our solution into a series of goals. We want to be sure that we can solve the problem in much less time than we have committed to, so we want our first tier to be a full fledged solution to the problem that we can easily finish in time. The rest of the tiers are nice-to-have improvements that we treat as stretch goals. This helps us manage the risks around delivery, and make sure that we don’t spend indefinite amounts of time finishing nice-to-haves that may not be as important as the next Adventure.
We are all very much understanding what the goals are, what outcome we’re trying to achieve, and then as a team, we have the freedom to solve it however we think best.”
— Katherine Scheer
Andy: Awesome. Paige, as a designer, what sorts of activities might you do with an engineer or with Katherine?
Paige: Yeah. It really depends on what I’m working on at the time. I mean, Katherine and I have looked through surveys and card sorts together. A couple of times engineering paired in with me on design stuff, and it was really just going through creating screen versions, prototyping those together, and trying to figure out how different pieces connected all the way down to what icon should represent this thing. My work varies a lot.
Katherine: Lots of user research, and the engineers will come in and see the testing that we do.
Paige: Yeah. We do a lot of testing, and that’s a great time for engineering to get in contact with our clients and see them using the things that they’re building. Any time I can bring clients to sit anywhere on the team — I think Katherine is the same — like, we jump at that opportunity.
Katherine: Yeah. And because these Adventures are small, the idea is that we want to get feedback fast to see, did this improve? We spend a lot of time with users. We’re lucky because our technical consultants [on Mavenlink’s business intelligence team] represent the main tier of users. Just being able to reach out and get them to get feedback is just so easy. It’s so safe, because they’re Mavenlink. We’re lucky in that regard, but now we’ve got all these beta clients too, so we’re definitely getting more and more conversations going with real clients, which is always eye-opening. I’m always like, “Okay. I’ve got all new priorities.”
Paige: Something that I was super nervous about when I first started having engineering pairing in on design things, is during an interview being very clear what the rules of engagement are. When you’re testing people, you have to be very precise. I’ve definitely trained Katherine well on when we’re timing things versus not timing things. I was nervous about that in the beginning, but everyone’s been super great about it. I love pairing in with engineers, because it’s kind of the flip side of all of that. They challenge me to think about all the technical limitations but also possibilities, so for me to see the structure of how the software is built helps me in designing things that will be great for the engineers to actually build but also for our users to use.
Andy: That does lead to a question that I have here. I think being a collaborative team, there’s lots of different directions the team could be pulled based on the different priorities or the different roles that are on the team. How does product engineering and design come together to define the direction of this team?
Katherine: That is sort of what our Adventures are solving, right? It keeps us focused, and it keeps us from going on tangents. That’s a very partial answer.
Paige: Yeah. I was going to say I think we have to kind of barter, or we collaborate to figure it out. I have my dreams and goals. Engineering has their dreams and goals. Katherine has hers. We’re on a greenfield project, so they’re all super important, and we could go a million different directions. By really coming together, going through those adventures, solving the problems, and staying outcome focused is, I think, how we stay on track.
Tiffany: We did that today, you know, asking how many things we wanted to work on this Adventure. We cut out like half of it.
Katherine: Yeah, so it’s like, “Okay. Wait. We can’t go another two weeks. We’ve got to get this done in a week.”
“Every team has so many different things that compete for your attention, but ultimately there can only be one thing that is “most important.” We can try to multitask so that everyone does a little on a few different priorities at a time. This mostly results in several things done slowly, and in fragmented knowledge and silos. I prefer to throw all our team energy against the next most important thing.”
— Jason Larsen
Paige: We do have longer team goals as well. We have our OKR’s that we outlined and success metrics that we have identified. Those help as well with the smaller tasks, making sure we’re getting to the right place.
Katherine: Yeah. It’s like, “Okay. How impactful is this vs. these other things?” The success metric of this objective is to get five more clients live on production by December. With that being one of the biggest success metrics, we then say, “Okay. What are the biggest pains that’s going to help get these clients? What do we need to solve that will make the biggest impact in that?” The OKR’s are good, because they’re farther reaching. We can use them to measure and say, “What’s going to move the needle the biggest?”
One of the nice parts is that our team isn’t beholden to client commitments, so we have that ability. We just spent a couple of weeks re-architecting the editor page. What we built first was the “get it done quick,” and then we’re realizing that there’s a lot of UX pains around it. We realized that the tool we were using just couldn’t do it anymore, so we had to stop. We basically paused an adventure midway, and said, “We need to take this on. We need to take on a refactor of this code. There are two different ways we could solve this, so let’s figure out which one.”
From a product perspective, I’m like, “Ah. We’re not moving forward in all these things that I want to get to clients.” But the team can create this argument that’s like, “No. We need to do this in order to be able to do those things.”
Paige: I don’t think we have any super selfish people on the team in terms of, “My thing is the most important, because it hasn’t been done in forever.” We all want the best outcome for the platform. With that goal, we can get there.
Ethan: One thing that definitely should be mentioned about this team is the sense of humor. I think MSYNC-hole, even the team name, and the boy band being referenced, we need to reference those as often as we can, and we do.
Paige: For the record, the MSYNC-hole is the workspace we created in the Salt Lake office.
Katherine: And it’s great, Paige is sitting there with the engineers, and then when I go to visit, I sit with the engineers. We’re like a team, and I think just that helps build camaraderie. I miss it.
Paige: That was a big turning point for me actually, because before that I was separate from the team. Even when I was a part of the team, I was sitting farther away.
Katherine: Yeah. I really like when everybody on the team sits together. I think that’s a good team building, just naturally.
Paige: Now we virtually sit together every day.
Katherine: Yeah, and play Among Us. [laughter]
Andy: What has changed now that everyone’s been working from home? What’s been surprising about that?
Katherine: It does level the playing field, but I don’t feel like with this team that was ever a problem anyways, because I’m always remote no matter what. Especially because it’s hard to get a piece of my time, this team is the best at pinging me. Hitting me up in Slack, just so that I feel like it’s easier for sure. Everybody here is very proactive. I want to say as goofy as we all are, this is a team of solid professionals. If there’s a meeting on someone’s calendar, they will either say “I’m in” or “I can’t make it.” I think everybody is really good about keeping on top of communication. We’ve figured out channels to communicate that work.
“I never feel like I can’t ask a question, so that back and forth happens all the time. Everybody on the team is really willing to help me out when I need clarification on something.”
— Tiffany Forsyth
When you’re part of the Mavenlink culture, you’re always learning and expanding, so some of the things that we have opportunities in Mavenlink is to be able to present to our peers and to be able to share out the things that are important to us. We’ve done that in the past, and we need to keep doing that. The things that work great for us, we’ve brought people in and talked to them about how we use Notion. We’ve still got stuff on our plate that we want to do to be better at sharing out for other folks to kind of look and see, “Oh. Maybe that’s a tool I want in my tool belt too.”
Paige: I will just say I think our team started using Whimsical the most, and now we’re almost out of licenses. It’s cool that we’ve been able to share that, and the rest of the department is using it. I’ve seen our CTO Roger Neel use it. I’ve seen our VP of Product Jared Haleck use it. It’s so cool to see the things that have worked well for us work well for others.
Andy: Thanks for your time. We covered a lot of good stuff here. Thank you so much for sharing.
Tiffany: Thanks Andy.
Katherine: Thank you!
