Three-Legged Leadership

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

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

Maybe you’ll find it helpful too.

+++++

THESIS

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

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

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

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

Now let’s look at each step in detail.

STEP 1: Be strategic

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

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

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

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

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

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

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

 

STEP 2: Get input.

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

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

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

A few examples:

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

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

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

A few more examples:

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

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

 

STEP 3: Be decisive.

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

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

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

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

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

+++++

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

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

Transparency vs. Efficiency

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

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

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

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

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

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

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

The benefits of transparency

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

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

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

The costs of transparency

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

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

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

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

The benefits of efficiency

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

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

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

The costs of efficiency

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

By focusing only on efficiency, the costs will be:

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

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

The solution is not a formula

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

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

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

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

Conclusion

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

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

Departments vs. Project Teams

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

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

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

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

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

Some background

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

blog_post_image2

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

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

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

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

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

  • Hiring the right people
  • Keeping those people happy

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

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

What happened?

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

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

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

blog_post_image3

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

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

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

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

What was the perceived problem?

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

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

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

And that’s where we failed.

What was the actual problem?

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

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

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

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

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

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

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

What were the lessons learned?

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

Absolute size doesn’t matter

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

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

Autonomy is relative

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

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

Self-organization is a soft principle without a hard application

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

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

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

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

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

Flexibility is an illusion

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

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

As for departments…

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

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

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

What’s the solution?

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

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

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

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

blog_post_image4

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

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

  • transparent
  • fast
  • effective

Now pick two. No, seriously.

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

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

Conclusion

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

Kill Your Babies

How being ruthless can make you a better Product Designer.

As a young designer, my approach to assignments resembled family planning: I conceived ideas, developed frameworks, and delivered polished interfaces to an expecting client. It was a “waterfall” approach to creative production, an artifact of agency-thinking.

While a methodical process, it was also a painful one.

So much thought and polish went into any one idea that changes were often gut-wrenching, time-consuming exercises. Creative Directors criticized the typography. Engineers balked at the technical complexity. Clients freaked over prices. Every slice of their scalpels hurt me somewhere deep inside, regardless of the rational exterior I projected. Some days, I felt like a man-boy raging against the machine, working countless hours to polish designs that rarely made it through production intact.

In retrospect, it’s obvious why everything felt so monumentally difficult:

No one taught me how to kill my babies.

+++++

Lesson 1: How babies are made

Be it a vintage car, sterling sliver flatware, or conceptual mockups for a user interface, all it takes are the right circumstances for someone to form an irrational attachment to an inanimate object. Objects become personal over time by virtue of their familiarity. Subsequent experiences may then reinforce a particular feeling of specialness. Given enough time (and emotional stimulation), the ordinary becomes extraordinary, growing into an out-sized version of reality. Finally, the victim is blinded to any suitable alternative, in spite of all the evidence suggesting otherwise.

That’s when a “baby” is born.

Lesson 2: Why babies are bad

This is fine for weekend mechanics working alone in a garage. Their babies will grow up to become timeless tributes to human invention. Avid polishers of family heirlooms shouldn’t worry too much about their behavior either. In either case, their babies do not require any other approval in order to exist.

For product designers, however, baby-making is an especially unhealthy, disruptive practice.

Creativity comes at an emotional cost for many practitioners – so even straightforward assignments can quickly become personal. In turn, creative people are prone to making babies precisely because they take their work too personally. If those attachments are tolerated or nurtured, small details will soon get in the way of stuff that truly matters, and can cost designers valuable relationships. (Oh the bridges I’ve burned by arguing about typefaces and button styles!)

Lesson 3: Prevention is key

As professionals, we are expected to separate our Self from the problems we were hired to solve. For some, maintaining a professional distance from creative work comes naturally. Personally, I’ve had to learn how to translate what I feel into more appropriate, productive responses.

For example, whenever feedback from a teammate or client triggers an emotional response, I ask myself a simple question:

Is the feedback about the details, the execution, or the idea?

EXAMPLES

  • “Make the filter menu options blue” = about the details
  • “I don’t think users will use those filters” = about the execution
  • “Our users won’t filter” = about the idea
  • “Put more product shots on the home screen” = about the details
  • “Add a gallery” = about the execution
  • “Our mobile app should be more product focused” = about the idea

Based on the answer, I then determine a response according to a few rules:

If it’s about the details, they’re not worth spending personal equity over. Be willing and eager to compromise. Sometimes a designer can gain helpful allies by giving up on small details early on. That trust can be used later, when it is more critical to the success of the project.

If it’s about the execution, the designer should present a stronger case through research and analysis. Nevertheless, it’s not worth a war. Perhaps further exploration is indeed warranted. Or maybe other possibilities were explored, but it was not adequately demonstrated why those options were inferior. When all else fails, basic user testing will settle almost any dispute.

