Interview with Jason Nochlin, CTO & Co-Founder at GaggleAMP

Ledge: Hey, Jason. Good to have you here. Thanks for joining us.

Jason: Glad to be here, Ledge. Thank you.

Ledge: Absolutely. So, would you mind tell us a little bit about yourself and your work and company, and what you guys are doing?

Jason: Sure. I am the CTO at GaggleAMP. We’re a 25-person company. We build an app that lets other companies get their employees involved in their digital marketing. So, if you have a thousand people and you want to spoon-feed them content to share on Twitter, LinkedIn and other networks online, our applications make that process super easy for both your marketing team and user employees in your company.

I came on as co-founder with our CEO, Glen Gaudet, in 2011. We had just an idea, my coding chops and Glen’s selling ability, and we ended up bootstrapping the company. Thought we’d be venture-funded. Talked to some investors who didn’t quite get the idea, but our customers really loved it so we just focused on the customers. We’ve been doing that for almost 10 years now.

Now, on the product development side we have a team of 12. Three on what I call the product design team – so product management plus designers – and nine engineers.

Ledge: Wow. Cool, all right. You wrote all the initial code and now you had to grow a team of 12. What’s that like? Share some of the stories on the way there. That’s a pretty long journey.

Jason: There’s definitely a lot of surprises along the way. We’ve had a lot of luck finding people who were doing freelancing previously, and then giving them a really good environment to come work in. That’s been our model, is to try to find frustrated freelancers out there and bring them in.

Ledge: We know about that, yeah.

Jason: I know you guys do. We’re very pragmatic in our initial hiring. I’m a strong backend developer. I’m not the guy who can make it look pretty, or I’m not the best one to be tweaking around HTML. Don’t have the patience to back in 2011 or deal with the IE bugs and things like that. So, our first hire was a frontend engineer who’s still with us, which is really cool.

We just plugged holes and then one day, all of a sudden, I was a manager. Once you head five or six people you start realizing you’re spending more time helping other people and doing ‘management’ than you are coding on your own.

Ledge: Yeah. I talk to a lot of tech leaders who struggle to get out of the code, like don’t want to. That they really like doing the code, and switching to a world of coaching, mentoring, setting standards and doing code reviews and all that is not rewarding.

I guess you did find it rewarding, or at least rewarding enough, but how do you balance the two things?

Jason: For me it was quite a calibration. I think I’ve gone too far off on both sides. There was one point when we had, I think, seven or eight people, and every Wednesday I’d have 15-minute one-on-ones with the whole team. Just boom, boom, boom, boom, boom. That was the way I was trying to manage the team.

Like this podcast, we talked for 15, 20 minutes just to warm up ahead of time. Fifteen minutes is not enough time to really have a growth-oriented coaching conversation with someone. I realized that model didn’t work, so went down to less frequent one-on-ones.

Through the whole thing though, I still have a very strong passion for coding. I knew I had to segment it out where I would have some ability to do some coding, but also giving the team what they need. Went back and forth between doing less management and more coding, and then more management over the years.

I would say one of our key hires that helped me out a lot was getting a solid product manager who also had experience in larger organizations. She was able to come in and set up some really strong processes for us that really let us bring the team from about 6, 7 people up to 12 where we are now, without the management side becoming too much of a headache.

Now a lot of what I used to do in one-on-one’s – e have things like going through specific issues, talking about implementation and design strategies, is now handled by regular ceremonies that other team members are leading.

Now, when I do have a one-on-one I can focus on what I’m best at, which is just helping just them talk through really tough problems or new technologies or other growth ideas that they have. I don’t have to spend as much time getting in the weeds in individual features.

Then, when I’m not doing the one-on-ones, I’m able to really focus deeply on the projects that we’re doing that I’ve chosen to focus on.

Ledge: Do you switch hats? Everybody knows you’re the big boss man, and if you’re coding and you’re a contributing member on the team, do you sit back in a standup and be like, “Hey, I am just another engineer.” Do you have to switch hats?

