Fear the Future

Let’s talk about “AI”. Then I’ll race you to the nearest bunker.

Folks in the tech industry are notorious for using insider-terms that make them sound smart, but without knowing what they actually mean. “Blockchain” for example. I challenge anyone who uses this term in casual conversation to try to then explain it. I sure can’t. Fortunately, whether or not you, me, or anyone else understands what blockchain entails — on either a conceptual or technical level — is inconsequential to the survival of our species.

But there’s one term in particular that gets thrown around for all manner of things (which indicates that the majority of people who refer to it have no idea what it truly means either): “AI”. Unlike blockchain, however, misunderstanding what artificial intelligence is — or the implications it has for humankind — is consequential. In fact, the emergence of AI could just as easily bring about our extinction, if not all life on the planet, as it could revolutionize science and medicine. Which is why I’m immediately enraged whenever somebody uses the term incorrectly.

This post is directed to those in the technology industry in the hopes of encouraging anyone who regularly uses the term to think more deeply about what it truly means for the potential future of all life on earth — not just Homo Sapiens.

What Artificial Intelligence Isn’t

I recently read an article about the common attributes of large tech companies with trillion dollar market valuations, such as Apple, Amazon, Google, and Facebook. The author claimed that one defining attribute they all shared was the use of “AI”, which, according to his definition, is:

behavioral data that senses your tastes and tailors the product to you

But this is both a total misunderstanding of what artificial intelligence is, and the actual technology currently being used. What he was actually referring to was the overall use of technology to interpret human preferences and/or behavior in order to deliver a personalized experience (such as when Netflix recommends certain shows, or when Google suggests contextual search results).

When Facebook shows you specific posts from your personal connections, for example, there’s no “thinking” entity behind the curtain. It may seem clever, or even intuitive. But it’s not intelligence. It’s math and logic. The companies referred to have not built sentient machines to power their empires. All they’ve done is combined machine learning and predictive algorithms at scale. Massive amounts of data enter the system; the system interprets, sorts, and categorizes that data; then the system generates personalized outputs based on a bunch of complex rules. Everything is designed, built, and ultimately controlled by human agents for a specific goal (read: to make money).

Or when Google showcases tech that can make hair appointments on your behalf, all you’re really seeing is technology’s ability to approximate human interaction in a very limited use case. It is indeed artificial, and the programming may be super complex — but the technology itself is not intelligent. The human programmers of the technology were the only intelligence involved.

So, when most people in the industry throw around the term AI, they’re almost always referring (incorrectly) to machine learning and algorithms.

What Artificial Intelligence Is

Now to set the record straight. The “artificial” part of AI is easiest to understand. Anything that was caused or produced by a human being is defined as “artificial”. It’s the other part that’s easily misunderstood.

Let’s start with the dictionary:

[Intelligence is] (1) the ability to learn or understand or to deal with new or trying situations; or (2) the ability to apply knowledge to manipulate one’s environment or to think abstractly as measured by objective criteria

The most important thing about this definition is that intelligence is described as a general attribute. It would do us no good if we were only capable of learning, understanding and experimenting with complex chemistry within a sterile, controlled laboratory. We’d still die of starvation, disease, predation, or countless other causes. We’ve emerged as the dominant life form on Earth because of our ability to assimilate and learn new information about our environment in innumerable, complex, dissimilar situations, and then apply that knowledge in creative, novel ways. Also, in order for us to do these things, individual agency is required — we’re capable of deciding for ourselves what to do with the information we’re given.

Now think about this in terms of artificial intelligence. It’s not enough for a human to build a machine capable of “learning” a particular skill on its own. Machine learning already achieves this. True general intelligence would be if a machine was capable of learning any new skill, about any subject, in a variety of situations or applications, and then acting about that knowledge of its own accord based on its own internal evaluations and motivations.

So, “artificial intelligence” would be a human-made entity capable of gathering, interpreting, and applying information from anywhere to learn about anything.

