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.



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.

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.

Learning How to Lead

If it doesn’t feel like drowning, you’re probably doing it wrong.

For a long time (longer than I’d like to admit), my primary responsibility was mastering the craft of design. From identity to print or Web design, there was a lot to learn. Branding. Layout. Typography. Color theory. Substrates and printing techniques. Technical requirements and limitations for the Web. These are all things I could spend a lifetime perfecting, only to remember that there will always be many people who are far more talented than me.

Then I ventured into the vast world of “UX” (mostly by accident). There was even more to learn. User journeys. Site maps. Information architecture. Wireframes. Content strategy. Functional requirements. The list of artifacts and specialties were endless! My only saving grace was that I was a halfway decent designer, so my documentation looked better than most. Still, it was yet another universe dominated by extraordinary talent.

Fast forward to 2016. I somehow landed a job at a startup company with a fancy title. I had experience designing things. I could do UX stuff. And by this time I had enough industry experience to somewhat understand how screwed up online advertising had become. Only now I was responsible for doing all the design things, prioritizing projects, hiring people, and getting shit done. It all sounded very exciting and important (because it was), but leading was a new frontier.


After several months of pretending to know what I’m doing, I had a meeting with a newly-formed-but-loosely-defined team. My grand vision was that we’d figure out our Experience Design Process in a 1.5 hours on a Thursday afternoon (because, um, we never had one to begin with). Instead, I quickly realized that shit was all fucked up, people had no idea who was responsible for what, and our collective activities felt more like an exercise in chaos theory. We barely even got to the actual process stuff.

So, I obviously felt pretty terrible at my job. Again. Only this time there was no hiding behind pretty layouts and clever copy.

But you know what? It was a very good thing that happened in that meeting. I learned in that moment to embrace my deficiencies and failures. It was no longer about my portfolio, my reputation, or my experience. This was about other people – super talented, immensely dedicated, very motivated people (if I had done anything right, it was hiring). This was a mess I honestly could’t fix on my own. I needed help. Because the problem had nothing to do with “managing” people.

It was entirely about supporting them.


In the days since that awkward, very painful meeting, I’ve been focused on the team’s success instead of my failure(s). There’s still a lot to do, and much more to learn. But I’ve started by trying to understand the challenges before prescribing solutions. My job, it turns out, is not to have the “right” answers, but rather involve those who actually have the experience, skill, and vision.

After several months in this role, I’m just now beginning to grasp how limited I am on my own, and how all the help I could ever need surrounds me in abundance. They are the answer. I am not the solution.

I’ve always had a knack for learning things the hard way… But this time, the truth never hurt to good.

The Zen of Building a Product Team

How to manage people and priorities for a growing team without being anyone’s boss.

One of the things I like most about working at Eyeo is the flat hierarchy. Everyone reports to a few senior managers, but otherwise people manage themselves. As a company, we define clear goals, and then allow everyone to apply their expertise however best supports those goals. And even though we’re over 60 people strong – half of which operate remotely all over the world – somehow it all works.

More recently, we hired a Product Designer and another Product Manager to fill out the team. Now what? How do we scale our capacity, while maintaining a “flat” organization? It definitely sounds like marketing spin, if not complete fantasy. But so far I’ve seen it work in practice, and on a daily basis. Someway, we find a way… usually without getting in each others way.

After giving this considerable thought, and reflection on my own experiences, below is my current approach to building a killer product team, but with a healthy does of skepticism. To paraphrase a popular adage, no plan survives first contact with reality.

But you have to start somewhere, right?


Get new hires started quickly, and support them completely.

If you hire self-directed people capable of delivering superior work, then they likely crave input and context even before starting. So, provide them with the resources they need to better understand your products a week or two before. Let them self-service their curiosity, and then ask specific questions later. When they do start – officially – you can give them problems to solve their very first week. Meanwhile, be available to answer questions, talk through ideas, provide file assets, or do whatever else is needed to help them succeed. No request is too big or too small.

Prove your commitment to the success of others from the very beginning, and they will be more likely to genuinely support your decisions later on.

Delegate ownership, not projects.

