Engineering People PodcastThe Engineering People Show, Episode 02: Dana Lawson

Treehouse for Teams

Treehouse for Teams
writes on March 12, 2018

“We have a rule, ‘No meetings are mandatory.’ If you don’t feel like you’re getting value out of this meeting, don’t go. You don’t have to go. Obviously, there’s a couple of times that meetings are mandatory, but the general sense is most meetings are not mandatory. They shouldn’t be. If that’s your one place to share information, that’s scary.”

Today on Engineering People:

Dana Lawson is VP of Engineering at InVision, responsible for leading 25+ engineers as part of a platform-engineering group covering DevOps, site reliability and data services in addition to the core product shared services. She has nearly 20 years of experience as a systems engineer and has technical skills spanning multiple disciplines, having led many different teams and worn many hats to complement a product’s lifecycle. As an individual contributor creating mobile applications to leading multiple teams that managed large-scale backend big data and infrastructure. With a true passion for people, she brings this mix of technology and fun to her leadership style.tha

Dana previously served as Director of Site Engineering at New Relic, where over her three-year tenure she grew the site-engineering team to more than 50 engineers. During this time, she led the support and engineering teams through a successful IPO and shaped the engineering culture to be a thought leader in its space. With a background in fine arts, she brings her creative vision to the engineering team at InVision, where technology meets design.

(Original episode released on March 12, 2018)


Show notes:

Dana Lawson on LinkedIn

InVision main site, blog and videos

InVisionApp and InVision Engineering on Twitter

The original Rosey

Transcript, edited for clarity:

Ryan Carson: Welcome to Engineering People, the show where we interview the world’s leading engineering managers, so we can learn from their experience and ideas. I’m Ryan Carson, the founder of Treehouse, and I’m your host.

Today, I’m joined by Dana Lawson from InVision. Thanks for joining us.

Dana Lawson: Thanks for having me. Excited to be here.

Ryan Carson: Yeah, it’s great to have you on the show. We already have a wonderful relationship with InVision, so it’s great to meet another great person in the company.

Dana Lawson: Oh, cool. We love what you guys are doing and we’re excited to be a part of the family, so to speak.

Ryan Carson: So, let’s dig into who you are. What is your job title?

Dana Lawson: My job title is Vice President of Platform Engineering at InVision. We have a pretty large engineering group and we’re divided into four departments. Mine is really the heroes behind-the-scenes of our beautiful product.

Ryan Carson: You keep it up and running.

Dana Lawson: Keep it up and running, yes, in addition to adding stuff that other people don’t want to build. Go figure. [laughter]

Ryan Carson: We’re glad you do it, that’s for sure. So, what does InVision do?

Dana Lawson: We are a design operating system. To break that down into more normal terms for everybody, we really build a design collaboration platform, which is new to begin adding in prototypes. It’s a place for the whole lifecycle of product ideation to come together with all the people that have a stake in it, and so that you can really cut down the back-and-forth. [It’s] a spot for you to really think about your product, get it going, and work with all the people that need to have a voice in what you’re building.

Ryan Carson: How many people are in the total engineer organization and then in your engineering organization?

Dana Lawson: We are a hyper-growth startup; I swear it changes everyday. So, by the time this is out these are all lies. [laughter] I think there’s about 130 people in engineering overall, and in my organization, currently today, we have 36 and we’ll have somewhere around 50 by the end of the year if we continue what we’re doing.

Ryan Carson: Wow, that’s bonkers.

Dana Lawson: It’s bonkers.

Ryan Carson: You talked a little bit about what your team does but what are your primary responsibilities, day-to-day?

Dana Lawson: My primary responsibilities are, in addition to hoping to have a seat at the table for the people that I support, are aligning with the CTO on vision of the technical architecture that we’re gonna use and somewhat curating the roadmap, because I’m not on the customer side, so I get to wear a little bit of the product management hat. And, just really instilling the culture of engineering, of what we want it to be and where we want to go, and bringing a voice to all the people that are around me in addition to all the cool tech. So, a little bit of it all.