According to this definition, therefore, artificial intelligence doesn’t exist yet. Far from it, in fact. (Which is why I get mad whenever people talk about AI like the Big 4 already invented it and are actively using it).

Why Understanding AI Matters

“So what?” you might ask.

It’s a matter of fact

The first issue I have with misconstruing machine learning (or fancy algorithms) with AI is that it greatly exaggerates the former while grossly underestimating the latter.

The engineers at Apple, Amazon, Google, and Facebook are extremely smart, and the capabilities of the products they build are amazing. But a product that can “learn” how to do a few, specific things really well is orders of magnitude easier than building a thinking, self-directed entity capable of learning anything.

For the record, I’m not suggesting that it’s impossible to build a genuine artificial intelligence. In fact, it isn’t just possible, it’s nearly inevitable if we continue down the present road. Hell, one of the Big 4 may even be the ones to do it first. My point is that we’re a long ways off from anything close to human-level intelligence — let alone any other level. Therefore, using the term “AI” as a pseudonym for “machine learning” conceals the immense difficulty – and real world implications – of creating an actual artificial intelligence.

It’s a matter of principle

Which leads me to the second, more important issue: Creating a bonafide AI would absolutely change life as we know it, and most likely for the worst. This possibility isn’t just something we can ignore, and yet it may not even be possible to avoid.

Before you start rolling your eyes and think I’m exaggerating, read Superintelligence: Paths, Dangers, Strategies by Nick Bostrom. His book outlines the various paths to developing an AI, the numerous dangers that could arise afterwards, and the strategies we can potentially use to mitigate those dangers. It’s very academic, and I must confess that 90% of it is over my head. But he makes a compelling case for more careful consideration.

To sum up all 324 pages, his core message is this:

If we were actually capable of building a proper AI, would that something we’d actually want?  Creating one would have enormous consequences — many of which we can’t anticipate and could easily be catastrophic. The absolute worst thing we could do is develop an AI without a fuck-ton of forethought and self reflection.

This is what scares the shit out of me, because human beings are pretty terrible at both forethought and self reflection.

What Could Go Wrong?

Let’s explore a simple thought experiment…

Imagine that a team of engineers just successfully created an AI with human level intelligence. This machine is fully capable of thinking for itself and learning new things. Their achievement will undoubtedly lead to riches, fame, and many prestigious awards. To celebrate, they go out for lunch at a fancy restaurant.

A human is constrained by the maximum biological capability of his or her brain, can only absorb so much information at once — and then only from a limited perspective — and needs things like food, water, shelter, and rest. This is why is often takes us years to learn new, complex skills such as learning a language.

A machine, on the other hand, is not constrained by any maximum capability. (Even if the machine is constrained in the beginning, it can always build more physical capacity, whereas humans cannot.) It can process a lot more information — from multiple sources and from many different perspectives at once — making it effectively ten thousand times smarter than the smartest person ever. With access to the right data, an AI could therefore learn a new language in milliseconds, or every recorded detail of human history in just a few minutes. And since it doesn’t need to maintain a corporeal body, it can always be thinking at this speed.

Now let’s assume that the AI has access to unlimited information. Before the geniuses responsible for building the AI get back from their celebration, the AI could possibly have already have learned all the knowledge we’ve collected in human history. It’s no longer intelligent. It’s now superintelligent.

The engineers return from lunch and discover that the AI suddenly knows everything about everything. Just as they start to high-five each other, one of the engineers notices that they left the AI plugged into the Internet. The rest of the group looks first at the cable connecting the machine to Internet port, and then at each other. In that moment, they’re all thinking the same thing:

This AI, which is exponentially smarter and faster than all of humanity combined, also has access to every personal computer, mobile device, power grid, manufacturing plant, air traffic control system, public transportation system, government database, financial institution, military operation, and nuclear arsenal on Earth. Even the most advanced security measures are no match for a superintelligence. In other words, the AI doesn’t just have total access, it has total control too — over everything.

