Three-Legged Leadership

There are countless approaches to leadership. This one is mine.

I never wanted to be a “Textbook Leader” or a “Paint-by-Numbers Manager”. My goal has always been to be authentic, unique, and teachable. Also, I have a terrible memory and find complex leadership methodologies unhelpful. So, I’ve recently been attempting to distill all the knowledge and experience I’ve gained so far into a simple framework that can be applied repeatedly. It’s already helped me navigate a variety of real-world issues.

Maybe you’ll find it helpful too.

+++++

THESIS

An inexperienced leader is like a three-legged dog: Although incomplete and often awkward, it can still run.

If you’ve ever seen a three-legged dog run, you’ll notice a specific pattern: It places one paw after another in rapid succession, but always in the same order. The two hind legs propel it forward, while the front leg provides direction and braking power.

Likewise, a leader really only needs to take three steps to progress over any terrain:

  1. Be strategic
  2. Get input
  3. Be decisive

Now let’s look at each step in detail.

STEP 1: Be strategic

Leaders are confronted with complex problems every day. It’s how they deal with those problems that makes the difference between a good leader and a bad one. The most common mistake I make, for example, is reacting to these problems. Whenever I learn that something is broken or dysfunctional, my first instinct is to fix it. Now. And yet every time I try to fix-it-now, I usually just end up making things worse.

Why is reacting to a problem problematic? There are at least three reasons. First, when you’re hearing about an issue for the first time from another person’s perspective, you definitely don’t have the full story. By reacting, you’re in fact only responding to incomplete and/or inaccurate information. Second, when you immediately propose a specific solution, you aren’t considering other possibilities. Finally, by responding with a solution of your own, you aren’t empowering the person who’s raising the issue to take ownership of it. As a result, your “solution” likely won’t solve the problem, and the other person will only learn that they can run to you for help whenever things get difficult. This leads to poor results and a low performing team.

A good leader, however, takes a step back and thinks about the situation critically before actually doing anything. In essence, being “strategic” simply means breaking something down and then figuring out possible ways to build something better than before (not just “fixing” something prone to breaking).

For example, when something isn’t working, I force myself to ask some critical questions, like:

  • Who are the stakeholders and/or team members involved, and how are they being impacted?
  • What is the impact on the business or its goals?
  • What are the risks if the issue isn’t resolved?
  • What are all the potential solutions?
  • What are the short term and long-term benefits of those solutions?
  • Based on the above, which potential solution should you explore first? Which one last?

…and so forth. By doing so, you can uncover the actual problem while revealing more opportunities to make a bigger, better impact.

It sounds simple. Yet in practice it often feels unnatural to spend time analyzing a problem before attempting to address it — especially if that problem is urgent and/or acute.

 

STEP 2: Get input.

To be clear, being strategic is not the same thing as having a strategy. The former is a process for critical analysis. The latter is a concrete plan of action based on facts you’ve gathered during that analysis. In other words, being strategic allows you to get the right inputs necessary to define a strategy. One leg follows the other.

But getting the right inputs is also harder than it sounds. Whether you realize it or not, you already believe something about the situation, or the people involved, when analyzing a problem. If you’re not careful, you can end up reinforcing your prior (mis)beliefs instead of learning the actual truth. This is called confirmation bias. For instance, you might only ask specific people certain questions because you know that they’ll tell you what you want to hear — therefore “justifying” your beliefs and reinforcing your biases. As such, your potential solutions will only address an issue from that limited perspective. Depending on the size and severity of the problem you’re trying to solve, this can lead to disastrous results.

It takes intention and courage to get input from those who have wildly different perspectives than you. It also takes skill to ask the right questions without betraying anyone’s confidence or alienating those you’ll need support from in the future. The trick is to ask direct, open-ended questions, but without accusations or assumptions.

A few examples:

  • Instead of asking “What went wrong?”, ask “What did you observe?”
  • Instead of saying “Tell me what happened”, say “Show me what happened.”
  • Instead of the question “What should have happened”?, ask “What is the result you would hope to see going forward?”

In essence, your goal in gathering input should be to separate personal interpretations from factual information. If done correctly, you can more easily identify the root of a problem while building a coalition of support to execute a potential solution (and then pivot if one particular solution doesn’t work). If done incorrectly, those who are to “blame” for a problem will become further isolated and deprived of the opportunity to improve gracefully. Or, if nobody actually did anything wrong/incorrectly, then nobody will take responsibility for making things better.

The same applies for proposing solutions. When coming up with ideas, it’s all too easy to have a favorite. This is the most dangerous form of confirmation bias, because otherwise avoidable mistakes can quickly become major problems — perhaps worse than the original one. So, it’s always best to get input regarding any possible solutions, and to investigate opportunities with an open mind. It all depends on what questions you ask.

A few more examples:

  • Instead of asking “How can we make sure this never happens again?”, ask “How can we improve the process going forward?”
  • Instead of saying “Here are my ideas for fixing the problem”, say “These are some possible solutions.”
  • Instead of the question “Which solution is best?”, ask “How would you prioritize these possible solutions in order of greatest potential impact?

At the end of the day, you should want everyone to feel motivated and responsible for delivering better and better results over time. That isn’t possible if you don’t truly understand the issue to begin with, or seek only to implement the fastest/easiest/most convenient solution.

 

STEP 3: Be decisive.

So far you’ve taken a strategic approach to responding to a problem, and have gathered all the input necessary to define a plan of action. Now it’s time to decide to act.

As a leader, “acting” isn’t telling other people what to do (in the corporate world, at least). It’s about communicating — both who you communicate to, and how.

For example, maybe the problem can be solved by tweaking a process shared by a small number of stakeholders. In this case, communication across the team/department/company isn’t necessary — only the people involved need agree and commit to changing something. You just need to make sure those important conversations happen, and document the outcome.

Or maybe the problem is complex, and/or will take more time and effort to address. In such instances it may be necessary to inform a larger group what the issue is and how you intend to solve it. Then you might need to work directly with a few smaller groups to implement a solution. Once a potential solution has been implemented, it’s then always a good idea to follow up with progress reports and end results.

The point is that you must stand up as a leader and take a position, educate and/or work with others, and remain present throughout the process. It requires courage, energy, optimism, and thoughtful communication. A leader who acts is basically putting themselves on the front lines, while sharing ownership of the outcome. Otherwise, they aren’t actually being decisive — they’re just maneuvering in order to gain the most by doing the least.

+++++

The world of business is complex. There are many factors that contribute to any one problem, and there is almost always a human component. As such, there is no perfect formula for problem-solving for as long as there are imperfect people who must contribute to any solution.

You might be new to leadership. You might have some experience, but still lack certain skills/abilities. That’s okay. Like a three-legged dog, you can still run with the others. For as long as you respond to problems strategically, get the right inputs from the right people, and then demonstrate decisiveness through action, any problem is solvable.

Learning How to Lead: Part 3

Genuine leadership isn’t a formula. It’s personal.

I’ve gained a lot of experience as a leader since joining eyeo. Most of it has been tactical, like hiring, developing talent, establishing processes, and unblocking things that get in the way of progress. Some of it has been strategic, like developing a vision for the product team, driving innovation, and setting priorities. But I still have a hard time defining what kind of leader I want to be, beyond all the things that need to get done. So, I started working with a personal coach to help me develop further.

The coach sent me a list of questions before our first session, just to get a baseline. They were difficult to answer, since I couldn’t really answer any of them unequivocally. During our session, she asked me to define what a good leader looks like, or if I had any role models in mind. Apparently, I really don’t know how to define leadership beyond vague American stereotypes, and I honestly can’t think of any leaders that actually inspire me (especially present day). I admire a few traits here an there, but no one person embodies the full expression of leadership that resonates with me.

That’s when it occurred to me: To develop further, I shouldn’t be trying so hard to copy somebody else, just because I think that’s what people expect from me. Fuck listicles. Fuck how-to manuals. Fuck role models. Fuck whatever I think other people think. Most especially, fuck any standards depicted in popular culture. What’s my genuine expression of leadership?

Again, it’s hard for me to answer this question. All those opinions and depictions and past experiences suggest that I can never be a good leader. I’m antisocial, not especially charismatic, hate being the center of attention, refuse to network, and I really, really don’t like telling people what to do. The quintessential image of the “strong”, bold, confident leader that commands a stage, publicly eviscerates incompetence, and regularly rubs elbows with powerful people makes me want to puke. To me, that just screams “self absorbed, egotistical asshole that needs to prove how awesome they are, all the fucking time.” I reject that template entirely.

But I’m just now starting to embrace the idea that I don’t have to be/do any of those things — that it’s possible to be an effective leader, and still be genuinely me.

After thinking a lot about this, some themes have started to emerge. They have nothing to do with external traits (like “charisma”), but have everything to do with internal values.

Here are some examples:

A leader serves those in their charge first, their superiors second, and themselves last.

A leader shouts praise for others from the rooftop, but delivers a rebuke behind closed doors.

A leader welcomes criticism, but eschews recognition.

A leader is always the first one on the battlefield, and the last one at the watering hole.

A leader knows when to be gentle, when to be harsh, when to be flexible, and when to be firm.

A leader can motivate others without demanding anything.

A leader would rather fail together than succeed alone.

A leader plans for both wild success and total failure.

A leader may not know the right answer, but they always know the right questions to ask.

A leader surrounds themself with people more intelligent, skilled, and talented than they are.

A leader sees the patterns and pitfalls others cannot.

A leader knows two things at any given moment: their own weakness, and the potential of everyone they lead

A leader makes plenty of mistakes, just never the same mistake twice.

+++++

If I could become just half the leader described above, that would be enough for me. The important thing is that I identify with the description above personally. Others will have to define their own leadership style.

So, how would you describe the leader you want to be? I encourage you to embrace your own definition before trying to fit someone else’s. Otherwise you’ll end up becoming just another Listicle Leader.

Accidental Success

Lessons learned from launching a new product that wasn’t supposed to exist.

When we launched Trusted News — a brand new desktop extension that has nothing to do with ad blocking — my expectations were low. One or two articles from any publisher would have been enough to make me happy. Instead, a total of 78 publications wrote about the product, including TechCrunch, Fast Company, c|net, and engadget. Meanwhile, over 5,000 people are now actively using it 😀

Being the first product I’ve ever worked on that went from nothing-to-something, I credit any success to the team, timing, and our communications department. Still, it would be wise to reflect on what went right, since developing new products will be important to eyeo’s future success.

LESSON 1: Passion is paramount

