5 Organizational Theorems of WeSpire Engineering

On the Shoulders of Giants

If you haven’t read Netflix’s culture SlideShare, Valve’s employee handbook, or the Redis Manifesto, then stop reading this and go read them now. Ok, great to have you back.

You know why those are all amazing? They make a bold statement about what each of those organizations aim to accomplish and why. They describe cultures that are simultaneously appealing as an outsider and easy to assimilate into as a member. They each contain principles that elevate themselves above the banal corporate anti-culture, representing a radically different way of doing business. We want that.

Theorems > Values

In part this is related to the values that each company holds. But corporate values are axioms — you don’t need to defend them with evidence in order to justify their adoption. And therefore, while choosing the right values can influence a company’s culture, we believe our organizational principles tell a much more accurate and interesting story about what makes our culture unique. They are kernels of hard-earned wisdom gleaned from practice, data, and academic theory, and subject to constant revision and improvement.

Source: WeSpire’s Mission, Vision, and Values

The following includes a collection of some of these theories, as a guide for others into how we make our decisions. And I’ve also provided sources for many items, to help illustrate where each of the concepts originated.

1. Invest in Developer Joy

Make Coding Enjoyable

I’m humbly paraphrasing the Redis Manifesto here. Writing code can be really difficult work, so we try and offset that by striving to make it as enjoyable as possible.

Use Natural Motivators

Coincidentally at WeSpire, our job is to help our clients engage their employees. Intrinsic motivators are powerful tools that we encourage our clients to use. Just as we build those tools into our product, we use them to make our own work rewarding.

Intrinsic motivators have been shown to produce greater returns and stronger outcomes than extrinsic. Some that we encourage are:

  • Autonomy — the ability to control your own work, day, and destiny
  • Competence — the desire to feel that you have mastered or are mastering a skill
  • Group Relatedness / Identity — the desire to be part of a group that you care about and that cares about you
  • Greater Relatedness / Purpose — the desire to help the world in a greater way

Extrinsic motivators are certainly less encouraged here, except for one particular type that strongly impacts the work we do as engineers.

  • Influence / Power — the desire to see your work affect others in a way that presents yourself positively

It’s actually the third implicit motivation in need theory, and as an organization you should never discount the individual need for recognition of impact.

2. Decentralize Authority

Decentralizing authority is a fairly standard concept for any organization that has to make complex decisions. Once a problem grows large and complex, it becomes very difficult for one person to see the entire scope. The best way to combat that is to break things down with decentralization. Here are a few ways that we’ve been able to decentralize authority, and where we’ve taken the idea from:

Empower Decision Makers

  • Decisions are made at the lowest level possible — Lean Startup
  • Projects, and the individuals assigned to them, have as much authority as possible to solve a problem that is as high-level as possible — Lean startup

Keep Employees Informed

  • Leadership provides information about how and why a certain decisions are made, but they don’t control whether or not a decision is always made — Netflix Principles
  • Everyone has sufficient information to state what is valuable to the business and why — Netflix Principles
  • Freedom of responsibility — everyone has the freedom to take on almost any additional responsibility if it helps the company — Netflix principles

Use Policies Sparingly

  • Policies are made sparingly. Each one is a line of code. They are made only with experimentation, evidence, and reflection — HBR
  • Remember that you get the behavior that you incentivize. Bad incentives originating from bad policies can demotivate the incentivized behavior and incentives that aren’t fully inclusive will eliminate good behaviors. Sometimes you just have to make a leap of faith instead of relying on bad incentives.

3. Follow the Single Responsibility and Separation of Concerns Principles

These two concepts are found frequently in computer science. They help to make code clean, understandable, and flexible. But just as they apply in building computer systems they apply in building organizations.

  • Whenever possible a responsibility should be delegated to a single person, or at least as few people as possible.
  • Individuals should have as few competing responsibilities as possible.
  • This applies even to time management. Limiting multitasking and providing a single responsibility for a long amount of time allows our engineers to focus. With greater focus we can avoid very costly context switches.

4. Optimize for Learning

This is a concept we’ve borrowed heavily from lean methodology and the Lean Startup. We’re a startup and no startup has a crystal ball that tells which features customers will love most. Instead of optimizing to build features fast, we focus first on what should be built. Here’s how we do this:

Evaluate Data Strategically

  • We use this rubric (influenced by Google HR, HBR, and our company values) to evaluate available information, before making a decision. Ordered from most to least valuable:
  1. Data that supports well understood theory
  2. Quantitative evidence
  3. Qualitative evidence
  4. Academic literature research
  5. Theory
  6. Internet researched support
  7. Opinions
  • Questions are encouraged, but you should respect the time of others and yourself. If you ask a question is it worth the context switch for someone to answer? If you don’t ask the question are you wasting your time? Frame your questions so that you learn the answers to potential future questions you may have. — WeSpire values

Manage Risk

  • Have a plan, but expect that your plan will have inaccuracies and unknowns.
  • Determine your riskiest assumption and make a plan to test it as quickly as possible — Lean Startup

Communicate Efficiently

  • Communicate all information multiple times. Repetition is key to learning, and we want recipients to retain as much of our message as possible.
  • Reflect on everything, both successes and failures. Celebrate success, and don’t blame people for failure. A culture of blame is an easy trap to fall into, so it’s important to remember that all individual failure is also group failure. There are always many systems at play, and no one should just be expected to know better.
  • Everyone should have access information about what the entire company is working on, but only be responsible to know the precise details of their own projects. At WeSpire we keep sprint documents, plans, designs, and retrospectives easily available to the company, but only the engineer/product teams that own the sprint are expected to have total mastery of those documents. — Buffer, WeSpire values

5. Eliminate Bottlenecks

Here I borrow again from my experience in computer science and in particular performance engineering. However, finding and eliminating bottlenecks is a well understood concept in any process optimization.

Avoid Blockers

  • Almost no one is entitled to slow down or block processes they don’t own. Our natural response as humans is to get involved whenever possible. But sometimes adding one more person to a process just ends up slowing information flow into a bottleneck.

Work Together

  • No one should have a monopoly on any skill or authority unless absolutely necessary. Skill redundancy is helpful on many levels. On the WeSpire engineering team everyone is full stack and no one has a job title that grants exclusive access to any particular type of work. This way we’ll always have overlap for code review, for when people leave on vacations, and for when there is far more front end work than back end.
  • Simultaneously the group should still possess a diverse set of skills and perspectives. — Kellogg
  • Work is most easily managed sequentially, but all members must be able to manage some level of parallelism because no one should ever be 100% blocked.

Work Smarter

  • Find solutions that fit the 80/20 rule first then determine if you need to do more. For almost any kind of task you can usually get 80% of the goals completed with just 20% of the work. Deploy that 80% solution as soon as possible. Don’t let all that value be blocked while working towards achieving 100% perfection.

* * *

Thanks for reading! Did we miss anything? Do you do it differently on your engineering team? Let us know in the comments.