August 14, 2018

Open Leadership at PegaSys

All over the news, employees at tech companies (Microsoft, Google) are increasingly pushing to have a say in business and strategic decisions. The Trump administration’s immigration policies, for example, have proven especially controversial, and many engineers have gone so far as to protest or issue petitions over whether to sell AI to ICE and provide cloud services to the Pentagon that could be used for drone strikes. A number of factors, such as the scarcity of engineering talent  and the growing share of tech in MBA hires, suggests that the days of the pointy-haired boss and empty suit issuing orders to the techies are coming to a close.

At PegaSys we actively seek to create a culture of participatory leadership from employees throughout the organization. We believe that to foster a strong engineering culture, everyone needs to have a say, in both creating technology and how we serve our customers. Looking at all these factors, we chose a “management” structure that focuses on infusing a strong open-source culture, participatory and fluid governance, and accountability at all levels. Conway’s Law notes that software is destined to reflect the organization that created it, and hence we aim to shape our organization based on the vision for our software, rather than vice-versa.

Our first priority is to cultivate open-source communities, like the kind that have made Ethereum successful from its beginning. We chose collaboration models to reflect both the culture and approach of open-source, so we can work seamlessly with the community as if the boundary was not there. Our internal governance at PegaSys drew on significant inspiration from the best open-source projects and foundations, including Apache, Eclipse, and Linux. Some of these concepts include how we create and resource projects, the architecture and product councils that provide guidance, and overall project management.

We are also creating software for decentralized networks, so using a classic command-and-control hierarchy would seem counterintuitive. Our model aims to be participatory, open to including members from all of our scrum teams in strategic and technical decisions. Our working agreements emphasize collaborative decision making and the usage of rough (rather than universal) consensus, through various steering committees and working groups that are designed to be diverse.

Lastly, we emphasize a fluid model of governance, with committees and decision-making bodies changing over time. At many tech companies, engineers must choose between working closely with technology or going the “management” route. Engineers don’t have to make that difficult choice with our model. Management seems appealing (have a voice! customer face time! better pay [maybe]!) but can be less exciting, and your technological skills might atrophy when you are not working as directly with the products.

By giving technologists space to participate in working groups and decision processes, they can continue to do what they do best while still making meaningful contributions to the overall direction of the company.

Those voices are valuable to us. Our choice of a fluid management process with working groups and steering committees is intentional, so participation in any of these does not have to be a permanent decision – a teammate can join a working group for a few months related to something they are interested in (for example, feedback systems), and then leave when its tasks are completed to focus full-time again on working as a developer.

Overall, we feel our structure gives us rich communication from diverse perspectives. That can be create new challenges, as it’s less easy to move with the groupthink you might find in a typical corporate culture. But we think that helps us be a better company.

Given the emphasis on participation and different potential pulls on people’s time, there’s one more important area: accountability. We don’t want people to get bogged down from talking about strategy and governance, so we have strong guidelines to outline expectations for teams and what needs to be done. We’ll be covering this in a future post!