Factable Solutions

Standing Parties: Please score this ANO Candidate from 0 - 60

Results will be visible after the poll closes. Your vote is displayed below.

Results are only viewable after voting.
Secured
#1
Factable Solutions is a lean, tightly run company located in Silicon Valley. The team has over 20 years of experience running production servers in a corporate environment as well as 13 years experience in enterprise software development. Initial plans are to run a high efficiency infrastructure node while also doing core development work on the Factom Protocol. Team members include:

Dr. Michael Lam (https://www.linkedin.com/in/michael-c-lam/) - A computational lithography expert and principal software engineer

Rajan Lakshmanan (https://www.linkedin.com/in/rajan-lakshmanan-4250211/) - An IT lead and manager of Global Technologies and Infrastructure at a large corporation.

We thank you for your consideration to be an ANO for the Factom Protocol, and look forward to any questions you may have!
 
Secured
#4
Hi Michael - thanks for your application!

You ask to be considered principally as a core developer, but talked mainly about the importance of business solutions. Would you be looking for grants to develop projects?

Do you have experience with consensus networks or working remotely as part of a decentralised team?

What's an area of protocol governance you either don't agree with, or believe should be strengthened?

Kind Regards!
 
Secured
#5
Hi Factable Solutions,

Thank you for applying and for the thorough responses to the application prompts!

You mention a commitment to working on the Factom Protocol's core development, and I believe that value is likely one of the single most important things that anyone in the Protocol could be working on or bringing to the table.

Another skill you state that you possess, is an impressive ability to take complex concepts and make them more easily understood by audiences. This is a pain point right now in the Factom Protocol; we don't have enough minds, bandwidth, or sometimes -- quite the right pitch to explain the brilliance of Factom in a truly simple and easily understood way. I know your responses pointed heavily to code development, which I think is fantastic, but I would love to know if at some point you would be open to educating more than just your internal network in Silicon Valley about the merits of the Factom Protocol and its worldwide potential.

I realize that with your team's Efficiency pledged at 60%, and with plans to perform code development down the line (6-9 months away potentially, as you mention), that asking for more probably seems gluttonous on my part. But if you're genuinely skilled at educating and can take a complex concept like Factom and demonstrate its value from a real-world, business-oriented mindset to audiences, then I believe there's powerful marketing potential in that value you bring.

I'd love a statement that can capture that value.

Right now, I view your stance on this particular topic (from your application responses) as something to the effect of, -We are a team of strong educators, we can educate audiences, we're flexible and will do what we can in terms of educating and/or marketing the Protocol within our inner circle- ...this is good, but I want to hear something more like, "Knowing that we have the potential and business acumen to simplify tough concepts and educate people on a variety of things, we will broaden our outreach of the Factom Protocol by educating and marketing to many of the sharp minds and companies that we encounter and/or seek out over time - and we believe we can successfully deliver that explanation and pitch to the tune that the Protocol deserves."

Could you make a statement similar to that effect (assuming that it is in line with your intentions)?
 
Secured
#6
Thank you for applying to be an ANO! I'll likely have some specific questions later, these are simply questions I am asking all applicants.

1. Will you commit to, if elected, having, at the very least, the executives who will play a role in this ecosystem:
A. Signup for this forum with their username being First Name Last Name
B. Have a personal picture as their avatar.

It's not a requirement that this happen and some won't care but I personally will score those who won't commit to this a little lower and I want to be transparent about that.

2. Will you commit to having a logo created and/or submitted to this area within 30 days of your election (I would provide directions).

3. Will you commit to keeping this area updated for your team (it's easy).

4. Will you commit to providing at least a quarterly update on the progress your team is making in this area.

5. If you haven't already posted them within this thread, please provide the LinkedIn of anyone you mention as part of your team.

Thank you!
 
Secured
#7
Hi Colin, thank you for your questions. Here are my responses:

You ask to be considered principally as a core developer, but talked mainly about the importance of business solutions. Would you be looking for grants to develop projects?
  1. While I’m a core developer at heart, I have experience in new product and technology development. It is extremely important in those early stages of technology development to have a firm eye on the business applications. It is much more important than with a mature technology. Technology developed in a vaccuum is rarely successful. The Factom Protocol is a technology which is still developing and with lots of potential applications. Part of successful startups is focusing the limited resources at your disposal into projects and development activities which will make the most impact on the most promising directions. So to my eye, a marriage of core development and business impact is an important principle and why I try to drive home that point. In the beginning, I would not be looking for any additional grants to fund projects. As I get deeper into the codebase and more integrated into the Factom ecosystem, I can better weigh the directions that need to be taken and it may very well be that we apply for grants for specific proposals, but this would likely be associated with hiring a new person.
Do you have experience with consensus networks or working remotely as part of a decentralised team?
  1. My experience is primarily in the corporate world, which is generally different from a consensus network, but in my experience isn’t that different. Ultimately in the corporate world, a manager is responsible for making a business decision, but they will never be successful if that manager doesn’t listen to their team’s input. I’ve found it is usually a very rare situation for completely split consensus within a team. This is likely because I’m in engineering where data rules, and it’s difficult to argue against appropriately generated data. That said, I have collaborated on projects with teams spread globally. I’ve worked with teams based in Korea, Taiwan, Moscow, Cairo, Europe, USA - east coast, as well as USA west coast. Usually the biggest issue is just the time differential.
What's an area of protocol governance you either don't agree with, or believe should be strengthened?
  1. As someone new to the Factom Protocol, I do not have as deep an understanding of the current governance as the existing parties in the ecosystem. As I get more familiar with the system, I’m not shy about voicing my opinions. But at first blush, it is impressive how organized the protocol is. My only concern right now (and I see its a concern of the existing standing parties) is the time overhead of reaching concensus on everything. As Factom grows, the existing committees will be critical to do a lot of the legwork within their specific area, and fairly inform all parties about the pluses and minuses of any given decision. The committees will therefore be important to be filled with representative members from all parts of the ecosystem.

    2. I believe one critical aspect of a consensus network and its governance is to make sure everyone is rowing in the same direction. Typically the CEO or division manager is responsible for laying out the vision of a technology, and its everyone’s responsibility to move in that direction. I believe its critical to have an objective common goal for all parties to understand what success is. In that manner, I personally believe a critical metric for the Factom Protocol is the average daily number of entry credits used. This is a direct measure of ‘usage’ of the technology, and all standing parties should keep this in mind that their projects and developments are working towards an end goal of increasing this number over time.
Please let me know if I thoroughly answered your questions. Thank you!
 
Secured
#8
Hi Nic,

Thank you for your kind words. Yes, I am often tasked with giving presentations at Technical Review Meetings with customers, which go over our engineering vision for the products I’m responsible for, as well as updates on the key technical issues the customer had concerns about. Additionally, I have frequently given technical presentations on papers I’ve published through SPIE, typically in the Advanced Lithography conference, which can have up to several hundred attendees listening to your presentation (out of a couple thousand in attendance overall). I’m quite comfortable with public speaking.

I’m happy to give my support to certain marketing efforts. We’d have to discuss specifics of what exactly you have in mind. I mention in my proposal that I view the Factom Protocol as a startup, where ANOs would need to wear many different hats, and if my skills are most needed in a different direction, I can always adjust. I think an important point to make about marketing, is that it is not just an external push of information outwards. Marketing needs to pull information inwards and pass it to the ecosystem. If people are skeptical about Factom, why? If people don’t want to use Factom, why? Is there some piece missing from the technology which is preventing adoption? The information obtained by marketing needs to be digested and fed back to appropriate players in the ecosystem to either improve the technology to meet those needs, or formulate a plan to show why those concerns are unwarranted. Marketing is a two way street.

Let me know if that fully answered your questions.
 
Secured
#9
Hi David, here are your answers:

1A - Yes already done
1B - Yes already done
2 - Yes, of course. ANOs are key representatives of the Factom Protocol, and they should maintain a professional, business appearance to the external world.
3 - Yes
4 - Yes, this is quite reasonable
5 - This has already been provided in the original post.

Please let me know if there are any other questions!
 
Secured
#10
Hi Michael,

Yes, that does fully answer my question. I'm glad to know that your team is flexible in their approach and focuses on prioritization of needs, and that you'd be open to both inward and outward marketing efforts (pending the state of the Protocol in those future times, and then determining what would or could be effective). The competency to educate (which I knew you had from your responses to the application) + the willingness to educate (which I feel you have sufficiently conveyed), is something that I feel the Protocol could really benefit from (in addition to code development).

Thank you for the detailed response, and for providing more background into your public speaking experience.
 
Secured
#11
Hello, Factable Solutions, thank you for application.
I ask this questions all ANO candidates:

1. With what efficiency are you going to operate?

2. If your efficiency is lower, than 60%:
2.1. What have you already pledged to the Factom? It's a good practice, when ANO candidates pledge works in advance before being elected.
2.2. Do you have an experience in running business? What kind of businesses it were? Please tell us more about it, so we can understand your strengths and what expect from your ANO if it will be elected.
2.3. What a minimum number of hours per week are you going to work for Factom? Do you commit it?

3. Do you participate in any other cryptocurrency projects? If yes, please reveal details.
 
Secured
#12
Hi Anton,

Our application goes into more detail about each of these question, but I will summarize the important bits for you below:

1. With what efficiency are you going to operate?
A. 60%

2. If your efficiency is lower, than 60%:
A. Our efficiency is not lower than 60%, but I will highlight the important points of your questions.

2.1. What have you already pledged to the Factom? It's a good practice, when ANO candidates pledge works in advance before being elected.
A. We have pledged to operate as a high efficiency infrastructure node, fullfilling our ANO duties related to core server operations and participation in governance. Additionally, I have pledged to learn golang and within 6-9 months be contributing to core development of the factom protocol.

2.2. Do you have an experience in running business? What kind of businesses it were? Please tell us more about it, so we can understand your strengths and what expect from your ANO if it will be elected.
A. As a principal engineer, I have worked in the corporate world for 13 years as a software developer, and seen all sides of the technology business from R&D, product development, customer deployment, customer support, and quality assurance. I have experience in early technology development having co-founded a successful startup in Design For Manufacturability (DFM) within Semiconductor Manufacturing, as well as taking business school classes in the Berkeley Haas School of Business during my PhD work. Additionally, I have been involved in previous business partnerships. I am well versed in running a business.

2.3. What a minimum number of hours per week are you going to work for Factom? Do you commit it?
A. We commit to fully realizing the pledges to the Factom ecosystem from question 2.1 above, within the time span given.

3. Do you participate in any other cryptocurrency projects? If yes, please reveal details.
A. No, the Factom Protocol is our only cryptocurrency project.
 
Secured
#13
Hi and thank you for your application.

In 6-9 months (your estimate for when you would be actively contributing to core development) would you still operate at 60% efficiency, or lower your efficiency to compensate for the core work you would be contributing?

How much time per week, at that stage, would you be willing to contribute (and at what efficiency)?

Also; at what price point would you lower your efficiency if the price went significantly down "to keep the lights on"?
 
Secured
#14
Hi Tor,

Please find my answers to your questions below:

In 6-9 months (your estimate for when you would be actively contributing to core development) would you still operate at 60% efficiency, or lower your efficiency to compensate for the core work you would be contributing?

This is a very tough question to answer, because it involves a decision ~9 months out, which I’ve found is an eternity in business when technology environments are moving so fast, especially when I am coming in new to the Factom Protocol and am still learning so much. What I can say, is that I am committed long term to being a valuable infrastructure ANO that is also contributing to core development as well as my business insights from 13 years in technology development. If elected as an ANO, you will be very happy with my contributions. If I ever were to lower my efficiency, I would communicate this to all the ANOs, and also pledge additional commitments to what you would be getting for that reduced efficiency. It may be more of my time, it may be hiring another member (of which I have a couple people in mind) should we feel the need to scale. Or its possible to go a completely different route and apply for grants to fund any future proposals.

How much time per week, at that stage, would you be willing to contribute (and at what efficiency)?

I tend to focus on results, rather than hours worked. After working with hundreds of engineers in my work experience, I have first hand knowledge of the potential huge efficiency gap between engineers. I’ve given problems to engineers who came back a week later, after spending 40+ hours on a problem and they literally have nothing to show for it. I’ve taken that same problem and given it to another engineer, who comes back the next day with a powerpoint effectively communicating the root cause problem, with data to back up their claims, and with their proposed solution to the problem. You learn to be very results oriented when picking people for your team. I believe my experiences as a Principal Engineer leading a team of engineers, my business insights into technology development, and my 13 years of experience in enterprise software development will produce highly beneficial results for the ecosystem while maintaining a 60% efficiency infrastructure node.

Also; at what price point would you lower your efficiency if the price went significantly down "to keep the lights on"?

As a two person company, our overhead will be quite low. The business will keep much of the revenue obtained from the monthly stipend (aside from taxes and expenses), building up a buffer in the event of a downturn. In the event of a long term downturn, which drops the price of the Factoid even below our monthly expenses, I am prepared to inject cash into the business.
 
Secured
#16
I've decided to ask all prospective ANOs the following:
  • What experiences do you have running dockerized applications?
  • What are some things you learned while running your testnet servers?
  • How have your ideas about mainnet infrastructure changed as you have become more familiar with running factomd?
Apologies if you have already answered one or more of these somewhere else.
 
Secured
#17
Hi Michael, thank you for your application. As a fellow engineer I can empathize with a lot of the points you make. Your experience and commitment to building your development skills is valuable. To be able to help explain Factom to others will be a great asset. Your application speaks volumes about your ability to convey things well.
One simple question. How, with only two people, do you anticipate being able to provide 24/7 cover? I know of teams with more staff who find it difficult.
 
Secured
#18
Hi Mike,

How, with only two people, do you anticipate being able to provide 24/7 cover?

Both of us will be trained for emergency situations. With today's connected world we would receive immediate feedback in the case of a server fault. each mainnet would have a backup node ready to go that can be immediately brainswapped to gain uptime back. We can then debug the mainnet server without panic to assess the situation and determine the underlying issue. We have generally seen the Vps providers are quite stable, and the reserve node for each would provide sufficient fault tolerance to secure the required uptime.

Let me know if that fully answers your question.

Jay, I'll be posting a reply to your question in a couple hours, I haven't forgotten.
 
Secured
#19
Hi Michael, Thank you for your response. My concern was less to do with the technicalities and more to do with the fact that with two people there is the prospect that no one may be able to initiate the actions you describe. If for example one person is ill and coincidentally the other person has another pull on their time. How would you seek to mitigate the risk that no one is available to start up a back-up node?
 
Secured
#20
Hi Michael, Thank you for your response. My concern was less to do with the technicalities and more to do with the fact that with two people there is the prospect that no one may be able to initiate the actions you describe. If for example one person is ill and coincidentally the other person has another pull on their time. How would you seek to mitigate the risk that no one is available to start up a back-up node?
There's eight current ANOs with one or two team members. Of those with more than two team members, I suspect many don't have more than two people that can manage their servers.

Paying more than two people to manage two servers is a waste of money in our current environment.
 
Secured
#21
Hi Jay,

Here are the answers to your questions:
  • What experiences do you have running dockerized applications?
Rajan and his team have designed and supported cloud and cloud based engineering applications. Some of the dockerized applications supported were Jenkins and PCI passthrough technology. Overall his team supported dockers and expanded the support to many teams in the company. He started doc’ing GKE as a management platform and its still in the works.
  • What are some things you learned while running your testnet servers?
The testnet server process has been very smooth. Detailed and excellent instructions as well as videos were available. They allowed us to spin up the testnet servers quickly.
  • How have your ideas about mainnet infrastructure changed as you have become more familiar with running factomd?
The ease of setting up and so far maintaining the testnet servers gives us high hopes that the mainnet experience will be as smooth.
 
Secured
#22
Hi Mike,

I understand your concern. Under most normal circumstances I believe that the two of us could coordinate such that there would be no issue. Being a software engineer, I almost always have a computer near me, and same with Rajan. If this is something the community feels strongly about, I would propose that the ecosystem agree on a minimum guidline criterion for server support for ANOs, and then we would naturally agree to support those guidelines.

I mention 'normal' circumstances, because I suppose one of us could be away on planned vacation or other unavailability, and the other person is incapacitated in some manner, while simultaneously having a server fault occur during that time span. Under these conditions I suppose a two person team would indeed fail on server uptime. If there is real concern in this community that a situation such as this would occur, then I would again be open to addressing this issue in a manner which the ANOs find reasonable.

I'm not sure that alleviates your concern, but we are again open to working with the other ANOs to come to a reasonable solution for this improbable event if it is of concern.