Our People from Across the Seas: MJ Kaplan

MJ Kaplan is a Loomio Channel Partner based in Providence, RI. She became involved with the co-op in mid-2013 while on a research fellowship in NZ. We chat with MJ about her background and why she became involved in Loomio.

mj_headshot

Why did you get involved with Loomio?

I was researching social enterprise as the Ian Axford Fellow through Fulbright New Zealand. I met members of the Loomio team at Enspiral and was immediately captivated by the motivation for the platform – to engage people affected by decisions in making decisions.  I started work 30 years ago as a community organizer and this principle of participation to create better decisions has always been at the center of my work.  Loomio makes that possibility easier and faster in the digital environment.  I  was super impressed by the team so I was thrilled to transition from research to engagement.  The team is smart, committed and deeply grounded in values and integrity.  I’m honored to work with them.

Can you tell us a bit more about the Boston Facilitator’s Roundtable?

This is a network of facilitators who work in business and community space in the greater Boston area.  We collaborate, support each other by resource sharing and we have a monthly workshop series.  Loomio is pleased to have had the opportunity to lead a workshop late last year to introduce participants to online facilitation and opportunities to expand their tool box of skills as better meet customer needs whether they are internal teams or diverse community efforts.

What do you do day-to-day? Maybe you could tell us a bit about what it means to be a channel partner, and what your experiences of this are…

I returned to the US in the fall after 8 months abroad.  As I reconnect with my community, locally and nationally, I’m introducing them to Loomio and exploring needs that might be met through the use of Loomio. I’m finding such a variation in the users that are excited about Loomio – universities, businesses, networks and, of course, activists. When some of the team came to the US in December, I joined them to meet with thought leaders in Washington, New York and Boston.  Everyone we met with was impressed and think that Loomio has the potential to be a game-changer to make collaborative decision-making easier and better. I think most people want to work through differences to make better decisions and they just struggle with clumsy tools and competition for time and space.  More than anything else, Loomio makes this important work easier.

What inspires you about working in Loomio’s community?

The team’s commitment to learn and grow is very inspiring.  From the earliest stage, they engaged with customers to refine the platform based on users’ needs.  I’m also impressed by their determination and discipline.

Where do you see yourself and Loomio in five years time?

My hope is that Loomio is a household word and tool like email and Facebook.  The more time I spend learning about Loomio the more applications I see for people to get the right group together, quickly flush out their views and quickly move to action.  I think Loomio can help families, businesses and whole communities be more productive and happier in their shared action.

I think most people want to work through differences to make better decisions and they just struggle with clumsy tools and competition for time and space.  More than anything else, Loomio makes this important work easier.

Open Sourcing Feminism: The Challenge of Collective Intelligence in 2014

VivCropped

Vivien Maidaborn

It is a shock to join a new industry, one forging open thinking, open models of exchange, and open source only to discover how closed it is to women.

This post began on a journey with my colleague Ben through Europe and the US in late 2013, talking with other people in the civic-tech and open source world. Our conversations were focused on citizenship, direct democracy, diversity and open technology. In about week three I wrote the following in my journal:

Journal Entry, Berlin Dec 2013

“What has been shocking is how few women have been part of this journey, how much men have dominated the space, across countries and cultures. My senses feel assaulted with this assertion of masculine presence in so many ways.

The men who hear me ask a question but address their responses to Ben; the woman-hating art on the office walls of men with whom we thought we shared a vision for the future.

The men who interrupt women’s conversation to assert their knowledge and expertise closing down the sharing already in play; the taking of physical space in buses and trains. In Strasbourg, even the youth delegation in our session, as wonderful as they were, were all men. I wonder if hearing and listening to the issues of youth is just one more priority that is more important than addressing the inequality of women, and the silencing of women’s voices?”

Since coming home to NZ I have been paying attention more to what is happening for women in open source communities and in the wider technology world.

Women are silenced in many different ways in life; in the open source and tech world this intensifies because of repeatability, and ease of broadcast. For feminists arriving into open source networks the marginalisation is intensified because of the shock at the actual experience compared to the expectation.

Gina Trapani suggests a conscious desire to exclude women within many OSS communities, a theory which is supported by comments on the recent gendered pronoun debate on Github. Both of these articles emphasise that fact that sexism in the open source community is consciously upheld and also strongly contested. It seems that the forces resisting change are still greater than the forces encouraging and facilitating it.

Who is in the room

The numbers of women in the tech industry, and particularly women engineers and coders tell us this is not an equal opportunity world. Google.org says they invest in increasing the diversity amongst people training in computer science, particularly women and under-served minorities because right now in the U.S. only 15% of computer science graduates are women.

How are we treated

If you want to know how deeply some people object to strong powerful women’s voices, the stream of online misogyny is the most obvious, widely broadcast and visible example. The message though is no different from what women experience in many situations. I am reminded how men yell at lesbians in the street, and vilify women who publically oppose male violence. The new thing here is the medium and the ease that misogynist messages are amplified.

The pathetic sameness of the message over the 40 years I have been listening to it, the shallowness and complete lack of intelligence does not detract from its success in controlling what women feel able to do, which groups to join or frontiers to cross.

There are well known situations where women have been attacked online, with the intent of silencing them. Feminist Frequency author Anita Sarkeesian found herself the target of threats and abuse after suggesting that society take a look at the over-sexualised potrayal of women in video games. Australian journalist Asher Wolf founded Cryptoparty and then left it on the basis of continuing misogyny and hatred towards women within and outside the party.

