[Secondary Proposal 3] API3 DAO Team Proposal Operations Cycle #4

Official Proposals
1

API3 DAO Operations Team Proposal

Team: Operations

Operations cycle: #4

Period: 1 August 2021–31 October 2021 (3 months)

Amount: $261,715.06

Destination: 0x98f1d35bB3A4570AeAa601aA3eB54d8fc7aB37e1

Scope

The Business Operations Team has the responsibilities below. The scope of the project will vary periodically, and this list represents the current state. Additionally, Mason Burkhalter and Heikki Vänttinen are designated as authorized signatories on behalf of the API3 Foundation for such agreements reasonably related to accomplishing the objectives and deliverables set forth in this proposal, until revoked by subsequent DAO resolutions.

  • Oversee general project development, including facilitating inter-vertical visibility

    • Align operations across verticals with project mission
    • Coordinate key operations and facilitate effective communications between teams in different operations verticals
    • Report to investors and other stakeholders
    • Steer execution

  • Maintain, monitor and operate infrastructure, including:

  • Mail server

  • Company Drive repository

  • Web servers

  • Websites

  • Security of infrastructure (Cloudflare etc)

  • Cloud backups

  • Communication and operations tools/platforms - Trello, DocuSign, Salesforce, etc.

  • GDPR compliance oversight and maintenance

    • Subject Access Requests
    • GDPR Audits
    • Training
    • Regulatory contact and management point

  • Facilitate staff onboarding across foundation

    • Access to API3 operational infrastructure, provisioning of new users/staff
    • Operational user accounts for performance of tasks - permissions etc
    • Access to and ongoing development of training resources and educational materials

  • Business Documentation

    • Design, maintenance, curation, and auditing as require

  • Legal and Compliance Services

    • Correspondence and negotiations with service providers, auditors, developers, partners, external counsel for legal opinions required by third parties, partner projects and entities
    • Ad hoc agreement drafting and negotiation
    • Compliance and regulatory research and communications

  • Additional Operational Tasking as required (ad hoc)

Requested Funds

opshl

Team Grants

OpsTeamTable

  • The destination for this proposed budget is a wallet address managed by Mason.

Expenses

During operations cycle #3 and in addition to other operational expenses like Slack, DocuSign, managed security services, API3 business servers for mail and web, the operations team promoted the BD - API Lead (Mason Burkhalter) to the role of Director of Operations, and has moved Emily for process analysis and Greg for Salesforce administrative management and support.

Moving forward, the operations team will need to cover all operational overheads of the API3 organization, including tools like Slack, Salesforce, DocuSign, API3 business servers for mail and web, managed security services, audits and training, etc. For these expenses, we will combine realized expenses from the previous BD - API cycle that are more appropriately labeled as operational expenses (i.e. Salesforce), as well as to use the previous cycle’s realized Operations expenses as a guideline. Further, the operations team has worked in unison with the BD-API team to develop new verticals and to trim down that team to only relevant personnel. For example, Camron will now be heading API3’s API Integration efforts and has built a team for this purpose that resulted in the movement of himself and Brandon from the BD-API team. The operations team is attaining Mason, Emily, and Greg; and has also incorporated a new part time role filled by Kyle to assist with DNS and network security tasks associated with email server and deliverability issues that have cropped up occasionally. Other personnel movements from the BD-API team include Ugur to Marketing, Gio to the BD Enterprise team, and Jacob G to the BD Platforms and dApps team.

In the previous cycle, the organization purchased a DocuSign plan for the year which will be used across the organization. Additionally, the team was over budget in cycle #3 due to legal fees associated with researching the security status of the API3 token in the EU and US jurisdictions, which is ongoing. Because of the continuing need to purchase new tools or subscription services and due to the ever evolving nature of organizational support needs that will be defined as the DAO grows rapidly, a 10% overage rate was applied to the cycle #4 budget as a means of hedging against any unforeseen miscellaneous or legal expenses that may arise as they have in the previous cycle. Any amounts left over in the end of Cycle #4 will be applied to the following budget cycle.

