Podcast: GitPrime’s CEO on Quantifying Engineering Productivity

Sep 14, 2016 | Inside GitPrime

This week Travis Kimmel, co-founder and CEO at GitPrime, joined Kevin Owocki and Miles Matthias from StartupCTO talk about quantifying software engineering productivity.

They talked about:

  • How to write good specs protect engineers from brain damage
  • What engineering looks like at a remote-first startup
  • How problems in engineering are often problems in the stakeholder-engineering relationship
  • The infamous ‘mood button’ story and the origins of GitPrime
  • Replacing Linkedin, drowning in beer, and more!

Head over to StartupCTO.io to catch the full interview. And be sure to subscribe and to keep up with software engineering leaders from Colorado’s thriving tech community and beyond.

What follows is the full transcript of the conversation…


Full Transcript

Owocki:
Hi. Welcome to Exec Podcast, the podcast for startup engineering leadership, brought to you from Boulder, Colorado. I’m Kevin Owocki, and I’ll be interviewing startup engineering leaders from Colorado, California, and all around the world. Let’s get started.

Hi there. Our guest this week is Travis Kimmel, the CEO of GitPrime. GitPrime analyses a team’s code base to quantify engineering progress. They make it easy to identify engineers who are stuck or bogged down through factoring, and quantify the amount of effort spent paying down technical debt. It was an extra special treat to interview Travis. He’s an engineer who built his own company, and the product is geared towards engineering managers like ourselves. Enjoy.

Hi, welcome to Exec Podcast. I’m here with my co-host, Miles.

Miles:
Hey.

Owocki:
Today, as our guest, we have Travis Kimmel, the CEO of GitPrime. Welcome, Travis.

Travis:
Thanks. It’s great to be here.

Owocki:
Good to have you. Could you tee us off by telling us the founding story of GitPrime?

Travis:
Yeah. GitPrime started back in the day. I was working at another startup as an engineering manager, and started making, by hand, a bunch of reports in Excel to show what was happening in engineering. Initially, this was me hand-collating stuff from GitHub and our Git repositories to demonstrate how things outside of engineering affect the happenings in engineering. Early on, this was all super manual. That gig sort of wrapped up. At the end of it, I thought, “Gosh, this would be a great project to work on.” Kind of worked on it obsessively for a little bit, then it snowballed into a company.

Owocki:
Right. You said that you were hand-rolling reports. What sort of questions were you getting from stakeholders that you were trying to data-drive the answers to?

Travis:
One of the things that’s always, when you’re in engineering, it’s always a bit challenging, is that the work that engineers do, it tends to be invisible. When, let’s say you’re halfway through a development cycle, whether that be a traditional sprint or, you know, some people do them longer, like a month. You’re halfway through, and you get a stakeholder who changes their mind. That’s pretty frequent. One of the things that’s invisible is the cost of doing that.

My goal was to surface that cost so we could talk a little more frankly about things like, well, it’s fine if we want to change direction here, but there’s a bunch of sunk costs in development. We’ve got to realize this will extend the deliverable timeline. There’s a certain type of operational waste. My goal was to encourage stakeholders to think out, from the user’s perspective, what we really want to build before we start, so we could get these clean implementations that are so nice to have in engineering.

Owocki:
Okay, got it. So it sounds like you’re trying to- It sounds like your end game, a little bit, was pushing back on changing directions mid-sprint.

Travis:
Yes.

Owocki:
Okay. How do you quantify the waste that’s associated with that?

Travis:
We tap into version control. We use Git, as the name GitPrime suggests. There’s a ton of data in there, but you sort of have to mine it out. One of the things that we look at it is how quickly code that’s written gets rewritten. This can be a good indicator of a mid-implementation shift. You drop in a bunch of stuff toward the feature, then that feature changes fundamentally. Oftentimes that requires huge re-factors. This kind of thing tends to be, we feel it in engineering, right, But it tends to be invisible to people outside of engineering, who oftentimes don’t necessarily have a clear read on engineering operations.

Creating a shared language, which the best way we’ve found to do that is draw a picture of what’s happening, and that shared visual language, which is based on data, can help show that yeah, it’s cool, we can change directions, but there’s a cost. Engineering time is zero sum. Despite industry trends, it’s not great to continually work 60-80 hour weeks, which can be the result of these frequent pivots. It was about building a communication channel where we could all communicate a little more frankly there.

Miles:
Has the demand for this transparency always been from the business side, or has it been engineers too, asking for “I need a better way to communicate” these problems?

