HWGSD: David Messent

So you have talented people on a high-functioning team… Now what?

David Messent, a product manager at Omni Group, knows what it means to get things done. But it’s not because he stresses about “productivity.” It’s because his company hires carefully and keeps their engineers happy.

Below is my “How We Get Shit Done (HWGSD)” chat with David. Here are the highlights:

→  Productivity comes down to keeping smart people happy and engaged in their work.

→  As your teams and projects grow larger, your concerns may shift from having too much overlap between people to not having enough.

→  As a product manager, you’re not always the engineers’ manager. So “authority” can’t be a prerequisite for motivating a team.

→  When your team is already high-functioning, your biggest obstacles are external, rather than internal.

---

 

To set the stage, what’s your background with product management?

I had a background in tech support and training. Then I started at Omni Group in 2007 as a customer support person. At that time, all the PMs [project managers] at Omni came from support because of their role as customer advocates.

I was asked to help manage a product called OmniGraphSketcher, which was a brief excursion for Omni — we had one release and one iPad release — and that was a great experience. In 2014, when the OmniFocus PM job became available, I was asked to do that. I also have some formal training through the University of Washington Extension Course: I’ve studied product design and agile methods and go-to-market strategy, some of which I use in my job at Omni… and some of which I don’t.

Things at Omni have been pretty free-form. Each team gets to self-organize in a way that works for them, as long as it’s not too hard for other departments to work with them. So we have a fair bit of flexibility in how we run things and we’ve gotten to feel things out along the way.

Do you have both product managers and project managers?

No. In fact, our product managers are probably closer to project managers, in that we don’t do a ton of marketing activities. We do some product design, a lot of project management, and very little marketing.

One of the important things at Omni is that we’re a team built by engineers for engineers. We’re bootstrapped, so we don’t have shareholders or VC [venture capital] or anything like that, so we basically do what we want. That extends especially into the engineering department. For us, productivity is a matter of making sure the very smart people we hire are doing something that is gratifying to them and keeps them engaged. It’s not that they can’t work on things they don’t want to do, but it’s certainly a multiplier when they get really excited about a feature, or a bug even. We try to space that work around so that everyone gets a taste of it, and nobody gets stuck being the guy or gal with the mop for a long period of time. That’s an important part of keeping the team happy, and I think that’s the best way to ensure productivity for an organization that’s designed the way ours is.

I’ve had a change of heart about this recently. I used to think, “Systems and tools: that’s what we need!” But I just read Peopleware… 

Yeah! Peopleware!

…so what you’re saying about hiring good engineers, keeping them happy and giving them good stuff to work on, rings really true.

That’s a huge thing for us, and that’s a reason why our growth is slow. We’re super picky, especially about engineering hires.

In the past, we had fairly strict rules about how big a team could be and still be productive. But we’re finding that as our applications get more complex and are on more platforms — everything’s on both Mac and iOS — that it gives people enough room, letting us to have teams of five engineers with a part-time floater. And they can all be working and not get in each other’s way.

We’re usually afraid of loss of productivity because of collisions and getting in each other’s way, but now we’re even having the reverse problem. In the last retrospective I had, one of my engineers said, “I felt like I was too isolated from the rest of the team because of what I was working on.” His work was isolated enough and he was challenged enough that he didn’t have the leisure to read other people’s commits. He didn’t feel like he was on the team.

Have you always had this perspective on team dynamics or has it changed for you over time?

For the last year and a half, I’ve been on a team that is super high-functioning. Seeing what they’ve been able to accomplish has won me over in terms of Peopleware. But if you had asked me two years ago, I might have said, “Yeah, we need to find a way to get engineers to do what we want them to do!”

Sometimes when you’re a product manager, you’re not actually somebody’s boss. You’re in charge of the product, but you don’t have a lot of control over how someone else’s department is run. So when there are problems — if you have an engineer who isn’t properly motivated, or is having a personal issue, or is in over their head — and you can’t make a change that helps them, then you’re kind of stuck.