Cycle #3 Deliverables Achieved

  • API3 DAO Launch
  • Open Bank Project partnership operational support provided.
  • EEA event for cycle #3 - resources secured and supported.
  • Attended BTC Miami for networking
  • Greg repositioned to Operations team as Salesforce Process Manager
  • Mason repositioned to Director of Operations
  • Emily repositioned to operations team to manage processes
  • Analyzed key functions of business development and integrations in order to coordinate efforts - ensured development of necessary documentation and processes
  • Assisted in structuring Marketing efforts as they develop key customer analysis tools
  • Restructured the organization to better suit the needs as API integrations begin, moving valuable members to best-suited verticals
  • Salesforce functionality improvements:
    • Restructured lead tracking and redistribution in SF
    • Created process flows for lead data imports and opportunity creation to streamline BD processes
    • Created opportunity processes for the integrations vertical to keep records in SF
    • Continually improved processes around recycling leads to improve lead generation capture
    • Worked with Marketing to integrate an email marketing tool to facilitate data collection and improve email deliverability and business intelligence
  • Developed Integrations processes as API Providers begin running Airnode
  • Formalized the legal structuring of the DAO-governed API3 Foundation legal entity
  • Negotiated and finalized agreements with auditors, several enterprise contacts, and continued support and dialogue with prospective third party partners and services
  • Funded legal research on the token security status in the EU and US, which is ongoing

Deliverables

The majority of the team’s work is a regular series of daily operational tasks and management of internal business resources built to facilitate the successful business functions of API3 on a daily/weekly/monthly basis. These relate to the maintenance and operation of business-critical tools and infrastructure and regulatory compliance requirements such as GDPR, privacy, security etc, granular details most of which are by necessity confidential for legal and operational reasons, as is the case for any commercial organization.

Additionally, the operations team has been designed to serve as a readily available support vertical to all other verticals in the organization. This means that the team plays an active role in identifying gaps and strategic initiatives, and then defines and builds the processes and structure needed to adapt to or fix an observed inefficiency or problem. As such, deliverables will revolve around increasing the quality and effectiveness of verticals organization wide while aiding in the reduction of costs and inefficiencies as the organization evolves.

5 Likes
2

This looks good :+1: excited for the upcoming cycle

3

Two quick comments:

  • there’s a sentence at the end of the Expenses section that I think is unfinished: “Any amounts left over in the end of Cycle #4.”
  • the numbers in the Requested Funds table don’t match up with the more detailed Team and Salaries table (the Requested Funds items add up to $234,305.51 rather than $261,715.06). I think it’s the Expenses number? The detailed table numbers seem to be accurate.
3 Likes
4

All good in my book. I’m in favour of it after having witnessed the performance of the team in prior cycles.

1 Like
5

Dang dude you are def a lawyer, great catch. Took me a minute to figure out where I went wrong there.

3 Likes
6

This looks great to me. Let’s go!

7

This proposal is now live and can be voted on here: https://api3.eth.link/#/governance/secondary-3

1 Like
8

I’m interesting in initial ideas re: inter-vertical visibility – something I’ve been wondering myself too

2 Likes
9

Tons of stuff to do around that. I’d like to create an official role for reporting org-wide

2 Likes
10

@Mark_Fitzg has been taking that role until now.

11

I found the cycle 3 deliverables questionable. For example, I can’t think of anything that this team did specifically for the DAO launch.
It’s difficult to demonstrate tangible deliverables for an operations team that will warrant a budget of this size. However, the reason the budget is inflated is that it covers some of the expenses of other teams, which makes it difficult for the voter to assess efficiency. For example, the API BD team needs Salesforce to operate, but it’s not included in their budget and here instead. This makes API BD seem more efficient than it is and the opposite for the operations team.
A solution would be to charge other teams on your services so that you need a smaller budget and can get away with more minimal and accurate deliverables.

2 Likes
12

interesting and valid points - thanks!

13

Excellent input here, thank you.