It would be easy, I would think, to overwhelm a ceremony because your ideas and opinions would get over-weighted because you’re the man, right? Do you have to be deliberate about that? How do you accomplish it?

Jason: A lot of it depends on the personalities of the team. I think early on when we were smaller a lot of our meetings ended up being the Jason Show. I would be driving everything.

But we’ve built a culture where one of the key tenets is taking the initiative. We want to have everyone step up and fill holes when they see them, and not wait for permission to do that.

Now I feel like I get pushed out of ideas a lot in meetings. I’ll bring up an argument and then two people will jump on me and have six reasons that that’s wrong and we need to try something else. Or, if it’s a design meeting, we might resolve to an AB test if I have a strong opinion and someone else has a strong opinion or someone else has a strong opinion.

I think I’ve been lucky where there’s definitely the founder effect and everyone wants to present good news to the boss, but by having strong people who’ve been in past organizations and have experience they know to push back on that. The focus is really on what’s best for the company, what’s best for the customer, and not on implementing Jason’s vision.

It’s definitely frustrating sometimes but, overall, I’m very thankful to have a team that treat me as Moses coming down from the mountain.

Ledge: Yeah. It’s true. Your vision got to a certain point that was critically important, so you can’t give that away entirely. It’s like, hey, I innately know some things and I know some patterns of thinking that matter. But you also need to have the ego-swallowing event of getting out of the way and this thing is going to evolve past me.

I think every founder goes through that, not just in engineering. If we want to grow this, it becomes not just my thing anymore. I’m curious…

Jason: I end up having a lot of conversations along those lines of, if we’re getting too involved in something we’re going to end up being the bottlenecks. So how do we give that up? Or maybe it’s something that’s just not that important and we can leave it unmanaged for a period of time and come back to it.

Ledge: Sure. I would imagine a good product manager disposition is going to lead you in the direction of building for the customer anyway. That’s another reason that a hire like that is super important.

It’s also one of those things were you’re like, that’s an expensive investment – a person that focuses on product. What does that mean? We’re engineers. We can do this ourselves. We build the thing.

What was that mindset like, to understand the product is a function? That’s pretty hot now. I don’t think in the last couple years that that is as mind-blowing as it might have been some years ago.

Jason: From my experience hiring that first product manager, it was a perfect example of getting the right person who then figured out what the role was.

I was freelancing before GaggleAMP and hadn’t worked in any other company before, so I didn’t even really know what the product manager function was or was supposed to do. What I thought we needed was just someone to write requirements and get things ready for the engineers. It ended up being a lot more than that.

Plus, we brought in someone who I thought was really strong in the role and went above and beyond the role. She was able to introduce a lot of other processes and do things beyond just what a product manager would do.

Ledge: One thing I’ve seen with product management is, particularly from a larger company disposition, that there’s a dual role of what I would maybe call delivery manager and product.

That process stuff isn’t the pure product manager kind of role that you read out of the textbook. It is all of that talk to the users and get all the feedback and write user stories and stuff, but oh no, don’t let me touch all that process and scrum and ceremony stuff. Leave the scrum master to do that.

Have you merged those worlds?

Jason: They were merged here for a while. We experimented a couple times with getting a dedicated project manager. We found that the activities that we were expecting that role to do, really hard to do if you weren’t a product manager or an engineer. So, having someone nontechnical, at least for how we were approaching it, it didn’t really work out.

What we’ve done is taken that release management role and it’s shared amongst our engineering team at this point. That was one of the things that our product manager brings up a lot in conversations with me, is she didn’t want to be doing those activities because it’s not her core skillset – even that’s what the company needed at the time.

We’re still trying to figure out that balance now. Eventually, we’ll probably need some kind of dedicated Head of Engineering to work with our Head of Product, but we’re not there today.

Ledge: Yeah, cool. What have you learned about scaling the product? You’re dealing with big clients. You’ve got I guess probably a lot of transactional work – talking about thousands and thousands of people and trying to get things done.

