Example of use cases and need for such a position:

• the current week-long project of setting up an OnShape based Parametric Phoenix, and a print-in-place phoenix. --- these are small projects, this in particular fit in the on-the-fly approval category of CCC Discretionary Funds (under 1000$). The Tech Lead would propose such projects as bounties or per-person, approve them, check them, prepare them and so on.

• longer projects such as the older NIOP, which need oversight and testing, and getting multiple resources brought together, besides the engineers, such as people to test print and to wear-test the devices. --- these are projects that need a lot of oversight to make sure they go in the right direction, and a knowledgeable member of the community needs to be responsible for that, and be available for consulting on such topics.

Pay is what drives the responsibility here. As mentioned, in my case, with part-time/the monthly pay of the position and possibly pay for per-projects, it could be feasible for myself. The other option (for me) would be to have this set up so it doesn't take a lot of my time and can be run alongside a normal job.

TL;DR

There is a clear need for a tech lead to oversee e-NABLE's many technical undertakings. The position will demand enough time and energy to warrant financial compensation. There will likely be more instances where we'll want paid leaders in the future. 

There are numerous hard-to-answer questions about compensating leaders, how to hold them accountable, and how to resolve conflicts with them. We will need a lot of community engagement to answer these questions discover those we haven't asked yet.

Authoring a template for a fair contract between paid leaders and the community can overcome some of our community's unique challenges and enable us to do even greater things.

Why We Need a Paid Tech Lead

As I mentioned in the town hall, the decentralized and non-hierarchical nature of e-NABLE is one of our greatest strengths. However, there are downsides to this community structure, and one of those downsides is a lack of champions and decision-makers. We often have volunteers with valuable skills and experience who wish to contribute their talents. However, they are often unable to find an appropriate project to contribute to. Additionally, volunteers who need to make wide-reaching decisions often don't know how to proceed. Whenever a volunteer needs an assignment or must make an important decision, they need someone to turn to who understands e-NABLE's needs, processes, and goals. Lastly, if we wish to increase the number and scope of paid technical proposals, monitoring progress and providing direction and assistance to proposal authors will become increasingly important and demanding. I propose we address this need by creating a paid technical lead role that the community gives the authority to delegate and make technical decisions. Having a technical lead would increase the retention and utilization of both our volunteers and proposal authors and would enable us to pursue grander goals. Providing financial compensation for their efforts is necessary given the scope of the work involved, and will ensure we retain key community leaders.

Responsibilities of a Tech Lead

I believe the responsibilities of a technical lead should be as follows:

1. Provide direction to all technical volunteers who request a project to contribute to

2. Maintain a public list of which technical projects need volunteers and what specific skills or experience each project needs

3. Recognize opportunities to begin new projects when idle volunteers with the right skills are available, and bring recommendations for new projects to the community

4. Serve as the designated decision-maker for the technical direction of the community, and engage the broader community to make wide-reaching decisions when warranted

5. Take ownership of the technical proposal process and recommend changes to streamline proposal creation and accommodate the higher complexity and uncertainty of technical proposals

6. Produce a brief written assessment of all submitted technical proposals which assesses their fit with e-NABLE's needs and goals, and recommend that they be accepted, rejected, or amended

7. Assist both the community and technical proposal authors in appraising the price/value of technical proposals

8. Engage with authors of accepted technical proposals to monitor progress and status

9. Provide appropriate assistance or direction when technical proposal authors encounter blockers

10. Bring a brief written summary of both the status and weekly progress on all paid technical proposals to each town hall to increase visibility and accountability

11. Review all submitted deliverables for accepted technical proposals and ensure they are correct and complete

12. Maintain the e-NABLE device catalog

13. Serve as the point of contact for technical collaborations with other communities and organizations

Community Structure and Governance

The question of hierarchy and accountability is a bit tricky, given our very decentralized community structure. We will need to make changes and tough decisions relating to leaders. Creating a clear org chart with a(n) executive decision-maker(s) would be the simplest solution. However, I believe this approach would betray the culture of the community. Instead, paid leaders should be beholden to the community. Without an executive decision-maker, we must have a specific and concrete plan for implementing changes and addressing concerns relating to our paid leaders. I can identify three clear categories of decisions relating to leaders: changing the scope of their responsibilities, adjusting financial compensation, and redressing grievances.

Changes to Scope of Responsibilities

If the responsibilities of a paid leader are to be changed, the community must approve of said changes. The responsibilities of any paid leader must be concrete to ensure the community's vote on accepting a given compensation for said responsibilities is respected. However, requiring a community vote to make minor changes would be unnecessary. I propose that modifications to responsibilities that change the time and energy required by a lead by more than 20% require a community vote. Anything less than that should only require a supermajority vote at a town hall. 

How much time and energy a responsibility entails is admittedly subjective, and 20% is an arbitrary figure. Suggestions are welcome.

Changes to Compensation

As the time and energy required to fulfill the responsibilities of a paid leader change, adjustments to compensation in both directions will be warranted. I propose that changing annualized compensation by more than $1000 from the figure last approved by a community vote requires another community vote. Smaller changes should only require a supermajority vote at a town hall.

Both paid leaders and community members should always have the right to propose changes to compensation. Those changes should be based on the time and energy required by leaders and the skills and experience required to fulfill those responsibilities. Implementing periodic reviews of the responsibilities, efficacy, and compensation of leaders would likely be useful to foster transparency and trust. I'd love to hear what others think about this.

Redressing Grievances

I don't have any good ideas or strong feelings about addressing problems like interpersonal conflicts or a leader's failure to fulfill their responsibilities. This will likely be the most difficult part of the contract between leaders and the community to iron out.