Business : Organization

From bitrary
Jump to: navigation, search

Business : Research


Suggested Rules for an R&D Team

The rules here are optimized for getting proper technical results in as small time period as possible. The suggested rules are not suitable for satisfying corporate social needs.


  • No event-driven deadlines! Minimum deadline for a software development project should be 1 year and if the deadline is missed, then the only sanction should be the absence of payment, because the developer has probably already bore the burden of spending ones time on the project without getting properly paid for it. There is no need for extra bonuses for delivering sooner, because the sooner the developer delivers its deliverables, the sooner the developer can start to work on next paid project, possibly from another client. Developers/scientists should get paid for delivered results, WORKING prototypes, agreed upon documentation, measurement data, etc, not "working hours". It is possible to agree that the paid project can be a study of some problem, in which case the paid deliverables are the documentation about the observations made during the study.

An example: pay the Columbus for the voyage, 50% upfront for the ships and crew, but do not demand the discovery of the America and pay the rest of the 50% project fee for a thorough travel log that contains all the rest of the observations, even if there aren't that many observations. In the case of the Columbus example, an observation might be that there was just one huge sea and no other continents were discovered, but the weather at the sea was such and such. The developers/scientists, who deliver more working/useful results will get more business over time and the best developers/scientists tend to be so self-motivated, motivated by the technical results alone, that they need money/payment only to be able to focus on the things that they are interested in and partly see the payment amount as a symbolic value that reflects the attitude of the customer towards the developer/scientist. For example, if some corporate lather climbing sleazeball gets paid far more than a proper, hardworking developer/scientist, then that developer/scientist will resign not because its compensation could not comfortably allow the developer/scientist to focus on technically interesting projects, but because the lower payment is perceived as not sufficiently valuing the efforts of that developer/scientist. In that sleazeball versus proper developer/scientist situation compliments from superiors to the developer/scientist are seen as lies, which are worse than even empty words would be.

  • The person, who does the work, decides, how it is done and with what tools it will be done, because only that person has the time to properly get to know the problem at hand and the person, who does the work, itself has to endure the deficiencies of the chosen tools.
  • Investments to project work hours and tooling budget should be decided by a technical specialist, who self works on the problem, not some "general manager", who probabilistically ruins a project's technical success by starting the project without having proper amount of money and time available for the completion of the project and does not understand the huge technical wins that can be obtained relatively cheaply (time wise and money wise), if the work on the main project reveals new information about new technical opportunities that can be taken advantage of by working on an ad-hoc sub-project/side-project.
  • Leader of a team of technical specialists (physicists, software developers, biologists, etc.) has to spend most of its time doing the very same work that the rest of the team members do to be competent enough to earn the proper respect of the rest of the team members and to properly understand the actual hardships that the rest of the team members have to endure during the solving of the problems that the team has to solve.
  • Everyone have to be able to work at the edge of their capabilities despite the fact that different people have different preferences and different skill levels within their preferences. Technology and tools MUST NEVER BE MANDATED, they must be chosen by the person, who carries out the task. Idiots, who do not have an opinion about their tools, MUST NOT BE HIRED! Only resource limits and interfaces are subject to negotiation.