Thankfully, amid the blasts of hate mail and trolling of feminists’ Twitter accounts, a movement of resistance to the oppression is also growing. While projects like Everyday Sexism are bringing to light examples of sexism in the advertising, workplaces and the corporate world, there are growing numbers of women opening up the conversation about sexism in the open source world and the internet. Take a look at  Geek Feminism and Tech LadyMafia who are creating an international network of women becoming guardians of the space.

The UK Guardian article on the ‘4th Wave of Feminism’ highlights some of women who have spoken out:

“A chorus rose against online misogyny. Criado-Perez highlighted the string of rape threats sent to her on Twitter, writer Lindy West published the comments she received, (“There is a group of rapists with over 9,000 penises coming for this fat bitch,” read one), and the academic and broadcaster Mary Beard, Lauren Mayberry from the band Chvrches, and Ruby Tandoh from The Great British Bake Off, all spoke out on this issue.”

What do we value?

Journal Entry, New York Dec. 2013

“It is so easy living in my own lesbian friendly woman-loving context to forget how quickly you become invisible and how diminishing it feels to be not seen or heard when you are right there in the room; to see my voice falling like empty air on ears not listening, and to experience the privileging of men’s voices even when in themselves they reject that privilege. Perhaps most shocking is that even when asked to stop, some of these passionate and values-aligned men cannot hear anything except their own voice, spewing their own brand of self importance in an endless gush of loud advice and domineering confidence.”

The privileging of male voices in the room is a more subtle way of silencing women in the open source community. In my observation, this happens in three ways:

  • Women are socialized to listen carefully to men – our safety depends on it and we do it very well. Men are listening to women much less carefully and often not at all.
  • Men tend to be in the roles and occupations that have either structural authority or are seen as the more important roles.
  • Finally, power attracts. So when people see who has the power in the group, attention flows that way.

We tend to value roles that are dominated by men, and in the open source community that is the engineers and coders. It is clear we need more women in these groups, but we also need to value the roles that sit alongside the coders. Many of us aspire to inclusion and collaboration across diversity, but how many of us actually do the core muscle work? A good litmus test for open source organisations and teams to understand who you privilege in your team, is to play with these gender bias games. Understanding whose voice gets listened to in your group is a great start.

Entertaining difference?

One argument is that women and men enjoy different social and work contexts; that there are good reasons why we might choose different roles and jobs, and even good reasons to work separately. While there may be some seed of merit to this argument, many who hold this view ignore the contextual factors of the abuse, bullying and lower pay women experience compared to men.

Building a New Narrative

The narratives we tell around open source itself, are part of the reason people are not considering the gender politics of the community.

The prevailing pattern in human rights movements is to give importance to the issue itself – peace, indigenous rights, nuclear freedom, mining etc. This becomes the narrow focus, and the connections between issues, oppressions and contextual factors are lost. As early as 1960 this was being written about in the context of the peace movement, and many of the issues raised in this  Feminist Magazine Solidarity article remain totally relevant today.

It is noticeable in the web, that most articles about open source focus on the technical issues; the new code or tool, the pattern of use and the growth data. Wikipedia defines open source without any reference to the inclusive ideals within which it is grounded. And PC World is equally uninterested in anything except the growth and impact for business. This reflects the male interest and bias in the narrative around open source software.

Even more lacking is the narrative about the collaboration required to build good open source software, and how to do that well with greater input from diverse voices. We are missing so many of the discussions on how the interactions with online community informs technology. This issue is addressed in the work Nancy White et al did for their book Digital Habits. In this narrative, the technology serves community – it is clear that community is the purpose. Which raises the question of what is being served by marginalising women in a community interested in collaboration and collective intelligence?

Finding Collective Intelligence

Sexism exists in many (probably most) work environments, so why is it so critical to stamp out in the open source community? It matters here like nowhere else because open source is about collective intelligence; it presents an alternative to individualistic models of the economy and cultural life. Collective intelligence is an oxymoron if in the process it excludes half of the population.

There are fantastic reasons to use and develop open source software. It addresses the fundamental issue of the right information and connectivity, involves collaboration and delivers better software. The goals of feminism and the open source movement have much in common, and the community could learn a lot by embracing feminist values.

Access and Diversity – Open source software, tools and resources are being built for a diverse world, where 50% of users will be women.

Openness – Women’s rights are human rights and the internet is a vital space for women’s organising and participation across the globe. This aligns so closely with the intent and purpose of the open source community. We can build on each other’s strengths to achieve greater social justice.

Security – Privacy and security in the net is being constantly improved, but often fails to consider the security issues for women. We need to use our particular skills, knowledge and experience to create safe internet spaces for women.

The Challenge

The challenge of today is to make room for the complexity of new power relationships in our diverse societies. We need to recognise and respect both our differences and our similarities, as we will inevitably merge, separate, combine and retreat in the work of solving the systemic, interconnected, wicked problems of our time.

Women are an integral part of this work. We are deeply and profoundly affected by exclusion and marginalisation today as much as ever. The interface between the personal and political has long been a narrative that women bring to systemic change.

The collective intelligence central to collaboration and inclusive decision-making needs all of us. I once defined myself as lesbian separatist so I could grow an identity separate from general society. These days I recognise that overcoming separatist thinking is a key part of the solution.