I remember our very first meeting as an unofficial project team vividly. Having identified those who were potentially interested in embarking on this experiment, I presented the problem (disinformation on the web) and asked everyone lots of questions:

  • Did we genuinely care about this problem? Yes.
  • Did we fully understand the problem? Sort of.
  • Could we build something that would actually benefit users? Maybe.
  • Since this would be an unofficial project, were we willing to devote our free time to this, without knowing how long it would take or what challenges we would face? Hell yes!

Step 1 of our journey, therefore, was nothing more than declaring our willingness to work together, and commit to the experiment. A few people dropped out, either due to lack of time, interest, or technical experience. Those who remained were both passionate and ready to roll up their sleeves.

This inherent desire was our secret sauce. It’s what kept us going during many nights and weekends, got us through uncertainty, and helped us forge the right partner relationship to deliver a real solution.

LESSON 2: Partners are pivotal

About that partnership. It was pure serendipity that Paul Walsh, CEO of MetaCert, and myself happened to meet at the exact right time. Our marketing agency out in California, Rocket Science, introduced us shortly after we established a voluntary project team. Paul and I both worked in San Francisco, so we met for coffee and started talking. It turned out we both cared intensely about the same things, and his company could provide the data solution needed to build a functional product.

It wasn’t until much later that I realized how important — and exciting — this partnership would be. Not only did they create a custom technology solution (for free), they then figured out how to scale that solution for sustainable growth (again, for free). They were in this for the long haul, and they had our backs. As a result, our product would have actual, immediate potential for long-term success beyond its initial launch. That’s more comforting than I can fully express.

Only now do I understand the essential qualities any partner should have. Namely, they should genuinely share your vision, fully understand the problem you’re trying to solve, and be capable of delivering a sustainable solution. Everything else is about alignment and coordination, and takes a lot of work on both sides to get right.

LESSON 3: Size matters

Few people knew about the project internally. Those who did know doubted that we’d succeed in the end. So when we announced that Trusted News was going live — after just 11 months of semi-secret work — many people were caught off guard, and nobody knew how we pulled it off. This was actually intentional.

There were a lot of unknowns in the beginning, but there was one thing I was sure of: the fewer people involved, the better. If you know anything about working at eyeo, you know such thinking is blasphemous. We generally don’t do anything without involving anyone/everyone with an opinion to weigh in, debate about every single potential problem/solution, and then spend months in code review or QA.

But I wanted speed. We had to deliver something sooner than later. And that something didn’t need to be perfect. It just needed to work. If we could do that, then we could make it better over time. This is why I kept the team as small as possible, the scope of our vision limited, and the user experience super simple. If we didn’t know how to build something, we learned. If the vision was too ambitious, we scaled it down. And if the user experience could be trimmed down further, we did so without mercy.

By working as a small team under the radar, we avoided any bureaucratic pitfalls. By committing ourselves to creating a true “minimum viable product”, we could focus on delivering something of value now, instead of trying to build the perfect thing later. As a result, we introduced an entirely new product in less time than it took the rest of the company to build a single new feature for any of our existing products.

LESSON 4: Timing is everything

There was another reason it was important to prioritize speed over perfection. Since the 2016 US Presidential Election, “fake news”/disinformation had become a hot topic, and the media was paying a lot of attention to it. In less than one year, the issue had gone from a fringe issue that nobody cared about, to a one that’s generated endless headlines in the press. In other words, a lot of people already cared about the very problem our product was intended to address, and there likely wouldn’t be a better time to capitalize on that attention.

Yet it wasn’t just about delivering something soon. We didn’t want to just hit the “UPLOAD” button the first moment we could and call it a day. That’s why we developed a communication strategy and waited until an agreed upon day and time to have maximum impact. A few of us wrote blog posts about the launch, the vision, and technical details. Our marketing agency wrote a press release and lined up interested publishers. Ben, our Director of Communications, pre-pitched the story to the press. Then, at 3:00 pm CET on a quiet Tuesday, we collectively announced Trusted News to the world.

If we had waited until everyone else in the company understood and agreed with our plan, or the product was “perfect”, we likely would have missed the fake news party. And if we didn’t wait to launch at the right time with the right message, either the press would have missed it, or totally mangled the message. Instead, the launch itself has had a meaningful impact that we can easily build upon (instead of struggle to recover from).

LESSON 5: Downtime doesn’t have to be a downer

Truth be told, we probably could’ve launched a few months earlier. What held us back was our partner. It took them longer than anticipated to deliver the technical solution and relevant data. This was to be expected, though. MetaCert has a core business with existing, paying clients to take care of. The company is also growing like crazy, and they’re working on big, interesting stuff (like an initial coin offering for their new, proprietary cryptocurrency). The fact that they dedicated resources to build anything at all for us is amazing, and a testament to their passion for this project. And the fact that they thought about a long-term solution is proof positive of their ongoing commitment.

Still, one must remember that “downtime” is inevitable when working with a partner. Sometimes they’re ahead of you, sometimes you’re ahead of them. The important thing is to remain flexible. While MetaCert was working on the stuff we needed for launch, we spent our time studying the issue of disinformation more extensively, identifying potential issues, and conducting user research. Now that the product is live, all those investments we made during that downtime have provided the information required to develop a roadmap and a solid plan for extending the product beyond Chrome on desktop computers.

LESSON 6: Embrace your base, but mind the masses

There’s one lesson in particular that product companies often forget: There’s a huge difference between the early adopters of a product — your “base” — and the masses you want to reach. In our case, we didn’t do any actual marketing for the launch of Trusted News. Sure, a few people probably downloaded the product after finding it by chance on the Chrome Web Store. Most of them, however, learned about Trusted News from a news article. This means that many of our first users read about technology and/or new web products regularly, and likely have a deeper understanding of the “disinformation problem” than the average person. Being more educated also means that they will have higher expectations of our product, and are therefore going to be the most critical…and vocal.

The best thing about the “base” is that they already “get it”. Their feedback is extremely valuable, and the problems/issues they complain about are often things you need to improve anyway. Ignore them, and they will punish you. Embrace them, and they will become your future evangelists. But don’t make the mistake of trying to serve them.

The ones you should actually be serving are the masses — the millions of people you want to reach, but who don’t understand the problem you’re trying to solve very deeply. They have a simple need or pain point. They stumble upon your product by accident, learn about it from social media, or hear about it from their friends. Then they either find immediate value in your product (and continue using it), or they don’t (and never use it again). Interestingly, what they need/want is rarely want your base needs/wants. Early adopters want granular control, broad functionality, and the ability to influence the future of your product. The average users just wants shit to work, and don’t want to think very hard when using it.

So listen to your base, and then translate that feedback into a product experience that will appeal to average users. It’s simple in principle… but really, really hard to do in practice.

LESSON 7: Haters gonna hate

This is the most obvious, but difficult lesson every product manager has to learn.

When we announced the product internally, there were plenty of colleagues who thought it was a poor solution, doubted anyone would actually find it useful, or complained about the things that didn’t work exactly right. When the press wrote about it, some of them focused on the imperfections of the initial experience rather than the overall intention of the product. And dozens of users who disagreed with the label for a particular website immediately gave it a one star rating, left negative comments, and/or uninstalled the product.

Sure, these reaction hurt. But the feedback is usually valid, and it all confirms what we already knew about the product’s current shortcomings.

Yes, I’m sad that some users were so disappointed that they abandoned the product. But we know it will only get better with time. (We also see that the current retention rate is around 90%, so we’re doing something right.)

And yes, those in the technology industry who say our solution is limited, imperfect, or lame wound our egos. But you know what? Until they put some skin in the game and build something better, fuck them. At least we’re trying!

+++++

There will be many more things I have yet to learn (like how to scale a product that demonstrates early success). I certainly don’t want to loose our momentum, or make anything worse. I’m hopeful, however, that the lessons we’ve learned so far, and the one’s we’ll learn in the future, will arm us with the experience and knowledge we need to successfully launch other products in the future.

Let There Be Trusted News

Introducing an add-on for Chrome that measures the trustworthiness of websites you visit every day.

About a year ago, my wife (who’s also a User Researcher at eyeo) told me about an idea she had for a browser extension that could identify fake news. I shared this idea with the Product Team a few months later, only to discover that many of them already had a passionate interest in the subject. Knowing there was a collective will to act, and a unique opportunity in the market, I pitched the idea to our executives, who gave me their approval to explore a minimum viable product.

So, I formed a small team of core contributors and a few advisors—just enough people to get shit done. Together, we defined the opportunity, designed and tested a prototype, and then built something real. Today, the Trusted News Beta add-on is available on the Chrome Web Store in English-speaking markets.

Download Trusted News for Chrome

This is the story of how Trusted News came to be.

The Trusted News website heomepag

Trusted News website homepage

THE VISION

In the beginning we saw a huge opportunity to address fake news, and had lots of ideas for an extension. We wanted to do things like measure each page for accuracy, suggest alternative articles from websites across the political spectrum, and offer users the ability to categorize and rate content themselves. But an initial product, produced with limited resources, would have to be the best possible compromise between what’s possible now versus later (with more resources).

Therefore, we started with the basics: 1.) A solid vision 2.) great data sources and 3.) a straightforward user experience.

The vision itself is simple. Essentially, we believe that the distribution of misinformation online is a huge problem. Brexit, the 2016 US Presidential Election, and the polarization of society in general are just recent examples that have had enormous consequences. We wanted to build a tool that would rate the quality of content simply, accurately, and fairly as a user browses the web. However, it’s not within our authority (or ability) to declare what’s true, or what’s false… That should be up to the individual to decide for themselves.

Our primary goal, then, should only be to inform users of the trustworthiness of a particular source of information. They can believe or trust in whatever they want, but at least they have a tool that helps them separate fact from fiction. With this as our primary directive, we had a foundation to build on.

THE DATA

List of data sources

List of data sources

The really hard part was also the most critical. Reliable, unbiased data sources were the key to delivering any product worth installing. Only such data sources are exceedingly hard to come by (or openly accessible). Nearly all of the ones that do exist lean one way or another politically, and they don’t necessarily measure/score the same content sources.

Luckily, I happened to know the CEO of a company dedicated to information security and the accurate tagging of content. MetaCert started off providing cyber security tools to help developers and service providers keep porn off their networks. Then they began labeling all sorts of content that impacted corporate communication technologies, such as phishing attacks and malicious websites that were known to distribute viruses or malware through chat bots. They recently launched MetaCert Protocol, an anti-fraud and URL registry that pulls data from several sources, including PolitiFact, Melissa Zimdars for it’s News Reputation category, and their own extensive database, which identifies content across a variety of categories like fake news, far left, and far right. Plus, they offered a custom integration of their database into our own extension. MetaCert Protocol thus became our initial data provider.