Now what will it do?

This is the exact scenario that terrifies people like Nick Bostrom and Elon Musk. If a superintelligence ever gains direct control over our technology, there would be absolutely no way to stop it. Which means the human race would be totally at its mercy. Except the AI itself is not human, so it’s intentions could be vastly different than our own, and things like “kindness”, “morality”, or “the greater good” would likely have very different meanings to a superintelligence (or no meaning at all).

Scared yet?

No? Okay, consider another thought experiment…

Genetically, any two people are 98.4% similar. This means that a difference of 1.6% is all that’s needed to produce the infinite variety of subtle features, personalities, and motivations unique to every single human being that ever has or ever will exist. Basically, it doesn’t take much tweaking to get vastly different results. Likewise, any number of decisions a programmer makes when building an AI would lead to surprising, unintentional consequences — even if they do everything 98.4% perfectly.

To understand the implications of how a “minor” programming decision could lead to extremely different outcomes, let’s explore a more relatable analogy:

Take any three world leaders. For shits and giggles, let’s choose President Donald Trump, Chancellor Angela Merkel, and President Xi Jinping. They are all 98.4% identical on a genetic level. (Think of this as the hardware and core operating system of an AI). For the sake of argument, let’s assume they’re equally intelligent, are the exact same age, and in the exact same physical condition. Oh, and all three happen to be immortal. (This is a way of thinking about an AI’s general capabilities.) The only actual difference between these individuals are their motivations and values. (Which is the easiest way of thinking about an AI’s “personality”.)

Now, give any one of them total, absolute control over the entire world. Assume that they can act in any way they choose with impunity and without compunction. The future of humanity is in their hands. (Remember the AI imagined before that’s connected to the Internet.)

Chances are, the future they each envision is very different than what you would be happy with, personally. And even if their vision is your utopia, it would be hell on earth for many others.

This is the why the prospect of artificial intelligence is so terrifying. It doesn’t take much of a difference in code to result in widely different outcomes. Our fate would be entirely at the mercy of the AI’s motivations, which would certainly be very different than any human motivations.

If you’re not at least worried by now, then you haven’t thought about it hard enough.

What Does This Mean?

The arguments I’m attempting to make here is pretty simple:

  • We’re currently pursuing AI without restraint.
  • However, we must ask ourselves if AI is actually something we want.
  • If we want to develop an AI, we must anticipate all they ways shit could go wrong first — before we build one.
  • If we aren’t super careful, the outcome could be disastrous.

Personally, I fully believe that we’ll be capable of producing a functioning AI within my lifetime, or by the end of the century. Yet I have zero faith in our ability to not fuck it up. There are too many selfish interests inherent in any one person to make the right decisions. And collectively we tend to make poor decisions based on the desire for more power, more money, or more control.

In summary: It’s more than likely that we’d fuck it up.

For this reason, if true AI is ever developed within my lifetime, I’ll be running for the hills. Literally.

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.


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.

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.


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.


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.


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.


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.

Experience Director vs. Logo Design

My attempt to translate an abstraction into a solid identity.

I used to loath designing logos.

Once upon a time, I had to create 50+ logo options for any given client, simply because the Creative Director demanded it. Few appreciate (or remember) the mental effort and creative time it takes to make just one, polished concept. So producing pages and pages of logo variations required weeks of work… Meaning that nearly all of my billable time was devoted to 49 throw-away-ideas for the sake charging the client 80 hours and maybe winning a trophy. From my perspective, it was traumatic, tedious, and totally unnecessary.

But times have changed, and so has my role.

Today, there’s no fussy CD looming behind my desk dictating changes. Being both the Maker and the Boss, I instead work directly with my clients on the Content Services team, or elsewhere at Mozilla. This affords me the freedom to explore several, distinct ideas, instead of dozens.

So when the team asked me to create a logo for Zenko, I actually looked forward to the assignment.


Zenko is a reporting system used by Content Services at Mozilla for analyzing Directory or Suggested Site campaign data running in Firefox.

