Proposal: Professional Recruiting

[Ryan Taylor]

This is cross-posted at www.dashcentral.org/p/hr-recruiting-201704

This proposal funds a budget for professional recruiting services to assist the core team in quickly filling the positions that appear likely to fund in the April budget. The expansion of the core team in the proposal is large, expanding the number of full-time rolls from 14 to 30. See the proposal here https://www.dash.org/forum/threads/proposal-core-team-expansion.13950/ for additional details on the planned expansion or specific roles.

Given the number of roles being created, recruiting, filtering, interviewing, and negotiating offers for each of these positions represents a tremendous time-commitment of the current core team members, particularly for those responsible for a functional area that will be making the hiring decisions.

By bringing on a professional recruiting firm, much of the burden of the hiring process can be lifted, allowing the team to remain more focused on their ongoing responsibilities. These specific help includes:
- Active recruiting of potential candidates
- Creation of job descriptions and pricing salary range comparibles for the positions
- Advertising positions through public postings
- Filtering potential job candidates through screening
- Arranging interviews with core team members
- Assisting with negotiations and making final customization based on candidate experience and location
- Coordinating onboarding process, start dates, etc.

Typically, professional recruiters take anywhere from 20-30% of the first year salary as a fee. For these 16 roles, that would be well over $200,000. However, as we are already working with August Venture Talent on the core team salaries project, they agreed to rates that are a small fraction of that rate. We feel that the value of getting resources faster and enabling the core team to be less distracted by the recruiting process over the next two months (a time we consider critical given our recent success) is well worth the expense. Having the team focused on hiring over the next two months would carry significant risk of losing our momentum. We have an arrangement that will allow us to choose between hourly services or a flat fee specific for each role. AVT would manage the entire hiring process from end-to-end. Although there is likely some uncertainty surrounding the hourly figures, our estimate calls for a total budget of $48,000 to complete all 16 positions. If we happen to fill certain roles through our already-started efforts, we could come in under budget and we would reserve any leftover funds for future recruiting needs where it makes sense.

There are several key members of the core team that would help free their time from the hiring process through this proposal:

Andy
Ryan
Holger
Robert
moocowmoo

I have said many times that our biggest challenge right now is growth, not money, but that we would do our best to use the available resources as efficiently as we can. I do recognize that it would be less expensive to conduct this recruiting on our own, but it would come at the expense of our growth rate and take away from our capacity to execute. Given these circumstances, leveraging an external recruiter makes sense at this time.

If you have any additional questions, please post them in the Dash Forum and tag @babygiraffe or @fernando in your message to ensure we see your post.

Requested funding is as follows for the April 5th budget cycle:

• 561.06 Dash for core team recruiting services ($48,000 USD @ $85.553 per Dash based on March 28th average rate at https://bitinfocharts.com/comparison/price-dash.html)
• 5.00 Dash proposal reimbursement

Total: 566.06 Dash

Note: Should any funding remain, we will apply it toward future core team HR expenses.

Manually vote YES on this proposal:
dash-cli gobject vote-many 05294827ca9101181b359ca2c8527307955763ddb4b6de15f467c12ea6ce7c56 funding yes
OR from the qt console:
gobject vote-many 05294827ca9101181b359ca2c8527307955763ddb4b6de15f467c12ea6ce7c56 funding yes

Manually vote NO on this proposal:
dash-cli gobject vote-many 05294827ca9101181b359ca2c8527307955763ddb4b6de15f467c12ea6ce7c56 funding no
OR from the qt console:
gobject vote-many 05294827ca9101181b359ca2c8527307955763ddb4b6de15f467c12ea6ce7c56 funding no

 

[GrandMasterDash]

Pity the recruitment team can't do some vetting on the people submitting proposals... just saying...

 

[demo]

Instead of recruiting proposals, they recruit persons-servants. Pity.

Instead of defining what job they want to be done and ask anybody in the free market whether he is able to accomplish the job (this can be done in an alternative budget system) , they create a centralized bureaucratic pyramidal "state", in order to control everything. Not the best lead Dash, Dash is leaded by the trusted.

The reason of all this?
It is because the Masternodes are eponymous, so they are liable in front of the law, so they are afraid to trust anyone in the free market. Masternodes are afraid of the anonymous, and they dont like them, although they owe them the vast majority of the code they are using (the bitcoin code)

The solution?
Turn the masternodes as much anonymous as you can, and as numerοus as you can. This is the only way to avoid liability. But this obvious solution in order to avoid centralization and liability has been rejected by the masternodes, thats why Dash turns more and more towards a centralized bureaucratic pyramid.

 

[ashmoran]

Doubling the team size at once is incredibly rapid growth. My gut feeling is that if they were brought in all at once, the even if the recruitment company takes all of the admin work off the core team, that the new team members will still be a huge drain on the existing developers. They won't know the code, they won't be used to the development process, they'll have questions, they'll make mistakes, and so on (regardless of how experienced they are). Indeed, using a recruitment company may just shift the bottleneck from the hiring process onto the onboarding process, as having teams hire directly and grow themselves puts a natural limit on how quickly they can expand, whereas when people are air dropped en mass, the limit can come from the chaos that follows shortly after. (I've seen this happen!)

Doubling the team size will also massively increase the potential communication among team members, increasing the management overhead. If the code is kept suitably modular and people are organised into relatively autonomous teams around those modules, this isn't necessarily a problem. If it's not managed carefully, it can end up with everyone fighting over each other's code. (The Core vs Sentinel split is an example of how to do this well, and this sort of approach works well if used recursively through the code.) Not only this, but everyone who starts will probably at some point leave, and software teams must find a way to preserve their knowledge, otherwise the next wave of developers may be faced with a huge pile of code that nobody understands, because nobody who worked on it is still around. If, for whatever reason, 16 developers come on board and then leave after a year, then unless they wrote very clean, well-tested code, the price will be paid by future developers, who must try to understand what they did.

Using a recruitment company to offload as much of the work that doesn't need the knowledge of existing team members is probably a good move. What I would like to draw attention to (based on past experience seeing this go wrong) is that teams need to grow only as fast as their systems and processes allow them to, otherwise the result is like trying to fill a party balloon with water using a fire hose.


Sent from my iPhone using Tapatalk

 

[GrandMasterDash]

Just for the record, I wasn't knocking this proposal. Yes, of course it carries overtures of centralization, but we've had that argument over and over and it's time to accept that this is what dash is; a hybrid of old and new.

Anyway, all I was saying was, there have been times when I've been questioning the integrity of some of these people submitting proposals. And it seems to me, if they perform badly, let down end users or turn out to be scammers, that this reflects badly on dash as a whole. Thus I was wondering if it was at all possible that proposals of a certain size could benefit from some kind of background check / vetting procedure through an exchange / agency. A company like Crypto Capital Corp would make a good partnership.

 

[ashmoran]

Instead of defining what job they want to be done and ask anybody in the free market whether he is able to accomplish the job (this can be done in an alternative budget system) , they create a centralized bureaucratic pyramidal "state", in order to control everything. Not the best lead Dash, Dash is leaded by the trusted.

The reason of all this?

There is a good reason to do it this way. The amount of time masternode operators have to read, analyse and vote on proposals is limited, and they don't have access to all the contextual information about how development is working day to day. Masternode operators simply aren't able to collect and process all the information necessary to make every decision. So it is more effective to let them decide who will lead certain projects, and then let that person/team make the more fine-grained decisions they are better positioned for. This is no difference from a company, the directors don't make every hiring decision, they choose the executive team and let them manage the rest.

 

[crowning]

To be honest I'm not a big fan of hiring lots of people to do lots of stuff, I think an organic growth as we had so far is much more healthy.
9 women can’t make a baby in 1 month.

 

[ashmoran]

9 women can’t make a baby in 1 month.

Very true! And there's an excellent book about what happens if you try.

 

[demo]

Thus I was wondering if it was at all possible that proposals of a certain size could benefit from some kind of background check / vetting procedure through an exchange / agency. A company like Crypto Capital Corp would make a good partnership.

There is a good reason to do it this way. The amount of time masternode operators have to read, analyse and vote on proposals is limited, and they don't have access to all the contextual information about how development is working day to day. Masternode operators simply aren't able to collect and process all the information necessary to make every decision. So it is more effective to let them decide who will lead certain projects, and then let that person/team make the more fine-grained decisions they are better positioned for. This is no difference from a company, the directors don't make every hiring decision, they choose the executive team and let them manage the rest.

It is not the amount of time the masternode operators have to read, analyse and vote that is limited. It is the number of the masternodes operators that it is limited. You need more masternodes operators to vote.

4000 masternodes , which means about 100-200 operators, are not enough. Have a look at wikipedia, how many writers are needed in order to built a decent encyclopedia? A similar (to wikipedia) number of voters is needed, in order to vote something decent. But you dont understand that, and you will never do until you give it a try and see the results. It is something similar to wikipedia, nobody was ever able to imagine that a decent encyclopedia could be built by random numerous writers.

And of course the other problem is the month finilization. You have to overcome the stupid idea of doing every month a budget finilization for all proposals, and let every proposal to finilize whenever it reaches the decided threshold (currently set to 10%).

So dont blame the limited time the masternodes operators have, neither search (like @GrandMasterDash is doing) for an agency to do the voting job for you. Blame the naive design of the budget system.

 

[ashmoran]

4000 masternodes , which means about 100-200 operators, are not enough. Have a look at wikipedia, how many writers are needed in order to built a decent encyclopedia? A similar (to wikipedia) number of voters is needed, in order to vote something decent. But you dont understand that, and you will never will until you give it a try and see the results.

I don't understand the comparison. Wikipedia is a publishing system, and each writer contributes the own little bit to the total content. It's an additive system. Dash governance is a decision making system. Anyone can add proposals, like anyone can add content to Wikipedia, but the voting process is designed to accept or reject this content, not add to it. It's a subtractive system.

Maybe it would be better to compare governance to forum moderation? Moderators approve or remove content, but do not (in their role) create it themselves. A small number of moderators can maintain a forum with thousands of times more writers. The difference is moderators can make unilateral decisions, whereas Dash governance uses democratic majority rule.

So dont blame the limited time the masternodes operators have, blame the naive design of the budget system.

I was not blaming anyone. I was just stating the fact that masternode operator time is limited (there are only so many hours in the day, only so much information can be communicated in this time, and people can only think so fast), and that this is a constraint on how much can be processed through the governance system. If good decisions are to be made by masternode vote, some must delegated, simply to respect the laws of physics.

Considering that the Dash budget system is the first working budget system in a cryptocurrency, it seems a bit unfair to me to criticise it for any weaknesses. The Dash 12.1 Sentinel code has rewritten the governance system to make it more flexible, and while currently it's just being used to mirror the previous budget system, it opens more options for the future.

You used the word "blame" twice is this sentence and I feel this is a bit harsh. People here are trying to do their best. This is a new and difficult problem to solve, and it is unlikely that they will get everything right first time.

 

[demo]

I don't understand the comparison. Wikipedia is a publishing system, and each writer contributes the own little bit to the total content. It's an additive system. Dash governance is a decision making system. Anyone can add proposals, like anyone can add content to Wikipedia, but the voting process is designed to accept or reject this content, not add to it. It's a subtractive system.

Dash governance is designed to be a subtractive system, but it could be otherwise. For the below reason, I have already told you.

And of course the other problem is the month finilization. You have to overcome the stupid idea of doing every month a budget finilization for all proposals, and let every proposal to finilize whenever it reaches the decided threshold (currently set to 10%).

The finalization of the proposals should not occur every month. The votes for every proposal should be accumulated, and the proposal should not be finilized until a threshold is reached. This alternative governance system cannot be considered as a substractive system. Accumulating means adding, so it is an additive system. The votes could be designed to behave as an additive system, and not as a substructive system like it is currently designed in the Dash governance system.

For example, this is what I do to all my polls, here in this very forum. My polls never expire, and the votes are accumulated. I just need more voters, for some of my polls to pass the threshold.