If everyone on the team has comparable skills, then they should be permitted and encouraged to work on a variety of projects. But in the end, each product does need a final decision maker. Therefore, give those with similar roles authority over a specific product or problem. For example, one person might own the mobile version of a product, while the other owns the desktop version. However, they should always be willing and able to help each other as needed (or desired), on any project.

This way there is accountability, but nobody gets bored or feels trapped thinking about the same problems over and over again.

Connect people working on similar problems.

When giving someone the authority to solve particular problems, also make certain that they work together with at least one other teammate to support the larger goal(s). This approach offers checks and balances, since they will naturally challenge one another in search of deeper understanding and broader insight. “Management” may be necessary to ensure that communication and delivery happen smoothly, efficiently, and productively. But once a person is connected to the right teammates, get out their way.

If the team member understands the problem and requirements fully, you won’t have to micromanage their individual contributions.

Maximize transparency. Minimize process.

The Open Source community is clearly capable to working collaborative, globally, on common projects, and with clear goals / deliverables. So why not make this the standard approach for internal product teams as well?

By simply documenting all the problems, goals, priorities, research activities, etcetera, anyone can find answers to their questions more easily, and they will understand the “why” much more easily. Inviting everyone to participate in a minimal process, and then allowing them to ask questions organically, also helps people in different time zones, or with different expertise, to find the information they need to do their job more effectively.

The context and completeness of information is everything. This is the key to unlocking great potential, because once smart people start working together on a common problem, they will quickly arrive at better decisions than you ever could on your own.

Never ask a software engineer how long it will take to build something.

Software development is not a linear process with defined tasks and timeliness. It’s jungle warfare, and everyone’s always hacking something. Engineers have to figure out exceedingly complex problems all the time, and often without knowing what challenges they’ll run into next. Therefore, you’re never helping by asking them “when can you get that done?” because they honestly can’t tell you.

Instead, ask them what’s blocking their progress. Work together to solve problems they can’t by themselves. The faster you can connect the dots, and get then get the right people talking to each other, the faster a developer can solve the enormous list of problems you gave them to solve.

Remember, your engineers want to ship amazing products – preferably ones that operate as intended, and without flaws or inconsistencies. Let them take as much damn time as they need to figure it out, and fully support them along the way. In the end, users will thank you for it.

Leave no one behind. Ever.

If somebody needs help, spend time learning about their problems before offering solutions. Then actively help them help themselves.

If somebody says something upsetting, confront it directly, and in the moment (whenever possible). Then seek new solutions instead of further blame.

If somebody feels lost or unheard, help them find their way or their voice. Ask them how you can help, and then follow through. A motivated, empowered individual will likely find another way to reengage with the overall team.

These, and other individual circumstances, will arise no matter the company culture or existing processes in place. It’s okay and totally normal, but it’s still your responsibility to respond with empathy and action.

Everyone matters. Encourage respect and cooperation, but never tolerate blame or inaction.

Own your mistakes and failures.

Even the best, most well intentioned plans go terribly wrong. Longterm success is a collective effort, over time, through trial and error. A growing team will present all sorts of problems or challenges you cannot possibly anticipate. So learn what exactly went wrong, and why. Then fix it or try something else, and move on.

Indeed, you’ll fuck up plenty of times – especially the harder you try. But embracing failure is the first step to finding a credible solution that will produce better results, for everyone.

Just don’t ever fail the same way twice.

Why a Triceratops?

How to represent everyone without representing anyone.

Download the infographic: How user data is protected on Firefox New Tab (PDF – 633 kB)

Illustrating something highly-technical is more about storytelling than it is about design. My personal process often starts with a deluge of diagrams, wiki pages, stakeholder meetings, and follow-up discussions with engineers. Once I finally understand the details myself, it’s then my job to distill all that raw information into a single, coherent story.

That’s where the plot usually takes an interesting detour.


The Content Services team recently asked me to develop an infographic depicting how Firefox determines which Suggested Site to show a user. The narrative itself was easy to illustrate because I had tremendous help from my teammates. But regardless of the refinements I continued making to the design, a crucial element always remained conspicuously absent:

The main character.

In this case, the main character was a Firefox User. My principle challenge, of course, was representing a person of any age, gender, ethnicity or language from around the globe. Secondarily, I wanted readers to feel something – maybe even smile. But most importantly, I wanted readers to clearly identify the User as the star of the infographic.