THE EXPERIENCE

We had a vision. We had data. Now it was time to design a user experience and an interface that was easy to understand.

Toolbar Icon

Chrome toolbar icon

Chrome toolbar icon

As a user navigates from one website to another, we wanted to arm users with contextual information without getting in their way. The first, most obvious way to communicate this information is through the Trusted News icon in the browser toolbar. We decided to make the icon display a traffic light system that immediately tells users whether a website is trustworthy (green), biased (amber), or untrustworthy (red). That way a user already has an indication of the trustworthiness of a website without having to click on anything.

Bubble UI

Example of a "Trustworthy" website

Trusted News interface showing the label “Trustworthy”

But if they do want more information, it should be simple to find and understand. The best way to do this is through the extension interface (aka the “bubble UI”), which is displayed whenever a user clicks the toolbar icon. Here, we had a limited amount of space to show information, and knew that whatever we showed would make or break the entire experience.

Example of an "Untrustworthy" website

Trusted News interface showing the label “Untrustworthy”

One challenge in particular were the labels themselves. We didn’t want too many categories, or to be overtly political. Yet we did want the labels to be meaningful and genuinely helpful in making decisions. In the end, we came up with several categories that would show prominently in the bubble UI using the data available from the MetaCert Protocol registry…

  • Trustworthy: Websites that are known to consistently provide quality, accurate information, regardless if the publisher is liberal, conservative, or moderate.
  • Untrustworthy: Websites that are proven to produce false or purposefully misleading content.
  • Biased: Websites that contain politically biased content or promote unproven or skewed views.
  • Satire: Websites that produce satirical content, and are not intended to be sources of actual news.
  • Malicious: Websites that are known to distribute viruses or malware.
  • Clickbate: Websites that knowingly uses misleading headings or article titles to attract readers in an effort to increase traffic and revenue.
  • User Generated Content: Websites that contain user generated content and therefore can’t be accurately evaluated.
  • Unknown: Whether there’s too little data, or no data at all, there isn’t enough agreement between the data sources to assign any label to the website. Therefore, the content may or may not be trustworthy… we simply don’t know (yet).
Example of a "Biased" website

Trusted News interface showing the label “Biased”

The data sources used to make the decision are displayed below the label in the bubble UI. This implies that all the sources shown contributed to the final result. The user can click on any of the logos to learn more about the owner of the data source. Ultimately, they then must decide for themselves whether to trust the individual sources and / or agree with the label.

Example of a "Satire" website

Trusted News interface showing the label “Satire”

After user testing, we also agreed that users should have the means to provide anonymous feedback into the system. Our sources are limited (for now), and they all certainly have their biases to varying degrees. But over the long term, we plan to add more data sources that measure more content from all over the world. Until then, at least we can ask users to help us improve the product by asking if they agree or don’t agree with the label shown—essentially crowdsourcing quality assurance—which will be included in the product soon.

LIMITATIONS

The Trusted News Beta is the only thing we had the authority, resources, and time to build: a minimum viable product. We of course aim to nail the initial offering, but it will inevitably be prone to flaws, or lacking in seemingly-obvious functions. That’s why this is just a “Beta”. We’ll be conducting further user testing in the future that will lead to more features and a better experience.

Until then, here are some things to keep in mind:

  • There are many ways a website could be labeled, from pornographic to left-or-right leaning content. What we chose instead was to keep the categories to a helpful minimum. When it comes to news, knowing which websites are most trustworthy is a more positive way to avoid fake news. Everything else, then, should provide only the information a user needs to determine if the content they’re reading is actual, reliable news, or something they should consider more critically.
  • As for websites versus individual webpages, that’s both a technical and user interface problem. For one, it’s nearly impossible to review and score every article or content page out there. There is no automated process for such a thing. This stuff takes serious people power, as only human beings can understand and categorize content with any accuracy. So, there would be mostly nothing to show the user visiting a webpage on a website with low exposure.
  • Then there are the people themselves. Irrespective if the human reviewer is from MetaCert, PolitiFact, or Melissa Zimdars herself, all people will be prone to some form of bias. They are not the arbiters of truth. They’re just humans making decisions. However, each organization has its own criteria (sometime very strict), and we’re confident that the results are as fair/accurate as possible.

INTENDED OUTCOMES

Armed with the information Trusted News provides, we hope users will at least think more critically about the websites they visit. Information—especially news—is often construed with “truth” simply because it’s real content online. But just because somebody writes something we either agree or disagree with with, doesn’t therefore make it true or untrue.

Beyond that, we intend to build a community of users, data providers, and partners to provide a more comprehensive, accurate, and fair product, across more countries and in other languages. We strongly believe that this is a long-term project that will take a lot of work to perfect (knowing fully it will never be “perfect”).

Also, everyone here at eyeo is a fierce advocate of the open web and personal privacy. We seek to bring transparency to the project, while being transparent ourselves, by making our product open-sourced, and data providers accountable. Meanwhile, users should be able to trust that their search history or personally identifiable information is not being collected, stored, or shared with third-party partners for profit. In time, we seek to establish credibility across the web publishing industry, and earn the trust of our users. Until then, the Trusted News Beta extension is a great start.

If you want to participate in this experiment, or provide feedback for future development, download it now on the Chrome Web Store or visit trusted-news.com for more information. We invite anyone who cares about preserving journalistic quality and integrity online to join us.

CREDITS

This project is the result of many people who have contributed to the Trusted News Beta extension one way or another:

Misha Thornburgh, the User Researcher that the developed a test plan, provided the information we needed to make the Beta better before launch, and the who came up with the original idea.

Ann-Lee Chou, the other User Researcher who tested the initial prototype, conducted interviews, and supplied the team with invaluable insights.

Mario König, the Technical Project Manager who worked with everyone involved to keep everything moving forward in perfect synchronization.

Martin Velchevski, the Product Designer who refined the user experience, defined the final interface, and built the front-end.

Tom Woolford and Lisa Bielik, the Content Managers who found all the right words for all the things.

Vasily Kuznetsov, the Lead Developer who took care of everything on the backend, including integrating the MetaCert Protocol database in a way that respected user privacy.

Special thanks to Paul Walsh, CEO of MetaCert/Founder of MetaCert Protocol, and his team. Without their help, commitment, and generosity, we wouldn’t have been able to produce anything meaningful whatsoever.

Transparency vs. Efficiency

You can’t have one without the other if you want the best possible results.

Most of the companies I’ve worked for in the past focused entirely on efficiency. There were clients to please, deadlines to make, and revenue targets to hit. Involving others with additional expertise, proposing and testing solutions, or striving for consensus were never options. The ask was clear: Produce. Now. And for as cheaply as possible.

The result? We always met the deadline, and we always delivered exactly what was requested. But the team responsible for delivering the right stuff at the right time were often miserable. Our bosses got fat bonuses and big promotions while the rest of us only occasionally received a shout out after donating countless nights and weekends to meet their demands.

The thing that bothered me most wasn’t the long hours or lack of recognition. It was the total lack of transparency. In order to make our deadlines and deliver what the client asked for, people at the top made all the important decisions, agreed on numbers and timelines, and then told everyone else what to do. Those who were impacted the most by those decisions were rarely, if ever, included in the process. This of course meant a lot of frustration and hurt feelings. But I could never argue with the final results.

Fast forward to the last 2 years. Now I work at an open sourced product company. We have no clients (just partners). The only deadlines we typically have to deal with are those we set for ourselves. Instead of revenue targets, we have company goals. More importantly, the company culture values inclusion, discussion, and consensus. We’re expected to take our time defining problems and exploring the best possible solutions. The ask is still clear, but completely different than anything I was used to in the past: Aim for perfection. However long it takes.

The result? We never make the deadlines we do set, and we never deliver exactly what was requested. That’s because the teams responsible for delivering things are motivated by perfection, not revenue. We take our time finding out exactly what the problem is we’re trying to solve, exploring potential solutions, and reviewing source code to make sure everything is just right. When we do deliver something, it’s only because dozens of people agreed on it first. It’s rewarding to work at such a transparent, inclusive company because individual involvement is highly valued. But it’s also super frustrating when we can’t seem to do anything without 1,000 hours of discussion.

There has to be a happy medium. Yet to find a “middle way”, it’s critical to first consider the pros and cons of transparency and efficiency, respectively.

The benefits of transparency

There are both philosophical and pragmatic reasons the open source development community, and companies such as the one I work for, value transparency:

  • Involving different people with different areas of expertise leads to a better understanding of the problem you’re trying to solve, and ensures a diversity of quality solutions
  • Encouraging involvement from others naturally builds trust and buy-in
  • Decisions are decentralized, and so individual contributors have more responsibility and feel a deeper sense of ownership
  • No one person is ever the hero; everybody succeeds or fails together
  • Credibility is easier to demonstrate when everything you do is “out there” for the world to see

In and of themselves, all these reasons for transparency seem like things everybody should want — all the time, and without limit. So why don’t more organizations operate completely transparently? Quite simply: Because transparency is expensive.

The costs of transparency

It’s only by working at a company like this one that I’ve come to realize the steep costs associated with a transparent culture. So far I’ve noticed that the more transparent you are:

  • The more complex every decisions becomes
  • The more sensitive people are when any decisions are made without their prior involvement or agreement
  • Thus, the longer everything takes in order to involve all the right people at the right time
  • And therefore the less you can react to outside change

If we didn’t have to worry about making enough money to keep the lights on, or winning over users in a fiercely competitive/hostile market, the costs wouldn’t matter so much. But when a company can’t deliver a better product than its competition — continuously and consistently — it will quickly loose users, credibility, and relevance. These are huge concerns that can’t be ignored.

Bottom line: Total transparency without any regard for efficiency can paralyze a company, and lead to its eventual demise.

The benefits of efficiency

Any organization that depends on ever-increasing revenue understands that by being more efficient:

  • Less resources are consumed
  • Less time is needed to produce/deliver things
  • Costs are minimized
  • Revenue is maximized
  • Results are easy to measure

All these things are extremely attractive to any company wanting to increase its value or strengthen its position in the market, which is why many companies worship efficiency like a religion. Focusing on sheer growth as quickly as possible is why Google, Amazon, Facebook, and Apple dominate industries and rake in billions in annual profit. The human toll of brutal efficiency means very little when there’s so much money at stake.

The costs of efficiency

