Frederick Townes is CTO and co-founder of Placester, a real estate marketing platform for real estate professionals. He's the founder of W3Edge, founding CTO of Mashable, and an active WordPress contributor. One of his largest contributions to the WordPress community was his web performance optimization framework W3 Total Cache.
We recently had the opportunity to sit down with Frederick and chat about the role of a CTO, the challenges of building a future-ready platform, and the opportunities for big data.
Hi Frederick! I know many of our readers will know you as the founding CTO for Mashable, but can you tell me a little bit about the work you're doing now with Placester?
The biggest thing that we're doing at Placester is building a digital marketing platform for real estate. The reason why that’s a significant undertaking is because there is a data problem in real estate.
The content in digital marketing for the real estate industry is always a property listing, and property listings are locked up in hundreds of databases around the United States. These databases follow some open standards, but for the most part each one is kind of a snowflake in terms of allowing agents to integrate with them and get the data out. So there are some unique problems in working with the data. There are challenges that make it slow going in terms of creating a consistent or predictable system. We have spent quite a bit of time getting to the point where 95% of the agents that come to us can quickly get online with their listings and personal website and start marketing.
Making a platform for real estate is also challenging because every single agent is an independent contractor. They are not employees. They don’t go to the office on Monday morning and their boss says, “Hey, John or Sally, here’s fifteen leads, go be rich.” We have to help them be successful individually, even though they may work on a team or be part of a large organization. So we focus on that challenge of creating great digital experiences for consumers, on behalf of the agent. What we’re really doing is solving lots of data and integration problems to make that experience seamless for consumers.
What drew you to solving that particular problem in that particular industry?
It kind of developed naturally, I suppose. We had to figure out what exactly an agent needed and what the vectors were that allowed us to create that initial relationship with them. We knew for sure that agents were spending ~$14 billion in aggregate -- so a big, big market -- and we knew that there are approximately 2 million agents, depending on how you count. After that, it was, “Hey, clearly they want a website, because they need to do things for themselves to cultivate their own business.”
Even with my wife, who was an agent in Boston and ultimately started her own agency, I saw that she needed to make her own Craigslist postings and do all these other activities on her own. There was no single mechanism or platform for her to scale herself and just focus on interfacing with customers.
We just kept having to figure out what was the most compelling initial value proposition for a customer and iterate over that. Ultimately we landed on websites, which meant we needed to solve a data problem. We realized that data was the key to unlocking lots of different doors, whether it's providing a comparative market analysis for a consumer, or providing a really great map search experience, or offering any kind of contextual data about a neighborhood. All of that was a data challenge.
We had to double down as an engineering team and make sure that this lifeblood of both our lives and our customers' lives was something that we were really good at. Once we got good at that, we had to move on to search problems and then, ultimately, to capturing data so we could measure performance, both of which are also in the data realm. There are a lot opportunities for big data in real estate.
You became a technical entrepreneur early on. Can you tell me a little bit about the path you took growing into the CTO role for the first time?
When I first joined Mashable, I wasn’t necessarily focused on the technical end of things. I was engaging with Mashable initially as a consultant, ultimately joining the team.
I think two key factors became evident about being a CTO. First, having a technical background is an advantage in making great products. That’s not to say you can't have other advantages, but I definitely think technical background is near the top of the list. The other thing is that marketing has become more technical. If you're marketing online in SEO, SMO, or doing E-commerce, it just requires more and more technical skills.
As I worked developing my own agency, I think I went through various phases of learning how to build teams, how to put together products for different industries. When I moved into media, it created an opportunity for me to really start working at scale. I had to learn how to deal with performance issues at scale, and that created an opportunity for me to spend time with a bit of a passion project. That project ultimately became a popular framework for scaling WordPress -- W3 Total Cache.
Were there specific things you learned that helped you early on?
There were four big things I learned early on in my career and started to do at Mashable: figuring out how to make a product, figuring out how to scale a team, figuring out how to scale a platform, and then ultimately figuring out how to represent the technical face of an organization.
I spend quite a bit of my time on acquiring talent now that we are in our Series B, our growth phase. On one hand, it's like being the gatekeeper and trying to make sure that I do my part in protecting the team from having new members that aren’t helping them make their professional lives better.
Then I try to make sure that the way we are solving problems aligns with the kind of talent that’s out there and where the business needs to go. A great example is that right now, we don't write a lot in Python. So let’s say we found a phenomenal Python developer we wanted to hire. Obviously, she’d want to write Python, but we would have to say something like, “Hang on, can you please contribute in Java, because that’s what we have already in place." So I need to make sure that I have a strategy and a methodology for how we incorporate a Python contributor. Early on in a startup, you need to add contributors that can move the needle right out of the gate. My job is to make sure that the team always has a strategy for how to take both the best talent available and the right tools for the job and get that aligned with immediate and mid-term business needs.
Learning how to be strategic is something that seems really simple. But when you're working with lots of talented people and your business has lots of moving parts, like every software company, it's actually a full-time job. If I could do things differently, I would love to have someone focused on helping bring in the talent for the interview and acquisition process, rather than doing that and worrying about direction and being a mentor and pick your favorite hat, because you wear a lot of them at a startup.
Hiring good talent can be tough. Can you tell me a little bit about how you handle hiring at Placester, and what do you look for in developers when they join the team?
Generally speaking, the process is really straightforward. And as with everything that we do, it's highly collaborative. Internally, we break down into four or five teams, and multiple teams will look at candidates and participate in the process of qualifying them. Then, when candidates come on site, they will also participate in different parts of the process.
We iterate on everything, not just how we build our software, but also how we acquire talent. It's hard to say specifically what the hard and fast best practices that we use are, but the biggest thing that we are looking for in hires is experience and talent. We are pretty good at vetting that. It's pretty challenging, I think, for a new candidate to join Placester’s engineering team, but when you actually do manage to join the team, it's an environment you don’t want to leave.
You mentioned collaboration was a big value for the Placester team. Is there anything else that sets the team and the culture of Placester apart?
It's the engineering philosophy or mindset. It's cliché, but the right tool for the job is something that we really think through when we put together designs and architecture. For example, we have a best-in-class natural language search engine for real estate. It doesn’t just look for keywords, it recognizes entities in your search phrase and interprets them. With that project, we managed to start growing the team and add some key players, then worked from prototype to production without any real material changes to the design.
That’s not typically how most development goes. Usually, you work on a prototype, go to water with it, get it in production, and release it. Even though there might be some tweaks that add stability or address bugs, chances are you're going to have to go back and rebuild the whole thing.
Obviously, that’s not as fast as knowing everything and doing it right the first time. I'm not saying that’s what we did, but we couldn’t have gotten any closer. Now we’re working on version 2.0 of our search technology, which really just democratizes it further into more customer’s hands. Our changes are mostly for scale, rather than completely revisiting the design. We’re basically bolting on the next component that we know we needed to add, then figuring out what tradeoffs we're comfortable with. So we’re iterating in a straight line, as opposed to retooling and rethinking, having the same kind of germ but ultimately doing it differently. We’re very fortunate to have a team with the experience to put together a software that’s 80%-90% right, so that we’re not having to back up the bus or learn some hard lessons. That kind of collaborative environment enables you to take on the competition and delight customers, but it takes more time than you would expect. Usually, the problem isn’t that the vision cannot be realized: the problem is how long it will take.
Developing a technical solution for a non-tech market like real estate is a really interesting challenge. Were there unique aspects of your customers that are driving your decision making or anything that surprised you during the process?
The real estate professional is not anti-technology, really. What they really want is some technology or platform to serve as the infrastructure for their business.
That seems straightforward, but what it means is that they didn’t necessarily want to come in and select some designs and go into some advanced editor and start moving things around. They just wanted to make sure that the right kinds of properties could be discovered in exactly the right way that works for their business, and that boils down to business rules. When you move into other elements that integrate with a website like a CRM, again, it's really about making sure we’re are doing things to craft the desired customer experience.
That’s somewhat counterintuitive, and a bit of a surprise when you look at the landscape of industry-agnostic tools like a Wix or a Salesforce, etc. They give you so much optionality that as a customer you think, “That’s gotta be table stakes. That’s where the bar is set."
Ultimately, these real estate professionals just need these tools to talk to each other. They need them to follow the process they want their customers to experience, and then they don’t want to worry about it.
Are there challenges that you're looking forward to your team addressing for your product coming up the next year?
We've spent the last couple of quarters really working on some of the key infrastructure. I think that we've always anticipated needing an awful lot of services. That means we've really focused on a micro-service strategy. These micro-services--whether it's infrastructure, data, search, whatever -- roll up into platforms that orient themselves around the problem we're solving, whether it's marketing, customer relationship management, what-have-you.
Then, on the shelf of a platform sit products. This allows web developers to ultimately build just about anything by integrating against services. As a result, the products on a platform seamlessly integrate into each other.
I was on the phone with a broker last week, and he told me about a pain point that he had with drip e-mail. I explained how our platform worked and noted, “By the way, the story I just told you involves three different products, but when you use our platform, you wouldn’t even know it.” He was kind of shocked.
Our platforms integrate with each other because they are all driven by shared micro-services. When you look under the hood of any large platform, you'll see the exact same kind of pattern at work.
What that means is as we inevitably grow, and as we face scale issues or need to iterate, we have two options. We can converge in our API, or we can take advantage of the fact that we've already divided and conquered. A given service will have its own scale needs, and we can address those independent of others, which is why we took that tack. It’s not a panacea, but it is a strategy that we feel gives us the right degree of dexterity or agility.
What’s your philosophy about supporting your engineering team and what you do at Placester to support growth and education?
We have a culture of mentorship. Part of what we're excited about in collaboration is the value of generosity, for lack of a better word. One of the more senior folks who joined the team expected that when he had a question, someone who had already been on the team probably had the answer. We shouldn't go reinvent the wheel: we should ask a question and get together to figure out how to leverage the value and knowledge that other contributors had, in order to find the shortest path to creating more value.
Mentorship and collaboration are probably the lynchpin elements of our culture, outside of entrepreneurial desire to create. Those three things are what you see when you walk through the office. Whenever I can, I try to hang out in different open spots in the office. What inevitably happens is that someone will see that you're available and pull you aside and jump in front of a white board.
We have idea paint all over the place, and it’s great. From Monday to Friday, you see the white boards get full, and then every weekend they’re wiped clean. The next week, you see them getting full all over again as the impromptu conversations go from, “Hey, let’s work through this is a problem” to, “Hey, can you poke holes in my implementation?”
Culture-wise, the challenge is trying to carve out the time and workflow so that people have an expectation that they're going to engage in these healthy behaviors. The rest is making sure that any contributor can get answers, whether it comes from me or another contributor, at a pace that doesn't make any single person a constant blocker. That’s how you create a high performing team.
Are there tools that you have found have been vital to your team's productivity?
Productivity and automation tools of any sort have been the best. JIRA is a priceless tool for us. It helps us track plans, make sprints, trade implementations, keep track of Google Docs that we’re working on. JIRA is kind of the canonical source for information in the organization.
Automation is also huge. After we’ve done something once, it's about figuring out a) how to do it better the next time, and b) how to make sure we don't have to relearn or revisit things we've learned the first time, which usually culminates in some kind of automation. Those two components are the things that matter most.
Automation takes all kinds of shapes. It's in the continuous integration like Codeship, it's in release engineering, it's in development operations, it's in quality assurance testing -- it's everywhere. The more time we spend thinking through and tackling new challenges, the better. That means anything we're going to do more than once that doesn't necessarily require the same level of attention is an opportunity for automation.
Time machine time. If you could go back in time and give yourself advice at the start of your career as a technical founder, what advice would that be?
Pick a pace that you feel you can maintain for a very long time. I don't say that because I fear burnout, or other people should. I say that because one of the things that really benefits a startup is moving quickly. If you move quickly, you're going to break things. Part of why you grow a team is to add folks and break fewer things. Do that, and hopefully you’ll go even faster. But if you're not really consistent with the pace that you're keeping early on, and you're not getting the right input, it becomes a struggle of mere activity versus actual value creation.
Getting that feedback loop and keeping the cadence and consistency of output are really key. If you're having trouble finding your product’s market fit, and you're making small pivots, and you're not internalizing and operationalizing what you've learned from the last build or release, then you’re going to have a net slowdown, no matter how skilled you are or how many resources you have deployed.
In a phrase: make your technical debt as intentional as possible. It's so much easier said than done. We’ve built an awful lot of stuff, so I have no real regrets. But, looking back, I can see how we could have shaved quite a bit of time off achieving some of the outcomes we've wanted.
Thanks for your time, Frederick!
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.