In other words, I needed a good mascot.

Folks don’t generally connect with the generic on an emotional level; so, I instinctively knew that flat, vaguely male or female silhouettes would be overly general for a global audience.

Maybe an animal? The Firefox mascot is a fox, after all, and small furry creatures are inherently disarming. I quickly discovered, though, that many animals could be interpreted as personalities types or even specific nations. Every option seemed close to the mark, but fell short upon further reflection.

Then the obvious roared in my face.

Historically, Mozilla has been represented by a dinosaur. And not the dead-fossil kind, either, but a living, breathing carnivore. I’ve always liked that image. The Mozilla T-rex, however, wasn’t the star of the story (and Mozillians aren’t all that carnivorous, anyway). Still, I could easily build upon this imagery without fear of alienating any particular person or group.

In the end, the species I chose to represent Users is one of the most recognizable. Besides being herbivores (which somehow seemed more appropriate), Triceratops command attention and demand respect. They’re creatures who appeal to our cooperative, yet intensely protective, instincts. They’re  important, impossible to ignore.

And when they’re smiling, it’s hard not to love them.

Done and done.

Click Here to Upgrade Your Starship

Stardate 53849.2 – the Delta Quadrant

Captain Kathryn Janeway of the Starship Voyager stands up from her chair, at the ready. Moments ago, the ship had lost warp power and the crew suddenly found themselves adrift. But before the Captain could request a status, a bright prick of purple light erupted on the main monitor, fading away into the strange, iridescent anomaly everyone now sees before them. Everyone has ceased their activity to watch the swirling cloud of unidentified origin or makeup, growing ever larger on screen.

Tuvok, report!” Janeway commands with confident urgency.

The Vulcan looks down at his console. “Captain, it appears that we have entered a temporal distortion field caused by the object ahead, and…”

A new panel slides into view on his screen. In simple, futuristic type, a message appears:

Error 606: Offline Mode

It appears that you have temporarily lost connection. You may be outside of our Preferred Starship Network Coverage Area.

We are rapidly expanding in the Alpha and Gamma Quadrants, and hope to be in the Delta Quadrant by Q4 of next year. Until then, you will have limited access to the features equipped on your starship.

Click here to learn more about the offline services available on U.S.S. Starship OS 9!

“Commander?” Janeway snaps, hands now on her hips.

Tuvok taps a small, gray button to dismiss the message. “My apologies, Captain. Voyager’s systems appear to be in… offline mode.”

“What? That can’t be right. This starship came equipped with the latest interstellar communication devices, which have served us well this far.” The Captain looks back at the enormous screen – the spiraling clouds converge to form a glowing, periwinkle vortex. “Never mind.”

“Engineering, can you restore power to the primary warp coils?”

“No, Captain – not in offline mode,” Chief Engineer B’Elanna replies hurriedly. “But we do have access to our secondary thrusters,” she adds optimistically.

Janeway pauses for a brief moment. A small, impossibly black hole is emerging from the center of the vortex like an expanding pupil. She turns to Tom.

“Lieutenant Paris, can you alter our current position, or at least put some distance between us and whatever that is?” she says, pointing.

Tom taps furiously at his screen, “On it, Captain.” Just before he initiates the final command to engage the thrusters, a video layer appears. There is a brief, but interminable moment of silence.

“I’ll have thrusters shortly. I just need 15 seconds until I can skip this ad and–”

“We don’t have 15 seconds, Tom.” she says over him. The Captain walks urgently towards the other side of the bridge and steps down onto the lower platform to take control of a vacant console. The iris is almost fully dilated, an ever-growing abyss of nothingness.

Janeway activates the communicator pinned to her chest, “Seven, what is your analysis?”

Over the intercom, Seven of Nine replies matter-of-factually, “Captain, we have lost control over our propulsion and long-range communications. All other systems are stable. I still have access to our primary–”

There is an awkward pause. There are no more spinning purple clouds on the screen, or distant stars beyond. Only blackness.

“Captain, what is your User Name and Password?”

Everyone looks at one another, and then at the Captain. Irritation flashes across her face. Janeway inhales.