The supposed key to efficiency is basic: centralized decision-making and limited organic contribution. This is why decisions at the vast majority of companies are made by a few people at the “top”, and everyone else at the “bottom” are expected to comply without opposition (thereby making robots even more attractive). By doing so, the time and effort required to go from Point A to Point B is a clear, measurable, straight line. Nevertheless, efficiency does comes at a steep price, and the ones who pay it are mostly the regular folks doing all of the actual work.

By focusing only on efficiency, the costs will be:

  • Limited understanding of the problem and potential solutions
  • Distrust, rejection, or confusion among those who are responsible for implementing the solution
  • Exclusion of meaningful input from stakeholders, which in turn undermines any sense of person ownership
  • The person “in charge” gets all the credit, while everyone else gets all the blame
  • Lack of overall credibility

If efficiency is not balanced by transparency, an organization is likely to burn through its top talent and loose its competitive edge in the long run.

The solution is not a formula

So what’s the answer then? Should companies instead focus more on transparency and less on efficiency? Is there a decision-tree that determines when one should err on one side or the other?

In my opinion, no. Just like choosing between hard or soft power, the context should always determine the appropriate response:

  • If a decision will affect a lot of people at the company, then more transparency is required. Those affected should be invited to the decision-making process, have plenty of opportunities to provide input, and a safe, constructive format to challenge ideas. Once there’s sufficient buy-in, then the focus should be on efficiency. The faster and smoother a decision everyone makes together is implemented, the more satisfied and committed everyone will feel.
  • If a decision will affect the direction or priorities of a product, transparency means two different things. Thing one: Those who work directly on the product should be involved in the decision. Thing two: Those who do NOT work directly on the product should be informed about the decisions, including the problem, proposed solution, and intended goals. Involving everyone will only lead to paralysis. When it comes to execution, the priority should then shift to efficiency. The team has defined the problem and explored potential solutions. Now get out of their way and test those ideas in the actual market at soon as possible.
  • If a decision will affect only a limited number of people, there’s little need for transparency beyond making others aware of a decision and the intended impact.
  • When exploring new ideas, features, or audiences, the relationship between transparency and efficiency becomes a little fuzzy. Sometimes a broad range of input from very different roles will lead to better outcomes. Other times a limited number of experts is more suitable. It all depends on the scope of the problem one is trying to solve.  The important thing to remember is that discussion/exploration should translate into meaningful action as soon as possible, because the faster you deliver a solution, the faster you can learn and iterate.
  • When there is external pressure or a finite window of opportunity, transparency will ensure that everyone understands what’s at stake. Once everyone is committed, those directly responsible for delivering a solution should not be overly burdened by communicating their decisions in real time. Instead, they should have the freedom to work as they see fit in order to deliver something in time,

While there is no perfect, universal approach to balancing the two, total transparency limits immediate impact, while total efficiency limits long term potential.

Conclusion

Most people naturally gravitate towards one of these two mindsets. Those who believe that everything should always be as transparent as possible don’t care about speed or velocity. They care about perfection. Those who value efficiency above all don’t have much patience for debate or lengthy discussions. They just want results. The former camp lacks urgency. The latter camp stifles potential. One extreme hurts the business. The other extreme hurts people.

So, it’s worthwhile for any company to decentralize decision-making through transparency, while enabling people to get shit done efficiently. When companies keep transparency and efficiency in balance, they can react to change faster, deliver better solutions, and unleash the full potential of their people.

The Case for Soft Power

Forget “command and control” or “rule by committee”. Instead, build coalitions of support. Then show the way forward.

They say that there are two kinds of power. “Hard power” is about rank, authority, and protocol. When somebody relies on hard power to exercise influence, they explicitly demand compliance. It’s brutally efficient, but it can sometimes come at the expense of other people. “Soft power”, on the other hand, is all about motivating others through mutual trust and shared interests. When someone exercises influence by building coalitions of genuine support, they encourage compliance. It’s terribly slow and often painful work, but the benefits (usually) outweigh the effort.

In reality, both are necessary — just not in equal measures.

+++++

All power is a reflection of perspective

I’m reading this book titled Reinventing Organizations. Based on what I’ve gleaned from the first 50 pages, the author’s premise is that any human organization reflects a common perspective on work, people, and values. He argues that these perspectives reflect specific stages of human consciousness. Successive stages of organizational development employ different methods for managing people at scale, and all of them are still operational today.

Each stage is assigned a color. “Red” organizations are purely authoritarian, for example. “Amber” organizations apply a strictly militaristic structure and rely heavily on protocol. Born out of the Industrial Revolution, “orange” organizations primarily seek to operationalize humanity and continuously optimize it for performance. Conversely, “green” organizations are relationship-based and rely on consensus to make decisions. Apparently, there’s now evidence for the emergence of “teal” organizations, which value individual contribution/potential in the pursuit of meaningful work. Or something.

Anyway, the point is that how organizations manage themselves depends on shared mental framework. This framework translates 1:1 with how power is expressed, such as through punishment and fear, rigid hierarchies and protocols, or bonuses and performance-based incentives.

I find this all very interesting, but so far I personally don’t identify with any one color or manifestation of power. If anything, my organizational mental-model would be “gray”. To me, how people, organizations, or cultures behave are just spectrums along a continuum. There are always extremes and infinite grey in between. There’s therefore no such thing as the best or right way exercise power because the “optimal” way to manage people or get shit done depends entirely on the spectrums unique to each organization.

In my case, I work for a German tech company with employees all over the world who work remotely. We’re mission-minded, values-driven, and allergic to hierarchy. According to the author, we’re probably an “orange/green” organization that wants to be “teal”. I just see different monochromatic contrasts and gradients. But so what? What’s more important is that power is exercised appropriately in any context in order to achieve the best possible outcomes.

This is where “hard” and “soft” power come into play. My chief responsibility is to ensure that people are working on the right things at the right times in order to achieve measurable results. Even though I have a designated rank that includes official management responsibilities, relying on hard power alone would be ineffective (and possibly destructive) in this context. When your company culture values transparency, inclusion, and self-determination, you can’t just tell people what to do.

But even if I could, or if I worked in an “amber” organization with 30 different seniority levels, telling people what to do isn’t my style, or, in my experience, generally very effective. Besides, super-smart/values-driven people (like the ones here at eyeo) don’t usually like being told what to do. Furthermore, people tend to do their best work when they’re genuinely engaged and co-own the final outcome. That’s why I rely mostly on soft power.

What does soft power look like?

To be clear, soft power isn’t about asking people to do things. Rather, it’s about inspiring them. There’s a big difference.

When a manager or leader asks somebody to do something, the subordinate or peer first considers their relationship with the manager/leader. In a hierarchical organization, no matter how explicit the “ask”, the “demand” is implied. In organizations that are more egalitarian, “pretty please” is implied. In either case, the other person’s motivation for doing something is solely about the person asking. If they like or respect that person, they’ll probably do the thing. If they don’t, they either won’t do it well, or at all. But even if they do do their job well, chances are the end result will be sufficient (at best), because their only real goal is to complete the work and avoid further pestering. So, asking for things isn’t really an expression of power at all.

Conversely, when a manager or leader inspires somebody to do something, the subordinate or peer primarily considers their potential contribution to solving a problem or maximizing an opportunity. In any type of organization, a truly motivated person will find a way to get something done because they actually care about the outcome. And if they care, the end result will likely exceed expectations. This is the truest expression of soft power.

To inspire people, real leadership is required. The manager/leader must identify a problem or goal, define a clear vision, actively solicit support, and then facilitate/coordinate any contributions needed to complete the task. They must be willing to listen to feedback, answer questions, and broker compromise. They have to constantly translate goodwill into meaningful action. And, most crucially, they direct energy towards a certain destination without prescribing a particular path. A wilting wallflower or passive-aggressive micromanager can’t do any of those things well.

When to use (and not to use) soft power

Obviously, relying on soft power alone is problematic as well. Imagine a life where everything can only get done if you “inspire” them to so. Nothing would get done. Or, at least, nothing you want will get done.

I have a basic rule of thumb I apply when making decisions. It helps me navigate the myriad problems I have to solve every day — everything from approving software requests to resolving interdepartmental conflicts. When is it better to use one’s title and authority, or do the hard work of building support for something?

It’s simple, really:

  • If a decision will affect only myself or another person, use hard power.
  • If a decision will affect lots of other people externally, use soft power to minimize risk, and hard power to maximize potential.
  • If a decision will affect lots of other people internally, definitely use soft power.

In practice, things like approving software requests, conferences, and equipment purchases don’t need “buy in”. I’m doing something for another person’s benefit, and have the explicit authority to make those kinds of decisions. I use hard power in these case.

Now let’s say, as a Product Manager, I want to release a new feature or product. Although my decisions should always be informed by research, the perspective of those with deeper expertise, and the technical requirements necessary to execute those decisions, I’m the one who ultimately owns the roadmap (i.e. the prioritized list of specific tasks the project team is expected to execute). Therefore, I use hard power to decide on individual roadmap items. However, there are always technical, legal, business, or user experience issues that aren’t just complex, but could also hurt our users, the team, and/or the company if we don’t get it right. In these instances, I use soft power to build the trust and willingness needed to take chances, alter course, or hit the “kill” switch.

But if, again as a Product Manager, I want to institute a new process that others will have to adhere to if they want to contribute to the product, doing so unilaterally will probably result in resistance, resentment, or outright circumvention. People always want a “heads up” if something is going to impact their day-to-day life. So if I really want a process to work, I should seek buy-in from all my stakeholders before anything gets instituted. That’s when I use soft power.

How does soft power work?

Saying that soft power is a person’s ability to exert influence by inspiring others is perhaps too lofty. In reality, I think of it a lot like coalition building — which should NOT to be confused with committee building. A coalition is a group of people that share a common vision and are prepared to do something about it. A committee is a group fo people assembled by virtue of position or importance, and who are tasked with making decisions that others will act upon. Obviously, the former will be far more conducive to getting shit done than the latter.

With this in mind, I go about building coalitions of support within the organization based on some straightforward principles:

  • Any coalition is build on trust and mutual interest.
  • Trust is the byproduct of familiarity, consistency, and honesty. There are no shortcuts.
  • Mutual interest is the byproduct of personal understanding, acceptance, and a sincere desire to achieve the same outcome.
  • In order to translate desire into meaningful action, each member must feel empowered to act, believe their contribution will matter, and share ownership over the final result.
  • Meanwhile, every member of a coalition is a peer-volunteer. Their is no chain of command, or an actual requirement to participate.
  • The job of the coalition leader, therefore, is to ensure alignment, develop a plan, and facilitate the process.
  • As such, the end result may not conform to the leader’s personal expectations, and they must be willing to accept that result.

