Pair Programming Fuels Mavenlink’s Mentorship-Driven Engineering Culture
We often ask teams, “If 90% of what you do is similar to other teams, what’s the 10% that’s not?” For Mavenlink’s engineering team, that ratio might be reversed. Their differentiators include a pairing-focused methodology, supported by a passion for good communication, as well as flexible, full-stack roles that prevent silos and encourage continuous learning. For this story, we visited their office in downtown San Francisco to speak with Maggie Sheldon (Senior Director of Product), Adam Ellsworth (Software Engineer), Andy Leavitt (Senior Software Engineer), and Paulette Luftig (Software Engineer). If you’re interested in working at Mavenlink, check out their roles in S.F. and Salt Lake City, or reach out to JB Steadman at jbsteadman@mavenlink.com.
Let’s start with the big picture. What does Mavenlink make?
Maggie: Mavenlink helps services businesses deliver their services more successfully. We replace multiple tools, like OpenAir, Workfront, and Clarizen, and gather everything in one place, including time tracking, project plans, and data for resource management. A lot of our customers are agencies and consulting businesses, and, for example, BuzzFeed’s partner content team. When they publish a new piece of content, they’re tracking time, they’re managing to a budget, they might need approvals from a client. You can do all of that within Mavenlink. All of your collaboration, all in one place.
Adam: It’s a little like Asana or Basecamp, but way more robust. Would you ever think to run a skills development program in one of those applications? Probably not. As teams get bigger, though, they need to solve increasingly complex problems. That’s how you grow, and Mavenlink helps make that possible.
Why did each of you choose to work at Mavenlink? And what were you doing before?
Adam: Before Mavenlink I was in physical product design and prototyping. I went to a bootcamp because I wanted to learn more about software, and I fell in love with it. At the bootcamp we did pair programming, which also blew my mind. All of a sudden I just knew: “I want to be in software, and I want to do it somewhere collaborative.”
Interviewing at companies, I always asked, “What do you do for collaboration?” Every single company said, “Oh, we’re always working together” — then I’d go onto the floor and everybody would have their headphones on. You could hear a pin drop.
One of my bootcamp friends ended up at Mavenlink, and he kept telling me, “I feel like I’ve struck gold. You’ve gotta check this place out.” When I interviewed, the floor was buzzing. There was just this energy — you can see it here today. That’s every day. People are actually paired, a team of four gathers up to figure something out, there are people leaning over desks. I immediately knew I wanted to work here.
Andy: Pairing is something we’ve been doing from the start, because Mavenlink was born out of Pivotal Labs. That was a big draw for me, too. Before I joined, I was making software for a healthcare company. We partnered with Pivotal Labs when we were re-platforming our system, and I realized I loved their process. I loved pairing, I loved test-driven development, I loved the product cycle. That Pivotal DNA is here.
Maggie: I come from a consumer software background. I worked at IMVU, the company the book The Lean Startup is based on, and before that I did children’s apps. When I joined Mavenlink, I was a product manager and UX designer. Now I’m the Senior Director of Products. It’s great, I think, that someone with my background can really grow here.
Paulette, you come from a less traditional background, don’t you?
Paulette: Yeah, my background is actually in counseling. I used to do social work with youth and families, and I also used to work full-time as a yoga teacher. When I moved to San Francisco, I had the opportunity to make a transition, so I did Dev Bootcamp and became a software engineer. My first job as an engineer was doing e-commerce work.
“Through the rotations, I’ve been able work on different technologies and different business functions in a relatively short period of time.” — Paulette
Mavenlink is awesome because I was allowed, as a new recruit, to really develop my skills. The pair programming and the way we rotate lends itself to that. Through the rotations, I’ve been able work on different technologies and different business functions in a relatively short period of time.
Pairing clearly shapes your day-to-day. How does your process actually work?
Adam: For people who don’t know, it’s two screens, two keyboards, and two mice attached to the same computer. You don’t type at once, but you can easily trade control. The metaphor I like is that one person drives and the other navigates. So, the navigator thinks about the higher-level structure and sets the direction of the work, while the driver filters those ideas and gets the important ones into the code. It requires the complete attention of both people.
Paulette: We work in teams of five to six people, and each team has a lead. We rotate every day, so we don’t end up pairing with the same person all week. When we rotate, we look at each engineer’s personal goals, and try to put them on teams that will provide useful experience. So, if they come in strong in frontend, we’ll put them on a team where they can use backend skills.
Adam: We also switch teams every few months, so you can work on different areas and missions within Mavenlink. I haven’t worked on one thing for more than three or four days at a time. In some respects you have to be okay with that. You have to be like, “This is my baby, my awesome code…and I’m done.”
Maggie: Everyone here is full-stack. Pairing and rotating helps new people become full-stack pretty quickly. It also reduces knowledge silos. If we have a new project in a particular area, everyone should be able to do it. At other companies, only the mobile people would get to work on a new mobile initiative. That wouldn’t happen at Mavenlink. We all get to try our hand at what interests us.
“Everyone here is full-stack. Pairing and rotating helps new people become full-stack pretty quickly.” — Maggie
Andy: For scoping, we use a measure called velocity, which is basically an estimate for how far we expect to get in the week. We want to deliver consistently, but we also understand that things happen. People get sick. Sometimes you come up against a hard problem. We use metrics to understand when that’s happening, but they’re used to make the team better rather than punishing a team for not hitting a certain number. Everything is very negotiable. As an engineer, I appreciate being able to go into conversations with leadership with confidence, rather than feeling like you’re in the dog house.
Tell us more about your team’s philosophy. How has pairing shaped your approach?
Maggie: To start with, we have a lot of people from nontraditional backgrounds. I think that’s part of why we have such an empathetic set of folks.
Andy: There’s definitely a culture of learning and development that reaches through all our levels — the pair, the team, the department. We approach things with humility. I feel like the things I say are heard and acted on, and I have an opportunity to act on them myself.
“We approach things with humility.” — Andy
Adam: It’s not just “I want to learn this so I can be the best.” It’s, “I want to learn this so I can teach the people sitting next to me, so we can all grow.” I’ve never felt that more strongly than at Mavenlink. Paulette is one of our visionaries. She helped us rethink the feedback process, which came from her experience leading the intern team. A big part of their growth came from feedback, and now we’re all involved.
Paulette: We also do a lot of workshops, and lunch and learns, and book clubs. In one of our book clubs, we read Nonviolent Communication and talked about how we could bring more of that into the company. We also teach team members how to give, and how to receive, feedback. Pairing helps us with our communication skills too, because we’re battling things going on with code. Sometimes personalities clash, and pairing helps us learn how to speak more clearly and communicate effectively.
Sounds like there’s a big focus on learning. Do you have specific learning programs, or is it mostly ad hoc?
Paulette: One program I can think of is Friday Projects. On Friday afternoons, we take a break from our normal work to focus on whatever we want. Most people use the time to for learning and development, often working on a specific technology. It might be working in our codebase, or it might be totally unrelated.
“On Friday afternoons, we take a break from our normal work to focus on whatever we want.” — Paulette
Adam: Friday Projects came out of a team Paulette was on. It started out as an experiment: “Let’s see what happens if we set aside a chunk of time for self-guided learning.” Now we’ve scaled that idea to the rest of the engineering team. My first Friday project, I installed a multi-microphone system in the office, because we do all-hands town halls with the Irvine office and we could barely hear them.
Paulette: One of the challenges we regularly address with paired programming is who’s getting to drive. Sometimes the more senior person ends up coding more than the junior person, who’s really the one who needs the experience. Now if you miss out on an opportunity to learn during the week, you can follow up on a Friday.
How does your culture play out in code? I mean, it’s one thing to feel valued, but is the product actually better?
Maggie: I think it is. For example, architecture teams can often have this ivory tower vibe. I’ve worked on teams in the past where a group of people gets chosen, you don’t know why, and they go meet in a secret room and make decisions that never get explained. Here, we have open meetings that everyone is actively invited to. The difference comes in the input. Because everyone is full stack, and we all know how the pieces fit together — and because we know how to collaborate — our decisions are more informed. There are very few blind spots when we do it this way, which matters even more when a decision affects everyone.
Paulette: Just to be clear, it’s not only meetings. You can also volunteer to be a part of the architecture team.
How is the engineering team organized? You have two development offices, right? San Francisco and Salt Lake City?
Andy: The product team is 46 people, and there are 32 engineers within that. Six engineers are in Salt Lake City with me and 26 are in SF — we hope there will be more in both offices soon. Also in Salt Lake we have a PM, a designer, and a QA engineer. Within each office, we want to have a full set of roles. Obviously we’ll collaborate across offices, but we like each office to be capable of producing work independently.
Adam: For pairing, we use a tool called Screenhero, which allows us to keep the pairing structure across cities. I’ll be here in SF, Andy will log into Screenhero from Salt Lake, and suddenly he’s transported into my computer. We both have headphones on and we’re talking through the problem.
How much do you work? I know engineering teams often have, let’s say, unconventional schedules.
Maggie: Well, maybe we’re conventional in that way. When you’re here, you’re here. When you’re outside of the office, you’re not doing work. When I joined, I asked, “What book should I read to really understand Mavenlink?” No question, it’s Extreme Programming by Kent Beck. That’s where our concept of work-life balance comes from. If we’re asking people to stay late or work on weekends, we consider it a management failure. It’s an absolute exception to ask people to stay late.
“If we’re asking people to stay late or work on weekends, we consider it a management failure.” — Maggie
Adam: I’ve had the occasional Saturday or Sunday where I just clean up some code. Every single time, I get an email from somebody saying, “What the heck are you doing? Go have fun. Why are you working on Sunday?” Every single time.
We know you practice Test-Driven Development, which has roots in Extreme Programming. How closely do you follow these ideas?
Andy: One of the key messages of Extreme Programming is “Move slow so you can move fast.” We use TDD and write tests before we write code, so we can make sure we’re meeting the customer’s needs. Your test might fail at first, but ultimately you’re providing a better, more stable product to the customer.
Adam: Our tests are stories for what we’re delivering to our customers. When everything is green, that’s when we’ve done our job. All of our features go through a process of QA and product approval. We try to keep that feedback loop as tight and short as possible. Another benefit of test-driven development is we can make aggressive changes without fear. Ultimately, it makes us more nimble as an organization.
“A benefit of test-driven development is we can make aggressive changes without fear.” — Adam
Maggie: To add to that, I think QA is necessary. Some TDD teams don’t have QA at all, which I don’t agree with. Our QA process helps us see our work from an empathetic perspective. We get important qualitative feedback like: “Yeah it passed the test and performed the function, but the user experience was really weird.”
How close are engineers to customers? How do you learn about customer needs?
Maggie: Sometimes the communication is direct, actually. But that depends on the engineer — there tend to be strong preferences on this. Some engineers really enjoy talking with customers. We’ve had other engineers participate silently on customer calls so they can hear the customer’s feedback without having to speak to them directly.
Adam: I think the level of empathy and emotional intelligence amongst our engineers here is quite high. Not every person wants to talk to customers, but I think everyone wants to do right by the customers and know how the customers feel about what we’re building.
Maggie: Yeah, I’ve gotten engineers asking, “Can you tell us why we’re doing this? What impact is it going to have?” People crave a mission and a purpose. My solution is pretty simple: we hop on a customer call and hear with our own ears.
Let’s talk about accountability. As engineers, who are you accountable to, and what are you accountable for?
Andy: We’re accountable to the customer and we’re accountable to each other.
Adam: Look, not everything works all the time, but overall we’re building a better product. When you’re on your own, you can have a lot of internal anger and frustration towards your code. As a pair, accountability means staying positive, working through those problems, and keeping each other focused. It means lifting each other up, even if it’s a grind. This is so simple, but when my attitude is better, I’ve found that my success rate is much higher.
“Everyone here is paired up with a coach.” — Paulette
Paulette: We’re also accountable to ourselves. Everyone here is paired up with a coach. We meet once a week to talk about what’s going on and set goals for ourselves. Technical goals, or goals like learning to communicate better. Our coaches help us stay accountable to our best selves — I think this is a big part of growing as a person.
What does it mean to be a coach here? Is it the same as a manager?
Andy: Coaches are like managers, but they’re not responsible for the output of a team. Instead, they’re focused on career growth for the people they coach. Most of our engineering coaches are still active engineers; engineering is their main job, but they also mentor newer or more junior developers.
Maggie: I see the coaching practice as a key factor in helping our team grow. The personal attention and feedback coaches provide are really important.
What technology are you working with, and what’s your approach for integrating new technologies?
Paulette: I actually wanted to work at Mavenlink because we were working with Ruby and Rails. Until recently, we built front-end features in Backbone and Marionette, but now we’re moving to React. Our first team using React and Redux is well down the road of finishing their work. Soon, we’ll expand the rollout to other teams.
“It’s a nice time to be alive when you can deploy code and get feedback within half an hour.” — Andy
Andy: Our DevOps team is always providing us with options, for example builds with Kubernetes and deploying multiple staging environments. As engineers, we want to know if our code worked and if it broke anything. We have a continuous integration setup that allows us to deploy code and get feedback really fast. It’s a nice time to be alive when you can deploy code and get feedback within half an hour.
Adam: We literally cannot run all of our tests on our dev workstations. I think we’re pushing 43,000 tests now, so that continuous integration tool is really important.
Can you tell us more about your transition to React and Redux?
Adam: Sure. We deal with a lot of frontend data. One customer might have 100 different projects at any given time, and each of those projects will have up to 50 different fields, all of which need to be sortable. React is really streamlined for that. React also has a virtual DOM it retains in memory so, when it makes manipulations, it’s done there, which makes it much faster. If we need to manipulate the data on a page, React uses a virtual DOM to make those changes more efficiently.
Maggie: A tremendous amount of thought and collaboration has gone into making the transition to React. It’s empowered team members to come together and make decisions that will affect all of us.
Awesome. Does anybody have a specific feature that you’re proud of helping bring into world?
Adam: When I joined the team, the first thing I worked on was letting customers add skills for their users. It was really cool to see the explosion of skills that came online as soon as we released. That feature is a foundational block for many of our customers, and they’re using it in totally different ways. The skills database is just giant.
Maggie: One of our mid-market customers really drove a lot of the requirements for Skills. Now that we’ve released, they’re actually trying to sell up into their parent corporation and get them to use Mavenlink, too.
“It’s a good feeling to know that people are paying attention to the work you’re doing” — Andy
Andy: We celebrate every major feature that gets released on any team. As a company, we’ll get emails from salespeople and other teams saying, “Great job. That feature really helped us out with this client.” We love knowing that people are paying attention to our work, and that the work creates real impact for customers.
Adam: Also, sometimes we go get Korean barbecue to celebrate finishing a feature.
Maggie: Oh yeah, we’re going to get Korean barbecue today! We just released that holiday calendar capability.
Not to kill the vibe, but what’s not going great? What does it look like when things aren’t going well here?
Adam: Well, actually, what comes to mind is the holiday calendar. We bit off more than we could chew.
Maggie: Yeah, we wanted to create a reusable UI component called an editable grid, and build new functionality to allow people to create holiday calendars. The problem was, we packed in more functionality than the feature needed. We hit pause recently and realized, oh my gosh, if we do all this, we’ll do nothing else for the rest of the year.
Adam: We could have predicted that, but we didn’t. We worked for a good four to six weeks before we realized it. I think the positive note on this is that, once we realized what was happening, we sat down and talked about it. Because we use Pivotal Tracker, we could analyze different approaches, and that saved us a lot of time.
“I was like, ‘Okay, what does Bert and Ernie get you? What if we add Elmo?’” — Maggie
Maggie: It was a challenging decision, but Adam made it really fun. He assigned Sesame Street characters to the specs to help us narrow things down. I was like, “Okay, what does Bert and Ernie get you? What if we add Elmo?” We turned this pretty awful realization into something that was sort of playful and fun.
Andy: Also, not everything is perfect in the code, so you’re going to see opportunities to make things better and introduce new patterns. If we made it seem like our practices make every line of code perfect, that’s not the case.
What’s Mavenlink’s vision for the next few years? Is anything big going to change in the near future?
Maggie: When I joined Mavenlink, our customer makeup was primarily small and medium businesses. In the last two years we’ve really moved upstream, to midmarket and enterprise customers, and we’re seeing our mix of new customers reflect that. We’re a Gartner Cool Vendor, which means the analysts at a lot of these enterprise customers are recommending Mavenlink.
In terms of where we’re headed, we’re building an integrations platform that will support different types of General Ledgers and CRMs our customers are using. We’re also investing in resource management — helping very large companies efficiently plan and track project staffing. That feeds into our ultimate vision, the Mavenlink Network. That would mean being able to move across business boundaries to get expert resources from other organizations. This will help our service business customers better serve their clients.
Why is now the right time to join Mavenlink?
Maggie: For one thing, we recently announced a round of funding, which will help us meet our ambitious goals for the product and team. We’re also at a moment where engineers get to move fast, with the agility of a startup, but supported by the security of an established company. Our processes are well established — TDD, pairing, rotations — but it’s far from a monolithic company and the team is still relatively small.
Adam: That means you have the opportunity to make a big impact. We are facing really hard user problems every day, and working to build features that none of our competitors have mastered yet. It’s also an interesting time because we are moving to React. That’s just one of several places an engineer could influence a core part of the team and company.
Interested in joining the team?
Check out Mavenlink engineering roles in S.F. and Salt Lake City, or reach out to JB Steadman at jbsteadman@mavenlink.com.