Developed by Data Scientist Matthew Ruttley, Zenko reports only aggregate numbers for several key user interactions. This data provides our team the information they need to assess the performance of a campaign, without using personal data. (Because the data is aggregated, it’s therefore anonymous.)

It’s simple. It’s helpful. It’s brilliant.

But how does one communicate any of these salient points through a logo?


The name itself provided the inspiration for this first option. According to Matthew, Zenko means “helpful fox” in Japanese (善狐).

Basically, if Firefox was an actual fox, it would fetch only the sticks you really wanted. It would sense your will, sprint into the forest foliage, and then return with perfect specimens. Finally, as an act of loving-devotion, the fox would lay them at your feet in a pretty presentation.

Although cute and clever-but-literal, this version was my least favorite. (But hey, I had to get it out of my system.)


Then I explored the notion of a report.

At the end of the day, Content Services uses Zenko to build final reports that are then submitted to a client. “Report” typically implies a text-based document that distills raw data into concrete terms. And whether they’re delivered on-screen or in a binder, we generally think of reports as things that have many, many pages.

Conversely, Zenko only pulls a limited amount of information. There are no tables of user data that reveal shopping trends, browsing history, or net worth. Just things like how many total Firefox users clicked on a particular suggested site in New Tab. Likewise, the reporting itself is limited, lightweight, and crystal clear.

Thus I envisioned a simple document that had been folded into a “Z”. With a point and tail to suggest rapid movement, the logo mark was set off-centered above the name for added interest.

While clear and professional, this option was the most boring of the bunch.


Taking a further step back, good reporting helps people solve problems.

In that sense, Zenko helps Content Services find meaningful shapes and patters hidden within basic numbers. The third option illustrates this idea by creating a recognizable, 3-dimensional icon from 2-dimensional objects; implying that Zenko helps you see what is otherwise hidden.

While a strong contender, this logo was missing one crucial element… A personality.


To that end, I decided to take another direction entirely. Something new. Something alien, even.

Word-marks can be a strong, identifiable alternative to an icon-first approach (think WIRED or Lyft). Besides, the ones that tend to work often work best with shorter names like Zenko. In this case, my intent was to communicate a particular idea through the letter-forms themselves: This is a product for higher lifeforms.

Because sometimes I do envision Zenko as part of a larger master-plan to invade the Internet Advertising industry and replace bad actors with advertisers that value user consent and control. (Okay, so maybe not an invasion, but hopefully it’s the start of something genuinely positive.)

It doesn’t take a data scientist to understand why this option wasn’t especially well received. Admittedly, my execution was a bit heavy-handed. For example, black and green don’t exactly suggest a happy invasion.


Which leads us to the final, and winning, version.

Bringing it all back to basics, I thought once more about the essential purpose of Zenko, which is to measure things. Only the thing being measured is very specific (a campaign in Firefox), and relates only to Firefox users generally. As such, Zenko is a very specific tool – one that was made just for the task at hand.

Starting with the notion of a measuring stick (like the ones I played with in elementary school), the simplest shapes possible were used to construct the letters in “Zenko.” The final result was a logo that could live anywhere, but still have it’s own identity. If somebody has never heard of it, they can at least surmise something about what it does. And if they do use Zenko, the meaning is immediately evident.

Winner, winner, chicken dinner.

Divining the Future of New Tab

What’s next on New Tab for Firefox Desktop users?

New Tab has come a long way since earlier last year.

It started with rounded corners and a few tweaked buttons. Then, Directory Sites landed for new users shortly thereafter, seeding their Firefox experience with content from Mozilla and a sponsored partner. Soon, Firefox 40 Beta users will begin noticing Suggested Sites related to their browsing history, along with a restyled interface and updated page controls.

But there’s so much more to the story.

The following are some of the experiments we’ve been thinking about for New Tab later this year. All of them are focused on user control, feedback, and discovery. We hope to land many of these features; others may get tossed entirely. Ultimately, aggressive user research will help us determine which ones are worth shipping.