Journal Entry, San Fransisco Dec 2013

“Half way through our trip I am woken up to the danger of dropping women’s priorities, women’s voice and women’s work from consciousness. In this young and technological world I am working in, I feel like there is a subtle fight going on all the time for us to respect the powerful and important differences in the perspectives that women bring. Every day I see the tweets from the UN Gender programme reminding me about the work of many many women in the world. The daily work often defined by water, food, children, health of communities and the fight for safety, education and safe reproductive technology. Through the Women’s Refuge work in NZ, we can see that it is still a deep cultural reflex to control women through violence and intimidation. I am reminded about the fight for life women face in a world where fundamentalist religion and patriarchy are growing – those twin deadly power-over paradigms that assume men are more vital and important than women. Women’s voice, presence, involvement is not some nice to have, something to fight for after we have resolved poverty, or changed the way democracy works. Women are integral to the success of the open source movement.”

Vivien Maidaborn is a founding member of Loomio, and has a depth of experience in organisational systems, decision-making processes and social change acumen. She has been CEO of CCS Disability Action and Relationships Aotearoa in New Zealand, and is the founder of the social enterprise Lifemark.

Vivien is one of two female founders of Loomio, alongside Alanna Krause who is interested in innovation, technology and structures for positive social impact, as well as being a director of the Enspiral Foundation

Pattern Recognition for Management

simon

Simon Tegg 

Middle managers have it pretty rough. Pop culture knows them as Dilbert’s pointy-haired boss or the insufferable David Brent from The Office, but their job is essentially to solve unsolvable problems.

Before Loomio I was occasionally thrust into positions of managerial authority over my fellow slackers. A queasy feeling would come over me when I realised that I would constantly have to infringe subordinate’s autonomy by trading off with business objectives. I would quickly downshift back to my previous minion role. In Venkat Rao’s terms I was a Loser -that is, someone who loses the economic status game by making the strategic, rational decision to reduce stress levels and slack off rather than ‘climb the ladder’.

Since I started at Loomio things are much more complex. Everyone is the Boss. It just depends on their domain-specific experience and track-record, for how much of the Boss they are at any given time. Again I’ve found my self with some authority, or at least strong opinions on how particular things should be done, but with a personal investment in Loomio’s success I can’t shy away from messy problems. I’ve also had my fair share of management failures and learnings from my year in a fluid, startup, co-op, social enterprise.

To help think about the problem of management I appropriated the Competing Values Framework and remixed it, with inspiration and heavy borrowing from Fred Kofman’s and Venkat Rao’s recent posts about the impossibility of management. The result was the following 2×2, which I’ve found useful for deciding which management pattern to apply to particular work contexts.

Before we dive into the patterns, to navigate the 2×2 you need a grasp of three key variables of work and business: motivation, uncertainty, and coupling.

Motivation

Management is still coming out of the shadow of Taylorism. For the Taylorist, productivity is a simple matter of providing the right incentives for performing tasks in the most efficient manner. Incentives can be either positive, e.g a bonus, or negative, e.g. a reprimand or the threat of being fired.

Kofman splits incentives into individual-level outcomes or team-based outcomes. When managers incentivise individual-level outcomes (track individual sales targets, lines of code written etc), it’s easy to spot the shirkers and low-performers and coach them or move them on, while at the same time attracting top performers by awarding bonuses. Unfortunately, collaboration and overall performance suffer as individuals focus on their own targets at the expense of helping others.

With team-based performance management, the team can easily share tasks and risks more efficiently by buffering each other. The downside is that individual staff have the incentive to skive off without being noticed by the boss, and arguably star individual performers aren’t attracted to a work environment where the team will take the credit. Kofman has a talk about this tradeoff here:

This is a useful insight, but if you’ve been paying any attention at all, you’ll know that there’s much more to motivation than rewards and punishments.

Dan Pink has popularised intrinsic motivation with his book Drive. In Pink’s model (get this), we can perform tasks for their innate joy, and are happier and produce higher quality work when three conditions are satisfied:

  • Autonomy – the task performer is free to choose the task.

  • Mastery – the task is neither too hard nor too easy.

  • Purpose/Relatedness – the task connects its performer to some greater mission and provides a supportive social environment.

Most workplaces are hierarchies where the boss chooses what you’ll be working on, you rise to your level of incompetence (the Peter Principle), and you’re striving to make the shareholders richer, so satisfying all three conditions is pretty rare.

To be fair though there’s more of a continuum between extrinsic and intrinsic in the underlying research. Its possible to leverage quasi-intrinsic motivation by indoctrinating your employees with a feel-good corporate mission, team-building exercises, and granting degrees of autonomy etc. But even clever tech companies like Google struggle to match tasks to the appropriate skill level.

Uncertainty

The second variable is the degree and quality of uncertainty that a venture currently accepts. According to Rao there are three uncertainties relevant here:

  • When – are you trying to minimise time uncertainty (i.e. a hard deadline),

  • Who – role uncertainty (who will be doing what),

  • What – output uncertainty (you need a very specific thing)

In a mass-production factory it’s possible to reduce all three uncertainties to levels where next year’s production forecasts are meaningful. Management can be a colour-by-numbers activity.

