Values

ProgCode values, above all else, the idea of

  • Ownership
  • Autonomy
  • Collaboration
  • Non-hierarchy
  • Decentralization
  • Push and Be Pulled
  • Personal relationships
  • Transparency

Furthermore, we encourage the idea of pushing and pushing changes/efforts, but at the same time have the humility of being pulled back. The staff should have no ego as much as possible, and we encourage being candid and honest to one another. These, of course, should be grounded on the personal relationships we have built with each other. Finally, transparency is such an integral part of the way things are done that it is always in the core of everything we do.


Ownership

We fully respect and try to cultivate as much as possible the idea of ownership of individual member, may it be on the code they make or any initiative they decide to take. We respect ownership down to the basic level of ideation, where the idea is brought about into the community and we respect the ideator’s ownership of it, thus we will never set a culture of bringing down other’s ideas. Instead, we see ideas as seed or the most basic level of a member putting a stake into the ProgCode community, and that is something that has to be cultivated and allowed to grow.

On the other end of the spectrum, ProgCode should not and will not have any ownership beyond the goal that it is intended to do. If we go beyond the need to provide a framework of support to the applications within the network, we will then create a reason for us not to become obsolete, which is against the core objective of ProgCode.

As an entity, ProgCode cannot and will not own anything outside the intended purpose of becoming a framework of support. However, staffers should still be able to own projects but it will not and should not be under the ProgCode identity.

Autonomy

In the same vein, ProgCode does not and will not interfere with the decisions within applications. The decisions on legal structure, direction, movement, and next steps, is all decided on the part of the app creators, and will not have any unsolicited input from ProgCode. ProgCode comes in a place of service, not dominance.

The services we provide include support frameworks partners can adopt any parts of which they choose, which will make it easier for them to get started. This would include things like templates, planning documents, operating structure, etc.

Collaboration

This is where the idea of conduits comes in. As staffers, we are the facilitators of collaboration within and also between projects.

Members to Projects

This means that we will constantly find ways for individual members to collaborate with app leaders, by constantly engaging them into conversation and find ways for them to be a happy contributing member of the tech community. We want to have an open conversation and outreach to volunteers, and become a positive force that wants to offer opportunities for them to become fulfilled members who are making a huge impact for the progressive movement – through their skills and talent.

Projects to other projects

It is already a given fact that there are projects that have complementary – sometimes identical – goals and ways to go about problems. ProgCode is not and will not be in the business of forcing any of these projects to merge as it totally violates our view point on autonomy, but rather become an open communication channel and a conduit for opportunities for these projects to collaborate.

Projects and the network outside

The projects within the community serves a bigger purpose, and that is to affect, serve, and make an impact to the world outside. Staffers – through their connections – will find ways to build connections between the projects and civic society.

Non-Hierarchy

Non-hierarchy recognizes that the network is flat, and that the leadership or perceived leadership is set on how connected you are within the network and the quality of service you have provided to those connected to you. The goal of which is to maximize social capital. The idea of non-hierarchy pre-supposes that the “leader” entity is not awarded or bestowed upon a person but rather earned based on your service to one another and standing within the community. As Prog Code, staff people will inherently look at us as leaders who have contributed to help build this community, so it's crucial to adhere these values

That is why the idea of “the board” is a construct for legal purposes only and should be treated as such. The drivers of change are indeed the applications and app creators themselves, so as staffer it is our best interest to provide the connections and the communications necessary for these projects to become a success within their team, and to the general public.

“Power” is posed not as an entity that is entitled to anyone – despite being a staff member (see Ego Check) – and is not the currency we want to cultivate. Influence for the good of the community, good will, and personal relationship, are the entities we try to cultivate in the community – a non-hierarchical ecosystem allows for that to happen.

Decentralization

This may be mis-construed as the same as non-hierarchy but that is not the case here. The idea of decentralization is the delegation of the “centers” of the network across multiple hubs. The structure of the network is a community that has the gravities around applications, and app creators driving their own works within their projects.

Given that the network hubs are the applications, and that members are funneled into the ProgCode ecosystem initially, our best interest is to bring the conversation and action onto the hubs around ProgCode, constantly trying to make the “mass” of ProgCode as small as possible by sending volunteers to the projects, bringing development and activity into those projects.

This highlights the need for ProgCode as an entity to not own any projects other than anything that facilitates the lessening of the ProgCode “mass” and driving energies into different projects. Owning projects dilutes the goal and message of ProgCode.

Push and be Pulled

As encouraged in our pilot program, we want to encourage self-determination and a self-starter attitude in the network. Contrary to a top-down approach, we encourage people to not wait for any permissions and give themselves the permission to do things they want to do. This is rooted in the idea and belief that people within the network wants what is best to serve and add value to the community, so the trust everyone gives out to everyone will hopefully affect the decisions of the individuals within the network.

However, it is also a network of humility and a lack of ego, wherein we should be able to pull back folks on the things they do, without ruining their spirit. All staffers are encouraged to pull back when needed, and are also encouraged to push forward any time.

For example, the social media account is shared by multiple people, and we are all encouraged to push items during the weekend to our own devices, however the network folks will also be able to pull back any posts made under the @prog_code

Personal Relationships

The network will not be a network if there are no personal relationships gluing everything together. ProgCode emphasizes the need for us to make connections between us and the people we serve, and it will not happen through just providing technological tools to members and staff. We value constant conversation, talking about the issues, making relationships and friendships within the network and outside of it. Only then with these myriads of connections, intertwining around each other, will we have a sustainable network.

Transparency

Transparency is a tool to empower members to really do something for the community. We see transparency as a way to provide access to different parts of the house and allow people to “get their feet wet” and know for themselves how to contribute. We always say that people will contribute however they want to contribute, and they will engage however they want to engage. Being transparent opens up that dialog of engaging and contribution in ways that are truly beautiful.

On the other hand, we recognize the need to have private conversations for private information, and we also use privilege information as a way to empower leaders. We understand that there are information that should not be shared in public, like personal information, trade secrets, and future plans. As such, we are adamant in reinforcing privacy and security if necessary.

Accountability

We rely on accountability to the network, as the network is visible to all, everything you do, anything you process and commit to is seen by the network. This is one of the forces we leverage to provide space of self-regulation and freedom all across the board.

results matching ""

    No results matching ""