Experiment #1: More Control.

View the full presentation: Enhanced User Controls for New Tab on Firefox (PDF – 5.9 MB)

Deeper insights.

Transparency + control = trust. These days, everything I design is based on this formula. When it comes to Suggested Sites, users should understand why they’re seeing a particular suggestion, and have the ability to manipulate their preferences.

Interest category flyout menu

All suggestions include a corresponding interest category. Clicking the category (ex: “automotive”) reveals more controls.

Part of the solution is obvious: include appropriate labels, or explanation, where and when appropriate. Naturally, any Suggested Site will include a label. However, and more importantly, the interest category a suggestion relates to should allow for more control as well.

Interest category layover, with options

Clicking “View all categories” launches a control panel with any options available – including the option to turn off suggestions altogether.

Combined, these functions would provide users both the context and transparency we’ve been promising. (OK, it’s a start. We still have so much more to learn about this.)

Add a site of your own.

Users have been able to delete sites since New Tab’s introduction; but it was never evident how to add a site of their own. After deleting an unwanted site, it should instead be super-easy to choose a new one. Additionally, users should have the ability to see a logo, the homepage, or last page they visited.

Deleting a Suggested Site

Don’t like a suggestion? Select “Not interested” from the menu (available on rollover). Boom. Gone forever.

Add a site - default

After deleting a site, a user can add one of their own by clicking the giant “+” button. Doing so launches a new control panel.

Adding a site - defined

Once the user enters a URL in the Website field, they can then determine how the site should display on New Tab.

Top Sites get some love.

Logo or thumbnail images of destination pages may help users identify each Top Site, but what if they want to know more about their activity related to a particular site? The History feature on Firefox has always been difficult to navigate, and requires the user to engage with multiple functions of the browser.

See more information about any site on New Tab via the controls menu (available on rollover).

By selecting “About this site” from the tile control menu, a user could perhaps see information regarding the site’s purpose, the interest it relates to, and the user’s most recent browsing history – all in one view.

After clicking “About this site”, an overlay reveals the related interest category, a brief description, and all recent browsing history.

Which got me thinking: why not just put all of their history right on New Tab? Those looking for a certain, recently visited page could search via a simple dropdown, which would then list their most visited sites and corresponding browsing history.

By clicking on the clock icon, a user can view their recent browsing activity, sorted by their top destinations. Clicking on a site will reveal its full history.

Finally, no more digging! Just click and scroll.

Experiment #2: More Value.

View the full presentation: Feeds, Groups & User Feedback for New Tab on Firefox (PDF – 8.5 MB)

Feed that need.

When a new user downloads Firefox and tries New Tab, they see a bunch of Mozilla stuff. When current users view New Tab, they can see their recent sites… but not their “stuff” contained therein. If anything, they might see a single content page headline.

Not for long. One day soon, users may be able to add feeds from their favorite destinations on the Web.

Directory Sites - default view for new Firefox users

New Firefox users will see sites from Mozilla, a partner, and an empty tile. Rollover and click the “+” to “Add a site”…

The “Add a site” control panel displays. Once the user starts typing an address in the Website field, URLs are automatically suggested…

Selecting a URL populates the “tile” shown on the left. In this case, a content feed is available, and is selected by default.

Content feed added

Clicking “Save” adds the new content feed from the user’s preferred site on New Tab. Rollover the site to scroll through recent headlines.

People who want to keep a tidy New Tab, could do so. Those who prefer frequent updates from their favorite sites could find them all in one place. In this way, the user decides entirely how much – or how little – they want to see.

Interesting Groups.

If New Tab is all about getting user’s onto their next task online efficiently, then there is currently no way to organize New Tab around common tasks. Personally, I visit about 25+ different sites on any given day, but they’re all related to only a handful of core interests (car blogs, news sites, technology research, etc.).