Ryan Carson: What were some of the biggest obstacles and issues you’ve had to deal with in your current role, and how did you, or how are you solving those?

Dana Lawson: When I started with InVision a couple years ago, there was less than ten people in what we know as platform engineering so that’s some hyper-growth. I think just trying to build really personal relationships — because we’re 100% distributed — while hiring tons of people and trying to lay down a vision of where you want to go and where you want to be is a huge challenge because, unlike some of the constraints you have when you are all in the same office, we have those in addition to rapid growth. So, just trying to find creative ways for people to be people and do their best work, and stay aligned and define the next steps of where we’re headed. I’m sure everybody says that same thing, but—

Ryan Carson: No, that’s a unique challenge you all have.

Dana Lawson: It’s a unique challenge that we have. And being able to trail blaze — there’s not a lot of companies that are taking it all in 100% distributed. More companies are being bold. Etsy’s pretty much 100% distributed, there’s a few others — GitHub, HashiCorp — they’re all going out there and saying, “We’re gonna remote only.” At an organization of this size, you’ve got to get creative, there’s not a lot of literature out there.

How to hold a distributed team together

Ryan Carson: What are some of the things you’re doing, then, to hold that together?

Dana Lawson: We try to do team dating, where we get teams together in real life and meet — and not so much to pair a program, but to really know each other. We do virtual happy hours — which is funny for me, because I’m in Portland, OR, and, well, the company’s worldwide. Sometimes you have a happy hour that’s really early in the day. Hey, 11:00 AM!

In other ways, it’s trying to establish a written culture and not taking for granted that stuff that goes through Slack — or your other instant messages — that everybody’s gonna see. Really encouraging people to just write it down and then over-communicate, and repeat, repeat, repeat, repeat and always repeat. So, we are always building internal tools to help us stay aligned, having a pretty stringent, one-on-one cadence — and putting on rules of engagement about things that you can take for granted when you have that in-office culture, for trying to keep people with of varied backgrounds too because the other challenge — which I don’t see it as a challenge, I think of it as an opportunity — is we have such a globally diverse team. You have to think about the way you speak in euphemisms, and metaphors that you just are like, “Hey, this is how we talk,” but really being intentional with what you’re trying to convey. And so, we’re always looking at new ways we can keep people connected.

Ryan Carson: Do you do anything specific inside of Slack to do that?

Dana Lawson: We’re so Slack-heavy dependent. We use Hubot, Slack bots, a lot, and a lot of the things that we do are through that bot technology. So, for instance, our bot is named Rosie after The Jetsons, our bot helper. We have this whole Jetsons theme — which is really funny, because only us older people are like, “Oh, The Jetsons!” except for the reruns. Where we’re like, “Go watch the cartoons.”

Ryan Carson: It’s on YouTube.

Dana Lawson: Yeah, it’s on YouTube. So, we do a lot of stuff through interactive bots; people deploy, people know status, people know who’s on-call. You just go into Slack and ask Rosie. Rosie typically knows everything that’s going on, and we do a lot of interactive where we pull data in and out.

We also do something that’s, I think, pretty unique where, talking about the culture — we’re engineers, right? In engineering, go figure — we have a Jekyll site in GitHub where anybody can come and do a pull request against our engineering handbook of all handbooks. It’s called “Engineering Notes.” and it’s a place with curated information about how we do business, what the teams are up to, these are our processes, these are our best practices, here’s our project plans and our root-cause analysis — anything that is centric to engineering is in this Jekyll site that’s run out of GitHub. What’s cool about it is that, following that open-source methodology of anybody can do a pull request. Anybody, anybody — I don’t care who you are — can come and say, “You know what? I’m gonna make some change today.” You get the consensus and then it’s merged. We do it in a variety of ways. We’re always looking at ways to just get better and better and better, and that’s where we use Slack, our own internal project management tool, we also use Google’s Framework for objectives and key results. So, just all these little points and always going back and refining them, especially as we add more people. Because what may have worked even a month ago, we had 20 people that month, may not work.

