In this installment of CodeProject interviews we talk to Elizabeth Ayer, the Redgate SQL Source Control product manager and developer with a clear passion for user experience.
You’ve been at Redgate for close to a decade. What path did you take to get there?
EA: I was a math and computer science major back in the very old days and moved to the UK for my post-graduate work. I quickly realized that it was a little bit too abstract and what I really wanted to do was make things. So I was a programmer myself for a number of years - first for some educational websites and then for a division of Siemens which did, entertainingly enough, product lifecycle management. And I say entertainingly because now we're focusing on database lifecycle management, which to me looks like completely unrelated things with almost identical names.
Before Redgate I was working for this 450,000 person company and realized I was just too distant from the problems I was trying to solve. I was too distant from the users and the things I was trying to develop weren’t actually making people's lives better. So that’s when I made the move to Redgate. Here, I have the direct ability to drink in the user needs and turn those into something that can actually make people's lives better.
I’ve been a product manager since I started here, focusing on a number of different tools from IT administration, to developer tools, and now a strong focus on database.
In your role today, you are the product manager for SQL Source Control. What kinds of things are the team working on? What does an average day look like for your team?
EA: There are actually two teams working on this project right now. One is doing a revamp of migration functionality, which basically lets you do overrides. If you don’t want to deploy things the way that it’s automatically done, you can write some SQL to customize it. Our first version of migration met some of the needs but not enough so we’re doing a big overhaul. One whole team is working on that – I say whole team and it sounds grand, but it’s basically two developers, a tester, and a user experience specialist.
The other team is the mainline team. And there are five developers, two testers, a technical communication specialist, and each team has a project manager.
The average day is a little different for each developer, but we do have some constants. We tend to be fairly flexible with time so people will start arriving from early in the morning. Each team will have a daily stand up – it’s very scrum-board focused. We have a lot of communication around boards and Post-its. It’s a very Post-it-heavy environment – like there are Post-its littering the walls and floors here. I assume you have never been to our building, but if you have, you would know how the Post-it company stays in business.
What is the SQL Source Control development team methodology?
EA: We work in what are called Release Trains. The idea is that you take large themes of work and then give the team some autonomy within those themes to figure out how to solve the problems. You try to equip them with the tools and information they need to make their own judgment on the best way to meet the user needs. They work in one or two week sprints (or time boxes) and it’s all about breaking that big meaningful thing into tractable smaller chunks and then plowing through it.
The time boxing makes you really aware of your tradeoffs, keeps you super focused, and really aids in clear prioritization. You end up delivering the highest value things in the scope of that fairly short time timeframe.
As an example, Git integration was born of this methodology. The team was given the theme of "we want to support Git better, here is your time box, go." They were able to pick out what were the most important things for our users. Based in part on what they know about Git, it’s a perfect thing to give developers some autonomy over because they are the experts in version control, not a business person, and also on user feedback. They were able to translate that into the top features and just knock them off in strict value order.
Transparency – particularly with your product roadmap – also seems to be part of your methodology. Can you explain that a little?
EA: The SQL Source Control team have a slightly further out-looking road map than other projects. That said, the other product teams might have a shorter horizon, but that level of transparency is certainly the way products get managed at Redgate. What’s interesting to me is that four years ago or so we were really cagey about these things. We really agonized about whether or not we should put the roadmap up – what if the competition would find out?
We eventually realized that the most important thing was bringing awareness in general to our customers. They needed to understand what they were getting into when they purchase our product. They needed to know what to expect. It was never going to matter if our competition found out our plans. Over the last couple of years we’ve increased transparency and openness and the end result is an improved relationship with our customers.
You’ve mentioned the user quite a bit. They seem to be at the center of your company culture. Talk to us a little about that.
EA: We do have a great culture. I think we were unique like ten years ago but Silicon Valley has since caught up with us, so I can't claim that we are the only one to have an amazing culture now. At the end of the day, we are really devoted to solving our users’ problems. That’s core to our ethos of how we develop our software.
It was that way from the absolute get go. Redgate was created to solve the actual user problems, but we wanted to do it in a way that actually treated the end user like a grown-up who was capable of making his or her own tooling decisions. So, yes, that is very much embedded in the culture that we have here. I guess that's also been present because we were some of the earliest people in the Cambridge area who even employed or knew what a user experience person was and that they've always had a huge influence on products in Redgate. Even though the whole development team is fairly oriented towards what an end user is trying to achieve and what the goals are, also having people there who are one hundred percent focused on that end user experience of our products is important.
Where do you see the organization going from here?
EA: From my perspective, there's something really interesting going on at Redgate right now. As developers change the way they work – as they move to continuous integration and continuous delivery - their tooling needs change as well. The things that we're developing need to fit into this new way of creating software and they need to enable the changes that are happening as developers are making their whole processes better. Before it was much more: "Ah, you have a problem? Here. We’ll fix it." Now we’re thinking about the developer process and ways we can modify our products to help with the transition and process. We’re going from a kind of really narrow point tool focus, to trying to make sure we enable these changes. That’s really interesting to me.
From a personal perspective, what has been your favorite project to work on thus far in your career?
EA: What’s been my favorite so far? I’ve been on some really great projects. At the risk of upsetting one of my two projects at the moment, I’m going to pick one that is actually going on right now. The SQL Source Control migrations one. The reason I say that is that the team is one of the best I've ever worked with. And again, I hate to say that because this isn’t meant to take anything away from my other team, but working with a team who really, really gets it - who just understand what the users are trying to achieve and has internalized that so well – it’s just such a pleasure. I’m really enjoying working with developers that understand at a deep level what the user problems are.
For a developer just starting out, what kind of advice would you give to him or her so they could find themselves on a team that works that fluidly together?
EA: Maybe this is a product manager-centric view, but I think the advice is to understand the user problem. If you know that then you are better aligned by a guiding principle that’s actually shared. The actual teamwork, the day-to-day work then becomes really straightforward and discussion becomes just that - actual discussions rather than arguments from different principles.
Getting that deep understanding of users needs does takes some time to build up. Unfortunately, you have to actually spend some time away from your computer, but by stepping outside of your typical work day and spending time with the user. That is like a force multiplier on every line of code you write because you know that it’s going in the right direction.