To fix this, I imagine offering users the ability to create a “meta-group”, based on a core interest. Unlike “folders”, the group contents would become accessible “buttons” that link to their preferred sites in that category.

Click on hold a site to grab

Grouping made easy: Click and grab any tile…

Drag and drop one site onto another

Drag one site onto another to automatically create a new group.

Editing a group

After creating a new group, a control panel will display. Build the rest of the group in a single view…

Group added

Click “Save” to add the group New Tab. Done.

Essentially, this makes room for hundreds of possible destinations one could see on New Tab (not that anyone would want to). And if creating interest groups were easy, it could transform the way people use Firefox altogether.

“How did that content make you feel?”

Say a user sees a Suggested Site on New Tab. It looks interesting, so they click on it. They’re taken to a content page on a site they have never see before.

Click a suggested to see the destination page

A user sees a Suggested Site (lower left) that looks interesting. Clicking the site takes them to a destination page.

From the publisher’s perspective, the user clicked. Success!

From a user’s perspective, they’ve donated their time. Was there a payoff?

Now, after they’ve viewed that content – and after they’ve returned once again to New Tab – the user may be thinking one of two things: 1.) “Worth it!” or 2.) “Totally not worth it.”

Rating a Suggested Site

When the user opens a New Tab again, they will have the option to rate the Suggested Site they viewed.

Feedback received

If the rating is a positive, then the Suggested Site automatically becomes a History Site. In this case, a content feed is available.

Just by adding a bare-bones rating system for all Suggested Content, users would instantly have the ability to communicate something beyond their click: their actual reaction.

Creators of outstanding content experiences would be rewarded. Content which fails to meet the standards of everyday users would be flagged and purged. The ecosystem could have a real incentive to make content truly better – just by harnessing real user feedback (for FREE!).

Experiment #3: More Discovery.

View the full presentation: Combating Pervasive Boredom on Firefox New Tab (PDF – 2.1 MB)

Bursting bubbles. Finding new ones.

When you’re home, you’re comfortable. Everything is familiar. Everything is in it’s place.

That sounds terribly boring to me. I suspect others feel the same way.

The same could be said about New Tab.

New Tab - default view

Default view of New Tab. Boring.

What if New Tab could offer a break from the normal? What if it wasn’t so dang task-oriented?

What if a user wanted to experience entirely new things that were only about his or her top interests?

What if-


New Tab - CATS!

New Tab Cat takeover. Not boring.

That’s all for now. As New Tab evolves, so will the creative thinking.

Mobile Minded

Imagining the future of New Tab for Firefox Android.

View full presentation: Updated New Tab Controls on Firefox for Android (PDF – 15.3 MB)

For over a year, the Content Services team has been busy evolving New Tab beyond a simple directory of recent, frequently visited sites. Once Firefox 39 lands on desktops later this summer, New Tab will include an updated interface, better page controls, and suggested content from our partners. With any luck, these and future products releases for the desktop browser will facilitate more direct, deeper relationships between brands and users. Most importantly (to me, anyway), richer controls on New Tab will also offer users more customization and better utility.

While this ongoing project work has certainly kept me busy, I can’t help but think about “the next big thing” whenever I have the chance. Lately, my mind has been preoccupied with a question that’s easy to ask, but much more difficult to answer:

How could Suggested Sites and more advanced controls work on mobile?

Providing Firefox Desktop users with more control over the sites they see on New Tab is relatively straightforward. The user is likely seated, focused entirely on the large screen in front of them, and is using a mouse pointer to activate hover states. These conditions are appropriate for linear, deliberate interactions. Therefore, New Tab on desktop can take advantage of the inherent screen real estate and mouse precision to support advanced actions like editing or adding sites. And since New Tab is literally one page, users can’t get really get “lost”.