Walk through some of those design decisions.

Jason: It’s interesting. Our modus operandi is primarily to take feedback from customers and bring that into our product design. We’ll do a mock up and then go have a conversation with four or five customers around it, capture that feedback in our Wiki, and then use that to inform the design process.

Usually, when we have a design meeting that goes off the rails where we’re getting too focused on minute points, someone will raise their hand and say, “Let’s go back and review the customer use case and make sure we’re aligned there.” Having that, always referring back to the use case and the specific request of the customer, has helped us make really good design decisions.

The other thing that we decided to do, I think about 18 months ago now, that we’re just starting to release is do a platform rewrite. We had this code base that I had written however many thousands of lines in 2011 and 2012, 2013, mostly by myself. Then we brought in more engineers and we kept changing design preferences and just architecture willy-nilly. It’s like someone would watch a talk and we’d implement a pattern.

We started over with some new functionality that we wanted to build. We decided to start that as a new application, rather than building it into our existing application. That did slow down product development for a period of time, but it’s going to give us a much better foundation to go forward for the next three to five years, once that’s fully ready.

Ledge: We’ve had a lot of people talk about the tradeoffs and monolith or microservice. You sound like maybe you’ve landed somewhere between the two, where you’re breaking off pieces of the application but maybe not micro, micro, microservice.

Talk about that a little bit.

Jason: We tried going down the microservices path. That was one of the architectural expeditions that we went on. Just found that there’s more and more functionality that depended on couplings. We ended up having to figure out APIs and things that would have just been a single-method call in a monolith. So we decided to focus on the monolith.

Then with wanting to start over with the new architecture, we have basically two monoliths that talk to each other now.

Ledge: How did you make that segmentation? Is that just a functional segmentation, like it makes sense to have two applications?

Jason: Yes. Basically, the new functionality with everything that goes along with that model-view-controller stuff is in the new application. It makes API calls – and some new UI – but it makes API calls back to the old application.

I think eventually, we may end up just bringing all of the old functionality into the new application, and cutting off those APIs. But as a time-to-market thing, that made the most sense – to have the business logic already in the old application that we can reuse be accessible over APIs and then build the net] new functionality in the new application.

Ledge: Right. It was less of bog down the whole company in v2. A pragmatic choice to at least, hey, let’s just separate out, allow ourselves to use some old foundational work, but not be saddled with the entire old application there. That’s interesting.

Jason: Exactly.

Ledge: You talked about, I guess, you made a move over the course of time to cloud and now serverless. Love to hear best practices there. What have you learned?

That you’re on Ruby. I don’t hear Ruby and serverless all the time. That’s an interesting story.

Jason: I think AWS just released Ruby support in November or October of last year. We are just working on our first functions, I guess we could call them, in Ruby that we’re going to deploy on serverless.

For us, the one place we do use microservices, we’re not doing a lot of microservices calling other microservices, but if there is some standalone functionality that is highly decoupled we’ll throw it into a function.

For example, we have some report generation functionality for customers that wanted custom data exports, and that we’ve built into serverless functions. It just calls the database, generates some CSVs, and then pushes those to an external FTP server. Rather than putting some code for one specific customer into our monolith, this, we can just have in Lambda and it’s totally separate. Don’t have to worry about it breaking anything, and if it breaks we know it only impacts that one customer.

For use cases like that the isolation made a lot of sense.

Ledge: You don’t have to fork your main products. You can stay multi-tenant SaaS, but you can use serverless to introduce ancillary functions for a given client.

Jason: Exactly.

Ledge: Did you ever think then – maybe it doesn’t happen – is serverless almost like the sandbox to allow you to test stuff out that you might roll back into the monolith? Or is it just like, hey, it’s going to be out there forever?

Jason: I haven’t thought of it as a sandbox, but some of the reporting things we do for one client end up being useful for other clients. So it’s possible.