Ryan Carson: That’s interesting that you allow people to do pull requests on “Engineering Notes.” So, who is responsible, though, to own that project and make sure it’s moving forward? Is that the CTO, or you, or a mix of people?

Dana Lawson: It’s a mix of people depending upon the section. Different sections of the notes have different owners of it, to where you have the ability to merge, but it comes down to consensus. We don’t want to leave it out open, ’cause some conversations can go forever. Engineers are just like, “Angular versus React,” that’s crazy time, but you may have a conversation of like, “Oh, here’s one of our values.” And, maybe I think this prose doesn’t really relate, or it’s changed. Anybody can go in there, do a pull request, we’ll have a conversation. Shoot, it goes silent, we’re gonna merge, we’re gonna merge. We’re like, “Here you go, this is done. Now, it’s in the book.”

Objectives and Key Results

Ryan Carson: I love it. That’s awesome. So, you do use OKRs, which is interesting. How does that work on your team?

Dana Lawson: Well, we do them a little different than Google, where they come from the bottom. I wouldn’t say they’re completely from the top, it’s really from a business perspective. Business will say, “Hey, I want to hit these objectives these years.” The CTO will go and say, “Well, how are we, as an engineering organization, gonna meet the objectives of business?” We want to look at it through the lens of not just what we’re doing as engineering, ’cause as builders, sometimes, you put those blinders on and only care about what you’re doing and not what the other team is doing. So, we have these alignment calls, “Well, we’re gonna do this as a business,” and then we try to model some high-level objectives as an engineering organization and then those cascade down — all the way down, somewhat, to personal objectives. Those are more kept outside of our big project reporting statusi but they definitely go down to the team level. We try to ensure that everything that we do is meeting those business objectives.

So, for instance, if we say, “Hey, we’re gonna deliver this new product line,” then, all the teams are gonna say, “Is the work I’m doing today moving us towards delivering that product line?” If not, then it’s a good talking point to say, “Well, are you working on the most-important priority?” or “Are you working on the right priority?” So, maybe there’s a priority that we don’t even know that should be bubbled up even higher, that should be given a bigger seat at the table, because now we know this is out there and we’re working on it, so it should have that same visibility as other objectives. So we do them in that way.

Ryan Carson: That makes sense. Is there a way that everybody can understand what other teams’ or people’s priorities are and how they relate to the big vision?

Dana Lawson: Yeah. We built a tool for ourselves, it’s the brainchild of Bjorn Freeman-Benson, our CTO. ‘Cause, we’ve tried a million different OKRs, we just keep trying tools.

Ryan Carson: You should release it.

Dana Lawson: We should! I keep telling them, I’m like, “This tool’s so badass.” I don’t know if I can say that.

Ryan Carson: You did, that’s great.

Dana Lawson: It’s so great that it just makes it easier, because you can be really succinct about what you’re trying to say. The way that it works is you have these big agenda items. We try to keep them sane; you’re not gonna have ten of them. If you have ten major company priorities, you’re probably doing too much. So, we try to keep them to a sane number and everybody can see that top level and they have measurements of what success looks like and everyone underneath them. Some teams will have them as a one-to-one and some will be like, “Oh, hey. I’m not working on that, and that’s okay.” You don’t have to work on all of them. Then you’ll see the departmental ones, where you’ll see mine that match up to that — and below that, the individual team one, directors and teams, that all roll up.

Fridays at InVision

Dana Lawson: We roll up the status every Friday, every Friday we also do some other creative things. You can go read almost CliffsNotes of how we’re meeting it. If you wanted to, you could dig down to the team level but you can also look a little bit higher. But everybody knows, it’s the one source of truth for where we’re hitting the marks. And we have these cool little charts, these burn-down charts, and all these little knobs and things.