If it’s about the idea, then a designer should defend their idea with authority, clarity, and in terms of how it would advance the goals of their stakeholders. The only people who care about design awards work at agencies. Everyone else cares about effectiveness, efficiency, or scale. How does the idea solve both the business and user problems? How does this idea solve those problems better than other solutions? Does it allow for future growth or refinement?

Through applied reasoning, I can identify my pet-attachments more easily – and then smother them quietly before they develop limbs! The real secret is to do this every single time. Consistent practice has lessened my sensitivity over the years, and has allowed me to develop new, automatic responses.

Still, some babies will survive – which is why I test early and often. Overwhelming negative results diffuse strong attachments better than any self-help exercise. Yet I’ve also learned (the hard way) that any testing will have its limitations.

Lesson 4: Testing is a tool, not a solution

Agencies are hired to produce a final product, so they typically reserve user testing for the end to “validate” their vision (if at all, and only if the client pays for it). By the time real users actually experience the final product, both the agency and the client have usually moved on, and how it performs matters only insomuch as it leads to another Statement of Work.

Product companies tend to do the opposite. “Big ideas” are costly, resource-hungry, and technically complex to implement. Unless the company is building something from scratch, there’s already a core product fully developed. As such, most testing is tactical by nature, pitting one variation against another to find the most “optimal” solution. Unfortunately, while classic A/B testing is great for refining details or exploring alternative executions, it is not an ideal methodology for comparing different ideas – especially big ones.

This is when moderated studies or field research become critical to fleshing out a larger story. Moderated studies can provide detailed feedback, personal anecdotes, and measurable outcomes about specific product features. In-home interviews can reveal more about how users think about the Web generally, or how it intersects with their daily experience. However, there is one notable disadvantage to “going deep” like this: Scale. Most of these include less than 12 subjects. That’s hardly representative of any single audience, let alone several.

In other words, research will point in a general direction, but rarely reveal the final destination. In fact, research may lead the researcher astray, and even reinforce babies through favorable results.

For this reason, I’ve started using a simple framework that consistently yields the most meaningful results, without injecting my personal biases into the outcome.

Lesson 5: Results depend on the strategy

There are three basic types of user tests…

  1. Unmoderated tests are task-oriented, and measure the success or difficulty users have completing a specific action. Most tests take only a few minutes to complete, and all inputs are measured to identify pain points or confusion. Results are available immediately.
  2. Self-moderated tests are those in which testers talk out loud as they perform a task or answer questions. Their inputs, voice, and activity on screen are recorded. Quantitative data is rendered as charts and graphs for instant analysis, but videos must be viewed, transcribed, and analyzed by a human. Although final results and analysis take longer to complete, the information gathered is rich with user sentiment, candid commentary, and deeper insights.
  3. Moderated tests require a professional researcher, real people, and often a living room environment (in-home, or recreated at a testing facility). The researcher guides testers through a set of tasks and asks open-ended questions in real time. Tests of this nature last anywhere from 45 minutes, to an hour and a half. Once all the sessions are complete, the researcher gathers those results and produces a detailed presentation – complete with background, personas, data, analysis, and recommendations. The time and money required to conduct just one moderated test with several participants is substantial, and in-home “field studies” are exponentially more expensive.

Since each methodology has inherent limitations, a designer should likewise have a strategy for what to test, when, and how. (Otherwise they consume all their resources for minimal benefit.)

Taking all this into consideration, the following is now my approach to testing:

Use moderated tests to identify new opportunities, or a common user problem. They will capture how real users feel about real products on the Web, while still leaving plenty of room for innovation. “Big ideas” should ideally spring from this well of research, or at least directly solve the user problems identified therein.

Use self-moderated tests to vet proposed executions of a particular idea. This is how I seek and destroy every baby possible. Intentionally pit competing executions against one another, measure them equally, and evaluate the results impartially. If done well, the winning execution should determine the best place to start iterating.

Use moderated tests to fine-tune the experience. Once the Big Idea has been distilled into a minimum viable product (MVP) that real users can interact with – that’s when rapid, tactical testing helps me refine the interface or simplify the experience. I fully aware that nothing is ever perfect, and even the best solution now may not be a good one later. But by testing every feature, at some point, I find it easier to spot deficiencies that warrant moderated testing. Sometimes problems resist my solutions altogether, and moderated studies become necessary for further insight.

So far, applying this formula has killed nearly every baby I brought with me to Mozilla, and has helped me abort the ones I’ve made since.

Final Analysis

As a product designer, I will always feel a sense of “ownership” over the things I create. I may take things personally, or secretly harbor inappropriate feelings on occasion. At least now I have the tools to avoid making babies when possible, and ruthlessly weed out the ones I’ve been secretly protecting.

These days, I care more about idea babies than the design babies. Design details can be modified far easier than overarching ideas. Getting regular feedback from users enables me to let go when it’s not critical, and dig in when something is.

Of course, I’ve only learned to develop this perspective the hard way… After fighting too many of the wrong battles.

So don’t be like me. Don’t let your babies become bigger problems later on, and get in the way of work that matters.

Be ruthless from the beginning.