But for a startup or creative service venture, like the ‘Fast, Good and Cheap’ adage it’s impossible to have all three simultaneously. Accordingly, Rao defines talent management as: “dynamically managing the returns on human resource investments by exploiting the coupled uncertainties involved in who, what and when decisions.”

In creative industries talent management becomes an artform. The skilled manager must make constant tradeoffs among business uncertainties and between these uncertainties and workers’ motivation and wellbeing.

Coupling

The third variable, coupling, is a constraint. Different types of work tend to require different degrees of coupling between workers, and workers will generally have their own preferences.

Software development often requires highly coupled ‘pair programming’, code reviews, and QA to ensure large projects are maintainable long-term, while a sales rep can operate independently of the mothership for long periods.

Simply put, highly coupled (functional) teams will help satisfy social needs but often reduce autonomy, while loosely coupled work can operate with minimal managerial overhead and satisfy autonomy, possibly trading off with social needs.

The Patterns

Management patterns for worker run businesses

To make our 2×2 we’ll split off the two factors that we have the least control over, coupling and outcome uncertainty and see how the other parts of the puzzle intersect.

Coordinate: Explicit Outcomes + Tight Coupling

The coordinate pattern should be familiar – it’s textbook project management. You require explicit outputs, and to achieve these you have a team of specialists, each working on sub-projects with dependencies.

For our team here at Loomio, this pattern crops up whenever we interface with a government bureaucracy. Bureaucracies are notorious for requiring explicit outcomes (“can we get this stack of forms filled out in triplicate, please”), often due to well-intentioned regulations to ensure accountability. These tend to need specialist knowledge like legal, accounting etc, and different parts of these projects will have to be arranged in series, rather than in parallel (“Once legal have signed off, we can review, then send it off to accounts payable”).

You’ll probably need someone with an overview of the entire process (the project manager) to keep things ticking along, who, in a traditional company, will perform this role on an ongoing basis. In Loomio flatland, these roles are temporary (I like to think of this as “temporary hierarchical zones” in a sea of collaboration).

Inevitably, there will be time and cost overruns. Individual specialists and high dependencies means the system is fragile to any slip. Due to serial dependencies, a slip in one specialist’s workflow ripples through the project as lengthening delays as everyone falls out of sync.

Hierarchies use the coordinate pattern by default. ‘Who’, and ‘What’ uncertainty are minimised at the expense of ‘When’ uncertainty blowing out. While the coordinate pattern is often necessary, getting stuck in it tends to burn out workers. The work tends to be routine, high pressure, low autonomy, and extrinsically motivated by the threat of missed targets (which typically happens).

Collaborate: Flexible outcomes + Tight Coupling

Moving across to the collaborate pattern, we now have a tightly coupled cross-functional team working towards flexible outputs. Devs know this as Agile Software Development. Here the desired outcomes are penciled in and the team is free to implement as it sees fit, using some highly structured processes, within which the details are emergent.

For teams that adopt sprints and report some measure of value, the ‘When’ uncertainty is reduced, at the expense of ‘Who’ uncertainty, while ‘What’ uncertainty slips as the implementation details emerge on the fly. We know that at least some value will be delivered on a continuous basis, but with all that collaboration there are no legible metrics on who did what, reducing opportunities for managerial control.

The lean startup crowd love continuous value delivery. When the product evolves rapidly the likelihood of finding market fit goes up. Further, working in a tight, collaborative team, with a degree of autonomy is going to strike a decent balance between social needs, task-skill match and autonomy.

Compete: Explicit outcomes + Loose Coupling

The compete pattern usually applies to the work of the sales and marketing teams. They get some explicit outcomes alright: “make it rain”. But this doesn’t need to be tightly coupled with everyone else. Sales seems to be one area where the commissions and performance bonuses may work, and seems to suit the goal-focused type (what Dan Pink calls Type-X).

Personally, I can only go about 2-3 weeks on 100% Compete mode before burning out. Whereas I can probably sustain a 70/30 Compete/Create split for 2-3 months.

Create: Flexible Outcomes + Loose Coupling

Finally, we have loose coupling and flexible outcomes. For a traditional organisation the create pattern carries far too much risk. You just let workers just go off and create stuff? On company dime? ‘What’ and ‘When’ uncertainty shoot up, you only know ‘Who’ is not available to do all that other urgent work.

Yet only the create pattern offers optimal conditions for the innovation that your organisation desperately craves. You’ve got autonomy, the worker can self-select an optimally challenging task, management just has to supply some social support and a higher purpose worth achieving.

Companies like Atlassian, Google, and 3M have leveraged the create pattern with their famous 20% time. Though it seems in Google’s case this often more to do with talented bullheaded employees than official policy. Apparently, Gmail, Adsense, Autocomplete and Google News originally started in 20% time, so that worked out okay.

The balanced portfolio of management patterns

Try thinking of these patterns as a balanced portfolio. For us, Collaborate provides baseload returns through continuous value delivery and reasonable levels of worker happiness. Coordinate and Compete are tactical moves that depend on the terrain, and Create is high-risk play with high potential returns.

For example, Jon shifted from his responsibilities as coordinator of the development team and went into create mode. We got a major boost in Jon happiness, a comprehensive set of mobile mockups, an entire new UI for Loomio 1.0.

At the personal level, you may want to consciously adopt a split and consider a deloading phase. I’m using weightlifting terms here, but the same concept applies to mental and emotional work. Weightlifters recognise how spending too much time in the same pattern can lead to burnout or stagnation. My personal preference is a 40/60 create/collaborate split. I’ll shift into this split after heavy episodes of coordinate and compete to rejuvenate.

