Interview by Thomas Peham
January 12, 2016
Photos by Pivotal Tracker
Dan Podsedly manages Pivotal Tracker, Pivotal Labs’ award winning project management and collaboration software.
Even before Pivotal Tracker, Dan had found his passion for the agile development paradigm.
While a lot of collaboration software has come and gone, Dan has managed to keep Pivotal Tracker on track since its launch in 2008.
Share this interview:
Thanks so much for your time, Dan! Can you share some insights on what a typical day in the life of the GM of Pivotal Tracker looks like?
Sure. Monday is always the most challenging day for me, because it’s a new week, and sometimes I forget what happened three days ago.
Our team, the Pivotal Tracker team, is about 30 people now. We also work with other teams at Pivotal, Pivotal Labs in particular. In my role I try to maintain the vision, observe our overall road map, and work closely with other people on our product team.
Much of what I do is trying to keep us heading in a steady direction.
Part of my job is mapping it all out, down to the tactical steps that we take every day toward that direction. Sometimes, we have to change direction, and I get to make some hard decisions about what we want to do and what we don’t want to do. Keeping the team up to date on what we’re doing and why we’re doing it is part of my job as well.
I also do a lot of things that crop up. I make sure that we’re collaborating well, that we take care of things before they get too bad. One of my other jobs is making sure that we get out of the office for happy hour or a curling event game frequently enough, because that’s also a way to build camaraderie and celebrate our wins as a team.
It’s really important to keep communication over a beer after work alive.
Since we’re also part of a much larger company at Pivotal—with about 1,500 to 2,000 people—I make sure that there are connections between Pivotal and Pivotal Tracker. I’m also involved in hiring and tend to do a lot of the initial technical interviews with developers.
Can you give some insights into the process which made you choose to start at Pivotal Labs back in 2004?
Sure. Pivotal Labs sort of emerged out of a group of us who were already working together in a less formal capacity. We were a bunch of contractors who happened to be on the same project back in the early 2000s and even before that, to a certain extent.
What brought us together was, partly, technology. In that era, there was a lot of buzz about object-oriented technology, and that led to extreme programming methodologies, XP for short. We were doing object-oriented programming and XP, working on some big projects in the Bay Area and Silicon Valley.
As a way of working, extreme programming really made sense for us and we found it pretty effective.
Early on, Rob Mee, Edward Hyatt and myself worked at a startup where we took care to do XP properly. It was all about pairing, test-driving, small teams, and the customer was actually in the room.
All of this stuff, which is pretty standard today. Agile was a new thing as well back then. We were doing some amazing stuff, like continuous delivery and deployment. It was a fantastic energy that we had.
However, that startup didn’t succeed, because it was hit hard by the dot com crash. But we learned a lot and, gradually, that became the beginning of Pivotal Labs. We were starting to build things for other startups, and our secret sauce was the way we were working.
Even though there are books written about it everywhere, this kind of basic stuff always gets overlooked.
Nobody talks about the basics. However, the basics are really what matter. And we just embraced the basics.
We started to work with a lot of startups. We were squished into this little office, almost like a doctor’s office, in the old Flood building above San Francisco’s Union Square. There were just a few of us, and we were doing this XP thing. We figured we weren’t smart enough to do amazing things without having processes and structure in place first. Structure being: Small increments, one backlog, a small team, very good communication, and tests to make sure we don’t make mistakes, because we can’t afford to make mistakes.
We are also got good at just saying ‘no’.
We grew organically, and Pivotal Tracker was something that was there from the very beginning. Pivotal Tracker was that simple tool we needed to stay focused on a clear, fine-grain backlog.
That’s all that Pivotal Tracker was. Just a simple tool, this thing on the side. Everybody who started at Pivotal Labs has worked on Pivotal Tracker at some point.
Can you share some ups and downs of Pivotal Tracker since officially launching it in 2008?
Every software product or code-based service that has been around for decades is going to have some inherent challenges. Over the span of ten years any product is going to see different people coming and going.
One thing that I’ve realized is that, in general, there is a very strong connection between people and code.
As people come and go, they bring new ideas, ways of thinking, and attachments with them. The code will morph with the people. If we were to hire a whole new team and hand them our code base, they would probably refuse to work with it, because it’s not their code.
They would immediately start changing everything, because this is not how they would do it. With over ten years in business, you get a lot of that.
We’ve done a number of, medium to very large, rewrites, which were always a challenge. Do you keep going incrementally, and just do a little bit of refactoring along with a new feature? At some point, you start hitting some bigger walls, and you have to break those walls down.
We had a big rewrite, which we expected would take us about six months. In the end it really took us three times that until we had the feeling that it was done.
The other challenge is that Pivotal Tracker is built for a very specific need. We have a certain philosophy about how software teams should work at Pivotal. That philosophy is embodied in Tracker as a tool. It assumes your team has embraced Pivotal-style agile practices and Tracker as a result is very good at keeping you on the rails, nudging you to stay on this well defined path. Tracker does offer some amount of flexibility, but teams that want to assert different ways of working, that's where we generally agree we can't really help them as much they’d like us to.
For us, this has always been a product challenge, whether we make Pivotal Tracker more flexible and support different ways of working – or not. There’s a huge market for more general-purpose, more customizable, more flexible tools. And we would probably have more users and more revenue. But one of the things that we want Pivotal Tracker to be, one of the things that makes it unique, is that it is very much about working in this particular way and encouraging it.
There are always distractions to do something crazy, fun, huge. Though, you have to stay on a steady path and, for us, it’s always been focused on the process.
What major trends and challenges are we going to face in software engineering?
Every year, there’s a new and better way to do X, whatever X may be, whether it’s a new kind of database for web application or a new frontend framework.
Don’t always go for the shiny toys.
The things that really matter are how you’re organized, how you choose your priorities, going incrementally, getting feedback and validation.
Everything is always evolving. I think, on the engineering front we have a pretty solid attachment to a certain way of working, because it has worked for such a long time.
The challenge is scaling. How do you go from five, ten, twenty person teams to teams of 50, 100, 500. At Pivotal we take a bottom up approach: You’ve got to have solid, small teams, and it’s all about how those small teams work together.
Our roadmap for this year is focused on better supporting teams and companies as they grow, for example in terms of cross-project visibility and more complex story acceptance workflows.
Has there been any special moment which you would recall as a big influence for making you go into the tech industry?
I have to think really far back now. I think the main influence which eventually got me into programming was walking into Radio Shack stores. They always had some sort of a machine there that you could play with.
I found it really fascinating to type character by character into whatever the DOS console was. It was amazing, and I ended up having Apple computers at home. I played around with them a lot, and did a bunch of coding just on my own, as a kid.
In my teenage years I kind of forgot about that. I was trying to be too cool, and didn’t like going to school.
I was hanging out with friends my parents didn’t approve of.
There are some interesting paths that I ended up taking and, in fact, I ended up dropping out of high school and started working at an auto parts counter at a Canadian Tire in Toronto.
I was pretty close to having a completely different journey, and then something reminded me: I can’t do this forever, I should do something I know I can do.
I kind of found my way back to school and took programming, analysis and computer science. But, in the end, I think, it was just walking around in a mall and seeing a shiny Apple 2 computer that pulled me in.
Can you share a bit how you handle your recruiting at Pivotal Tracker, and what the process looks like?
I’ll focus on the hiring process for engineers, because that’s always been our big recruiting focus, and we’re a pretty engineer-heavy organization.
Recruiting at Pivotal Tracker isn’t any different from recruiting at Pivotal Labs in general. The process is a little different from what’s typical at other companies.
If you apply for a job at Google or any other tech company (not to pick out any companies) you have to go in front of a committee with their arms folded, and they make you do some algorithms on a white board, and write some code with a marker. And you wonder about that, because this is not the way you would normally work. Nobody works this way.
It’s pretty well-known that we’re all about XP teams, and people coming to work for us are going to pair all day, every day.
Generally, we invite our applicants for what we call an RPI. RPI stands for Rob Pairing Interview. Who’s Rob? Rob Mee is the CEO of Pivotal.
He’s done a lot of those interviews over the years, but I hope he no longer does them on a daily basis, because now he’s the CEO of Pivotal and probably has more important things to do than spending his days RPI-ing.
But it’s called Rob Pairing Interview because everyone who does it, does it the same way. It’s really just a one hour pairing session. You sit down and pair on something, and it might be a contrived example, but there is a well-defined path through that example, and it touches on a lot of interesting things that are about the basics.
It’s not so much about the coding, it’s about the conversations.
It‘s about being able to verbalize thoughts. Can they read you? Do they hone in on what you’re trying to say? Do they learn from every step? Is there enough empathy there to be able to work as part of a highly collaborative team?
That’s step one, and it uncovers so much. Then we invite them to an on-site, where they come and pair with the real team for half a day or a day. They work on real things, and it’s like: This is what you would do if you were to come work for us.
That’s our interview process, rather than something contrived on a whiteboard, and it has worked well for us so far.
Is there any great piece of career advice you’ve ever received and would like to share with us?
I tend to be a little stubborn and ignore people’s advice, especially when it comes to careers. I’ve been fortunate to work with some pretty amazing people, especially at Pivotal. Pivotal’s become a dream career, because we’ve just done so many things.
I think the long haul versus just going for the quick win has always been a guiding principle for me. And I would tell myself to think a little bit further, even. I think the one thing I did right is getting connected to the right people. That’s what has opened all these doors for me and allowed me to do the things I’ve done.
Technology keeps changing. Don't go chasing it, it’s not always a silver bullet.
The things that end up mattering in the long run are maybe the more boring things. Take everything with a grain of salt, and keep the eye on the ball. The big things are people, relationships, loyalty.
If there’s a way to invest in those skills, it will have far more impact in the long run than any technical choice.
There’s nothing better than a team that works well together and goes through some experiences together, whether they’re ups or downs. There’s simply something amazing about that.