Structure without Bureaucracy and Making the Implicit, Explicit

This is the first of a series of blog posts we are writing about management structures we have implemented at Ushahidi over the past year. We call it our Ushahidi Operating System (OS).

The Ushahidi OS Part 1: Define the Problem — Structure without Bureaucracy and Making the Implicit, Explicit

A few years back we came upon a real tension in the organization. We were over 5 years old, people had burned out and reignited, or didn’t, a new guarde came in to help scale, and we had grown in size from our early startup years. And we realized that we had very little idea what everyone was doing each day and who was responsible for what. We had an idea of what the big picture goal was, “ship this”, or “complete these annual milestones for this grant or funding.” For some, the engineering team particularly, there was a clear direction of tasks, but we had no idea who was really responsible for say, handling that marketing strategy, or landing the next grant, or if we wanted to make a dramatic change to the website — who made the call, or decide which feature got built next, or fundamentally who really had the final call on each decision across this now larger, more-established organization? Being remote made this pain extra potent. In the first few years when we were smaller, a start-up, it was clear: the founders made these calls and everyone worked pretty much 24/7. But now we were 30+ people, we were running three different products/programs, and we had new staff coming from places like Google and The White House. Being humans, emotional beings, what all this meant was that if someone needed to get something done or needed help, they would ask the people on the team they liked the best, not necessarily the right person for the job or the person who was technically responsible for that work. The lines of decision making had become implicit and relational based on our human relationships. This resulted in a handful of cases where someone felt excluded from what they deemed as their domain, further causing anxiety internally about ownership and responsibilities that bubbled up to fill the vacuum that existed.

Ushahidi was founded in 2008 in response to the post-election violence in Kenya. It started as an open source project with remote contributors from around the world, many of them Kenyan, although not necessarily living in Kenya at the time. So from the start we were an organization of remote workers, with an open source ethos, who were mission-driven, and prided ourselves for being different. We don’t want to do time sheets or TPS reports. We don’t care if you prefer to work nocturnally or nine to five, as long as you get your stuff done. At first, having that fervor that inhabits the startup world, open source communities, and the humanitarian sector all rolled into one meant that we all overworked ourselves and had a distaste for traditional “management.” Do you work, simple as that, no bosses or corporate speak needed.

But as we grew older, and grew up, the organization changed. Some people say that the big change in an organization is when it reaches about 50–100 people, when you don’t necessarily know everyone’s name. When you are working remotely, I think this happens at around 25 people. And as we grew both in size and age, we had to also evolve the way we were running things. When we started we fervently believed in a “flat organization” and that “people can just get their work done.” But overtime we realized that this was not a perk, in the same way that “work whenever you want from wherever you want,” can be. In fact, when you have remote flexibility, having clear and concise direction is even more important than in an office environment. It was also a disservice because we were not empowering ourselves and our team with the ability to make decisions, to know where we are going, or to have the support and training to grow ourselves.

Many organizations revert to titles to know who is responsible for what, but for us, titles were also seen as antithetical to a flat — everyone just gets stuff done — organization. So those sign posts were also absent. We were flat alright, so flat it was two dimensional and opaque.

We knew we needed a change, but we didn’t want to feel like we were going backwards, selling out, become those TPS reporting, tie-wearing fools we never wanted to be. We needed to keep our own culture but help create some useful structure, and that meant keeping a level of autonomy, staying remote, and allowing for changing of roles internally, but simultaneously bringing transparency and clarity to the whole process. As one team member succinctly put it: “we need to make the implicit, explicit.” For a number of years I had a sticky note with the phrase, “Structure without bureaucracy” on my desk next to my computer, staring back at me.

We needed radical transparency to questions like: What are our goals and tasks as an organization and as employees? Are we all being held accountable to them? Who is responsible for what? How do we change those responsibilities when we need to? Who can fire whom, who decides raises and promotions? And how were we growing as team members? And so we began to researching management and organizational models, read theory, and designed what we now call “The Ushahidi Operating System (OS).”

Fundamentally it is designed as a system of management with three key tenets, 1) evolution by design, 2) put the people doing the work in charge of making the decisions, 3) roles and responsibilities > titles.

The Ushahidi OS Part 2: When Doing Change Management, Bring Everyone Along for the Ride