Another thing that we do is every Friday we have teams release demos of the work they shipped to production. This is work that is actually customer value, it’s not work that’s an integration or any other environment that isn’t customer facing. So every Friday all the teams release these two to three-minute demo videos of these things they’ve done. You can sit there in our Slack room and just watch these videos over and over. That’s another way. We have colors for some of our team names. Just like, “What’s the chartreuse team doing this week?” We don’t have that color, [laugher] but if we did you can go-

Ryan Carson: It would be really effective.

Dana Lawson: Nobody would be able to spell their team name. But, you could go watch the video of what they delivered and then read the notes on where they’re at, impediments they have and what’s next. It’s just a whole mechanism of visual, audio and different ways for people to learn and understand the information. You’ve got to hit it on all senses.

Ryan Carson: It would be cool if y’all do a video screencast of — it’d be hard, because all your OKRs are in there — but of how the tooling works. We do something similar at Treehouse: We have a two-year vision, and that two-year vision is very measurable. There’s actually not that many metrics in it and everyone’s work rolls up to one or more of those. We just did an all-hands where we said, “Here’s where we’re at in the numbers.” So, we’ve learned that we’ve got to point everybody in the same direction, the same numbers, everyone has to know what those are and you have to understand how your work rolls up to that number. Otherwise, you don’t know why you’re there.

Dana Lawson: No, and people want purpose. It doesn’t matter, professionally or privately, you want purpose. Most people want to feel like they’re giving their consciousness to something that is worth their while and so, by being really explicit about what you’re trying to do and having measurements, they you can see where that success is. It’s just super-important. It gets hard, it’s hard. There’s no one right answer. We were doing it via massive Google Docs and that was horrible.

Ryan Carson: That’s sounds like hell.

Dana Lawson: Clicking around, you’re 15 links in. You’re like, “I don’t even know where I’m at.”

Ryan Carson: “I just want to stop and give up.”

Dana Lawson: I just want to give up.

Ryan Carson: “I want to go to sleep.”

“No meetings are mandatory.”

Ryan Carson: How do you make time for developers to keep current with changing technology, especially given the hyper-growth you’re in?

Dana Lawson: Once again, I think you have to really have it a part of your culture. This piece of like, “Hey, you need to set time to have focused time and learning.” When you’re in those one-on-ones, when you’re a manager, you should really be talking about your professional development, and what we’re doing next. The awesomeness is people are so varied and so different that even if you haven’t been in the industry really long, you could still have great ideas because you don’t have the baggage, or you don’t have those restraints that you’ve been taught and learned. And so, having a piece of your culture be a part of learning, continuous learning, and giving people the opportunity and the time to do it on the clock. It’s easy for us to be like, “Oh, hey. Go learn Google’s Go,” right? “We’re gonna do Google’s Go. Go learn it.” But, you have to carve that time during work for them to do that, because people have lives and you want them to have lives. You want them to spend time with their families and their passions and their hobbies and the things that they like outside of making money. It’s really tough when companies have this expectation of “I expect you to go learn this, but not give you the time.” It’s just not feasible. So, we really try to encourage, “put time on your calendar! You are the master of your calendar!” We have a rule, “No meetings are mandatory.” If you don’t feel like you’re getting value out of this meeting, don’t go. You don’t have to go. Obviously, there’s a couple of times that meetings are mandatory, but the general sense is most meetings are not mandatory. They shouldn’t be. If that’s your one place to share information, that’s scary. So, we really try to carve that away. We use tools like yours. We encourage people to use Treehouse, other online learning, bringing in outside consultants. We have guilds all across.

We have the Go guild that meets every other week, and they just jam on Go. They spend that hour, or two hours, trading best practices, talking about the projects they’re working on and sharing that knowledge. We do a lot in the guild sense, in addition to thinning people out using tools. We also, company-wide, supply books to people that are interested in, like, “Oh, you want to learn more about the art of Agile. Cool, go buy this book on the company dime and educate yourself.” I think it’s really just having it a part of your culture.