This is why effective leadership is vitally important. The “leader” must lead without telling people what to do. They have to sell a vision, anticipate problems, resolve conflict, broker compromise, and coordinate activities so as to deliver the expected outcome. It’s not easy, and it doesn’t always work.

There have been times when I attempted to build support for something that everyone agreed was a worthwhile goal, but nothing happened. There are times when I’ve met collective resistance, or really upset some folks in the process (in which case, again, nothing happens). There are even times when end result is not at all what I had hoped it would be. But I’ve learned, ironically, that it all still helps to build trust over time because I regularly invite people to participate in things, instead of demanding that they comply with my whims. So, the next time I want to build a coalition, goodwill and cooperation are often much easier to foster.

Final thoughts

In conclusion, hard power should be a lever one pulls rarely and for a specific, limited purpose. Soft power is a tool that should be used whenever the consequences would impact many others. (The bigger the impact, the more soft power is required).

When power is used appropriately the result is trust and credibility. The more trust and credibility there is, the less one needs to pull rank or build support. Many times I don’t have to exercise any power at all. I just need to present the problem, and many times people are naturally to contribute to a solution. Not because I ask them politely, but because they know through previous experience — that I just want to make something better.

Personally, I don’t like thinking in terms of “power” since I believe that, ideally, power should be shared whenever possible. But hard levers and soft tools can sometimes be useful when you want to get shit done, done well, and for the right reasons. Which is really what I care about most.

Learning How to Lead: Part 2

You have to find your way before you can lead the way.

For the past two years I’ve been learning how to build and lead a team. The first year was mostly learning things the hard way: Through trial and error. By now I have plenty of examples of what doesn’t work, and a couple that do. But after groping around in the dark for long enough, some constants have emerged.

While I still fuck something up at least once a week, I’m beginning to understand what any good leader needs to do. These are a few fundamentals I’d like to share with anyone else out there who’s learning how to lead.

+++++

It doesn’t matter if you lead a small team or an entire company. It doesn’t matter what your team or company actually does. It especially doesn’t matter how much education, experience, or charisma you have. Every leader must continually learn how to do the following 7 things well:

  1. Define the vision
  2. Motivate the team
  3. Unblock things
  4. Develop talent
  5. Manage performance
  6. Build strategic relationships
  7. Learn and adapt

 

1. Define the vision

Regardless of the type of leader you are, if you don’t have a clear vision for what you want to accomplish as a team, then you’re just administrating processes. A good administrator can certainly achieve good results. As long as the numbers are all green, your job security remains strong. But if you want to actually influence the future of your team and/or company, that future must be vivid and real in your own mind. Without a guiding star, you can’t point to anything concrete, or properly articulate a vision that others can understand and agree with.

Only then can you do the next most important thing as a leader…

2. Motivate the team

Regular paychecks are reason enough for most people to show up for work. It takes a lot more to extract top performance and provide longterm satisfaction from your team. Their only automatic responsibility is to fulfill their responsibilities. It’s your job to inspire them to higher aspirations and achieve the vision you’ve defined — not through force or punitive measures, but by earning their trust, dedication, and loyalty.

It’s hard work. It takes time and unrelenting patience. And what works now may not work again in the future. The point is that your team shouldn’t be responding to your commands, but following your call to action. If they share your vision and entrust you with their future, your team can achieve basically anything.

3. Unblock things

A motivated team can do many things on their own, but sometimes something or someone stands in their way. Maybe a certain process is fundamentally broken, an important tool is missing, or a specific person is preventing someone on your team from moving forward. Your chief responsibility is to identify those obstacles and remove them. Just by changing a process, approving new software, or moderating a much-needed meeting, you can turn a frustrated, demotivated team member into a positive, motivated change agent.

Occasionally, the obstacle can be internal. Everyone has a bad day, a bad week, or a bad year. Otherwise exceptional people may struggle to delver exceptional results because of personal issues, emotional conflict, or virulent self-doubt. A good leader recognizes when a team member is struggling personally, and then reaches out with empathy and acceptance. Although it’s ultimately up to the individual to move forward, sometimes all they need is to know that someone else is there to support them in the process.

Whether external or internal, your ability to effectively unblock things preventing your team’s success is the “secret sauce” that will unleash their potential.

4. Develop talent

Everyone on your team has the potential to improve their existing skills or develop entirely new ones. But if you don’t take an active role in developing talent, low performers will never grow and top performers will plateau. An effective leader recognizes the weaknesses and potential of each and every team member, and then provides the necessary opportunities, guidance, and/or encouragement for them to improve.

It starts with assessing skills. Most people are really good at a few things, proficient at many things, and terrible at couple other things. For example, a designer might be superstar at creating beautiful interfaces, and competent at defining the overall user experience and interactive elements — but then totally suck at communicating their rationale to the rest of the team. In order for such a person to reach their potential, they must learn how to present their ideas and resolve disagreements constructively. Otherwise they’ll struggle to advance their career or add more value to the team/company (which inevitably leads to a role vacancy). Therefore, a good leader will help that designer develop their presentation skills through coaching and practice.

Those who are really good at many things, and reasonably good at everything else, need your help to progress to the next level in their career. If you’re confident that they can execute all their current responsibilities expertly, then you should be giving them opportunities to do completely new/different things outside the scope of their designated role. By inviting them to participate in other activities in a leadership capacity, or as a key advisor in initiatives important to the overall company, they will continue to grow as individuals and become more committed, valuable team members in the process. Because let’s face it: keeping the exceptionally talented is one of your top priorities. If you fail to challenge them, they will eventually leave (usually at the worst possible time and for totally avoidable reasons).

In the end, you should expect everyone on your team to leave one day. The difference is that they should do so because they’re fully prepared for the next challenge or phase in their career — not because their talent was undervalued or outright ignored.

5. Manage performance

Raw ability is meaningless if you can’t measure its effect or value. Each and every person on your team should know exactly what they’re being held accountable for. The company’s goals and your team’s outputs must be quantifiable (or at least qualifiable) to translate them into meaningful performance. Without results you can measure, you can’t fix what’s broken, celebrate any real “success”, or have true accountability.

Once you have explicit measurements, you can focus on what’s important and minimize the risks. You can align motivations and extract more value from every contributor. More importantly, you can create a fairer, more transparent environment for all. If you harness a collective desire to exceed expectations —while unleashing their potential — your team will overdeliver no matter what the expectations are.

6. Build strategic relationships

Power structures exist within any group, team, or company. Sometimes they can interfere with your personal goals or your team’s work. Other times they can provide strategic opportunities to effect positive change elsewhere. Every leader should always know which power structures need to be nurtured, repaired, or cultivated.

Bad leaders only tend to strategic relationships in order to build their own reputation or career. But good leaders tend to them for the good of the company and/or the team. They spend the time necessary to meet with existing and potential stakeholders to establish trust, find common ground, and build a coalition of support. They do this because they know that without sufficient support, their team cannot ultimately succeed. And the very best ones do this preemptively, well before they ever need any actual support.

7. Learn and adapt

The one skill that allows any developing leader to become a great one is the ability to learn form one’s mistakes and try a new approach. If you suck at any of the things listed above, the worst thing you can do is ignore them. Doing that will either destroy you or your team (or both). Being a tenacious student of failure is the figurative key to your literal success.

If you need training, sign up for a class. If you need guidance, find a mentor. If you need help, don’t be afraid to ask for it. For as long as you’re improving, you will only get better, stronger, and more confident over time. Insecurity will only stunt your development and eventually sink your ship.

+++++

Personally, I suck at many things. I often have difficulty communicating a strong vision, struggle to motivate the team, or fail to build the right relationships with the right people at the right time. Sometimes I try to unblock something, but just end up making everything worse. And developing talent or managing performance often requires more “tough love” than I’m inclined to provide.

At least now I can finally see what I need to work on with more clarity, even if I don’t quite yet know exactly how to.

Departments vs. Project Teams

Structure should begin with motivation. Not the other way around.

I recently wrote about the challenges a start-up company faces when it grows into a mature, medium sized business. Yet there’s one topic of debate within the company I work for that particularly frustrates me: Structure.

How an organization coordinates its activities and organizes itself sounds like a horribly mundane topic. It is. But that’s not why it’s frustrating. The biases for and against certain ideas, principles or frameworks are what drive me bat-shit crazy because they often get in the way of making actual improvements. Or they just make things worse. Either way, it’s a major problem when performing any work begins with structure. And since I manage a group of people that depends on almost everyone else in the company to get shit done, structure really, really matters to me personally.

Even after a year of trying to evolve the company structure into something that supports our growing organization more effectively, we don’t talk much about specific processes or workflows. We still argue mostly about the differences between departments and project teams, and how they can best serve an organization like ours. It’s like we’re stuck in an existential loop talking about David and Goliath. To summarize the popular beliefs expressed in these countless discussions: Departments are inherently bad, and project teams are inherently good. Therefore, we must minimize the importance of departments and focus on making project teams succeed. Perhaps, in the not-so-distant future, project teams will replace departments altogether and our utopian dream of the ultimate workplace will finally be realized.

Although I understand the sentiment, I vehemently disagree with that assessment.

Some background

In the early days at eyeo there was no structure — just a dozen or so people doing the work of 50. Departments and teams weren’t necessary, and would only have consisted of single individuals anyway. But by the time we were 50 people, de-facto departments had already begun to emerge as a byproduct of natural self-organization. At around 80 people, those departments were determining processes and workflows that defined our culture and how we worked. As a result, we had suddenly become a big, slow beast that was easily paralyzed by major decisions. That’s not a good thing when opportunities are scarce and competition is abundant.

blog_post_image2

Illustration 1: Departments – In the beginning there were just departments, some of which were explicit, others implicit. Projects were always ad-hoc, and work was driven primarily by the executives.

Thus we set up a task force to analyze the current structure and operational patterns. Our mandate was to come up with a better way of organizing ourselves and working together under increasing external pressures. Our goals were to improve efficiency and increase speed overall, while preserving the fundamental values that make eyeo a unique, fulfilling place to work. In other words, a small group of people were tasked with engineering a solution to a huge, complex problem that would affect everyone in the company. (No pressure!)

The real problem, many believed, were the departments themselves. Departments — especially traditional ones — are typically large, include only certain types of people, and represent the most basic, obvious way to organize a bunch of people. They are the opposite of “agile”. They often establish self-serving processes that get in the way of everyone else. And, worst of all, they are by nature exclusive (which, ironically, automatically makes them mutually dependent on one another). When thought of in these terms, departments are like giant ships on a canal that need a long time and lots of space to properly coordinate so that they’re all going in the same direction… And if just one ship wrecks, the whole fleet can go down with it. That’s a lot of risk, and tremendous overhead, to manage.