Travis:
Actually, recently, we’ve had a bunch of feedback from engineers who’ve written in to say thank you. I think that it sorts of starts at this layer of middle management who’s responsible for things like predictability, right? They want to know that the engineers are being successful. If you’ve ever been an engineering manager, you get into this state where you want to be a good actor. Interrupting an engineer is inherently costly.

Whenever I was managing engineers, I tried not to do that, but not interrupting somebody who’s kind of stuck, or waiting on some stakeholder to clarify something, is also pretty costly. You find yourself in this double bind. The best use case of our product is to resolve that sort of stuff, to allow engineers leads to be timely and powerful advocates for their team, both by understanding what the team is up to, and then being able to communicate that to stakeholders and kind of take the heat there.

Miles:
That makes sense.

Owocki:
Do you guys have an ideology with respect to agile? I know there’s a lot of people that solve this kind of problem with combine or sprint or extreme programming. Does your tool replace the need for an agile methodology, or does it augment the need for an agile methodology?

Travis:
Wow. That’s an awesome question. I kind of think it depends on how you use it. From one perspective, more data is never a bad thing. It’s just a question of whether or not you can parse it. The history of agile is really fascinating. Waterfall was great when it was great, except you got these developers working in a cave for six months to a year, and then coming out with a shazam moment. Agile brought it tight feedback loops, which are always really good. Today, I think that- We’re big fans of agile. We do tight development cycles, that sort of thing. I think one of the challenges with agile is that you can get into a position where the burden of management gets externalized onto engineers.

What I mean by that is, as an engineer, it’s very hard to predict when things are going to be done. It’s almost more of a managerial role to do that. There’s this phenomenon that sometimes happens in agile where you make the engineers responsible for understanding when their work will be done, which is a task-switching cost, because now, as an engineer, you have to both hold that higher level of forest-y view, and the trees view of what you’re doing. The cognitive load there is pretty extreme. I think one of the problems with agile is there’s nothing uniquely engineer-y about it. It’s really awesome, it kicks the hell out of Waterfall, but it was imported from industrial engineering. There’s nothing inherently software-y about it. Software teams have their own unique challenges. It’s a creative discipline. If you start a painting, it’s really hard to say when you’ll be done with it.

The dynamic where engineers need to predict when they’ll be done with things that are sort of opaque when you start, and then held accountable for that prediction is not super healthy. What we do is, this plays well within agile. Agile can still give rough estimates for when things will be done. Then there’s also this level of if you can see, very clearly, the work happening as it’s happening, management can take ownership for deliverables. If they notice something going a little bit awry, start socializing that with stakeholders ahead of time, which really helps the team.

Owocki:
Right. I’d agree. My next question is about the overhead of having that situational awareness of when something’s going to get done in the larger roadmap for an engineer, and also all the complications associated with architecting and designing a system. Is that not a thing for an engineer to have a little bit of accountability towards a deadline, and towards a larger roadmap?

Travis:
Yeah. I think that that varies a lot, depending on team dynamics. On our team, the way we tend to do it is we do have a lot of feature ownership at an engineer level, just because, all right, our engineering team is super strong. Our product is uniquely engineer-y. Bringing in a lot of engineering influence is really good. I think that it’s a delicate balance. At the end of the day, it’s just a delicate balance. There’s a great Twitter account, I Am Developer, recently had this Tweet where he was just ranting about the additional overhead of making sure that JIRA reflects what you’re actually doing.


I think that level of maniacal process accountability is a bit of a drag. I do believe a lot in having an ongoing dynamic at the beginning of an implementation, between product and engineering where specs are a collaborative effort.

Owocki:
The other thing that I’ve noticed is a cultural thing. You want to have accountability for the individual engineers, but in order to do that, the engineers need to trust that accountability is not going to be weaponized. Since software engineering is fundamentally a creative discipline, if a deadline is missed, then it can be a real tough conversation when that sort of issue is going to get weaponized against that engineer.

Travis:
Absolutely. All too frequently—I love the term “weaponized,” by the way. All too frequently, this turns into, “Well, you said it would be done Thursday, therefore we’re just going to hit you with a hammer and force you to work unbelievable hours.” I think we should just do away with that.

Owocki:
You and I have the luxury of sort of working in companies where the founders are engineers. I’ve found that working in a company where you can be product focused and long-term focused has heavily correlated, for me at least, with having engineering or product founders.

Miles:
I would say even in a company where, I mean, our company isn’t engineering. That’s not our product. Even our CEO, his background is computer engineering. Even that background is super helpful.

Owocki:
I’d be curious, once I get into my late 30s and into my 40s and have worked for CEOs that aren’t first-time CEOs, if that trend changes a little bit, and people get more used to building software.