Ryan Carson: It’s interesting that you seem to tie that into one-on-one. Specifically, “What’s your plan to get better and how can I help you do that?” which makes a lot of sense. That was a great answer. Thank you.

There are tools like GitPrime that measure code contribution and churn, do you measure throughput velocity at all?

Dana Lawson: That’s a tough one! Because every team is different and, depending upon the problem that you’re trying to move past or the way of your workflow lifecycle, it doesn’t really make it an even bar. If you have all these teams that look alike and have the same kind of problems, it’s really easy to use a tool for that metric. But, for instance, I have a team that has the hardest work, and I don’t know how these people do it. I’m like, “Oh, that’s so hard.” They’re working on the back-end side and data algorithms, and they’re not gonna have the ability to just say, “Oh, every two weeks,” ’cause their commits are just so lengthy, and it’s trial and error and it’s sandboxing — so we try to measure how big is the problem set, and are we making it better every week, or every sprint, as we should be. But, going on that one-to-one, it’s an opportunity, also, for people — not that they want to — to game the system, where it’s like, “Oh, look at all these,” because, nobody’s gonna dig in there and say, “Oh, man. Look at these 200 commits,” they could be spaces. You could just have commits on indenting, [laughter] which is important but not that important. And so, I think they’re good as one of the variables to measure success, but you can’t just have it as the one.

Ryan Carson: No, it feels like aligning everyone to your OKRs — or us, to our two-year vision — is where you end up getting meaningful work anyway. Because it feels like development engineering and coding is so much more like creative writing than it is producing a number. It’s really hard to measure. I think all of you in engineering have a really hard time with that. I feel bad for you.

Dana Lawson: Well, because people are like, “Well, engineers, they’re so binary. Zero, one, zero, one.” And, I’m like, “Actually, when you’re a developer, you are an artist.”

Ryan Carson: It’s totally creative.

Dana Lawson: It’s totally creative. You can do the same thing in many different ways and it should really be about the output and the quality, versus “Hey, I did this death by a thousand cuts. Look at all these changes I’ve put in there.” You don’t want that culture.

Ryan Carson: This has been so interesting and really neat to hear about some of your internal tools. I love the guilds idea, I haven’t heard that. I think we may try that at Treehouse.

Dana Lawson: You should try it.

Ryan Carson: Yeah, that sounds great. So, I’ve got to let you go, let you get back to your remote team work. But, thank you so much for your time.

Before we go, actually, where can folks find you online?

Dana Lawson: I am on an online sabbatical.

Ryan Carson: Okay, good. So, you don’t want to be found, great.

Dana Lawson: I don’t want to be found. And, it’s not the cool, hip tools or social media today. I had to take a Twitter break, I’m a very sensitive person and Twitter was-

Ryan Carson: I get it, Twitter.

Dana Lawson: But, they can find me on LinkedIn. I accept everybody. I know it’s why I have thousands of friends on LinkedIn. I’m like, “Of course I do!” So, you can find me on LinkedIn.

Ryan Carson: And InVision, where do people find y’all?

Dana Lawson: You can find us on Twitter. We are an InVisionapp, we have our own Twitter handle for InVision Engineering, it’s called InVision Engineering. And, just search the web, we’re out there. We have a pretty active video channel and a blog as well. So, we’re around.

Ryan Carson: Cool. Thanks, Dana. You’ve been a star and we will keep cheering you on from the sidelines. Thanks a lot.

Dana Lawson: Thanks, Ryan.



talentpath, treehouse, diversity, tech, hiring plan, diverse team


Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Get Started

Leave a Reply

You must be logged in to post a comment.

man working on his laptop

Are you ready to start learning?

Learning with Treehouse for only 30 minutes a day can teach you the skills needed to land the job that you've been dreaming about.

Start a Free Trial
woman working on her laptop