The solution, the same “many” believed, were project teams. Smaller units of people that worked on a particular thing until that thing got done were easier to manage and maintain. They could focus like a laser on limited, specific goals. They wouldn’t be so dependent on other teams if every role required was already a dedicated resource. Most importantly, they would be free to work however they wanted if they didn’t have to worry so much about external processes.

By creating project teams that could get day-to-day work done more quickly and independently, departments would then only be responsible for two things:

  • Hiring the right people
  • Keeping those people happy

Everyone would still have a “meta-group” they could identify with on a general level, but their contribution would have a more direct, immediate impact on project teams.

It all sounded really good at the time, even to me.

What happened?

Early on we decided that all project teams should share some characteristics. For example, every team should be:

  • Small (no more than 2 pizzas should feed an entire team)
  • Autonomous (there should be few, if any, external dependencies)
  • Self-organizing (teams should decide what they work on and how they get work done)
  • Cross-functional (teams should include roles from across departments and include a variety of specialized roles)
  • Flexible (most teams will have people that are dedicated all the time, and members who contribute only when needed)

Based on this criteria, our knowledge of all existing work streams at the time, and months of extensive interviews with individual employees, we proceeded to carve up the company into over 30 individual project teams (with no more than 12 people each) in addition to the 9 departments we had explicitly identified. Then we rolled out the new structure to the organization with an announcement and corresponding manifesto. We had kickoffs with each team, and gave some general guidance. By the summertime, everyone was supposed to be working within their project teams in earnest.

blog_post_image3

Illustration 2: Departments & Project Teams – We kept the departments in place, but made them all explicit. Then we added project teams to drive all the work. People from each department are either dedicated members, or occasional contributors. How work gets done is determined by the individual project teams.

So we were really surprised when things didn’t go very well. Sure, we thought, some tweaks and coaching would be necessary. But with time, we anticipated that project teams would naturally replace traditional departments and workflows, resulting in efficiency and increased “velocity”. In actual application, though, many teams were confused about what they were supposed to actually do and/or failed to make much progress on anything substantial. A few did in fact work great out of the box, but that was mostly because they were working like that before any teams were formally announced. For the most part, the majority of teams struggled to function as intended, and couldn’t resolve their issues on their own. Even after 6 months of trying, it’s obvious that something isn’t “clicking”.

As a consequence, departments have since become even more entrenched than they were to begin with. This should not have been surprising. When goals aren’t clear, processes are undefined, and help is hard to come by, people often retreat to the one group they can relate to, rely on, and get help from: their peers. And where do all their immediate peers “live” in a professional environment? Departments.

Now the debate between between departments versus project teams has resurfaced. Only this time we can’t just hope that departments will eventually go away. We have to face entrenched issues that are not easily solved by a reorganization exercise.

What was the perceived problem?

After copious reflection, I’ve come to the conclusion that we didn’t understand the actual problem we were trying to solve, and then prescribed solutions based on ideology.

We thought the problem was the structure itself. The original structure was getting in our way and slowing us down. Thus, we assumed that by arranging the parts differently, people would start to work more efficiently/effectively naturally. We approached the whole situation like a mechanic approaches tuning a car. Replace all the slow parts with lighter, faster, more powerful ones. Boom. Now you’ve got a track vehicle. Just get in and drive.

But organizations aren’t inanimate objects made up of parts. They’re living, breathing organisms made up of complex, fickle humans. You can’t just arrange them a certain way and expect better results. In the case of a company, structure is a function of its humanity, not the variable that defines it. You first have to deal with the things that make humans human. Otherwise you just end up making everyone miserable.

And that’s where we failed.

What was the actual problem?

It wasn’t until after things started going pear shaped that I remember a course I once took in psychology (shortly before dropping out of college). I had learned about Maslow’s hierarchy of needs. Whether wholly or partially true for every person, I always thought it was a simple way to figure out what drives people.

I fully believe that at the most basic level, our personalities, activities, and personal choices are all driven by one thing: Motivation. We’re not humans because we have big brains and opposable thumbs. We’re humans because of our innate, internal desires. Everything else is an outward expression of those desires. Maslow simply arranged them into a pyramid according to relative priority.

Considering that every employee at our company has their basic needs met, and a safe place to live (presumably), belonging within the company in general is thus the basis we should start from in terms of structure. We all want to belong. It’s the foundational requirement for a happy, healthy, productive company culture. Until we truly believe we belong, however, we’ll always be seeking to prove ourselves as worthy, or find ways to avoid rejection. Neither of these motivations serve a company very well in the long run, since they are essentially self-preservation instead of the long-term success of the organization.

Only once we feel like we belong can we start being our true selves. This is the basis for Maslow’s fourth layer of the pyramid: Esteem. Having “self esteem” is another way of saying that we recognize our value or contribution to something bigger than ourselves. It’s achieved only through applied, consistent actions that yield demonstrable success. We gain self-esteem from positive experiences, and garner the esteem of others by being reliable and trustworthy.

The very top of the pyramid, self actualization, is something much deeper and more complex. If all our other needs are met, we believe that we belong and that our work makes a difference, then our motivations start to become a lot less about us fitting in and more about our long-term purpose. Or, to put it another way, that’s when we start caring about our legacy. Who we really are, as individuals, matters most when there are no other external deficiencies to drive our motivations. Then we can ask ourselves, “when I’ve done and said all that I can, what actual value will remain?”

Bringing it all back to the discussion of company organization, departments, and project teams, the problems we faced were never really about structure. They were about motivation. People want to feel like they belonged and make a difference, not an org chart and manifesto. They want to be able to trust their coworkers and be trusted in return, not enforce trust through specific process and procedures. Above all, they want to know that they’re truly valuable.

In prescribing a solution based on ideological principles, we ignored the human motivations any good structure should actually support and focused too much on logic and “measurable results”.

What were the lessons learned?

Applying Maslow’s hierarchy of needs to how things worked out in reality, I now see the requirements we came up with for project teams in a different light.

Absolute size doesn’t matter

The requirement that all teams should be small was purely arbitrary, and stemmed from an ideological point of view that “smaller is always better”. However, the “right size” for any group of people trying to get something done is entirely relative. If we’re talking about a collection of close friends who are trying to arrange a dinner party, then sure, there’s an absolute maximum number. But we’re not talking about that. We’re talking about professionals who are trying to build software products. Sometimes it takes a lot of people to accomplish just one thing. And that should be okay. By forcing a requirement to keep teams small, we ended up with too many small teams who can’t get shit done by themselves.

At the end of the day, what actually matters is not size, but a common purpose… which is all about belonging.

Autonomy is relative

The biggest problem we recognized with the old structure was the labyrinth of dependencies needed to ship something. Somebody owned the goal or vision. Others owned the visual design, content, or user experience. Someone had to build it, yet another had make sure it was built correctly, and still another person had to develop the communications plan. So how do you assemble all those necessary parts into a small team that doesn’t rely on other people or teams to deliver results? (The answer: You can’t — at least not all the time.)

Dependencies are not in themselves a “problem”. The real issue is whether or not the dependent parties trust one another, and value one another’s contribution… which is all about esteem.

Self-organization is a soft principle without a hard application

Okay, so as a project team you are expected to define how you will work together, what tools you’ll use, and the priorities of things you want to work on. But how do you know if your workflow will work for everyone else in the company? Will your processes or infrastructure be compatible with those from other teams? Are your priorities aligned with the company’s larger goals or other important projects you’re not responsible for? What if you have a big disagreement and nobody is the obvious decision-maker? Suddenly “self-organizing” seems like a fragile principle that falls apart the moment you apply it.

But so what? Most people don’t really want to make all their own decisions, even if they could. (And those who do/can rarely make the best decisions all the time). Rather, they just need to know if they’re making the right decisions, in the right context, and have the full support of the rest of the organization. In retrospect, the problem we were trying to fix had nothing to do with raw power or explicit authority, but had everything to do with a sense of belonging and shared esteem.

Cross-functionality in not a problem that needs to be solved

It’s almost weird to include cross-functionality as a requirement. Of course any team performing complex work will include various specialists. If you want to build and launch a massive product update, you’ll need designers, developers, content and translation managers, quality assurance people, legal experts, and marketing/communication folks (at a minimum). Specifying that a bunch of different roles should be a part of any project team is therefore not helping anything. It’s stating the obvious.

What isn’t obvious, however, is how to ensure all those cross-functional people work on the right things, recognize when to bring in other contributors to achieve success, or ultimately reach their full potential. Only the self-actualized team can do all those things successfully.

Flexibility is an illusion

Our original thinking was that there would be a bunch of people who would be dedicated to ongoing project work, while a few others would only contribute as needed. Our intention was make sure each team had enough resources to perform their work without hogging all the resources (especially in cases when only a few people contributed to a bunch of different project teams, like content creators). In practice, however, dedicated members were always waiting on those ad-hoc resources to get shit done. And the ad-hoc resources never knew exactly what was going on and/or were rarely included in important decisions. Basically, we learned that there isn’t such a thing as an “occasional contributor”. Everyone should be considered a dedicated resource.

Why is this important? Because the most basic need a employee has is to belong. If they’re temporary, or only needed once in a while, then they aren’t actually a part of the core team… so they don’t belong. And if they’re not included in important decisions, or invited to recurring meetings, their self esteem erodes while their value to the rest of the team is questioned.

As for departments…

Departments have a bad reputation because they can often be bloated, slow, procedural, and bureaucratic. Yet the one hugely important characteristic they all share is that departments are permanent. Permanent things are stable things. And when humans get frustrated or feel insecure they tend to seek refuge in the most stable things they can find. So, on a primal level, departments are “entrenched” within our professional psyche because they are stable, and therefore predictable. Stability and predictability are foundational to one’s sense of belonging.

This is in direct opposition to the idea of project teams. Projects are temporary because they have a clear end. A team that does nothing but temporary work may feel a sense of accomplishment, but not necessarily a sense of belonging and meaning. For example, let’s say that there are 3 teams dedicated to a major product, but then the company decides that the product is no longer worth the investment. What happens to all the people who were on those project teams? They will all have to be absorbed somehow, or else fired. Neither outcome is especially appealing to somebody who just wants to know they have a permanent role in a company that values them.

And by the way, when defined and managed correctly, departments have far more value than just hiring and keeping people. For many folks, they are like an extended family who depends on one another for advice, comfort, and validation.

