6 ms·

This Startup Built Internal Tools to Fuel Major Growth

76 points by mountaineer 12y ago

arthurjj 12y ago
As someone who has been a product engineer and internal tool engineer I really appreciated that they made the distinction. Some other points to think about. 1.In the first version of the tool don't have the tool make a decision, just have it generate information, not make decisions. So if it is telling you which sales lead to pursue, first have it generate metrics on why you should pursue a lead 2. Once you have a tool that makes decisions always have a way to let a human override the tool's decision 3. Start with a process then add a tool. It's almost always either to work out bugs with people then software
- noahbrier 12y ago
  Noah here from Percolate. I agree and what's interesting is I also think these are pretty classic values for enterprise (or b2b) software in general. Without the centralized data it's really hard to build any of the workflows or other tools.
  - arthurjj 12y ago
    Agreed. That's why I like to start with a process and then build a tool. If people find the process valuable enough to follow it then you know the tool will be providing real business value
silentmars 12y ago
One downside to this approach is that it can tend to create status or power rifts between the product people and the tools people. In traditional shops, the "skills that pay the bills" product people often get better treatment, higher status, greater advancement opportunity and stronger job security than tooling people, who are often seen as being on the cost side of the business. Startups that go down this route should be on the lookout for this potential for divisiveness and culture fragmentation.
- inthewoods 12y ago
  The approach they seemed to take to deal with this was bringing in an outside developer. I'm not a fan of this approach for a number of reasons - but mainly because then you've got a dependency on a single outside person or firm to maintain that application going forward.
  - noahbrier 12y ago
    To answer both: On the division side, we have found a number of people who are simply more passionate about building products for their peers than building products for customers. I interviewed one last night, so I can confirm this is the case. Because the job includes a bit of product management and a bit of design, it ends up being something fundamentally different than what we ask engineers to do. As for the outside devs, I agree that is a challenge and one of the things that ultimately led to us hiring internally to help support and continue to grow those internal products.
toisanji 12y ago
would love to see examples of other companies being built like this. This could be built as an incubator.
- devonkim 12y ago
  It really depends very much upon how the company's built and how its people work culturally, but I think this is absolutely more important for larger companies than smaller ones just because communication overhead far exceeds pretty much every other barrier (regulatory and compliance included). I'd hesitate to go this route if the product is aimed mostly at an audience used to structured communications such as engineers (github issues, IRC channels, and even wikis are far more structured than the usual e-mail chain like in a mailing list). This is part of why companies with usable CRM like Salesforce have done so well in providing value to their customers. So, I'd totally do this if I was going to start something that's aimed mostly at enterprise users or with potential to have a need for lots of cross-functional communication like a start-up operating in a highly regulated space.
pbreit 12y ago
Seems to be working for them but I would typically advise against too much energy spent on automation and internal tools too early. Tools can really slow you down in the early going when things are changing rapidly. And you can typically throw inexpensive bodies at many of the tasks that are otherwise candidates for automation. The one thing I do like is that building tools gives more employees experience in building product.
- noahbrier 12y ago
  I would generally agree with that and we had many instances where we chose to have people perfect workflows prior to fully automating them (and there are lots of situations where that remains the case now). With that said, and I don't know that it was perfectly expressed in the piece, I do think there's a concept that engineers take for granted around the attitude that goes into creating products and automation that needs to be pushed hard throughout the whole organization.
  - calinet6 12y ago
    Have you looked into W. Edwards Deming at all? His ideas on quality and systems are echoed almost perfectly in this article and in what you're saying here, especially in bringing systems thinking to the entire organization, not just engineering (where abolishing repetitive tasks using scripting comes as second nature). Really astute stuff. I think he'd reply on the point above, that it's far better to build the system and have it be less than perfect than to rely on a brittle process. "A bad system will beat a good person every time." - Deming So, it will probably not be a waste of time. Has your experience proven this out in general?
    - noahbrier 12y ago
      Haven't read any Deming, but will check it out. Any particularly good place to start? I'd say in general it has proven out, though there have certainly been some cases where we tried to build products prior to fully defining the challenge/process and they were basically DOA. Again, here internal tools are just like external products: Without a tightly defined challenge/opportunity it's really hard to deliver a useful product.

