Managing with Trust and Expectation

For the past 6 years I’ve been part of a rather unique organization in Ushahidi, where we decided early on that how we’d run the organization was that we would trust each other and expect that everyone would act like responsible adults. It’s worked brilliantly, even as we’ve grown and spun up new enterprises and organizations such as iHub and BRCK.

Yesterday I read about the Berkshire Hathaway “strategy of trust”:

Mr. Munger, 90, was ruminating on the state of corporate governance, offering a counternarrative to the distrustful culture of most businesses: Instead of filling your ranks with lawyers and compliance people, he argued, hire people that you actually trust and let them do their job.

It’s well worth a read, and I didn’t expect to find parity in leadership philosophy between us and a 300,000-person family of organizations.

How do we do it?

There are probably other organizations like ours, ones who have decided to trust their team and assume that people make good decisions based out of the best intentions of the organization and their colleagues, over themselves. We didn’t set out with a great body of knowledge on how to do this, but instead with some theories that we’ve refined over time. Here are the most important ones:

Find the Right People
David, Juliana and I particularly don’t like to micromanage. We’ll work with you to define the goal, but if you expect someone to tell you how to get there, you won’t fit. We don’t check up on you all the time, you tell us when there’s a snag. You need to work autonomously. We’ll help, and are always there for a conversation, but your job is to get from point A to point B.

It’s always better to find people who are smart and get things done, who can work autonomously and tend to not put themselves first. Big egos don’t go well with this kind of team, so we look for humility when interviewing.

I remember making a mistake back in 2009, hiring someone off of reputation and resume, without really digging into their portfolio or doing multiple interviews. Ever since then I’ve refused to look at CVs or resumes and each new person goes through about 4-5 other people on the team before we make the final decision. Those other people on the team catch things I wouldn’t, some about skill, but most about ethos and personality.

Knowing the Ethos
If an emergency happens where you are, can you make a decision and run with it, without having to ask permission? You should be able to. This is especially important in an organization with a globally distributed team that deals with crisis and disaster. We decided that everyone should be able to make critical decisions about deployments of the software, partnerships and strategic steps on their own. Just fill everyone else in on it as it comes up and if adjustments need to be made, then we do it together.

To make this work, we had to ensure that everyone on the team, from junior engineers to new QA staff actually understood the foundational elements of the organization. Not just what we built, but why we built it, how it all started and where we were going in the future. While there’s no “intro to X” classes, we do throw you in the deep end early on. It started with our first hire, Henry Addo from Ghana, who found himself speaking in the French Senate in Paris in his first month on the job. That made us realize that public speaking forces you to learn a lot more about the organization that you’re in, quickly.

Our goal is that a camera and mic can be put in front of any team member and they can answer any question on the organization. The way they answer it might be different than me due to speaking styles, but because they understand the ethos of the organizations, it is still correct.

Per Diems
We don’t do per diems. You’re traveling for the organization, spend what you need on food, lodging and transport. Be responsible about it, since this is money needed for the organization to grow. If you’re in NYC, we know things are more expensive, if you’re in Omaha we know they’re not. The “Agency Effect” (or Principal Agent Problem) comes into play here as the incentives are wrong between a team member and the organization if they get an allowance for travel.

Final Thoughts

I suppose what I’m saying is that if you truly trust people to act like the adults they are and to do the right thing, they generally do. All the corporate oversight you can apply won’t stop an Enron from happening, so something else has to work. It has to be something that’s real though, people can sniff out very quickly if it’s a manufactured, or fake, trust. This means as much of the onus lies on the leaders to “let go” as it does for the team members to shoulder and own the expectations that come with their role.

My greatest takeaway from the Mr. Munger and Mr. Buffett was found in the last paragraph:

Mr. Munger, in a previous annual meeting, contended that the best way to hold managers accountable is to make them eat their own cooking. Mr. Munger pointed to the late Columbia University philosophy professor, Charles Frankel, who believed “that systems are responsible in proportion to the degree in which the people making the decisions are living with the results of those decisions.” Mr. Munger cited the Romans, “where, if you build a bridge, you stood under the arch when the scaffolding was removed.

We all need to stand under our own bridges more often, and I’m going to figure out how to make that happen in my organizations.

Making Ushahidi

[Below is my Tech4Africa talk, given today in Johannesburg, South Africa, titled “How we built Ushahidi, w]

I’m used to talking about Ushahidi, and as all of you guys who frequently talk about your product or company know: it gets old spouting off the same old stuff over and over again. That’s why I’m excited about today and for being invited to this excellent conference, since I’ll be telling the backstory, the quirks and funny bits that got us to this point and made our Ushahidi culture what it is today.

This is my story of Ushahidi – Of a small organization that dislikes hierarchy and being told what we can’t do. One that questions everything, embraces innovative thinking, takes risks boldly, and sometimes learns the hard way that we’re human after all.

In January 2008 I spent a week watching news reports roll in from Kenya, frustrated. Frustrated because I had said for years that “technology helps us overcome inefficiencies”. Wasn’t the madness of Kenya, in it’s post-election violence throws, it’s lack of media coverage, and lack of real information just this? Why was I unable to do anything?

It turned out that I needed an idea, and for once I couldn’t come up with one on my own. That seed of an idea that grew into what you see today came from a simple bullet point by my friend and fellow blogger Ory Okolloh, asking if we could map reports of violence around the country. Thus Ushahidi was born.

