It’s important to remember that investment isn’t a completely altruistic act. While investors clearly want to encourage innovation, a primary motivation is to see a return on that investment. At the end of the day, they’re gambling that your idea will make them money.

This can make investing in true innovation tricky. True innovations are those rare game-changing technologies that revolutionize an industry. They’re notoriously difficult to spot. How often have you heard that people thought Apple would fail when they released the first iPhone or didn’t believe in Facebook when it first went public? True innovation rarely looks revolutionary to begin with. So how do investors spot which ideas are worth the effort?

We spoke with Jason Warner, managing director at Redpoint Ventures, to understand the reasoning behind investments and why investors are so picky.

1. Typical SaaS companies are easy to invest in, but true innovation doesn’t follow the same model

When developers start searching for investment, it can often be discouraging. While investors might not understand the intricacies of every technology company they invest in, they can at least spot the trends. They know and understand how a Software-as-a-service (SaaS) company grows.

If a company is growing, it has a very familiar pattern. And so investors can be quite confident that they’ll see a return. They’re much more willing to take a risk and ‘YOLO’ an investment.

“SaaS companies are really well understood in terms of how they grow,” explained Jason. “There is no real investor challenge to understand that if a company is growing 2x and its enterprise sales look good then … [investors] can just “yolo” invest into them. Because they understand what these companies look like … It’s all just Excel spreadsheets.”

-On the Dev Interrupted Podcast at 40:29

2. Investors often wait until the first round of funding, but developers need seed funding

If you’re developing a revolutionary piece of technology, then it’s likely that you need investment to get you off the ground. However, it’s difficult for investors to sort the good from the bad. How do they know you’ll be successful, without a few years of revenue behind you? It’s a catch 22 situation. You need the investment to get those first few years, but the investors need to see a few years before they’re willing to invest.

Look at how Netflix completely surprised the world. Nobody predicted that it would change how we watch video (most of all Blockbuster, who fatefully ignored the potential). This is a trend that harks back decades. Online shopping, personal computers, the television, even electric light bulbs were all disregarded when they were first conceived.

These industry-changing innovations need investment much earlier than typical SaaS companies. And spotting what works is more of an art than a science.

“[Investors] miss the fundamentals. They can see the ones that are the trends,” Jason said. “It should [then] become obvious in the next round or the round after that from other investors … oh yeah, that is a great company.”

-On the Dev Interrupted Podcast at 41:18

3. Developers need to seek out companies like Redpoint for seed investment

If you have a truly new idea, you’ll need to find an alternative to the usual investors. A company like Redpoint, which focuses on giving seed funding, is much more likely to take the time and actually investigate whether your technology will be a success.

It will take longer, of course. And it might not be the full amount you need to get your business started. But it’ll be what you need to begin building a proof of concept, get those first few years under your belt and start pitching to other investors.

“[If you’re] talking to a Redpoint investor, you should be flattered,” Jason explained. “What we’re thinking is that you are a majorly important company in the future. You have the potential to land … If Redpoint invests in you, we want it to basically mean that we think of you as a new primitive on the Internet or in whatever sector that you are in. And other people are going to build upon you.”

-On the Dev Interrupted Podcast at 41:35

Listen to the full conversation

If you’d like to learn more about what Jason thinks and how to secure yourself an investment, catch the podcast on our website.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Grammarly has a simple but ambitious mission: to improve lives by improving communication. Every day, our AI-powered writing assistance helps 30,000 teams and 30 million people communicate clearly and effectively wherever they write.

But behind our technology is a team of engineers. Until recently, our engineers focused exclusively on building a product for consumers. When I came aboard to lead new initiatives as the Director of Engineering for Grammarly Business and Grammarly for Developers (expanding our product to support teams, organizations, and third-party developers), it was clear Grammarly approached full-on hypergrowth.  

Then the pandemic changed everything. Suddenly, we found ourselves transitioning to a remote-first organization amid hypergrowth hiring and onboarding. The company doubled in the past year to over 500 team members, and my teams have grown even faster. 

To be successful, we needed to spearhead initiatives that solved two problems. The first involved people: How could we successfully maintain a culture reflecting Grammarly’s EAGER values in a remote world? The second was technical: What tools and practices would enable our team members to thrive? 

Transitioning to remote

Historically, Grammarly has had an in-person culture. We have four hubs—in Kyiv, San Francisco, Vancouver, and New York. But when I joined in July 2020, everyone was remote. Few assumed it would stay that way, but the “return to normal” kept getting pushed further back. Eventually, Grammarly adopted a remote-first hybrid model. 

With “remote-first,” Grammarly team members work primarily from home. However, we continue to believe in-person interaction builds trusting relationships and a supportive culture that fosters innovation. So our offices became collaboration hubs where face-to-face meetups will also take place each quarter.  We made this decision based on our progression as a company; because we felt we’d learned how to communicate and collaborate effectively and saw advantages to the remote-first model.

Keeping it personal 