76 points by mountaineer 12y ago

As someone who has been a product engineer and internal tool engineer I really appreciated that they made the distinction. Some other points to think about. 1.In the first version of the tool don't have the tool make a decision, just have it generate information, not make decisions. So if it is telling you which sales lead to pursue, first have it generate metrics on why you should pursue a lead 2. Once you have a tool that makes decisions always have a way to let a human override the tool's decision 3. Start with a process then add a tool. It's almost always either to work out bugs with people then software

noahbrier 12y ago
Noah here from Percolate. I agree and what's interesting is I also think these are pretty classic values for enterprise (or b2b) software in general. Without the centralized data it's really hard to build any of the workflows or other tools.
- arthurjj 12y ago
  Agreed. That's why I like to start with a process and then build a tool. If people find the process valuable enough to follow it then you know the tool will be providing real business value

silentmars 12y ago

One downside to this approach is that it can tend to create status or power rifts between the product people and the tools people. In traditional shops, the "skills that pay the bills" product people often get better treatment, higher status, greater advancement opportunity and stronger job security than tooling people, who are often seen as being on the cost side of the business. Startups that go down this route should be on the lookout for this potential for divisiveness and culture fragmentation.

inthewoods 12y ago
The approach they seemed to take to deal with this was bringing in an outside developer. I'm not a fan of this approach for a number of reasons - but mainly because then you've got a dependency on a single outside person or firm to maintain that application going forward.
- noahbrier 12y ago
  To answer both: On the division side, we have found a number of people who are simply more passionate about building products for their peers than building products for customers. I interviewed one last night, so I can confirm this is the case. Because the job includes a bit of product management and a bit of design, it ends up being something fundamentally different than what we ask engineers to do. As for the outside devs, I agree that is a challenge and one of the things that ultimately led to us hiring internally to help support and continue to grow those internal products.

toisanji 12y ago

would love to see examples of other companies being built like this. This could be built as an incubator.

devonkim 12y ago
It really depends very much upon how the company's built and how its people work culturally, but I think this is absolutely more important for larger companies than smaller ones just because communication overhead far exceeds pretty much every other barrier (regulatory and compliance included). I'd hesitate to go this route if the product is aimed mostly at an audience used to structured communications such as engineers (github issues, IRC channels, and even wikis are far more structured than the usual e-mail chain like in a mailing list). This is part of why companies with usable CRM like Salesforce have done so well in providing value to their customers. So, I'd totally do this if I was going to start something that's aimed mostly at enterprise users or with potential to have a need for lots of cross-functional communication like a start-up operating in a highly regulated space.

pbreit 12y ago

Seems to be working for them but I would typically advise against too much energy spent on automation and internal tools too early. Tools can really slow you down in the early going when things are changing rapidly. And you can typically throw inexpensive bodies at many of the tasks that are otherwise candidates for automation. The one thing I do like is that building tools gives more employees experience in building product.

noahbrier 12y ago
I would generally agree with that and we had many instances where we chose to have people perfect workflows prior to fully automating them (and there are lots of situations where that remains the case now). With that said, and I don't know that it was perfectly expressed in the piece, I do think there's a concept that engineers take for granted around the attitude that goes into creating products and automation that needs to be pushed hard throughout the whole organization.
- calinet6 12y ago
  Have you looked into W. Edwards Deming at all? His ideas on quality and systems are echoed almost perfectly in this article and in what you're saying here, especially in bringing systems thinking to the entire organization, not just engineering (where abolishing repetitive tasks using scripting comes as second nature). Really astute stuff. I think he'd reply on the point above, that it's far better to build the system and have it be less than perfect than to rely on a brittle process. "A bad system will beat a good person every time." - Deming So, it will probably not be a waste of time. Has your experience proven this out in general?
  - noahbrier 12y ago
    Haven't read any Deming, but will check it out. Any particularly good place to start? I'd say in general it has proven out, though there have certainly been some cases where we tried to build products prior to fully defining the challenge/process and they were basically DOA. Again, here internal tools are just like external products: Without a tightly defined challenge/opportunity it's really hard to deliver a useful product.