I’ve found that many organisational problems (whether that’s a project failure or unhappy workers) stem from choosing the wrong pattern for a given scenario. A critical ingredient to this is knowing your position on the map and knowing when it’s time to move. The pattern needs to be chosen intentionally, rather than by default, and reconsidered frequently.

Thanks to Richard Bartlett, Alanna Krause, and Matthew Bartlett for their thoughts, editing and graphic design help. 

Vivien’s Travel Update

IMG_0607

Thoughts en route:

I am considering what it is I want from a trip as extensive and full as this one.

Madrid, London, Berlin, Amsterdam, Strasbourg, New York, Rhode Island, Washington, Boston and San Francisco.

Information will flow I am sure,  information on what others are doing, what steps and processes they are using, how they raise money. Meeting people and introducing Loomio will happen too.

Are these things enough of a reason for such a huge journey? I find myself thinking about opening to possibility, possibility of deepening relationships, possibility for opening opportunity, possibility for the unexpected to arrive on this journey.

I would love to meet people who have created successful scalable online social enterprise, who have thought through business models and identified ethical approaches to funding .

So much potential in NZ is limited by the piecemeal social enterprise sector , the lack of government action, policy or even interest in investing in this powerful new form of economic development. In NZ we have enthusiasm and ideas, start ups and enterprises but we don’t  have the conditions to thrive, not policy, not funders, not an engaged investment sector, nor a risk taking philanthropic sector.

So Loomio needs to play in an international space where some of these elements are already in place, where there is commitment and conviction about the role of social enterprise in finding new approaches, and technology to  create new outcomes in our world.

Where people are engaged right now in re-visioning , renewing and co creating what business, wealth, and economics mean for us as a world and global community for today a tomorrow.

This is the possibility that excites me the most, the idea of being part of an international community who knows our name and who sees the power of collaborative decision making.

Letting in the possibility of Loomio itself is perhaps the internal journey that this world trip provides space for.

A world where anyone can participate in the decisions that affect them. Truly what would this take?

A belief that many people thinking together will make better decisions than an individual will.

A commitment to a powerful sense of self worth in every person on earth, that their view is important, their Experience valid and their voice critical, especially in those decisions that most directly affect them. .

A strong movement of people bringing momentum and energy to  new ideas of citizenship  and what participating as a citizen could look like in this technological age.

I am struck by the idea that Loomio is already part of this story; the trip an opportunity to ensure we do our part well,  that we see clearly enough and dream big enough to connect all the pieces of this movement.

Creating from possibility opportunity.

Creating from opportunity  dreams.

Creating from dreams our dreams made manifest.

***********************************************************************************************

If Only Everyone Would Act Like They Owned the Business

A key principle for Loomio has been growing and developing in ways that live the change we want to see in the world.

Loomio has been around for 18 months,  and we have smoothly survived those first tricky 3, 6, and 12 month danger zones for any start up. I can feel inside myself a growing sense of confidence that we can actually succeed at inventing a horizontal collaborative organisation whilst simultaneously launching and growing a sustainable SAAS.

The women’s movement and collectivism has had a strong influence on my life, the ways I think about power and powerfulness in particular, but so has 20 years of traditional management theory and practice.

In this context I felt if any part of Loomio was important philosophically but perhaps beyond us practically, it was the goal of distributed management and decision making. After all, would it be timely, and efficient? How would we manage the inevitable interpersonal tensions and of course the risk of underperformance and good employment practice.

The cynics among you will say it is still early days, there are only 15 of you, wait till you scale, and you may be right. But I am feeling increasingly amazed by what we have achieved so far. Celebrating success creates more success, and most start-ups fail because relationships fail. Both these things make it really important to celebrate what Loomio has achieved so far in creating our version of a democratic and engaged horizontal organisation.

  • The legal structure is serving us well. Loomio is a Workers Cooperative, apparently the only one in NZ at this time. Every person employed by Loomio will be on a pathway to becoming a Loomio shareholding member.

  • I cant tell you the number of times I have been involved in conversations with other senior managers about staffing challenges and wished aloud that people would ‘act like they owned the business’. The amazing thing is that until now I have never really understood that this is a serious strategy; that staff sharing the ownership of upsides and risks in business is a real possibility for everyone! This idea seems to challenge strongly held ideas about a managerial class, and judgements about the unequal value of contribution.

  • The experience of Loomio through two intakes of contributors (employees) into members (shareholders) is that people are excited and honoured to be invited and immediately step up into a new more self-initiating way of being in the organisation and on behalf of the work we do together.

  • At Loomio we have identified performance as a team concern measured and reflected on weekly or fortnightly in the product and design scrums and the business development processes.

  • Every member and contributor at Loomio has a Steward whose job it is to clarify the persons emergent high level outcomes, and then support that person to succeed in achieving them. The Steward will most likely not be a member of the person’s direct work team and can be approached to provide support, advocacy and mediation when required.

  • Loomio is developing a remuneration strategy that reflects the balance between equity across staff and autonomy as individuals. People employed by Loomio will set their own salary within guidelines provided by the Equity and Fair Pay Policy.

I think the thing I most want to celebrate right now in Loomio are the informal systems of support and care that are so present in the team. People step into strong clear accountability conversations in timely ways, others offer space and facilitation when there are difficult interpersonal dynamics.