I look forward to meeting people in person at our first team-based meetup next year, but with my quickly growing team split between Kyiv and North America, we need to constantly build and maintain personal connections.

“I've onboarded fully remotely. I've only met four of my coworkers in person.”

- Dev Interrupted podcast at 19:33

Thus, we’ve tried our best to foster a thoughtful approach to team bonding at Grammarly—which signals that breaks and fun are important, too. 

Some example approaches: 

• Events celebrating everyone’s individuality and encouraging personal connections
• Coffee/donut chats, compliments of Grammarly
• Virtual hackathons

Our events motivate people to break from work and connect with each other. Activities range from educational to creative and silly, including an Indian cooking class during Diwali, a graffiti workshop, a cocktail class, a Halloween costume competition, and Grammarly’s twelfth-anniversary talent show. This personable approach also translates to how we chose the tools for remote collaboration.

Finding the proper tools

Setting hypergrowth teams up for success requires investing in the right tools and processes. As often as possible, we try to implement asynchronous communication and development best practices. Proper tools that facilitate organizational transparency are critical for alignment in a remote-first company.

Fewer people are required in Zoom calls because we share recordings and notes in open Slack channels. For collaboration and stakeholder alignment, our Engineering teams use Confluence for documentation, Jira for issue tracking, and Figma for collaborative interface design. Architecture and whiteboard sessions occur in Miro, while team retrospectives happen in Parabol. 

The archival component of these tools is invaluable; new and old team members alike can discover information through Glean, which gives us aggregated search across all our tools and content. 

Embracing the talent diversity potential of remote work 

One of the most exciting opportunities with remote work is in finding hidden talent in overlooked geographies. Silicon Valley gets all the attention, but it’s not the only region with great software engineers. There’s plenty of talent out there just waiting to be found. 

“Genius is evenly distributed by Zip Code, but opportunity is not”

- Mitch Kapor, Kapor Capital

Finding talent in other locations also leads to more organizational diversity. Whether that diversity is racial, ethnic, socioeconomic, or generational, diverse teams are going to improve your product. I’m a huge believer in diverse teams for two reasons: 

1. Better problem-solving than homogenous teams: I’ve witnessed this in my career, and it’s been proven with studies. Creativity naturally flows from visible and invisible diversity. Companies embracing differences will achieve better outcomes because the ensuing creative conflict helps you innovate and build better products. 
2. Stronger empathy for the customer: In Grammarly’s case, building writing assistance for the world’s 1 billion English speakers makes diversity in engineering critical. For example, those speaking English as a second language often visualize the language differently, leading to feature ideas that wouldn’t occur to primary English speakers. 

You need a diverse team to build the right product for a broad audience. We’re excited to use recruiting tools like SeekOut and partner with organizations like Elpha and AfroTech to help us connect with and hire engineers from underrepresented groups. 

Onboarding

But hiring isn’t enough! Many organizations are too focused on hiring, at the cost of onboarding. How we onboard folks and make them feel welcome is critical to their long-term success at Grammarly. 

A small test of our onboarding process is whether new engineers can push code in the first week. If they can, it’s a signal the dev environment is well documented and has minimal friction. The faster people can be productive, the more confident they feel, which ultimately boosts team morale. 

That said, onboarding is about more than pushing code. Engineers are encouraged to meet people and learn the product before they feel pressure to deliver. New engineers have a Getting Started Guide that includes who to meet and links to resources. Managers check in daily to answer questions. They also pair with a non-engineering Culture Buddy plus a mentor from their team so they can get to know all aspects of Grammarly life. 

Thoughtful onboarding during hypergrowth helps new team members build connections, which leads to better team health in the long term. 

Staying Grounded 

My advice to any organization about to engage in hypergrowth is to remain thoughtful. Think about hiring, onboarding, your processes, how you measure success, and how you want your employees to feel when they join your team.

Remember, too, that diversity is more than a checkmark or an abstract goal. Diverse teams will be your strongest asset. They will push creative boundaries—and in doing so will build the best possible product with the best possible outcomes. 

_

Want to join us in helping 30,000 teams at thousands of companies succeed through effective communication? We’re currently hiring for roles across the Grammarly Business and Grammarly for Developers teams.

Join the Dev Interrupted Community

With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>

To call Google a titan of the tech industry would be an understatement. Their name has become synonymous with the internet itself. The very act of retrieving information from the internet - the core functionality of the internet and its most basic purpose - is known simply as “Googling” something. On their road to becoming the web’s biggest search engine and a moniker for the internet itself, Google also pioneered much of what it takes to grow a company at scale. 

On the Dev Interrupted Podcast Google Senior Engineer’s Hyrum Wright and Titus Winters, shared their lessons learned from programming at Google with LinearB Co-Founder and COO, Dan Lines. Both engineers have a deep understanding of the principles behind software development: Hyrum is semi-famous as the "Hyrum" of Hyrum's Law; while Titus is responsible for 250 million lines of code that over 12,000 developers work on.

