Thanks for posting, @mikerowan!
Looks like you got a few friends to vote as well ;)
What are the challenges of running R&D inside a grown-up startup? Do you recruit developers from the inside or did you grow the team by recruiting new folks?
Happy to intro the first offspring from @SendGridLabs aimed to let developers build more scalable and reliable Apps & APIs w/o breaking the bank - we're happy to help how we can.
Thx @rrhoover - Yes, SendGrid Labs is an incubator and our projects focus on helping developers with productivity, efficiency and scale. We're passionate about helping developers in areas we've experienced frustration during growth periods which could be distracting to our core focus. Loader.io is a great example of what we've used to help us test scale, and we've opened it up for everyone. You'll see many more projects from Labs.
@rrhoover our process isn't as advanced as you might think, but it works! First we talk to developers - a lot, and our Labs office is actually co-located within an accelerator co-working space. We hear lots of things, problems, distractions and general frustration that sometimes cripples these startups from focusing on their core engineering to grow & scale their business. We're engineers too and find we're building things to get the job done but are ultimately distracting to our core product goals. Finally, we have an amazing engineering team at SendGrid and we get so see and learn about problems that most people would never see just based on the scale at which we need to operate. We take all this input and discuss the most common pain points, figure out a way to fix and then and get to work building a service. It's a lot of fun building exactly what you want, when you want to do it!
Hi there @nbashaw - Grown-up startup is a great way to put it and exactly how we like to think of SendGrid. The recruiting model is mixed, but based on the core SendGrid growth it's hard to poach internal resources all the time. The challenges are interesting, but the most important by far is making sure the solutions we develop are for the developer community at large. While it's important to help SendGrid solve problems, it's just as important to be sure we don't get consumed with only SendGrid's needs. This can be a challenge because we're in fact powered by the mother ship, but outside input form other developers feeling the same pain is critical. If we confirm it's broad enough we move forward, and we aim to solve the needs of not only SendGrid but as many other developers as possible.
Product Hunt
Product Hunt
Lex
Threads
Threads
Threads
Threads