What’s the solution?

To be honest, I have few concrete solutions. What I do have is a deep sense that our current solution was fundamentally flawed to begin with. We should have first started with the motivations that drive people at our particular company, and then defined structures that supported those motivations while facilitating the collaboration necessary to produce consistent, meaningful outcomes. Some work is temporary. Some of it’s never-ending. But the people who do the work should always be regarded as permanent assets.

If I were to go back in time, and had total control over how the task force approached our mandate, I would start by redefining the permanent structures of the company according to shared motivations. Leaving aside the negative connotations, I’m perfectly comfortable calling these permanent structures “departments”. What I care more about is how departments are defined so that they cultivate a sense of belonging. A few ways come to mind:

  • by areas of expertise (product, development, legal, etc.)
  • by strategic focus (communications, delivery, operations, etc.)
  • by product platforms (desktop, mobile, services, websites, etc.)
  • or by geographic locations (Cologne, Berlin, North America, etc.)

Any way would have advantages or disadvantages. The important thing is that the majority of people genuinely feel they belong in their department.

blog_post_image4

Illustration 3: Departments & Functional Teams – Maybe a better approach would be to establish departments according to product platform, and then form teams based on functional roles. All work would be driven by the departments, but teams of like-minded people would determine how work gets done for each individual work-stream within a given project. Projects and products can come and go, yet everyone would still have clear goals and a permanent place where they “belong” since the platforms and functional roles would never change.

Then I’d figure out a way to facilitate both short-term and long-term work within those departments. Again, I would start with some basic motivations. Any work a dedicated group of people perform can be a few things:

  • transparent
  • fast
  • effective

Now pick two. No, seriously.

A very transparent department can be a highly effective one as well… but transparency is overhead, and so everything will take longer. Or else a department can be extremely fast and effective… but decisions will have to be made by a limited number with minimal debate (or documentation). A department can even be transparent and fast… but they’ll likely never go very “deep” when solving problems, and therefore will be less effective. Which might be okay if you can make small, iterative improvements that makes a big difference over time.

The real question is: Which of those two attributes do you value most? Only then can you possibly derive the best processes, platforms, and protocols to reinforce those values. Also keep in mind that the two most appropriate attributes might be different for each department.

Conclusion

To summarize, a company’s structure and its processes are extremely complex issues. When defined and implemented well, people will feel like they belong and can make a difference. When defined or implemented poorly, people will become unmotivated and unhappy. So, start with what motivates your people. Until you truly understand those motivations, any structure or process is going to feel arbitrary and prove ineffective.

What the EFF Doesn’t Understand

A few choice words for the Electronic Frontier Foundation

This post is personal, and from the perspective of somebody who works at a company that was mentioned in the news. The views stated here are my own and do not represent the official views of company. Any inaccuracies are unintentional and my fault alone.

+++++

The company I work for, eyeo GmbH, recently released a version of Adblock Plus for Firefox on desktop. The update includes a new Settings Page which provides a variety of options that users can enable or disable with a single click. One of those options, Acceptable Ads, is on by default, and includes a new feature allowing users to opt-out of Acceptable Ads with tracking, specifically.

In response, the EFF wrote a couple of articles that were aimed squarely at eyeo, Adblock Plus, and this particular attribute of the product. One article is a critique of the new update, including their particular issues with our product itself, our policies, and the company in general. The other article provides step-by-step instructions for disabling Acceptable Ads with third-party tracking.

The TL;DR version of both articles boils down to the following:

  • The old product was flawed
  • With the new product, users are still exposed to security and privacy risks
  • Acceptable Ads should be an opt-in feature, not opt-out
  • Acceptable Ads without tracking should be enabled by default for users that have tracking protection enabled
  • Because eyeo is a commercial entity, its motives, business practices, and criteria for Acceptable Ads are suspect
  • Acceptable Ads are just a shady scheme to make more money anyway
  • By the way, here is some advice for fixing all these various problems…

As an outsider reading those articles, I would probably think that eyeo is a shitty, evil, greedy company. Thank goodness the EFF came to the rescue on behalf of users everywhere and sounded the alarm!

But I’m not an outsider. I’m very much an insider. Which is why I wanted to share my own assessment of the situation.

Context is everything

What those articles omitted was that eyeo attempted to collaborate with the EFF on the new Settings Page way before it was ever released. It began a long time ago with an email from them pointing out a particular conflict regarding tracking protection and Acceptable Ads. I personally set up a few of our initial meetings to discuss their issues and to share with them our plans for the next release — including the new Settings Page. We then responded to their feedback as much as we could at that time, and showed them our revisions. They still did not approve, and weren’t especially interested in further involvement.

We even invited them to join the Acceptable Ads Committee, which is a completely independent, non-profit organization that represents users, publishers, advertisers, technology companies, and user rights advocates who are entirely responsible for the Acceptable Ads criteria. In fact, we thought the EFF was the perfect organization to advocate for user rights online, and knew full well that privacy was of utmost importance to them. By having a seat on the Acceptable Ads Committee, they would have had an opportunity to evangelize important issues with the very people who matter most to the future of advertising on the web. Unfortunately, they declined.

Then, suddenly after we launch the new ABP and Settings Page for Firefox, the EFF shares their opinion with the world — quite starkly, and with heaping mounds of moral superiority.

My theory: They couldn’t get their way, on their terms, or according to their preferred schedule. So instead the EFF decided to pressure eyeo into doing what they want by making us a public spectacle (and maybe even instigate a user boycott in the process to make it really sting).

Regardless of their intentions, the EFF is of course free to make any critique they want of us, or anyone else. We always have, and always will, applaud their commitment to user rights online and dedication to privacy, security, and better business practice issues. I don’t fault them expressing their views. But I do take issue with the implications they made in doing so.

History is everything

About those Acceptable Ads...

Before Adblock Plus and other ad blockers existed, there was basically one way publishers could earn money for the content they produced: advertising. More importantly, completely new industries were built around the technologies that delivered those ads automagically, in real time, and without human intervention. When Adblock Plus and others started getting really popular, therefore, publishers were getting hammered, and they had absolutely no control over the situation.

That’s precisely the reason why the founders of eyeo created “Acceptable Ads” in the first place: so publishers could still earn revenue for the free content they provide to users who have an ad blocker installed. Most users didn’t seem to mind seeing some simple, nonintrusive ads (if they noticed at all). It was a good, albeit small step forward for the web publishing industry that allowed users to continue consuming content for free. Over time, the company has gone to extraordinary lengths to create fair, user-centered standards that publishers and advertisers can implement easily on their websites.

Still, eyeo has always gotten a lot of flak for Acceptable Ads, whether it’s about our motives, our policies, the money we earn, or the Acceptable Ads Committee. Still, after years of calling us dirty names, the IAB eventually teamed up with industry giants to form the Better Ads Coalition. And now, the entire online publishing and advertising community is suddenly concerned and very serious about ad quality. Dare I say that Acceptable Ads have instead had an overall positive effect on the entire web, even if they are far from perfect?

About that Acceptable Ads Committee…

The original criteria were indeed determined by eyeo, but based on actual user research. Once we began offering a whitelisting service to partners, we quickly realized that credibility and fairness were of chief concern to everyone. The Acceptable Ads Committee was therefore formed earlier this year to take over all responsibility for the criteria as an independent body of representatives from across the web community. eyeo no longer has any say, and doesn’t even have a seat on the committee.

The EFF could have had a seat at the table. They turned it down. And now they question Acceptable Ads on principle. But wouldn’t users have benefited more from EFF’s influence on a committee made up of important/influential people, than from a scary blog post about eyeo? Just sayin’.

About the new option on the Settings Page…

Once we learned about the issues EFF had with the original implementation of Acceptable Ads and its conflict with tracking protection, we immediately started working on solving the issue. We had a number of challenges and limitations to deal with. For one, we wanted to make it clear to users what Acceptable Ads are, and what their options were on Adblock Plus. We also had to respect our partners, who rely on Acceptable Ads to generate revenue for the free content they publish. If we made Acceptable Ads an opt-in feature, many users would never try the product with Acceptable Ads enabled in the first place, and thus would deprive publishers even more revenue. By making it an opt-out feature, publishers stand a better chance at earning money through noninvasive ads while still giving users the choice to participate. Furthermore, ads without any tracking are less relevant and therefore less effective, which means fewer users will respond. And if users aren’t clicking ads because they aren’t relevant, advertisers aren’t making any money… which means publishers aren’t making any money… which means the whole notion of “free” content is in peril. Again. That’s why Acceptable Ads without tracking are a secondary option.

Is our solution perfect? Absolutely not. Would I personally rather that Acceptable Ads were an opt-in feature on Adblock Plus? Absolutely. Would I prefer that online advertising didn’t require tracking to work effectively? Most definitely. Maybe one day those things will be true. But the world we live and work in is complex and imperfect. Gigantic problems like improving the online advertising industry take a really long time to solve, and require a lot of hard work along the way. Our primary goal with this latest update was to at least make the options explicit, and to make it as easy as possible to configure the product without have a huge, negative impact on the publishers who make the web a place worth visiting. On that metric, the new Settings Page is a huge improvement.

The Settings Page will continue to evolve over time, and we’re committed to making it better, more transparent, and more fair. However, it will require willingness and cooperation with the very publishers and advertisers who are critical to keeping content on the web free for everyone.

About the company…

Yes, eyeo is a for-profit, commercial enterprise. We charge partners with massive volumes a fee for participating in Acceptable Ads. And I, personally, make absolutely no apology for it.

Our core mission is to provide users more choices over the content they consume on the web, while offering publishers and advertisers ways to fund the content they provide. We can do that most effectively, and on a scale that matters, by being a company.

The web economy is just like any other capitalistic system: money matters. If we were to become a non-profit that developed nothing but pure ad blockers with every privacy feature imaginable built in, we would gain loads of credibility with users and organizations like the EFF… but such products don’t generate large user bases, and without a substantial user base we would have very limited relevance with companies and industry leaders. As a non-profit, we would have a limited number of supporters, and equally limited influence on the industry as a whole. But as a company that serves users and partners in major markets or industries — with real money and longterm sustainability of huge businesses at stake — we’re in the best possible position to influence all the players at once, and in a positive way.

Also, nearly all of the money eyeo makes is invested back into the company. Just six years ago, eyeo was a 3-person startup without an office or even chairs to sit in. Today, the company employs 112 people worldwide, and offers a suite of products that collectively offer users, publishers, and advertisers a better experience online. eyeo also has two offices to facilitate all the work that happens, outfitted with all the equipment and systems needed to collaborate and communicate. Meanwhile, we’ve managed to become profitable and sustainable. I’m super proud of all these facts.