Loomio is still a start-up; like all startups we manage cash flow on a day to day and week to week basis. In a workers cooperative context this involves everyone strategising cashflow dips, and adjusting levels of Loomio work and contracting work so the over all momentum remains in place.

I remember a time at Relationshps Aotearoa Inc.as CEO, when the government contract was paid 3 months late. The main risk in my mind was not paying staff on time. I managed this by mortgaging my family home to ensure no-one was adversely affected by poor government payment processes. It did not occur to me to share the problem with staff or to expect they would want to be involved in resolving the situation.

Perhaps this experience highlights the power and flexibility of an organisation where everyone acts like they are an owner of the business because they are  an owner of the business.

***********************************************************************************************

Travel updates

Madrid

Madrid was challenging for me. The environment was very structured and very male dominant. I had forgotten the feeling of being in a conversation and people responding to the comments I make to the man who can talk on my behalf. Thank Goddess Ben was noticing this as well – we just agreed he would bat the ball back. The evening session was hard, all in Spanish, plenty of deep tiredness, but also fascinating. Loads of emotional energy firing around, trying to read the emotional context was an interesting experience. Highlight – without a doubt Reyes Montiel talking about the Spanish Green Party (Equo) use of Loomio at the regional and national level. She also had good questions like:-

* how can we facilitate better so 1 person with lots of time doesn’t dominate?

* How to make it work for more people?

The next morning was completely different. Small number of us, probably the most aligned men with what Loomio is doing. I had great breakthroughs in my thinking talking with them that morning.

  1. Loomio is radically different from any of the Madrid projects because there are women involved, because we talk to people using Loomio, and because we have a diverse range of skills in the team. I sat in deep appreciation of all of you, the diverse, wonderful, skilled and conscious Loomio team.

  • Secondly, that our commitment to scale and measuring social impact also sets our strategy on a completely different path that the other Madrid initiatives. They are totally focussed on the Political. Which brings me to my third point.

  • By everyday democracy we mean building the capacity and competence for group discussion and decision making from small groups up to large groups, starting where people are at,and learning as we go. We mean building the context for everyone to be involved in decision making wherever in their lives. What I have become more conscious of is how this frame leads and guides our development in much more commercially scalable ways than if we had focussed on the political system. From where I am sitting here in London these team diversities and strategic focus have made Loomio so much easier to talk about and compelling for people to hear about. (just saying)

London

IMG_0611

Hub Westminster

This was an easy gig for us. Probably 30% of the people were supportive NZers. There was a real buzz in the room. People from that meeting are inaction in Loomio already and we have strategic follow up business meetings on Monday as a result. Customers and Channel partners were easy to spot and keen to follow up.

The main coder in the room at the Hub event was Paul MacKay, who works for NESTA and his own business Folk Labs and had great feedback for us.

Point People Dinner

Oh my goodness, Hannah did this with such class and attention to detail. I loved every minute of it, even the fish and chips! We met Kate Swade from Shared Assets who are a group working on public decision making around shared spaces, like the canals. Kate wants to work closely with us and we will be following her up as a priority. Hannah had really worked her network to find and invite exactly the right people to this exclusive, in a basement, under a skating rink mystery dinner

KPMG

KPMG in London have decided to commit to the front end of the start up scene. Set up an accessible informal team in the tech hub area of London and are building long term realtionships for long term pay back. Aimee who leads the team, just ‘got’ us immediately. She loved the tool and we discussed two opportunities to explore together. This was such an important meeting because it really exemplifies the difference in this European market to our own small and comparatively poor market. The opportunities and the interest in Loomio is palpable. What is also clear is that we have developed in a way that people see as best practice. Lots of positive feedback about our approach.

Said Business School Oxford

Cool  international representative group of men (no Oxford isn’t a men only environment it is just that only men go there!).

Nesta

Basically they are interested in social impact that will increase the well-being of British People in 3 categories, including participation and democracy. They would definitely invest in a NZ company if everything else stacks up. Joe rapidly talked through a process sort of like this:-

-Is there a problem/need? “YES”, -Are people willing to pay to fix it? “YES” – is it built based on customer feedback, “YES” , great lets move on. Joe began to think about introductions to important London agencies. We left after 40 minutes feeling deeply excited.

One day after a venture capitalist told us to stick to social enterprise but that the hard part would be finding people open to investing in an overseas company, we had found two!

Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana

Loomio is a tool made by a ragtag bunch that grew out of the Occupy movement, anarchist and activist circles, free-thinking musicians and artists, open-source advocates, techno-utopians, social entrepreneurs, and collective community builders. We’re a worker-owned cooperative company with no bosses. As you might expect, we aren’t predisposed to enjoy being told what to do, having role titles, or submitting to strict rules.

Like most developers, we’d heard of the Agile Method of Software Development, and we picked up bits and pieces gleaned from blogs or conversations. But we still resisted any kind of “oppressive” restrictions on our freedom.

We just didn’t get it – the Agile Manifesto isn’t so different from what you might see in an Occupy manifesto. It says right in the Scrum Guide that Scrum teams are “self-organizing”. We were hyper-conscious of process in our general meetings right from the start, but it took us a lot of trial and error, and practice, to apply the same rigour to process in our workflow.

Turns out, Scrum is what freed us, but only when we submitted to it fully.