I’m going to walk you through three defining moments for our organization, and our platform, not all of them pretty, but which make us who we are.

1. Let’s look at the ad hoc cast that got it started:

The Ushahidi Team - circa Jan 2008

Ory Okolloh – lawyer, blogger and Kenyan political pundit
Juliana Rotich – renewable tech geek, blogger and database admin
David Kobia – developer and top Kenya forum webmaster
Daudi Were – blogger and web guy
Erik Hersman – Africa tech blogger, web guy
Others – a various cast of tech and non-tech people swarmed around the first Ushahidi deployment in Kenya, helping with small tasks and then disappearing.

Key points:

  • You’ll notice that there was not a single one of us who had any humanitarian experience
  • None of us had taken part in any open source project. (v1 was built in .NET)
  • Most of us were self-employed, running our own businesses or consulting, and didn’t like working for big companies.
  • The only common denominators that we shared was our love of our home; Kenya, and the ability to blog.

Thus, we felt we were the best placed to create an African open source platform for crowdsourcing information, our tech gift to the rest of the world.

We didn’t think of that at all actually. Instead we were madly Skyping, emailing, wireframing and coding over a 3 day period to get something up as quickly as possible.

We were brutal about every decision:

  • If it wasn’t absolutely necessary, throw it out.
  • Pick a name, any name, we don’t care if non-Kenyans can’t say it, just get a domain up asap
  • Launch this app, it’s functional, we’ll fix bugs and features on the fly
  • No one has a short code for us yet? Screw it, it’s not worth waiting, we’ll get one eventually.
  • Money, what’s that for? Media budgets are overrated, we’ll blog it.
  • We don’t have a logo. Oh well… Launch already!

How our team came together, the way we made those initial decisions and how we interacted and leaned on what would become our community was defining. It still colors how we operate, our organizational communications and our community focus.

Lessons learned:

  • This taught us to keep a shallow and wide decision-making structure so that everyone had access to all the information about ops or platform that they desired. Anyone was empowered to make decisions, since thy understood the macro-game.
  • Release code early, it’s better to have it out and being tested and worked on in the real world, than hidden away in a sandbox somewhere.
  • If you want it done, build it yourself, don’t put it off onto another team member.
  • Community = success
  • No money, no worries. Build good stuff and good stuff happens, money follows.

2. Technology is only a tool

allocation

No background in open source projects meant that we had little experience in how to engage programmers, designers and the help needed to get things moved from that initial .NET build into an open source language. David and I were trying to decide what language to write this in, and we ended up picking PHP over Python since we thought more African programmers would be proficient in it.

David wasn’t a PHP guy (yet), so the early helpers, the volunteers like Jason Mule, Henry Addo and Chris Blow were a huge help in making the decision to go with the Kohana framework and a myriad of other decisions.

3 months later we announced v0.1 of “THE NEW AND REBUILT USHAHIDI PLATFORM!”

We were very excited, after all, wasn’t this the platform that would save the world? And we were ready to show the world just how it could be done. Gamely mounting our white steeds we charged into a deployment of Ushahidi in the troubled North Kivu region of the DR Congo.

Echoes of that failure splatting against the ground remind us still, today, of the complexities of the space we build software in. We learned from those lessons though, and Ory wrote a good blog post making sure that it was shared within and without.

Lessons learned:

  • Technology is only 10% of the solution needed. The rest is administration and messaging.
  • Stick to what you do well. Our team is built to build software, not be a deploying organization
  • (caveat! We do help in deploying rarely, like Haiti and Kenya, but we now pass those off, or partner)
  • Own your failures publicly, learn from them.

3. Enter the failephant!

The Ushahidi Failephant

Only a few months later, after the DRC debacle, we were rested and ready to fail again.

Al Jazeera had used the alpha version of the Ushahidi platform in Gaza, a group of organizations and individuals were deploying it to monitor the worlds biggest elections in Indian, and we had a number of groups in East Africa testing it out.

Our model was that we had a small team at Ushahidi whose job was to come up with and guide the core architecture of the platform. Volunteers also worked on core, but were also encouraged to extend the platform in their own ways. It was working very well, and still does.

We were ready to release the code publicly.

Before I say anything, let’s revisit that point earlier about none of us having eroded on an open source project before…

Preperations were made, blog posts were written, tweets were tweeted – and we got lambasted by one of the guys we respect a great deal in the open source community. Rabble called us out on all the things we did wong.

– The code repository was behind a user/password wall
– We weren’t available in the normal programmer channels like IRC
– Hard to plug into the rest of the dev community

Our team went to work, madly working over the next 12 hours to get our stuff straightened out. Finally I wrote another blog post, introducing our failephant mascot and apologizing for our ignorance and missteps.

Lessons Learned:

  • Listen and apply that listening to real changes
  • Again, own your failures. Fix things that are wrong.
  • It’s okay to think different in how you execute on a project as long as you don’t stray from the spirit of your community and self
  • .

Finally, I’ll end with this.

We’ve learned that technology does overcome inefficiencies, but that it still takes people to make it happen.

We’ve learned that more people need to buck the status quo, that questioning everything makes us better.

We’ve learned that Africans can build world-class software, and to expect nothing less.