But what lessons can we take from their interview - and their book Software Engineering at Google: Lessons Learned from Programming Over Time? How can we apply those lessons to our own projects? I’ve pulled out the core takeaways from their interview and condensed them so that any developer or company, be they responsible for 2,000 lines of code or 2,000,000, can learn something from Google’s roadmap. 

Why listen to Google

In spite of their enormous success and scale, Google doesn’t pretend to have all the answers; this lack of presumption is exactly the thinking that has made them the titan they are. Previous success is no guarantee of future success and no one understands this better than Google.

One thing that Google is very good at is not accepting how everyone else does it as the one true way.” - Titus Winters, on the Dev Interrupted podcast at 20:35

It’s easy to assume that events and conclusions are foregone, or that one event naturally follows another. Yet this is rarely the case. Most of the time people are working towards a specific outcome, and it’s not until later that the outcome is apparent contextually. This is true in life and software development. 

Google has spent the past couple decades approaching everything they do as trial and error, learning what does and does not work, and trying to institutionalize the things that do work. This is not a straight path.

This mindset is obvious in Hyrum and Titus’ interview. Titus uses the analogy of Lewis and Clark to explain how the software development process at Google has unfolded. 

“They say Lewis and Clark explored the Louisiana Purchase, by which we mean, they took one path out and one path back, which is not exactly mapping, but in a similar way, we're trying to give an exploration/trip-report/map.” - Titus Winters, on the Dev Interrupted podcast at 6:17

He’s admitting that Google doesn’t have all of the answers; that Google’s path isn’t the only path to success; that other paths may be superior to Google’s; and that their path may not work for every business. But, with decades of experience, Google has learned a thing or two along the way, and maybe, just maybe, we can all learn something from the path they have trailblazed.  

After all, there aren’t many companies in the world that have hundreds of millions of lines of code. 

The 3 Pillars of Software Engineering at Google

“Anyone can change a line of code or change 10 lines of code. But how about changing 10,000 lines of code or 100,000 lines of code in a reasonable time? - Hyrum Wright, on the Dev Interrupted Podcast at 17:15

With so much code to manage, Google has made maintaining their code a strategic goal. Code must be fresh and able to sustain changes to the code base for business or technical reasons. To best allow for this, they have identified 3 concepts that they believe are core to software engineering. 

1.Time

All of the hardest stuff that software engineers are going to have to deal with like skew version, backwards compatibility, issues with data storage, dependency management, upgrades and many more, are all problems created by time. Once dev teams realize this, it will change their perspective on how best to write code.  

For instance, if you are going to get rid of your code within one or two years, then you probably don’t need to worry too much about making changes or upgrades to it in the future. But if you are going to write code that will remain in use after five or ten years, then you may want to approach it differently. 

If dev teams want their code base to last, they need to think about constructing code so that it can sustain changes within an organization’s lifespan. This fundamental realization allows time to peacefully coexist with the second pillar. 

2. Scale

How your system scales is a relationship with time. Scaling isn’t a new problem and Google has been at the forefront of pushing scale their entire existence. For instance, email existed before Gmail and search engines existed before Google, but Google’s brilliance was their ability to scale these technologies better than their competitors. It’s the root of their success. 

To beat their competitors they adopted a mindset of scaling as a process - a continual evolution. 

As a company grows, all of its operations expand and that continued expansion requires more resources, which begets even more resources still. This means growth cannot occur superlinearly because if it does, eventually a company will consume all of its resources maintaining the status quo.  

The key takeaway is to make sure your codebase and software both scale sublinearly, that way if your codebase doubles or triples you won’t need six times as many engineers just to maintain your systems. (Sublinear scaling refers to team growth that occurs more slowly than the number of supported services of a company. Superlinear growth is the opposite - with team growth outpacing the number of supported services.

3. Trade-offs and Costs

After taking into consideration the best practices around time and scale, what is left is good decision making. Just as Hyrum and Titus note in their book, “in software engineering, as in life, good choices lead to good outcomes.”

However, no organization has perfect data on which to base every decision, and therefore must strive to make the best decisions they can with the most data possible. People need insights into what an organization finds impactful.

For instance, if an engineer spends a week on a project, it should probably be a project the organization considers a priority. Because if it is not, then no matter how perfect the code, it probably wasn’t the best use of the engineer’s time. Brain power should be devoted to the most difficult problems, not where a semicolon should be placed. The cost of incorrectly evaluating trade-offs is failing the 1st two pillars. 

Coming Home

While Hyrum and Titus may not be Lewis and Clark reborn, they have a valuable story to tell about trial and error in the Information Age.

How a company scales is likely to define how it differentiates itself from its competitors and whether or not it will be successful. A company that can scale sublinearly will thrive, all others will stagnate as victims of their own success. 

Minding the principles of these modern-day explorations into the wilderness of code will help any organization keep an eye on the most valuable resource: time. But remember just as Lewis and Clark found one path forward, they didn’t find the only path forward. 

We can all learn something from Google, but never forget the path forward is your own.

Join the Dev Interrupted Community

With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>