Embracing Scrum In Its Entirety – It Ain’t Easy!

Because we’re stubborn, we had to learn the hard way, by making mistakes. More than a few times, just as we thought something we were building was nearing completion we’d realise it was not quite right (or even very wrong). Or things would take way longer than we thought. Or people would get frustrated at the way the team was working.

We’d have informal conversations about process improvements, or just carry on building until it worked. Tasks could continue indefinitely. We had no way of tracking our performance, and as the team and project grew, we were finding it increasingly difficult to make changes. Sometimes we felt like the app was locking us in to a particular trajectory against our will.

Loomio co-founder and lead dev Jon was frustrated by this dynamic but didn’t quite know how to change it. One day, he stumbled across a video by Ken Schwaber, and was inspired to study up hard.

Jon asked for team buy-in. He asked for permission to be an asshole about it until we actually got whipped into shape and started following Scrum for real. We might be a bunch of wilful individualists, but we wouldn’t be here if we weren’t prepared to do what’s best for the project first and foremost, and we saw that this was it. All consented to some much-needed bossing around.

It certainly wasn’t easy at first, and Jon had to continually repeat the phrase “let’s stick to the process” until he was blue in the face. The main thing that Jon asked of the team, and the main take away that he got from Ken’s talk, was this: to get full value from Scrum, you must adopt it entirely, following it to the rule.

Retrospectives are the Most Important Part of Scrum

The real magic of Scrum is not just the Scrum techniques themselves, it’s that continuous process improvement is built in. You can’t do that without retrospectives.

Retrospectives are a formalised way for the the team to reflect on the sprint that just finished and discuss the good and the bad of it. It’s about resolving conflicts or misunderstandings, and celebrating the good things that happened during the sprint, with the purpose of making process improvements for the team to adopt in the next sprint.

Following Scrum process closely is hard. We found that we needed plenty of practice to get a rhythm as a team. To get good at it, we had to learn together through practice, reflection, and communication.

We developers like to think we can teach ourselves anything by reading about it on the internet. But there are some things that you just don’t comprehend without stepping out of your comfort zone, actually putting it into practice, and making some mistakes you can learn from. You cannot really understand retrospectives by reading about them on the internet (yes, we are aware of the irony that you are reading about this on the internet – go out and try it for real!).

When you’ve got a lot of work you want to get done, or you’re already sure your opinion about something is correct, facilitated processes can feel like they are slowing you down. But our experience has taught us that in the long term, they absolutely pay off.

“I usually approach any meeting with a certain degree of trepidation, as it feels like it is getting in the way of real work. However giving the retrospective the time it needs has paid off time and time again. The simple exercises you participate in as a team brings out how everyone is feeling about the state of the project. You can’t help but address the major issues in the room. Having timeboxed conversations in order of priority and finding process improvements to address issues is the therapy that the team needs. Despite initial resistance, I regularly come away from a retrospective with renewed faith in the team.” – Rob (crotchety old Loomio dev)

Sometimes retrospectives are a place for challenging conversations and confronting issues you might otherwise avoid. It’s a place for anyone in the team to say what’s bothering them. These frustrations, which might otherwise fester, can be turned into great process improvements when facilitated properly. When you have great facilitation, the group benefits from shared understanding and protocols, skill at helping everyone communicate effectively, and tools for handling conflict.

Here are some facilitation techniques that have worked for us:

  • Visual: drawing progress lines, mood graphs, walls of post-it notes, and writing up the agenda of timeboxed conversations clearly

  • Verbal: consciously deciding on speaking protocols depending on time constraints and content, to empower people with varying communication styles. Some examples are a round (going in a circle, everyone speaks once), popcorn-style (people ‘pop’ whenever they feel they have something to say), a stack (people add their names to a list and they are called in order), or other agreed protocol (such as not speaking again until two others have spoken)

  • Cultural: personal circumstances, stress and emotions are legitimate dimensions to how people work. We start meetings with a check-in round focused on personal wellbeing. We make it OK to mention issues related to mental health, family obligations, gender dynamics – whatever needs to be acknowledged. We explicitly celebrate people taking time off to rejuvenate or study new skills.

Process Improvement in Practice: Experiment, Learn, Repeat

Here’s an example of how one of our processes improved through formal retrospectives.

When we first started, we deployed code as soon as whoever was working on it and whoever else happened to be around thought it was ready. This worked at first when Jon was the only developer on the team, but as the team grew it meant that we were missing certain necessary checks. Just small stuff like making sure the UX was intelligible, and that what we’d built was actually responding to the original customer need we’d set out to address (!).

During one of our retrospectives, we arrived at the conclusion that we needed a sign-off process. In traditional Scrum, the Product Owner signs everything off, so we decided to try that. This wasn’t the final answer, though, because we found that it wasn’t always clear what criteria exactly the Product Owner should be using. We tried giving the Product Owner a check-list of criteria, but it was time consuming for them to have to chase different people around to see if certain things were done. Also the Product Owner isn’t a code or design expert, so things were still getting missed.

Next we experimented with what we called ‘sign-off parties’ – get everyone together at the end of the sprint and do it all at once. We had a senior designer as Design Owner and a senior developer as Code Owner, and everything could be verified at once without the Product Owner needing to track people down. The problem with sign-off parties was that, inevitably, problems would be discovered (a good thing) but we’d find ourselves at the end of the sprint suddenly finding out we had a bunch more work to do (a bad thing). This bottlenecking caused every single sprint to start going over.