Finally, about all the people who work at eyeo. We’re mostly a bunch of nerds who care about the internet. We were founded on open-source principles. Privacy and security are so central to everything we do that sometimes it feels like we get nothing done. We barely know anything about our users, and any data we collect is only with their explicit permission. We even fight over whether or not our internal processes are transparent enough (let alone our external ones). In other words, we care deeply and passionately about everything we do, and strive to build the best possible product solutions for all stakeholders (not just one group in particular).

In conclusion, I fail to see how being a for-profit company somehow makes us untrustworthy or corrupt by default in any way. Our actions will determine that. And so far, I see a company that’s in it for the long game, and genuinely wants to make a positive difference.

So when the EFF claims to see “dark patterns” in eyeo or its practices, I call “bullshit”.

Values are everything…

At the end of the day, the only big difference between the EFF and eyeo is our ideology. Our values, however, are essentially the same. We believe in an open web that’s free and fair to all. We think existential threats to privacy and security must be addressed. Whenever we show up to court, we frame our arguments in terms of user rights, and in doing so have won major victories that protected those rights for users in Germany and other European Union nations. Above all, we believe in truth, transparency, and accountability. So instead of pressuring us to comply with their point of view, I would rather they continue to work with us, and others like us, in a more positive way.

Until then, I can only hope the EFF doesn’t give up any more opportunities to contribute directly to the sustainability of the web in the name of “principles” or reluctance to work with “evil” companies. That approach is the opposite of effective or positive.

At eyeo, that’s what we want to be most of all: Effective and for the greater good. This is what the EFF doesn’t seem to understand.

Mo’ People, Mo’ Problems

Growing a small company into a medium-sized company is a lot harder than it sounds.

Over my career I’ve worked at both small companies (with less than 50 people in a single office), and huge companies (with multiple offices and more than 10,000 people worldwide). Both have their pros and cons, as well as their particular frustrations. But before starting at eyeo, I had never worked at a company making the transition from small, intimate start-up, to a grownup, medium-sized business. When I first joined in February of 2016, we were just 40 people. Today, there are 112 of us. That’s nearly 3x growth in less than 2 years.

Now I know first hand just how painful such a transition can be. Recently I’ve been reflecting on my recent experience to unearth lessons worth remembering. Here are some things that stand out.

+++++

With 40 people, direct, organic communication is critical. With 100 or more, direct, organic communication is problematic.

The most striking change I’ve noticed over the last two years is how people communicate. In the beginning, everyone knew everyone else and who was working on what. Individuals could operate mostly in seclusion. Every employee had regular check-ins with the CEO or CTO. All of us could easily fit into one big room each week to talk about our projects. If something wasn’t working, it was obvious who needed to get involved. In this environment, communication was mostly between individual people on an as-needed basis.

But as we grew, organic communication began to break down. More people meant more complexity and variety, making it more difficult to know who was responsible for what. And after a certain number, large groups naturally split into smaller sub-groups. These groups naturally introduced even more dependencies and increased complexity. At some point, direct communication became the least effective way of getting shit done.

In response to these issues, we defined departments and project teams, retooled (or created) processes, and even retooled our tools. The entire company was essentially rearchitected in a matter of months, and we’re just now learning whether or not these changes actually make things better (or worse). However, a few things have become clear already.

  1. Communication works best when it’s intentional, inclusive, and consistent. It doesn’t work so well when people neglect/ignore processes or other stakeholders.
  2. Good processes facilitate communication and lead to a final result. Bad processes cause communication breakdowns and lead to endless debate, which results in inaction.
  3. The more people involved, how you communicate matters just as much as (if not more than) what you’re trying to communicate.

We’re still learning how to facilitate collaboration between different people and teams and departments. Change is sometimes very difficult, slow, and/or painful. But coming up with potential solutions, testing them, and applying the learnings is the only sure way to improve.

Culture is something that naturally develops own its own. A culture that attracts and retains talent is something you must cultivate.

A culture initially forms whenever there are 3 or more people, and is mostly self-sustaining up to about 50 people. In a company, the founders and first-hires define their core values as a natural byproduct of working closely together on a lot of different things. Closeness and common cause translate quickly into the “way” things are done.

eyeo is no exception. When it was founded in 2011, the company had one product, no real competition, and a rapidly growing user base. Anyone who worked at the company in the early days had get involved in a lot of different projects outside the scope of their core competencies. They sat together in a cramped office for long hours, made decisions as a group, and relied on their instincts. They were passionate about open source development, user privacy, and technical excellence. Success or failure meant the difference between keeping the lights on for another month, or hunting for a new job. Thus, the culture that emerged was felt intimately by everyone, simply because they did everything together and shared the same, basic values. This culture continued to extend and evolve as more people with more skills were added. Even when I joined as employee number 39, the there was still a distinct, cohesive identity.

But then something started to happen around 60-80 people. More newbies questioning how things work or why they are the way they are invariably put pressure on the incumbent culture. Values that were once self-evident were forgotten or challenged, or else they became major pain points that got in the way of delivering results.

For example, one of the foundational values inherent in the initial eyeo culture was self-determination and a flat hierarchy. When you don’t have enough people to work on all the things well, everybody works on everything until it’s good enough. As long as shit gets done, nobody is going to question your authority, methodology, or decision-making process. So, it’s easy to just “take control” of something. When there are multiple specialists working on multiple projects, however, and those projects are dependent on lot of other people, “ownership” gets real fuzzy real fast. Authority, methodology, and decision-making gets questioned more and more often. Our self-determination and flat hierarchy eventually became a constant hindrance, to the point where things weren’t getting done because nobody knew (or agreed on) who was in charge to begin with. Today, we’re working through these issues and are making progress, but we still have a long way to go.

Another implicit, original value was user privacy. Our primary product was so “privacy-centric” that we didn’t know anything about our users. In fact, we were really proud of this lack of information. After all, there can be no privacy issues if no user data is collected in the first place. Yet this quickly became an issue right around the time I joined the company. As a product manager, how was I supposed to propose new features, improve the core user experience, or measure the effectiveness of any particular solution? How was I going to evolve our products into things that served all users, and not just the “techie” crowd? Now we have 4 product managers, 4 designers, and a bunch of marketing and communications folks. Suddenly, not knowing anything about our users on principle has become a liability. As a result, we’re constantly challenging the idea that “no data is a good thing”, and are working to find ways to collect the data we need to make product decisions in a way the protects our users’ identities.

That core culture is still a part of us today, but we’re trying to find a better balance between idealism and pragmatism. Time will only tell how successful we are. So far I’ve learned that:

  1. A culture that continues to define itself by accident eventually becomes unhealthy.
  2. The values that attract new employees are sometimes very different than those that retain existing talent.
  3. Ideals are implicit only until they’re challenged; whereas values are challenged only when they’re not properly defined.
  4. In the beginning, the most important duty of the executive team is to hire the right people. Once the company has grown beyond their capacity to manage every single person, then their primary duty is to define and cultivate the right culture.

I suspect that cultivating the ideal culture will continue to be our biggest challenge in the coming years.

As you grow, “us” vs. “them” will mean different things.

With a few dozen or less individuals, everyone at a company thinks of themselves as part of “us” vs. a larger competitor, industry, or system (“them” in the abstract). When everyone knows and works with one another personally, everyone’s ass is on the line. If one person fucks something up, the whole ship can come down. Conversely, when any one person succeeds, that sense of success is shared by all so that it’s always really the entire company that’s winning.

This was true of the company I work for now as well. Whenever our user numbers spiked or we won a legal battle, everyone felt like they directly or indirectly contributed to each success. If there were any internal struggles, they were almost always between individual people. And when we were getting pummeled in the press, it stung the whole organization, not just the guy in charge of public relations.

Then we started to grow from a few dozen individuals to a complex organization comprised of departments, project teams, and management layers. As more people were added, the fewer “originals” there were to share a sense of collective identify with. Instead, people began identifying with smaller groups within the larger group, be it their department or project team. These subgroups started thinking of themselves as “us” vs. other subgroups (“them” in local terms).

Consequently, problems were mostly felt as a struggle between subgroups, and less like existential threats to the whole organization. If something wasn’t working, it was no longer because Competitor A was outsmarting us—it was because Department Y couldn’t get its shit together. Tensions that mounted between individuals quickly metastasized into ongoing skirmishes between departments or teams, eventually becoming a full blown “problem” that was slowing us down.

Through these challenges I’ve discovered that the “us” vs. “them” mentality boils down to several things:

  1. Just as one cannot un-break a coffee mug, neither can a growing company un-change.
  2. Any change is stressful, and under stress individuals will invariably gravitate to whatever affirms their core sense of identity, including the people who are most like them.
  3. Unless a company actively nurtures a shared sense of identity, specific subgroups, such as departments or teams, become a proxy for “others like me”.
  4. In either success or failure, therefore, individuals within a large organization will feel it locally (within their subgroup), rather than collectively (as a company).
  5. If left unaddressed, a company can quickly become a victim of localized “us” vs. “them” mentality.

We’ve been tackling this issue by opening up dialogues between groups and executive leadership, holding forums to allow people to discuss topics that are important to them with other from across the company, and becoming more rigorous with our processes. There’s still a lot of work to do, but already I’ve seen the barriers between “us” and “them” start to dissolve. Although tensions remain, we’re slowly learning how to think like one, single organism again (even though a particular department or project team may only represent one, single leg of that organism).

In conclusion: Growth is painful. Steele yourself for the challenge.

There are a million other things that change as a company grows. Almost all of them are impossible to predict or effectively plan for ahead of time. The most important lesson I’ve learned going through this transition myself is that growth can be destructive if it’s not managed well.

Fortunately, the company I work for has been very careful. We came up with a list of roles we desperately needed, but hired no more than necessary. We took our time to find the exact right kind of people, and have always been rigorous in our on boarding practices. We anticipated the need for more structure and processes, and worked hard to propose the right ones to start off with, realizing that anything we instituted might need to be refined, or may not work at all.

The point is that we’re fully aware of how difficult it is to grow in a smart, sustainable way. It’s turning out to be more difficult than we imagined, perhaps, but for as long as we’re willing to test, measure, learn, and adapt, no problem is unsolvable.

Growing an organization may be hard work, but it’s also very satisfying when positive changes take effect. The key is to keep your eyes wide open, and to be fearless when facing new challenges. It’s the only way to stay sane while building for future success.