Regarding the DAO Launch, I think the rationale was in supporting those who are less knowledgeable about active participation, and overall assumptions were likely made as to the overall level of support/involvement in the DAO release. If we over-estimated that, we can remove that from deliverables if you think it would be appropriate to do so.

With respect to bloated budget for key infrastructure like Salesforce, I think your idea to charge individual teams makes sense. One main aspect to this tool is that it can actually serve most business related functions as a robust CRM/CMS tool. We tried conveying that this upcoming cycle we’re going to be working on cross vertical processes and visibility into those processes. For example, at a high level we are working on how each vertical would use Salesforce to track the accounts that were initially entered into the system by BDs. When a provider is signed up, then integration and marketing teams are contacting and coordinating with them on our marketing efforts and also getting Airnode integrated. The current plan is to build out these processes, then use them to inform the creation of a new vertical of account management. Because we are building these processes out on the operations side before then distributing the structural and procedural implementations, we didn’t think that leaving the tool on the BD budget made sense, because it’s likely this will require more licenses across numerous verticals.

I think once we have this structured, it would definitely make sense to spread this around by charging verticals for the support of the tool contributed to their verticals. This is also something we could start doing for Docusign and other various tools. Definitely worth considering generally the best approach overall. I think it also is worth mentioning that we are hopeful that we won’t go over budget at all and will have plenty rolling over into the next cycle. Some of the decision around adding a buffer is because of expenses like those that were incurred on the legal side in Cycle 3 that ended up causing the team budget to have a sizeable deficit.

14

Apologies for a delayed comment. Just sharing a thought, it is perhaps already embedded in the work streams - Competition and market intelligence. I have found that having it as a planned process can be helpful , especially in a the more competitive and rapidly evolving spaces.

15

Thanks Ashish! Can you elaborate a little here? I’m not sure I’m gathering what you’re suggesting.

16

Thanks for the quick reply @LikeTheJar . I meant a formalized competitive intelligence process. Generally speaking, i have seen that most projects / companies do some competition tracking, however in most cases it is more reactive or episodic (i.e. when some news / announcements catches attention).

I have been a part of some formal process implementations and found that it helps the organization

  • Understanding and Anticipating how competition and market will move
  • Serve as an important input to strategy. Can help the organization stay ahead of competition
  • Make the team at large more attuned to competition and market, and align the team on this dimension

By a formalized process i mean

  • An agreed frequency - monthly is reasonable for a roundup and a deep dive every quarter
  • Identified competition, areas of market to track
  • Identified data sources and proactively seeking information
  • A resource or team that collates and analyzes the information
  • Internal reporting is better done through a team meeting as that helps with a discussion and also gets in everyone’s expertise and involvement
  • This process works best when housed centrally and with a strong backing of the leadership team

This has been a long reply. Hopefully i could clarify. Else happy to get on a discussion and i can also share some examples from how i have seen other organizations do it.

17

Thank you so much for this thoughtful response! I agree with all of these points, and to a large extent we do much of this internally and through coordinated meetings we actually hold on a weekly basis. I think since the industry of oracles is relatively young and hasn’t fully matured, competitor analysis is a bit ambiguous, since we’re all going about solving the same problem in different ways. That said, I’d be happy to discuss this with you in more detail one on one if you think we could add more value to what we’re doing. Feel free to reach out to me at mason@api3.org or via DM and I’ll shoot you a calendar invite so we can chat.

18

I agree with the need to have each team’s budget be as transparent as possible, and can see the potential problems that having the ops subteam paying for all of the software etc used by other subteams can cause. However, rather than having individual teams pay an amount across verticals to reduce the operations budget (but correspondingly increase theirs), would it not be more efficient to break down the estimated cost of each subscription by subteam, but still have it included in the ops budget, for the next proposal? This would make it more transparent where the ops spend goes without needing the transfers.

3 Likes
19

Agreed, I was talking strictly about bookkeeping

4 Likes
20

Yeah I can certainly add a more detailed accounting breakdown in the next proposal. Thanks for the feedback, I’ll be sure to incorporate.

3 Likes