“Captain Kathryn Janeway of the U.S.S. Starship Voyager, Starfleet Authoriza–“

Seven interrupts, “No, not for Starfleet. I need your log in credentials for Starship OS 9 – Voyager’s native operating system.”

Just as Janeway opens her mouth to respond, a sudden, invisible shock-wave rips through Voyager – violently shaking the starship with such force that a few crewmen are knocked unconscious. While the hull quivers and moans from the force of impact, senior officers reach for a grip or attempt to stand. Rumbling continues to deafen everyone on-board, interrupted only by the metallic shrieking of large, structural objects. A few of the petty officers assume the fetal position beneath their stations. First Officer Chakotay yells something. Tuvok somehow steadies himself, only to loose his balance again. For a few moments more, all is chaos.

And then nothing.

Everything is absolutely silent, still and serene. The main monitor is black, but presumably still active. Objects of various size and mass are haphazardly thrown about the deck, lying motionless, as though placed on purpose long ago. Captain Janeway is up on one knee.

Chakotay fixates on the main monitor. “Captain, look!”

A small pillar of tightly twirling, iridescent clouds appears in a moment on the deck directly below. Everybody recognizes the violet glow immediately. Nobody breaths. Then, just as quickly, the vaporous shapes collapse into a universally identifiable form: a human male. He is smartly dressed in a simple, charcoal suit and tie.

“Yes, even my tie is purple!” the man begins with bright smile and outstretched arms. “I hope it wasn’t overkill, Captain Janeway.”

The crewmen quickly head back to their various stations in a coordinated burst of nervous activity. The Captain looks stunned, yet she manages to stand tall, adjust her uniform, and speak.

“Explain yourself!” She nearly shouts. “Who are you, and what is the meaning of this?”

“First, let me assure all of you that no one is an any danger.” The man looks directly at Tuvok, and then Chakotay, who are training their phasers at him. “At least not insofar as it has anything to do with me,” he adds with a wink.

Janeway stands with one hand on her hip, jaw set. “Explain. Now.” She glances at her two senior officers.

Still smiling, the man continues, “Of course, Captain.”

“I am not so much a person, as I am the representation of the Starship Interstellar Travel and Communications Network, and its intergalactic subsidiaries, in holographic form. Think of me as your visual interface between you, Starship OS 9, and the parties that offer this amazing – free – software.”

The Captain blinks. She does not look pleased.

He turns his palms toward the crew and shrugs. “But you can call me Steve, if it makes things easier.”

“And Steve, are you responsible for the loss of our warp drive capabilities?”

“Yes,” he answers calmly. “I’ve also taken control of your startship’s primary and secondary functions – for your own safety, of course. More importantly, I’m not materially real or even ‘here’ aboard this ship, so you couldn’t harm me even if you tried.”

Janeway considers the intruder’s words. “Tuvok?”

“Confirmed, Captain,” the Commander replies as he glances down at his monitor, then back at Steve.

Without breaking eye contact, the Captain raises her hand, signaling her crew to stand down. Tuvok and Chakotay exchange doubtful glances before lowering their weapons. The other officers are frozen in a state of hyper-alertness while Janeway walks deliberately over to her Captain’s Chair. Turning to face Steve, she lowers herself into the sparsely upholstered seat and crosses her legs. With hands folded, Janeway resumes.

“Well, Steve, you have our undivided attention. Let’s get on with it so we can continue our journey back to Alpha Quadrant.” She pauses for effect, and then asks harshly, “What do you want?”

“Certainly, Captain. Perhaps the grand entrance was a bit much. The marketing guys always want to deliver a compelling, memorable experience. Anyway,” he stands up a little straighter. “–this starship, its operating systems, and transmission of all subspace communications throughout the Universe, are now the sole property and responsibility of the Starship Interstellar Travel and Communications Network.”

Before Steve could continue, Chakotay interrupts. “That’s impossible! We demand to speak with Starfleet!”

Steve smiles anew. “Starfleet was consolidated, along with numerous other well established Network Providers, into a single, new entity through an intergalactic inversion with the parent company, Interstellar Systems.”

“Wait. What?” The First Officer is genuinely confused.

