---
# System prepended metadata

title: Untitled

---

## Draft response to ElProgreso:

#### Original Message:
> Not sure if I understand this proposal idea correctly (sorry about that) and the utility of Hats. Can you please walk us through how this improves organizational development, performance management, and contributor skills (developing talent). If at all. Or, is it more of an incentive based protocol that inspires contributors to get a higher Hat ID based on DAO deliverables?

#### Draft response:
In brief, the purpose of this proposal is to introduce a DAO-controlled role and permissioning structure into Maker operations, with the benefit of introducing greater Core Unit accountability to MKR holders and enabling clear designation of operational responsibility.

In particular, I see Hats helping to improve organizational development by:
- increasing role clarity and visibility; both for core units (and/or subDAOs) and individuals
- creating more flexibility in roles and permissions management within our operations
- reducing governance overhead by automating some of the above via on-chain logic, such as automatic role expiry or conditional revocation of roles/permissions
- helping Maker benefit from the productivity of individual responsibility without the risk of entrenched power

With respect to performance management, I'm imagining a future state where Core Units' responsibilities and permissions are tied to clear KPIs for Core Units, and/or where eligibility for certain roles is tied to reputation within the Maker community.

To get to this future state, it's my belief that we should start simple and then let additional structure emerge based on the needs of core unit facilitators. The structure of hats as a tree is a really nice property here since any Core Unit or facilitator with a hat can create additional hats below it to further delegate responsibilities, allowing a the governance structure to emerge organically as needed, rather than GovAlpha pre-designing it from the top-down.
