Continuing the discussion from Operations Workstream Outline:
Hey thank you for taking the time to provide critical feedback to my proposal. I have some responses that may clarify some of the questions you presented.
I will be providing a more thorough breakdown of costs and potential budget line items that will be returned to the DAO if unspent. The $60k a month spend for the workstream will most likely not be fully reached on any of these months but is available for the Operations workstream to achieve maximum success and not be a blocker for any other workstream’s development or testing needs.
I’d like a better understanding of job role specs between Workstream Leader and Operations Coordinator. There seems to be a lot of overlap there, but I might be misunderstanding? If the Workstream Leader is managing the Ops Assistants, then why is Coordinator needed? And if Workstream Leader is not managing the Ops Assistants, then what is the justification for $150k/yr salary for this role? Either it’s a demanding role leading and managing this Function (in which case $150k may be justified), or the Coordinator is taking most of the day to day work, and then Workstream Leader seems more like a part time role. Please elaborate or explain these functions more if I’m not understanding (very possible!)
It seems a little pointed that this workstream is being targeted for detailed job descriptions and justification when the other proposed workstreams have not undergone the same level of scrutiny as they pass. Perhaps this is to make a greater example, but it also strengthens the feelings that Operations has always been an underappreciated and misunderstood department of resources (beyond ShapeShift).
We currently run a barebones Operations team at centralized ShapeShift with 1 director, 2 Ops coordinators, and (2) Ops assistants. While the Ops assistants focus is primarily on testing, the coordinator and workstream leader will have both of their hands full with 40+ hours a week responsibilities of managing and coordinating the stream, other streams, meetings, triage, and ad-hoc requests.
In meeting management, Operations is looking at coordinating, leading, and maintaining:
Weekly Ops Sprint, Monthly All Fox, Unsolved User Problems, Weekly Governance, Workstream Kickoffs, Project go/No-gos, Retros, and various other meetings held on recurring schedules. While there will be coordination with with C-mod team on some of these meetings in terms of av capture; the organization, agenda, documentation, moderation, communication, implementation and success of all of these meetings will be on the accountability and responsibilities of the Operations Workstream.
The Operations workstream leader (and coordinator) is a very demanding role aside from the aforementioned meeting moderation and workstream resource Operations provides to the rest of the DAO. All meeting managment resources will be provided by the workstream leader and Operations Coordinator. While the workstream leader will have both the coordinator and the assistants as direct reports, the coordinator will be positioned to be an escalations and triage specialist for the assistants to assure timely responses and correct information relayed to the proper workstreams given the issue and priority. The Coordinator will have no management responsibilities to the assistants outside of training and triage/testing resources. The coordinator will be the only other Operations workstream member with meeting management responsibilities.
The workstream leader will be the manager of the entire team with responsibilities including but not limited to, all Colony interactions regarding payment, funding test wallets, one on ones (reviews, metrics, individual kpis), Cross workstream collaboration, triage resource, greater meeting manager/coordinator/organizer, testing, and reporting. This jump in responsibilities is a large leap from my current responsibilities as an Operations Coordinator (manager) and this job is currently well over a 40+ hours a week responsibility.
The goal will be to achieve 24/7 testing and triage coverage in the future. The early version of my budget was a block with all 6 assistants starting to receive payment on Nov 1. I recognize that there will need to be a hiring/fit process and we will not be able to achieve full 24/7 coverage on November 1st, and we will not be able to hire all team members on Nov. 1st. My statement under the pictured budget is definitely considered for this circumstance: “Any unspent test funds or other budget items will either be returned to the DAO, or rolled over to the next month’s budgeted amount with the remainder being returned to the DAO at the end of the quarter.”
There is no assumption that we will spend all budgeted assistants’ salaries on Nov 1 as we build the team out, any unfilled positions will lead to FOX in the Operations workstream that will be returned to the DAO. (Either at the end of each month or quarter, whatever is preferred and set as protocol.)
Leaning on the community for first response will be good for first acknowledging an issue, but we will suffer a massive tragedy of the commons without an acountable and trained representative that knows and has access to the responsibilities included in deescalating and resolving the issue. There can be a delicate balance we develop and train our community to that can assist in the discovery and reporting of issues, but the protocol and trust in following through to resolution should never be up to crowdsourcing in my personal opinion.
When and if Operations is able to get to a 24/7 testing and triage response schedule we will actually unlock and support a truly decentralized workforce.
Currently Operations has to provide a very small window for deployment testing, limited to less than the current Denver 9-5. If the DAO ever has hopes of opening the development to a decentralized (international) workforce, providing a global testing and triage response schedule will be key to our process, development, velocity and regression ratio.
Instead of 8 full-time roles as shown, I’d suggest 3-4. Workstream Leader (who arguably is the ops coordinator, see point above), and then 2-3 Ops Assistants.
I disagree with this short-sighted devaluation of the Operations responsibilities and time available to provide what is asked of them. When the Operations team was a team of 4, I was working 60+ hours a week waking up to fight regressions and system breaking issues at 1-4am multiples times a week and continuing an 8-6+ regular schedule. Asking me to take on a huge excess of responsibilities plus my current role with a smaller team and no promotion (actually a demotion considering all the new developments around payment logistics) feels deeply inconsiderate and out of touch.
Test Funds @ $7,500/mo seems really expensive. The “cost” here must be gas fees, correct? Other than net loss on gas fees, test fund crypto shouldn’t be loss, but should be re-used. So if it’s just gas fees, and we assume avg of $20 per test transaction (which seems high as an avg), that’d be 375 test transactions per month, or ~12 test transactions every day of the month. Is this appropriate? If more accurate math estimates are available to justify the $7,500/mo, pls post.
During the Airdrop testing with small network congestion, our two assistants were each burning well over $200/day in gas fees on the Ethereum testing all wallets and features. When THOR swaps are a function we can test, the edge cases of assuring all trades are successful can exceed $150+ in a regression test that is performed at least 2x a day (full coverage would be more like 4-6x a day).
When the network has crazy fees, there is no ‘wait for it to calm down’ option for Operations or Engineering if we need to fix or test something. We’ve all paid heinous gas fees across all chains due to random events or market conditions and will need to make sure we have the ability to going forward. In Centralized Shapeshift, Operations has the keys to all test funds and could provide them like Oprah whenever requested. These requests easily exceed $7500/month and were solely used for feature/development testing. Going forward some workstreams have budgeted test funds, if they have not, they will need to coordinate with Operations for testing their features. Operations is preparing itself to be able to support all requests from all teams for feature testing regardless of the feature, time, or network status.
Is $7,500 a month a lot for test funds? Absolutely. Are there conditions in the past where ShapeShift has spent that much in testing? Absolutely.
Again, my statement about returning unused funds from the proposal rings true here: “Any unspent test funds or other budget items will either be returned to the DAO, or rolled over to the next month’s budgeted amount with the remainder being returned to the DAO at the end of the quarter.”
We should be clear that CoinCap and Portis support functions are not in the scope of the ShapeShift DAO’s responsibilities (though they were
- in scope in centralized ShapeShift).
Until they are officially not under the scope of Operations (and hopefully are successfully operating on their own), Operations will support issues, testing, resources, and triage of CoinCap, Portis and any other feature, service, or device in the ShapeShift ecosystem. When they are successfully Officially no longer in scope, they will not be a part of Operations oversight. This call should be made by all stakeholders of the feature/service in question and not the Operations Workstream. If these can be achieved before Nov. 1st, great, If Operations has to help support the DAO transition to a full DAO and it takes time, there will be no balls dropped in a transition period.
I’d like the Mission of this work stream better defined. As written, “The Operations workstream has and will continue to herd the cats of ShapeShift, now into open source and decentralization. This workstream is focused on helping increase the efficiency and productivity of the other workstreams’ success metrics, tests, velocity, and output.” This seems very different than the opening paragraph of the proposal, in which it states the Ops Workstream is for “producing and maintaining the ShapeShift product suite and its uptime, responsiveness and feature functionality.” This sentence seems much more appropriate for the mission. I’d suggest just duplicating it in the Mission section, as it will help the community understand what Ops is specifically doing.
We do both of those things, but I’ll look at better simplifying the coordination part without cat wrangling metaphors if it is confusing the responsibilities and selling them short.
In terms of Metrics, the proposal says “We hope to develop a strong set of KPIs after the first quarter of the workstream’s existence. “ This is not accountable enough. Needs to say “We will produce
- an appropriate set of KPIs after the first quarter of the workstream’s existence.” Minor change, perhaps, but important.
Valid and will be updated accordingly.