Travis:
I think that if you have engineering awareness at the level of founders or somewhere out there, you get a lot of compassion, which is great.

Miles:
It makes it easier to communicate a lot of those things that are hard for engineers to communicate sometimes, that GitPrime is trying to solve. People understand that and can trust that more, because they understand the engineering process.

Travis:
Yeah. Definitely.

Owocki:
What other engineering management-y type problems did you run into at your previous gig that GitPrime is trying to solve?

Travis:
I think one of things is, since engineering is a bit misunderstood, the work that we all do is very abstract. It’s invisible. We’re sort of the wizards of today. There’s a lack of understanding about what constitutes good requirements, and the notion that that should be, ideally, a dialog. One of the things that I think, arguably, waterfall did pretty well, was flesh out requirements. The idea behind waterfall was “You’ve got to know everything you’re going to build, down to a T. That’s exactly what you’ll get,” which was a bit of a myth.

In agile, in today’s world, sometimes you run into these stakeholders who are sort of like, “I don’t know what we’re building yet. Just get started and we’ll get right into it.” Which is like … it’s sort of a kickback against that waterfall state. You really can’t do that. You’ve got to start with some pretty good shared understanding of what the mission in, and then have business requirements filled in by stakeholders. I’ve found that teams that can do that really well. A lot of the problems, quote unquote, problems of engineering, are actually more problems in the stakeholder engineer dynamic, where engineers are not totally clear on what to build. They’ll take a run at it.

We had this one, this is a great story. I was working at this place awhile back where we had a very senior member of the product team tell us that they thought the app needed a mood button. That was how the requirement came in, taken in JIRA. A helpful engineer picks that thing up, he’s like, “All right. I’ll take a run at it.” Builds this thing. Spends two weeks building this thing. Ships it, and then of course, the stakeholder was like, “Well, that’s not what I meant.” That sort of cascade of miscommunication, I think, is one of the central problems that we should all sort of band together and solve, and get this idea that engineers can pretty much build anything that the people can conceive of, but you have to conceive in detail, and share that, ideally, in documentation, product documentation that’s super robust.

Miles:
That was going to be one of my next questions. You talk about code churn and other pieces of the data, but do you have experience in—and maybe it’s part of product—in terms of frequency of communication, and the methods of communication, that are lending to better relationships?

Travis:
Yeah. This is something that we’re currently prototyping to build into the app. Looking at the conversations surrounding code. In general, I think that the way that this gets serviced in the most interesting fashion is the tension right now between remote work or not-remote work. Everyone’s super opinionated about this. Our team is distributed. Our CTO is this awesome. If you’ve heard of Git-flow, that’s Vincent Driessen, the guy who sort of conceived of that, is our CTO. He’s in the Netherlands.

We communicate in a very well documented written fashion, which has proven to be great for the product and engineering dynamic. We’re starting to see that trend. When you have timezone lag, or you’re just in different spots, having things, having deliverables in writing, discussing them in writing, having a big socialization period before implementation starts, and rolling that into product culture. It’s not just good for our remote teams, it’s good for all teams. At the end of the day, even if you’ve got 10 engineers on-site, it’s still 10 people at computers, whether they’re there or at their house.

Having communication happen in a really well-documented way. We use the heck out of Slack, one of things that we’ve been very opinionated about. My co-founder, Ben Thompson, works here with me in the office. We’ll start having kind of a heavy, important discussion, and we’ll look at each other and say, “Let’s take this to Slack.” We’ll literally go to Slack, go into the appropriate product room and start having the conversation there, so that we include everyone who’s not physically in the office. I think things like that are pretty key. It’s sort of how you create an inclusive engineering culture that’s sort of a-synchronous and all the modern stuff.

Miles:
Yeah, definitely. In my experience, I think engineers, on one level, definitely understand that and can remember to go have that conversation on Slack. It’s really interesting to me to talk about changing the behavior or reminding non-engineering people about why it’s important to go from this really easy form of just speaking typing on a keyboard, why that’s important.

Travis:
Yep. We’re institutionalizing that. Even sales conversations, marketing conversations. If you get a high degree of visibility, people can drive themselves. You can just check up on that in 20 minutes. Everybody knows what’s going on. Engineers have great ideas about marketing. Sales oftentimes knows what the next feature should be, because they’re hearing it a lot.

Owocki:
It’s sort of interesting, because what we’re talking about here is a cultural issue, not really a technical issue. What would you say to an engineer out there that’s working in a company where remote work isn’t a big thing, and moving conversations to Slack just isn’t an option that’s going to fly, culturally? What should that engineer do?