Finally we arrived at our current iteration of the process – rolling sign-off during the sprint. Now, when someone thinks their work is ready, they send it for sign-off by the Design Owner and Code Owner. There’s a checklist to make sure it’s been user tested, QA’ed, and cross-browser compatible. By the time it finally gets to the Product Owner for sign-off, they can see that all this has been done and don’t need to chase anyone around to make sure. Deployments can happen continuously and to a high quality standard, and doing this work is incorporated into the sprint itself, allowing us to actually finish what we set out to complete by the time the sprint is up.

It took three iterations of continuous improvement to get to where we are. Of course, our process around sign-off will continue to change as we grow, but we’re confident it will always change for the better because we’ve got rock-solid retrospectives.

Roles are Key, Even if You Are All in it Together as Equals

We are a highly collaborative team making a tool for collective decision-making, and a bootstrapping startup without the resources to employ people in Scrum roles who aren’t also on the Product Team. This creates an inherent tension with the traditional Scrum roles, which call for separation from the dev team, and hierarchical authority to make decisions.

We’ve worked through this tension by learning that Scrum roles are about personas and archetypes, not the individuals who happen to be in them. In fact, many people think that cross-functional managers are ideal for Agile, and at Loomio, every member is a manager. Thinking about the roles this way has helped us optimize them quite separate to anyone’s personal ego.

We encourage all our team members to learn about the roles and support them upskilling to the point they can take them on. We rotate people through roles periodically, to share the load and the learning, and to prevent anyone from getting too dictatorial. Going out to get external training is a great way to import Agile wisdom and culture into these roles.

We’re a cooperative company, meaning we’re all business owners, so the ‘business team’ serves everyone, and the traditional Agile ‘product owner’ has had to be adapted to our context, making it a highly collaborative role interpreting a wide set of priorities into a coherent work plan.

It’s up to the Scrum Master to facilitate the retrospectives. Once Jon had the process up and running, he handed the scrum master mask onto Mix – having a flair for the dramatic, he literally wears a black zorro mask when acting as the scrum master, so that he can take off the mask and participate in discussions as himself as well, and people don’t confuse the two personas or take it personally when he invokes the powers of his role.

The Scrum Master maintains a structured framework for the two-hour retrospective meeting, and ensures everyone’s voice is heard. We get through complex discussion points with minimal friction. The scrum master needs permission from the group to be a bit of a stickler, e.g. setting time limits on conversation topics and reminding people to stick to the conversational protocols we’ve agreed to.

Since we all own the business, we aren’t working for a paying client. So the idea of having a single product owner making the final decision on what features do and do not get built took a bit of getting used to. But it’s a very essential role to include and respect, to make sure we’re setting the right priorities and responding to feedback, user testing, and business circumstances.

Our current product owner, Rich, took over from Ben when he took off to talk about Loomio around the world. Rich stays in continuous contact with the user support, research, design, development and business teams, synthesizing all of that input into a coherent set of priorities for each sprint. He’s conceived his role as a communicator across different parts of the project, and a synthesizer of all the inputs.

What We’ve Learned:

  • Adopt the whole scrum process
    AKA: “Either scrum or don’t scrum. Don’t scrum haphazardly.” Take the time to learn it for real and get good at it, especially retrospectives. Attend a few external classes. Share the job of adopting scrum amongst your team. We owe a lot to the workshops held by Boost Media here in Wellington, who hold classes on many aspects of Scrum.

  • Focus on writing good stories
    We’ve learned the importance of writing better user stories, specifying clearly the who, what, and why of each feature. When you’re writing good stories and running good retrospectives, you can really start to feel the self-organising, self-improving nature of Scrum.

  • Make your sprints work for you
    Once you learn the rules, then you can start learning to bend them a bit. We started with standard weekly sprints, but found that the overhead of sprint planning and running a good retrospective meant that we didn’t have enough time during the sprint for all of the work we had to do. We’ve since moved to a 2 week sprint and made a strategic decision to start on Wednesdays rather than Mondays. This means we aren’t pressured to deploy on a Friday – meaning we’re no longer enslaved to the project all weekend worrying about bugs and fixes and things. Only through following the process strictly can you control variables enough to effectively experiment.

  • Track velocity
    Our mentor and code-guru Craig Ambrose recommended “velocity tracking”, a measure of user-facing value delivered per week. We dropped the ultra-flexible Trello in favor of the highly-opinionated Pivotal Tracker, with velocity tracking built in. Estimation is something that we naturally get all fussed about as developers. It’s hard. The best estimations involve all members of the team looking at well documented stories, and it rapidly highlights if a story isn’t clear. Estimating shows differences in the understanding of each story, allowing us to catch it much earlier. As we improve at this, having a good idea of task sizes helps us have an increasingly accurate view of what we can achieve in the short and long term.

  • Visualise progress
    We’ve experimented with visualising the sprint on a whiteboard. This helps us check in on our progress during daily standups, increases the visibility of stagnant tasks, and helps us see who is available for pair coding. In the example at the stop of this post, we were able to note how we slipped up on sticking to the stories in the sprint and made process improvements based on that.

Do you want us to work for you?

All this could be yours. We’ve got capacity over the next few months to work on your project. Join us in Agile nirvana!