Pair Programming Fuels Mavenlink’s Mentorship-Driven Engineering Culture

Job Portraits
Nov 8, 2016 · 18 min read

Let’s start with the big picture. What does Mavenlink make?

Maggie Sheldon, Senior Director of Product

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.”

Adam Ellsworth, Software Engineer
Andy Leavitt, Senior Software Engineer

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 Luftig, Software Engineer

“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.

The day begins with coffee and standups.
Left: Maggie, Paulette, and Val (left to right) discuss the plan for the day. Right: Pairing stations are a hot commodity in the office.
Left to right: Roger (CTO), Rob (UI/UX Developer), and Tricia (Director of Design) meet with a remote team member; on the other side of the wall, Paulette and JB (SVP of Engineering) fine tune her upcoming RubyConf presentation.
A pair of pairs! Slava (UX Designer) and Aaron (Creative Director) discuss design possibilities, while Chris (Senior UX Designer) and Rob (UI/UX Designer) talk through a user flow. Meanwhile, Aaron’s dogs, Layla and Finnegan, excel at pair napping.
Naomi (Software Engineer) discusses her project’s challenges with JB (SVP of Engineering) during their one-on-one.
Kevin (Software Engineer) asks Jeff (Senior Software Engineer) why he broke the build :-(

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.

“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.

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.

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.

Katlyn (Director of Engineering) records business goals, project goals, and risks as the entire engineering team helps set strategy for their updated blog.
As always, the discussion is inclusive — even the office dogs get their say.
Jeff, Mavenlink’s first engineering hire, receives a trophy honoring his five-year anniversary at the company.

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.

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.

Jeff shows off his motorcycle duds.
A few team members head to lunch, but not before running into Jeff on his bike.
Lunch in hand, engineers CC, Amanda, Desmond and Naomi (left to right) return to the office.

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.

“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.

The Dev Ops corner.
Left: In the Ops Corner, even the dogs know Vim. Middle: Cat-themed whiteboard sketch-off. Right: The team working on a tab feature displays their drink of choice.
Left: Framed Totoro puzzle. Middle: The team builds redundancy into everything, including Raspberry Pis. Right: Game night supplies.

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.

“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.

And the award for bean-bag lounge / ping-pong room / former elevator lobby with the best view of downtown San Francisco goes to…
Yet more discussions.
Pssssst. There’s a giant monitor right…behind…your computer.

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.

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.

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.

“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.

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.

“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.

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.

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.


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.

Your moment of zen: Hi there, Jon. Something wrong?

Job Portraits

Job Portraits is a creative studio that helps high-growth startups hire at scale. We are former journalists, founders, developers, and, yes, job seekers, working to improve the hiring experience from both sides of the table.

Job Portraits

Written by

We create content that helps job seekers make better decisions about where to work. Need help hiring? Say hi at jobportraits.com/#hi-there.

Job Portraits

Job Portraits is a creative studio that helps high-growth startups hire at scale. We are former journalists, founders, developers, and, yes, job seekers, working to improve the hiring experience from both sides of the table.