Travis:
That’s a great question. I’ve been meaning to write up something on this. One of the biggest challenges is pushing back against requirements when you don’t have structural power, like org chart power. The best thing to there, in my experience, has been you basically use the Socratic method. You keep asking questions. Take the mood button example, which is kind of hilarious. You say, “Okay, what would that look like? Just draw for me on a napkin.” Then you kind of walk it out. “What happens when I do x?” Just keep asking questions until what you get is either a pretty decent set of requirements or the entire idea collapses in on itself. Either one of those is good. It can be tricky. Engineers tend to literally be the smartest people in the room. I think it can be pretty frustrating as an engineer when what you want is just to go build stuff, and you’re having to get into this process. It really requires a lot of patience to walk people out on that stuff and to be a little more political, basically.

Owocki:
I know where I would get tripped up on something like that is that at first, I’d be inquisitive, but I think that if I think an idea is dumb, then you’re probably going to know within two or three minutes of the question, just through my tone. To your point, it takes a lot of patience to untangle that feature. I guess it’s less pain to try and be patient and to have that conversation up front than it is to spend two weeks building a feature that’s going to get shipped and then never used.

Miles:
Not only in terms of requirements, I think. In my experience of doing client work, where I had to do a lot of that, sitting down with a client and sussing out all the details that they haven’t thought about, that also really helped me communicate the cost of things, especially when it came to changes mid-project. “Okay, let’s talk in detail about what that actually means, and then the light comes on in their head about, ‘Whoa, all those little pieces conflict with what we’ve already built. It’s going to be longer, or cost more money, or something.'”

Travis:
In my experience, the greatest engineering managers are the ones that take on a lot of that burden. Then the engineers get to keep engineering. It’s a glorious thing to work for a really good engineering manager. They just absorb all that stakeholder pressure, all the politics as this sort of membrane. What you receive is really kick-ass requirements and a clear idea of what your day should look like.

Miles:
I’m really interested in what you guys are doing. One of the other things that I notice a lot with engineering teams is the engineering manager’s generally, sometimes, just an engineer who’s comfortable speaking, but not necessarily the best at communicating, or understanding the business side of things. It’s really interesting having something that will try to codify and quantify something that’s more instructive and more helpful to increase better communication, not just words for volume’s sake.

Travis:
Yeah. Engineering doesn’t have a lot of great political tools. If you go to a marketing department, they’ve got really robust data about what’s converting and they can use that to go advocate for more budget. Same with a sales team. Basically, you push button, out comes a Salesforce report. You can see where people are getting stuck. You can use that to put healthy pressure on all sorts, everywhere in the organization. If you’ve ever been to a board meeting, or been the person at a board meeting representing engineering, it’s sort of this narrative song and dance. That’s really unfortunate. I think we all want engineering to be a first-class citizen.

Miles:
It’s funny how much we can quantify, but at the end of the day, without the real reports and tool what you’re speaking about to business people, it’s kind of just about trust. “Hey, it’s going to be two more months. Just trust me.” You know? “Sorry.”

Travis:
In a situation where making those promises is inherently very hard, because of the nature of the discipline.

Owocki:
I think I was at a board meeting once and somebody asked me how we were going to do something. I said, “You know, engineering manager-y things.” I literally waved my hands as I was doing it. You know, jazz hands. Because I’ve been down that route of trying to explain exactly what we’re doing. It doesn’t communicate across, sometimes. Winding back to your point, I think that trust is super important at that level. Building trust is, that’s where the devil’s in the details. You really have to be shipping and delivering value. That’s hard to quantify.

Miles:
It would also be super interesting to me, and I don’t know if you’ve had use case for your product or not for this, to have a history of projects and visually say, “Okay, that project back there is kind of similar to this project we’re thinking of doing. Here’s how it actually went, and here’s where it went off the rails. Here’s why it’s way more work and time than we’re actually thinking this new project is going to be.” That’s one of the things that I always am finding myself doing. Someone will be like, “Hey, let’s do this, this, and that.” I’ll be like, “Well, actually, it’s a lot more work than you think.” If you could point to past projects that are similar and be like, “Hey, see how long that thing took?”

Travis:
We definitely want to get there. We also want to role in very deep-level detail about actors. How does working with a particular product owner impact our ability to estimate? That’s a really interesting question. We’ve had some of our teams take the data that we’re providing and manually look, they sort of create groupings of the work that happened across product owners. They can communicate with those teams, like, “This person seems to be doing a great job with requirements. How about we all learn from them?” They have all this data to back it up. I think benchmarking historical feature implementations, looking at being able to prove with data that a couple day’s worth of discussion on requirements pays dividends empirically, fascinating stuff.