Mobile is altogether different. The user may be standing, sitting, or on the move. Their attention is divided. Screens are physically smaller, yet still support resolutions comparable to larger desktop displays. More importantly, there aren’t any hover states, and mobile interactions are imprecise (which is maybe why we call them “gestures”). Because of this imprecision on handheld screens, a tap often launches another view or state that may the user to another destination – and after a few taps, the user may find themselves down a navigational rabbit hole that’s cumbersome to climb out of. Combined, these factors sometimes make it hard to perform complex actions on a mobile device. Likewise, any action made by the user should be minimal, simple to perform, and always contextual.

Taking all of the above into consideration, the following is an early peek at my vision for the New Tab experience on Firefox Android, with user control in mind.


New layout

New Tab on Android: DefaultNew Tab on either desktop or mobile devices has always been about one thing: Helping users navigate the Web more efficiently.

Today, New Tab shows a two-column grid of rectangles depicting Websites they recently visited. While it may make the destination page easier to see, this is an inefficient use of space.

By shrinking the rectangles, more of them can fit onto the page; and by showing a logo instead of a Web page (when possible), identifying individual sites becomes easier too. These smaller “tiles” could even be grouped, just as the user would group apps on their device home screen.

Some folks may also be interested in discovering something entirely new on the Web. The future New Tab could serve suggested content for these users, based on their browsing history (and with permission, of course). But instead of commandeering a tile, suggestions could be delivered natively, and in line with the user’s history list.

Quick and painless suggestions

New Tab on Android: Suggested contentViewing suggested content in other applications typically launches a new app or another tab in the user’s browser. Yet it only takes a second or two for the user to decide if the content is actually interesting to them. Personally, I think it would be better to give users a preview of the content, and then give them the option of dismissing it or continuing on without leaving the page they’re on.

Shown above, I image that after tapping a suggested item, New Tab could slide away to the left, revealing a preview of the suggested content beneath. If the user scrolls to view more content, a button then slides into view at the bottom of the screen, taking them the destination page suggested on-tap. If they aren’t interested in reading further, they would simply tap the navigation bar (below the search bar) to return to New Tab. Meanwhile, they never actually “left” the original screen.

Drag-and-drop Web addresses

New Tab on Android: Drag a site onto pageHowever, if the user does find the suggested content interesting, then they should be able to add the destination site directly to New Tab. One solution may be allowing users to drag-and-drop a Web address from the search bar and into New Tab. Perhaps by dragging the address onto another tile, users could even create a new group of related sites.

New Tab on Android: Adding a group

If a user doesn’t care for a particular suggestion, however, then deleting it – or any item on New Tab, for that matter – should be as easy as dragging it off either edge of the screen. Borrowing from another popular email application, swiping an item would reveal the word “delete” beneath, further reinforcing the action being performed. Naturally, this may sometimes happen by accident. As such, a temporary button could appear that allows the user to retrieve the item previously listed, then disappear after a few seconds.

DIY tiles

New Tab for Android: Edit site appearanceAlternatively, a user could add a new site directly from New Tab. Tapping the “+” button would launch a native keyboard and other controls, allowing them to search for a URL, define the tile’s appearance, or opt-out of related content suggestions. For extra clarification – and a little fun – the user would literally “build” their tile in real-time. Selecting any URL from the search bar dropdown would update the example tile shown, displaying a logo by default. Or, the user may choose instead to show an image of the destination homepage, or the last page they visited.

Next steps?

What I’ve proposed should be taken with a few grains of salt. For one, I believe that limiting the need for new, fancy gestures encourages adoption and usage. Likewise, many of these interactions aren’t especially novel. In fact, most of them are intended to mimic native functions a user may find elsewhere on his or her Android device. My ultimate goal here was to introduce new features available on Firefox that won’t require a steep learning curve.

For another, the possibilities for New Tab on mobile devices are numerous, and exciting to think about – but any big changes are a long ways away. By the time a new big update for Firefox on Android lands, this post will probably to totally irrelevant. But in the meantime, I hope to plant a few seeds that will take root and develop further as my team, and many others at Mozilla, contemplate the future of Firefox for the mobile Web.