3 ms·

I found your description here a bit more difficult to understand than the description on the website. I like the concept, as in having revenue streams that can

I found your description here a bit more difficult to understand than the description on the website. I like the concept, as in having revenue streams that can be shared with the people building the product. You thought about things like house keeping tasks (and bugs etc). I can imagine that it's an easy way to clean up some technical debt, just divert a bigger chunk of the revenue towards those bugs. Couple of things I'd love to see worked out a bit more. Maybe you mention them somewhere, but still: - How does this work in an interface? Sales people will not really go into git and see it, so I assume some kind of interface with sliders that match the streams+tags. Showing this can be insightful (a sketch can already give more insight in what you're actually building). - I assume there is some kind of holding period so that the 'bug' tag for example can be extended for a while, giving me the guarantee that those 20% of the shared revenue that went to bugs actually stays for a couple of weeks. - There is (obviously) a lot of weird scenario's possible here. Imagine a business requirement changing. I wrote a big piece of the functionality, but it becomes simpler. 90% of the code can be removed, someone else writes another 10%. How does this equate to money shared? I did all the 'heavy-lifting', but the other person made it workable in the current increment. - I can see this become really difficult to manage in larger teams and products, and possibly leading to unhealthy competition where people are enticed to work more against each other than with each other. Maybe there could be certain ways to make working together more attractive? For example, commits within a week from each other by different people attract some kind of bonus % to all involved? - In general, the idea is nice, but I wonder if the 'old fashioned' way of sharing profit with a normal bonus (hey, you guys did a great job) won't work better if applied correctly, although this could also be seen as a way of making the bonus structure work less politically colored, or at least more transparent.

kprifogle1 11y ago
janpietrz. Thanks for your feedback! I'll address your questions in order: - The interface aims to be dead simple. From the developer perspective there is little interface (aside from reporting back to them what they have earned, which tags earned the most, etc). The developers are simply adding tags into their git commits. From a manager perspective, there are two main interfaces: 1. there is a path to define revenue streams (which can eventually integrate into native accounting software). 2. There is an interface that lists out the unassigned tags which you can simply drag and drop onto the revenue streams and set the commission rate. I can definetely provide more sketches if you like. I hope to update the website soon with more detailed screenshots. - There is a time weight component that is optional. One algorithm is a time weighted decay component that continues to value contributions over time even after they have been removed. -Definitely, weird scenarios can come out of it. Skein isn't meant to be a one size fits all solution but rather a platform for companies to customize their own solution. Its also not meant to be a perfect solution, but rather a solution that is better than what we have now (which is nothing ;), which can be iterated on over time. In terms of the scenario you described simplifying the code is actually something that benefits everyone working on a particular feature because it increases everyones percentage participation, because the total percentage of code went down. This motivates people to refactor code more heavily. However, there are ways to customize this behavior as well. Time weighted algorithms could potentially help with you scenario. Also keep in mind, even though that first 10% of the code you wrote was largely discarded, it was also the first code, and probably contains the core components which if written well will not go away over time. - The target market for this product is mainly small to mid size tech companies that don't want to offer equity as a costly compensation that many engineers don't value in the same way that an investor or board member would, but still prompts motivation and rapid growth. The possibility of unhealthy competition is eclipsed (IMO) by the fact that engineers are now empowered to participate at a level they have never been able to before, and that is at the level of commission, which provides tremendous benefit and motivation. Therefore, the idea is to promote engineers to compete in a healthy measurable way that they can see and optimize to the businesses goals, rather than the current way which is very qualitative and not transparent, perhaps even in some companies a bit more political. I think your idea on offering additional bonuses to more collaborative efforts is a great idea! - Exactly. Skein also serves another purpose, while the compensation component is important it is entirely optional and customizable. Another main value add that skein provides is an insight into how individual initiatives (in this case tags made by developers) impact the top line of the company in terms of its relationship to different revenue streams. To this day that process is very much a black box. This allows us to move more towards "data driven product development" a concept that will prove to define and further the technology industry in years to come.

kprifogle1 11y ago

janpietrz. Thanks for your feedback! I'll address your questions in order: - The interface aims to be dead simple. From the developer perspective there is little interface (aside from reporting back to them what they have earned, which tags earned the most, etc). The developers are simply adding tags into their git commits. From a manager perspective, there are two main interfaces: 1. there is a path to define revenue streams (which can eventually integrate into native accounting software). 2. There is an interface that lists out the unassigned tags which you can simply drag and drop onto the revenue streams and set the commission rate. I can definetely provide more sketches if you like. I hope to update the website soon with more detailed screenshots. - There is a time weight component that is optional. One algorithm is a time weighted decay component that continues to value contributions over time even after they have been removed. -Definitely, weird scenarios can come out of it. Skein isn't meant to be a one size fits all solution but rather a platform for companies to customize their own solution. Its also not meant to be a perfect solution, but rather a solution that is better than what we have now (which is nothing ;), which can be iterated on over time. In terms of the scenario you described simplifying the code is actually something that benefits everyone working on a particular feature because it increases everyones percentage participation, because the total percentage of code went down. This motivates people to refactor code more heavily. However, there are ways to customize this behavior as well. Time weighted algorithms could potentially help with you scenario. Also keep in mind, even though that first 10% of the code you wrote was largely discarded, it was also the first code, and probably contains the core components which if written well will not go away over time. - The target market for this product is mainly small to mid size tech companies that don't want to offer equity as a costly compensation that many engineers don't value in the same way that an investor or board member would, but still prompts motivation and rapid growth. The possibility of unhealthy competition is eclipsed (IMO) by the fact that engineers are now empowered to participate at a level they have never been able to before, and that is at the level of commission, which provides tremendous benefit and motivation. Therefore, the idea is to promote engineers to compete in a healthy measurable way that they can see and optimize to the businesses goals, rather than the current way which is very qualitative and not transparent, perhaps even in some companies a bit more political. I think your idea on offering additional bonuses to more collaborative efforts is a great idea! - Exactly. Skein also serves another purpose, while the compensation component is important it is entirely optional and customizable. Another main value add that skein provides is an insight into how individual initiatives (in this case tags made by developers) impact the top line of the company in terms of its relationship to different revenue streams. To this day that process is very much a black box. This allows us to move more towards "data driven product development" a concept that will prove to define and further the technology industry in years to come.