The Startup Status Report: Good or Bad?
The difference between good managers, and good technologists. Why each needs the other, with a live status report for example.
Does a single Engineer or Technologist need a manager? I would argue yes.
Taking time out from the intensive technical work in a startup activity to report status, instinctively feels counter-productive, seemingly detracting from precious time.
This feeling increases, with increasing awareness, if the core work is not progressing as forecast. Thus what began as a feeling of irritation quickly becomes a feeling of dread, if not tackled early. This is especially acute in the situation of lone working, with little or no possibility of enlisting help to complete the work in hand, in the time originally forecast.
So we take a break from the core technical work of the startup to make a status report, as well as some other non-core promotional tasks.
Here we could do with a good manager, a manager who knows the nature of research and development work. Such a manager knows that this kind of work is a bit like that of an explorer who has to make their way through an unknown forest. A good manager is also aware that no-one knows the path through the forest until the forest has been explored.
The technologist is driven by optimism, a real faith in a successful mission, otherwise they might not be driven to even start on the project. Success includes delivering things on time. The good technologist’s optimism will always lead them to assume that the path they take through the forest will be the shortest. They base their initial estimate on that.
The good manager’s pragmatism will always lead them to assume that the path eventually taken will not be the shortest. They will base their estimate on that of the technologist, plus a margin based on their own experience of managing exploration projects, and pass this on to the stakeholders.
In the case that there is no manager, the time-to-dread factor is small, as there is no managing buffer between the technologist and the project stakeholders, and thus no real margin for error.
So, as the technologist working in isolation myself (On the VRENAR project, not the ongoing PhD project supervised by the OU), to avoid dread, I will provide regular updates, at least until I get a manager. The Stakeholders of my project are you good folks, the general public, who might be watching to see if my project is worth backing.
- Community Company, REMMI Research CIC, is now officially set up.
- Domain names remmi.org, remmi.io, and vrenar.io all set up.
- Stakeholder analysis complete
- Websites for domain names in process
- Token Sale White Paper in process
- Logical analysis of voting processes around 80% complete, pending further work on Software.
- Initial Ecosystem Software in Process on Ethereum test network.
- Release the White Paper (Top priority, as this is needed to begin fundraising and the Token Sale)
- Complete Logical Analysis, ideally before release of the White Paper draft
- Complete Initial Software, ideally also before release of White Paper draft
- Construct websites for domain names, White Paper site (vrenar.io) first.
Problems / Risks
- Ethereum client Mist proving to be very difficult to maintain successful running on main machine. Symptoms indicate blockage of traffic, but this is still under investigation. Parity Ethereum wallet used briefly, but now not functioning following system crash. Could be complicated by recent Windows fixes for Meltdown and Spectre Bugs.
To avoid clutter on Medium, future status reports will appear on: https://gitter.im/VR-enabled-AR-VRENAR-users/Lobby