Miles:
You could almost envision this, if that gets really, really good, having a GitPrime profile as VP of engineering. You could be like, “Hey, look at my-” Right now, on GitHub, it’s how frequently I put code in my repos and stuff like that, but you could be like, “Here are all my repos and here are all my-”

Owocki:
Travis, if you replaced LinkedIn for me, I’ll buy you a bunch of beers.

Miles:
Yeah, seriously.

Travis:
I think we would be drowning in beer. That’s like the holy grail. The thing that’s funny about engineering is you have all these different variables and different profiles of people working together. So you’ve got people who are the vanguard. They just go and they do the first push on implementation. It’s quick. It’s dirty. It’s not long-lasting code. Then you’ve got these oftentimes more senior engineers who come in there, doing a bunch of re-factoring and lay down bedrock. It will last forever. If you could get a read on that, of who the players in the team are, you can build a really powerful team that way. Capitalize on people’s strengths.

Owocki:
Should we bring it back home?

Miles:
Yeah.

Owocki:
All right. To you, Miles.

Miles:
All right. What are your engineering values?

Travis:
The top engineering values for us would be requirements shouldn’t be a struggle for engineers. They’re always a little bit of a … we always want to see really drilled out requirements, but that burden lies on the stakeholder. We think that engineers should get to maximize their time building stuff and being masters of their craft. Along those lines, we tend to involve engineer early in the spec phase, so we’ve sort of destroyed the wall. The second thing here is there is not product team versus engineering team. We roll those together, and we’re just like the product engineering team, which has been really successful for us. Then better to ask for forgiveness than permission. Initially, this was sort of a casualty of time zones, then we came back and institutionalized it: Just take a shot. Take a swing at a feature rather than sort of waiting on stuff, because in general, we’re working with people we trust.

Miles:
That’s a good segue into my final question, which is, do you have any great engineering war stories?

Travis:
Gosh. I bet we do. The mood button one is pretty fantastic. That was not from this company. From this one, we have one sort of epic long engineering war story. In the beginning, we-

Owocki:
I feel like we need to turn on a fireplace and get some cocoa or something.

Travis:
The prototype and proof of concept was my co-founder and I rolling out a bunch of early stuff. We did that, sort of proofed it out, got a round of funding. We said, “All right, let’s build it for real.” We went and got a contract team in who did a great job getting their early build out. The thing was awesome. We shipped it. We got a customer.

Then the ensuing implementations from there were this really interesting dance of cleaning up some of the early assumptions. There was a little bit of technical data in there. Cleaning that up while balancing shipping new features was just crazy difficult. Mad props to our engineering team, because every single week, there was sort of the shadow work that was happening with a ton of stuff that shipped that was hyper visible. They have continued to do that every single week, every single month, since then. It’s one of these stories, I guess you kind of, it’s sort of a you-had-to-be-there thing, but I think that this is a really good lesson for an engineering team, since I’m now kind of on the stakeholder side.

Throw people a visible bone, and you can do a lot of that cleanup work that we always want to do as engineers. That balance, it’s basically almost just a 50-50 division of work, whether it’s foundation, whether it’s R&D, whether it’s technical debt, just tons of foundational work with a bunch of things that are visible that are not necessarily high cost. The stuff that users want are like, “This button is hard for me to understand.” If you can balance those things and do a major and a minor sprint is one way that we’ve done that. The minor sprint is all of these quality of life upgrades, and the major sprint is laying track in the guts of the app. That’s been super successful.

Owocki:
It strikes me from your story that you guys might be using GitPrime to build GitPrime.

Travis:
Oh, yeah.

Owocki:
There’s a level of meta there that I’m jealous of.

Travis:
It does sort of feed back on itself. We look at these reports. We’re like, “Gosh, you know what would be really great in here?”

Miles:
That’s awesome.

Owocki:
That is very cool. All right, Travis. Thanks so much for being on the podcast.

Travis:
Yeah, thank you guys.

Owocki:
Okay. Thanks for listening. Find us at execpodcast.com, or on Twitter @execpodcast.

Ben Thompson

Ben Thompson

Ben Thompson is a co-founder at GitPrime where he leads design and customer experience. He is a Y Combinator alumni, with a background in product design, branding, and UX design. Follow @thebent on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Learn how engineering leaders are using data to help their team increase productivity and become even more effective. We've analyzed over 40 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This