
Apply HN: Skein – Engineers Paid on Commision - kprifogle1
Skein is a disruptive technology that definitively solves the KPI incentive problem for engineering resources.  No longer do engineering efforts have to be a nebulous pit with no way to measure the value of individual initiatives.  Skein is not only a platform for transparently determining the bottom line impact of engineering efforts, but it is a launch pad for a revolution in technology company compensation and culture.<p>Software Engineers of today are far more entrepreneurial and risk tolerant now than ever before.  Bring your sales and technology teams closer than ever before with Skein, and see endless rewards.<p><a href="http:&#x2F;&#x2F;skein.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;skein.io&#x2F;</a><p>Skein is a dead simple technology with complex and far reaching implications, not sure how it will work?  Check out the faq:<p><a href="http:&#x2F;&#x2F;skein.io&#x2F;faq&#x2F;" rel="nofollow">http:&#x2F;&#x2F;skein.io&#x2F;faq&#x2F;</a>
======
janpieterz
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
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
:/ Any thoughts?