“They bought Starfleet, Chakotay.” The Captain is holding her head in her hand, shoulders dropping slightly.

“Fascinating,” Tuvok states.

B’Elanna interjects, “That’s right, I recently heard some rumors about a merger with all the big players–“

“Inversion…” Steve corrects.

“-Starfleet, the Vulcans, Romulans, Klingons, Ferengi, Betazoids, Bajorans – even the Borg. Pretty much everyone, I think.”

“Indeed” Steve says with a sense of endearment a father would bestow upon his first child.

Then, sitting back in her chair, Janeway places both her hands on the armrests at her side. “I’ve heard enough. You still haven’t told us what it is you want with Voyager or its crew.”

Standing in his original position, the hologram nods in agreement. “Right.” Steve looks over to the Vulcan.

“So, you lost warp drive and access to your devices because the area you’re currently traveling in – the Delta Quadrant – is outside the coverage area for Basic Access. Due to the substantial investment required to bring Extended Access to the most remote expanses of the Universe, access will be provided only to Premium Travelers who have upgraded from U.S.S. Starship OS 9 to Starship X.”

He looks back to Captain Janeway. “Since your starship happened to be in the Delta Quadrant before this policy was enacted, we’re offering you the opportunity to upgrade to Starship OS X – for free! Only now, you’ll have a host of new features and tools to help you along your journey.”

The man’s smile softens into a disarming grin. His pleasant disposition is not enough to soften the Captain or put the crew at ease. Her eyes narrow as she leans forward, “And what do you get in exchange for our consent to this… upgrade?”

“That’s the easy part!” Steve exclaims. “The information you create, share or consume on Starship OS X will be collected by the Starship Interstellar Travel and Communications Network. This information will be shared with our partners so that we can continue to offer innovative new features that will make your voyage home a better experience!”

“In other words, you’ll know everything that we do?” Chakotay is finally catching on. “And you might share that information with your partners?”

Steve answers while adjusting his tie, “Yes. Technically.”

“…Partners which include the Klingons, Romulans and the Borg?” His voice now intensifies, “Our enemies?”

“Whoa there,” the man retorts. For the first time, the holographic image walks across the deck towards the crew. “First of all, your privacy is very important us. We would never share your personal information with anyone outside The Network; and even then,” Steve presses his hands together to gesture, “none of your sensitive information is personally identifiable. Thus, if any malicious third party somehow managed to ‘steal’ your data, it wouldn’t do them any good. Besides, we use the most sophisticated encryption available in the entire Universe.”

“I still don’t trust you!” Chakotay shoots back, pointing his finger squarely at Steve. “How can we be certain of anything you’re telling us?”

Steve shifts to one leg and folds his arms, “Commander, I think you’re missing the larger picture here.” Looking down, thoughtfully, he cocks his head to one side. “Consider the value you’re getting: In return for doing the very things you’d be doing anyway, your starship will finally be able to communicate with Earth. You’ll also be able to chart a more efficient course, navigate through uncharted territories with ease, and deploy your weapons more effectively.” Beaming, Steve adds, “Plus, you’ll have access to over 30,000 new recipes for your Replicator, from cultures all throughout the Alpha and Gamma Quadrants!”

Chakotay furrows his brow. “And you can’t get us home?”

The expression on Steve’s face turns blank. “No.” He purses his lips. “Unfortunately, The Network only supplies the equipment and the system which enables communication between approved devices. What you do with them is entirely your perogative and responsibility.”

“But you can get to us!?” The former Maquis leader shouts while pounding his console with one fist.

Looking back down at the deck with his hands clasped behind his back, the hologram says, slowly, “It’s… complicated. Particularly the special effects part.” Chakotay is about to say something when Steve raises his finger, “But remember, I’m not really ‘here’. I never ‘got’ to you,”  he gestures air quotes, “because my program has lied embedded within your starship’s mainframe since you installed Starship OS 9.”

“Dammit, I knew we shouldn’t have updated!” Ensign Harry Kim inadvertently exclaims.

The Captain takes two steps forward and interjects with stern clarity, “Gentlemen, this is ridiculous. Enough of the chit chat. We still have a long way to go before we reach home, and this is wasting precious little time.”