As we set out to set create a management system that created structure but not bureaucracy and made the implicit, explicit, we knew we needed it to solve the pain points we were experiencing. Fundamentally, people were lost. It wasn’t clear who was doing what, or always why. I would often find myself struggling to know who it was who was meant to do those user experience studies, or who was it who had final call on whether we could change the colors of our website, or who was responsible for doing the research and making decisions on what framework we would use? Moreover, when you get into human resource management, who had the call to hire new people, or let someone go, was a Product Manager an engineers’ boss, or did she just the final call on the feature priorities of the product? Did titles give people the power? When we started it was fairly easy, it was the founders’ call. They made all those decisions from from logo design to hiring and firing, but as we grew, changed leadership, and evolved, our structures needed to as well.

First, Bring Everyone Along

Our first step was to include everyone. Culture change does not work when part of the team cloisters themselves off in a room and then jump out with a ready-baked solution.

Communicate. Communicate. Communicate.

We started out the whole process by creating a “Process for Inclusion”

In our work with the team we presented the following on our first slide kicking off this process of change management:

“We want to follow a process much like the way someone would build software. Why not learn from the best eh? So we are going to put forth goals, document the roadmap, then conduct user research surveys (interviews with the team and board), and then synthesis and present to the team, get feedback, synthesis again, repeat.

This was the roadmap we presented to the team before we got started researching or changing anything:

• Idea for doing it
• Leadership does some background research
• Discuss who leads this process (leadership or external?)
• Send note to whole team with this document, explain to team motivation, goals, expected deliverables, and process of this.
• Create questionnaire for 1x1 interviews with everyone.
• Ask for feedback on questionnaire from team.
• Set up 1:1s with all team to ask core questions about: company values, what they love, what they would like to see change, how they want to see decisions made, response on a handful of management structures from other companies like ours, other input.
• Get board’s input before moving forward (what is our culture? how are we organized? how do we work?) what we know (our mission, who we serve, what we build, what kind of company we are). Who are we today, how do we make it explicit, what do we want to evolve?
• Synthesize results
• Share results for feedback
• Implement feedback, decide on management structure that meets our needs
• Create final document (presented at all hands)
• Begin to implement a more explicit culture and management structure
• Review after a quarter.

This slide is the management consultant version of the list above:

We found this great helpful test from a management blog we read while researching management structures:

“How do you know you’ve established a good process?

• It can be periodically reviewed by an external set of eyes.
• It can be modified.
• It can be deployed by anybody, not just the person who created/designed it.
• It can be understood and executed by anybody reading it, without the necessity to be interpreted.
• There’s a clear outline of how to proactively identify internal and external triggers of change that can negatively impact adoption of the process.”

After defining the process, we needed to collectively define the problem, motivation and goals. As we kicked off the first meeting on this we presented the problems, motivations and goals as the leadership and operations team saw them and asked the team for feedback. This was the final wording from that discussion:

“Motivation

Ushahidi is eight years old, we have traditions and core culture, we also have changed and evolved a lot. We want to try and codify a framework for how Ushahidi runs, so that if anyone decides to leave and go meditate on top of a mountaintop someone else can pick up and go.

The idea is to make explicit what makes Ushahidi, Ushahidi, and also clarify how we can grow, evolve, and adapt as we have new staff, more staff, new strategies, or new products.

The idea here is to take what often seems implicit, or just “this is the way we have always done it,” and revisit each of those, do they still work for us? What does each of us want to change, and what do we want not to change?

The motivation has come from advice from the board, various requests from the team, and from leadership to figure out how we can create ways to make this the best, transparent, and most efficient, place to work.

Change management has been difficult. And our structure hasn’t necessarily evolved in a way for us to do our best work, as our technology has.

Goals

The goal of this process is to gather input from staff, and from that input clarify Ushahidi’s:

• values,
• how we run/operate,
• how we make decisions,
• how to understand how to work at Ushahidi”

Also, sometimes defining what this is not, is just as helpful. We stated that “This is not a discussion on Ushahidi’s mission, products, or strategies. This is not a “Why do we do what we do”, or “what do we do?” This is about “How do we do what we do?” This is the third part in the process, focusing on our internal org, the “how do we work?”

Next time: The surveys we ran with the team, the resources we found while researching management structures, and how we engaged the team to create the Ushahidi OS.

Originally published at www.ushahidi.com on March 6, 2018.