The big thing is: you need to find a way to keep communication happening. That’s easier for us at Omni because we don’t have any remotes at all. This hurts us in hiring, but it helps us in productivity. We have great communication within and between the teams, we have the in-person dynamics, and we also have a custom bug/development database. We wrote the app years and years ago, and it’s kept gaining features. It’s both an issue tracker and a planning app. We have milestones in there and we can assign various metadata. Almost everyone in the company lives out of that app, although they use it in different ways. The features that the support team wants, for instance, are different from the features that would help me. Of course, finding time for internal projects that don’t make you any money is another thing…

Tell me about that!

In general, that internal stuff gets done when we feel like we have a second to breathe. A couple years ago, we had “December Projects,” where everyone took a month to work on something that wasn’t necessarily a commercial product. It could have been some technical debt work on one of those products, but it wasn’t a shipping feature. So we saw some advancement in our internal tools then.

We also have interns. Our getting-feet-wet project for the interns is working on our bug tracking system. It lets them touch our code without affecting too much, and that’s worked out pretty well. It’s not like our internal tools are languishing, but they get exactly the amount of resources that are necessary to keep them running.

So let’s say that you’ve hired great people and you have a high-functioning team. Nonetheless, there will be some obstacles, right? What are these obstacles and how do you address them?

Usually the biggest obstacles are external. They get thrown at us from Apple. It’s at the point with Apple where we try to have the decks cleared in June every year before WWDC, assuming we’ll be working heads down for the entire summer after that on whatever they debut there. And then we ship in October/November. Then we have the remaining six months of the year to work on the stuff that we want to work on. Adapting Apple features is so important to our visibility, so it’s something that we really emphasize.

There was one summer in particular — the iOS 7 summer, when the way iOS looks completely changed — when every app was faced with having to update or else look like they were a dinosaur. That was pretty tough. Thankfully we haven’t had as sweeping of a change since then, and let’s hope we don’t have another one this year.

Situations like that affect the usual things, like work-life balance. It means that people have to work harder, which means that they’re more stressed, and that can affect communication. But after that, it has to affect scope. We believe so strongly in work-life balance, so we’re not going to push people past the breaking point. We’re also not in a position to scale the size of our company so quickly to meet that kind of demand — it’s not in our best interest long-term to do that — so scope is the kind of thing that has to give.

Because of the position Omni was in at the start of the App Store, we’re able to do things that other companies that are starting now can’t do. We had an audience that was looking for our products on the App Store already, so we were able to price our apps the way we were used to pricing them pre-App Store. We also had relationships with people at Apple already and we had proven ourselves as a quality developer, so Apple had interest in having us on the platform.

There’s a podcast app called Overcast that has a “patronage” pricing model. The app is free, but if you like it you can choose to make a recurring donation to the app. This is a developer who’s been on the platform for a long time and has a lot of people buying his apps already. In his blogpost about the pricing model, he argues that any developer could do this. But, in reality, any developer needs to work for a long time to get to the point where they could implement that strategy. To say that it’s a viable pricing model for someone just starting a company today isn’t right.

Similarly, I acknowledge that we’re able to get away with a lot of the things we do at Omni because of the way we’ve been doing things for the last 20 years.

One last question, stemming on my own insecurity about not programming. Do you program? Do you think it’s an important part of product management?

I don’t program anywhere near at the level… I could not be employed as a programmer in any capacity! But I write a little bit of Python. And I understand basic computer science concepts. And I know my way around our build system and other sysadmin-y type of stuff, so that I’m not a burden to other technical people. If you’re really after productivity, you don’t want to have your engineers helping you with something technical rather than doing the work that they’re being paid to do… because chances are they’re making more than you are. [laughs]

But just the same, that’s one of the things I’m going to pursue next year as part of my professional development: trying to get a little more Cocoa programming experience so I can read commit messages and know more about what’s going on. 

Thankfully, I do have a former computer science professor on my team, so he’s always willing to explain things! [laughs]

For more about how things work at Omni Group, read Inside Omni.