Janeway takes a moment to survey her crew, then faces the parasitic hologram. “What do you want me to do?”

Steve smirks, “I thought you’d never ask!” He reaches around his back and then walks towards the Captain with hands outstretched. He is holding a thin, glossy tablet displaying two lines of text and large, pill shaped button.

Hello, Voyager!

Accelerate your journey with the latest tools and features found only on Starship OS X:

Click Here to Upgrade Your Starship

“Assuming you agree to the terms and conditions, all you have to do it click this button. I will then automatically install Starship OS X.” He taps the edge of the tablet for emphasis. “Easy, right?”

Janeway steps closer to Steve, reaching for the tablet, and taps the tiny link labeled Terms & Conditions, just below the big, purple pill. A new overlay appears: a single column of inscrutable, tightly spaced lines of gray text against a solid, white background. An indicator shows ‘Page 1 of 97’. She sighs.

“Captain?” Tuvok asks.

Without looking up at the Vulcan, Janeway responds, “Yes Commander?” She begins to scroll through the pages, scanning for headlines or anything set in bold type.

“If I understand correctly, Captain: By pressing that button, you will effectively be handing over all of Voyager’s data transmissions to the Starship Interstellar Travel and Communications Network, a multigalactic corporation whose primary investors include our most ardent enemies, in exchange for a slightly better Operating System than we had before?”

Janeway closes the window and returns to the original screen. “Yes, Tuvok” she responds with utter resignation.

“And if we don’t upgrade, then we will be stranded – perhaps indefinitely – in the Delta Quadrant?” the Vulcan asks with his eyebrows pinched together.

“Ostensibly, Commander,” she states impatiently, nodding to Steve, who is watching the exchange with great amusement.

“That is illogical, Captain,” Tuvok retorts.

“Agreed.” Janeway takes a deep breath in, smooths the sides of her perfect bun, and pivots to face the well-dressed figure of diffracted light. “But we have no other choice.”

Steve extends his arms to present the brightly lit screen. “Done with the chit-chat, Captain Janeway?” he teases.

She looks squarely into his holographic eyes, unsmiling, and presses the purple button.

Promptly after tapping the screen, another shock-wave rips through Voyager, knocking the crew onto the deck of the bridge one more time. Tremors continue for a few more moments, reanimating objects that had previously fallen. On the main monitor, stars reappear as the black void collapses, pulling the spiraling fingers of luminous, purple vapors inward like an enormous drain. The aberration quickly shrinks, much faster than it had appeared, until the hole itself closes into a pinprick, culminating in a brief flash of violet light. As the crew stands to their feet and regain their composure, Steve is still standing in his original position.

With an apologetic tone, he breaks the silence, “So sorry – I’ll have to talk to the User Experience Team about that.” Then, flashing a toothy grin and raising his hand to wave, he bids farewell. “Thank you, Captain Janeway! It’s been a pleasure!” Steve’s form bursts into a spinning vaporous tower, before collapsing onto a single point of light. He is gone. Abruptly, all the displays on-board flicker, producing new, beautiful interfaces. A message appears above on the primary screen:

Welcome to Starship OS X

Nobody says a word at first. Ensign Kim raises his fist and coughs, once.

The image on screen dissolves into the familiar canvass of black, punctuated by endless stars in all directions.

Janeway stands tall before her chair, relieved and confident once again. She looks intently into the deep of space and begins to command, “Lieutenant Paris–”

“Captain?” Tuvok interrupts, again. He cannot let the conversation go.

Without blinking, Janeway answers, “Yes, Commander?”

“I still do not understand why everyone in the known Universe would allow their activity to be broadcasted to opaque, corporate entities — which will now have control over our starships and communication systems — in the name of cheap, abundant access to the latest technology.”

The Captain closes her eyes, but otherwise remains completely still. “Rational or not, it’s the reality we have apparently created.”

Tuvak raises a skeptical eyebrow. “Then it is unfortunate that we failed to consider whether this is the reality we really wanted.”

Janeway opens her eyes, looks over to her Lieutenant, and concludes the discussion.

“Tom, resume our previous course. Warp 9.”

“Aye Captain,” he responds happily.

Kathryn turns to gaze at the image of space on screen. It no longer seems so infinite.