The code that we’ve put in serverless, at least the first functions, were highly specific to one customer. They basically ordered it as a custom work order so it made a lot of sense.

That’s, I would say, in general what we’re using serverless for, is some instance of moving data around. Whether it’s sending it to an external system.

We also use it to sync some tables in the database. For example, there’s one table that we sync between the old application and the new application, and we use a serverless function to handle that ETL process.

Ledge: Was it like a performance thing or more just like easy abstraction? Why not do that as part of the normal application? How did you decide what to put out there in that paradigm?

Jason: In this case, we had basically some user settings that we wanted to keep in the new application and the old application that both the old application’s functionality and the new application’s functionality depended on. n that case, as we looked at the use case, having the sync process made the most sense. Since it’s specific to one user and it’s part of the setup on onboarding, it made more sense than calling out to that table over an API.

Ledge: Right. Okay. When you made the new application, did you have to deal with a totally new data model too, where you have to kind of ETL yourself then during that process?

Jason: The one place we do have microservices, we have a single sign-on server, we handle setting up using user accounts in both systems. We had the ability of a user to log in without needing to set up an ETL, was already setup through the single sign-on server.

Other than that one table for user settings that I was just talking about, we haven’t done any other ETLs. Everything is either only in one application, only in the other, or accessible over an API.

Ledge: Right on. What’d you learn from the customer feedback process? Tips and tricks?

One thing we always know is every customer has an opinion. How do you know which things are worth rolling into your product or not? They’re going to tell you to do all the things they want, and every customer has a different opinion. How do you do a signal and noise analysis on that?

Jason: I guess at the very general level we have a community board, like a feature board, where people can vote up ideas. We look at the top ideas every quarter. That’s the place where we’re looking for multiple customers asking for a feature.

Then there’s always this situation of a salesperson just needs this one feature to close the deal that comes up. We’re selling to enterprises, so usually they have three to five things that they want customized.

We handle those requests. We build in some time in our schedule, every quarter, to handle those requests. If they’re gets to be too many of them then we push back on the sales team and force them to do the prioritization for us.

It’s funny. Almost every design decision you make that limits the functionality, as you scale you’re going to find someone who wants the opposite. For example, one that came up recently is we have a leaderboard functionality where when marketing puts a piece of content in our system and the members then share it, they get a certain number of points.

Well, we added a reset feature to that. Basically, the idea is you reset the leaderboard back to zero when you click the reset button, so that if they want to do a monthly contest they can reset it.

We have a contingent of customers that want just a pure reset, and then we have others that, if there’s something that’s alive in our system that’s available to share before and after the reset time, then it becomes unfair because the members who already shared it got their points zeroed out but then the members who didn’t share it yet can still get points for those messages. It makes the whole system unfair.

We implemented it the way where, if something was live in the system before you hit reset, nobody can get points on the leaderboard after the reset for that thing, even though they shared it a time after the leaderboard reset because of the fairness argument. But now we’re having customers come back and say, “Well, I just wanted to reset. I didn’t care about this fairness point.”

You’re going to be constantly surprised in any sort of limitation that we put in. Even for a fairness reason or gamification reason, someone comes up and doesn’t like it.

We try to model Ruby on Rails with conventional reconfiguration, but a lot of times what the customer really wants is configuration, and wants a more complex set of options that they can better fit their use case. That’s some place we bounce a lot, is how much flexibility do we give versus how much do we just make it have one way to do it, and the customers have to take it or leave it that way?

Ledge: Well, I’ll leave that as our final thought, that you only need to deal with this problem once you have customers that are so passionately debating about your product.

Jason: It’s a good problem to have.

Ledge: Right. Exactly. Don’t go out of your way to do all these things at the beginning. Once you have customers that have an opinion, you know you have customers for the long term. So that’s a good thing.

Well Jason, good spending time with you. Love the insights and we’ll be paying attention.

Jason: Yeah. Thanks for the time, Ledge. It’s great to meet you.