```yaml
---
slug: manifesto
published: 2015-04-13T00:00:00.000Z
description: An Engineer(ing Manager)'s Manifesto
changelog:
  - on: 2017-03-01
    note: Added "Optimize for people" to the manager's manifesto
  - on: 2019-01-01
    note: As I moved back into engineering, I refined my expectations of myself as someone writing code full time
  - on: 2021-02-14
    note: Removed the comment about escape velocity, as opportunity implies that
---
```

When mentoring other developers and managers, I get asked a lot what process I go through when I am picking my battles. To be honest, the one consistent thing I look to is my manifesto. [Defined](http://www.merriam-webster.com/dictionary/manifesto) as "a written statement declaring publicly the intentions, motives, or views of its issuer," a manifesto is a powerful way to communicate your values and beliefs. While I have a personal manifesto for my everyday life, I have this easily accessible where I do my work.

As I get better at putting my beliefs and values into words, this will continue to evolve.

## A Programmer's Manifesto

> Act ethically in & out of code.
> Your comments are missives to both your future self and to others.
> Think globally, code locally.
> Quality begins with the API. Quality ends with the experience.
> Always value the work of others.
> Testing tests the problems we know we know.
> Do not miss opportunities to learn.
> The existential nature of all code is to solve a problem.

## A Manifesto of a Manager

> Leadership is not management.
> Talent is not infinite.
> Optimize for people; the work will follow.
> Success is the success of others.
> Create opportunities.
> Act with the highest integrity.
> Remember you once wrote more than emails.

Removed the comment about escape velocity, as opportunity implies that

Document

As I moved back into engineering, I refined my expectations of myself as someone writing code full time

Added "Optimize for people" to the manager's manifesto

Link

blockquote

Manifesto

```yaml
---
slug: rfcs-ftw
published: 2017-11-01T00:00:00.000Z
description: A lightweight process that embraces the oldest consensus tool on the Internet
changelog:
  - on: 2022-03-09
    note: Moved the RFC repository to my personal github
  - on: 2020-02-21
    note: This article has been updated to point to the new URL location of the RFC repository
---
```

If you're already onboard with RFCs in your engineering org, [skip straight to github](https://github.com/jakobo/rfc) for a turnkey RFC process you can use.

When I first set out to [kill the status report](__GHOST_URL__/fix-the-status-report), the goal was for us as engineers to move away from the "what" and spend more time documenting the "why". Two and a half years ago, the idea of **whydocs** gave a name to source-committed rationale behind our technical decisions. This idea found its way into Agile methodology as Architecture Decision Records (ADR). Both whydocs and ADRs share a common problem. Companies with these tools in place are only capturing what was decided, not what was considered and decided against.

The answer to sharing ideas and intents resides in the oldest consensus tool on the internet, the "Request for Comments" (RFC). With an open, timely, non-authoritative design, RFCs not only capture what was decided, but what wasn't decided, technical ideas, and general thoughts about engineering. The broad application of RFCs makes it a stronger choice than whydocs and ADRs for capturing decisions in your engineering organization.

It Began With a Memo

In 1969, Stephen Crocker sent a memo to his partners creating a collection of connected machines known as ARPANET. In a [2009 op-ed](http://www.nytimes.com/2009/04/07/opinion/07crocker.html), Steve described his anxiety about publishing the notes of the informal working group, worried that "we might sound as though we were making official decisions or asserting authority." To minimize this perception, Steve titled the collection of ideas a "Request for Comments."

In the [third such memo](https://tools.ietf.org/html/rfc3) he sent, Steve explained his reasoning and set forth simple guidelines.

![RFC-3, Replicated in text below](https://user-images.githubusercontent.com/1795/146832281-e51c0697-a84a-4183-8771-3b5cb499cf4a.png)

> Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series.
> 
> CONTENT
> The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a NWG note is one sentence.
> 
> These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas. Second, there is a natural hesitancy to publish something unpolished, and we hope to ease this inhibition.

In these three paragraphs, a significant amount of procedural red tape could no longer take hold.

1. Anybody can create a note and have it included, regardless of length
2. Notes should be timely, not perfect
3. These are non-authoritative, non-binding ideas

For almost 50 years now, the RFC has persevered. Not only does it remain the standard way of proposing ideas for the groups created in the wake of ARPANET, but the use of RFCs has expanded to many modern languages and frameworks including [Rust](https://github.com/rust-lang/rfcs), [React](https://reactjs.org/blog/2016/04/07/react-v15.html), [Ember](https://github.com/emberjs/rfcs), [Python](https://www.python.org/dev/peps/pep-0001/), [Chef](https://github.com/chef/chef-rfc), and others. Every group that has adopted RFCs has sought to further democratize ideas and increase transparency within their organization. It's time for Engineering Organizations to enjoy these benefits.

## RFCs In Engineering Organizations

We intrinsically know that the strongest ideas are not born in a committee or a council, but instead from individual engineers solving difficult business problems. Yet when we find ourselves repeating work, ideas, and effort, we create governing bodies that attempt to exert control over our organization.

**Architecture Councils** are formed in order to approve or bless ideas, yet these autocratic groups often tear themselves apart due to a lack of authority or a lack of individuals wanting to interact with them.

**Guilds** are created when there's a common thread everyone shares (language, stack, framework) in order to pitch ideas and build consensus. These are synchronous events and discussions containing key decisions are rarely recorded.

**Chief Architects** are hired and are placed into roles where they must dictate decisions outside of their domain, driving engineering efforts underground.

A better answer to all of the above is an open process where anyone can submit ideas, get feedback from peers, and know that the collection of ideas is neither binding nor authoritative. Thankfully, for this process, we can return to the humble RFC. The three intents of the RFC process embody what we value in a transparent and collaborative engineering organization.

1. Anyone in the organization can propose an idea, regardless of length
2. Proposals should be timely, not perfect
3. These are non-authoritative, non-binding ideas

RFCs are a tool that gives us an alternative way of building consensus that favors modern development practices.

The key to the RFC's success in an engineering organization is the lack of friction. An ideal RFC process for a modern company leverages the minimum set of tools any engineer has on hand: an editor, a source control tool, and a code review system. Anything beyond these three items is extra-credit. The goal is to make it as easy as possible to publish ideas and collect feedback.

## Bringing RFCs to Your Team

Your first RFC does not need to be so ambitious as to turn the entire company on to the idea of RFCs. Local teams benefit from recording and broadcasting their intent for architectures, changes, and ideas regardless of the culture or climate around them. If you're a direct manager or an engineer, you have the power to take the first step.

That first step is (naturally) to create your first RFC and share it, just as Stephen did in 1969. If hand delivered letters aren't your style, the [RFCs for Engineering Organizations git](https://github.com/jakobo/rfc) we use at Aibex has the why, the how, and even RFC-1 titled "using rfcs" ready for distribution. Just fork the repository, answer the open questions, and publish to your company's code system. From then on, just take a few moments to capture your team's ideas and share them as RFCs.

Before long, other teams will notice. When you encourage them to participate and share their own ideas, your RFCs will gain momentum and visibility. Eventually, you'll achieve the open honest communication and democratization of ideas that is key to engineering organization health. All because you made a Request for Comments. Our organizations deserve nothing less.


Moved the RFC repository to my personal github

This article has been updated to point to the new URL location of the RFC repository

A lightweight process that embraces the oldest consensus tool on the Internet

strong

RFCs FTW

```yaml
---
slug: reverse-engineering-decisions
published: 2018-06-19T00:00:00.000Z
description: We can always go back, if we plan just a little ahead
changelog: ~
---
```

Prior to 1995, the idea of a "Type 2" decision didn't exist. In a [letter that year to Amazon shareholders](https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm), Jeff Bezos explained that all decisions at his company fell into one of two buckets. The first bucket he labeled "Type 1" and reserved for decisions that are irreversible (or nearly irreversible) and frequently have an outsized impact on a company. Everything else he defined as a Type 2 decision.

Type 1 decisions do exist, and they must be considered carefully. But that wasn't his concern; rather, Bezos was afraid that innovation at Amazon would stagnate and the company would lose momentum if they went down a path of applying Type 1 processes to **every** decision, including the reversible ones. The reality is that most decisions do not require extreme scrutiny, nor do most decisions put companies at risk based on their outcome. Most decisions are Type 2.

Because Type 2 decisions can be made quickly by high judgement individuals, these decisions help a company to be more agile. That certainly sounds like how we want engineering decisions to unfold.

Yet almost every engineering organization has fallen prey to applying Type 1 decision making to all of their decisions. All of us, often with the best intentions, have slowed down our decision making on the basis of risk then paradoxically rushed products to market without any idea of how to undo our decision if it doesn't bear fruit. With either of these two factors in play, every engineering decision suddenly looks like a Type 1 decision.

We need to get back to Type 2 engineering decisions.

## Engineering Decisions Aren't Type 1 (mostly)

Most engineering decisions aren't Type 1 decisions. As Bezos describes it, Type 1 decisions are "one-way doors… If you walk through and don't like what you see on the other side, you can't get back to where you were before."

![Racoons leaping from a kitchen cabinet to attack a person](https://user-images.githubusercontent.com/1795/146839478-6bcc5a50-9dce-468b-b750-7ea953f401cf.png)
_Most code changes won't be this scary_

We've sent humans to the moon. In comparison, bringing code back to its original state is trivial. Database migrations, selecting programming languages, and even choosing a cloud provider can feel on the surface like unidirectional paths. But databases have backups, languages can be changed later (you'll rarely ever be a single-language company anyway), and containers have made it easier than ever to change hosts. These decisions are not without cost, but they are certainly reversible.

So if engineering decisions are inherently Type 2 decisions, why would the following pitch fail at almost every company?

> We're redoing the chat system next month. I know we're mostly a Java shop, but I think we should redo the backend in Clojure. [insert the reasons for Clojure here]

There are a dozen different reasons why this proposal might fail. Most of those reasons will never be tested, though, as organizational bodies such as Guilds and Architecture Councils, along with systems such as Releases Checklists, are designed to say "no" to these ideas. While well intentioned, these are the systems that create additional process and hurdles that prevent change from even being attempted in the first place. The end state of most of these bodies is a heavyweight Type 1 decision-making process.

You don't have to go out and disband your Architecture Council, but you might want to change their charter. To return to Type 2 decision making, these groups can stop throwing up roadblocks to change and start focusing on how to help engineers make safe, reversible decisions by considering and controlling risks and by making it possible to reverse these decisions later.

## Controlling for Risk by Controlling Cost

Every company takes risks, gambling that the benefit of a feature or technology will [outweigh its cost](http://firstround.com/review/this-matrix-helps-growing-teams-make-great-decisions/). This risk is often hidden behind questions about how much something will cost or how long it will take. Cost and time are stand-ins for risk. For products and features built on established technology, the cost of developing a feature is always proportional:

`Cost of Feature = k * Cost of Product`

This is the normal equation for building features. When technology is known and constant `(k)`, the cost of the feature grows proportionally to the complexity of the product. However, this all goes out the window when we use a new technology to deliver a new product.

`Cost of Feature = Cost of Technology * Cost of Product`

Not only have we lost the only constant in the equation, but now any increases in the cost of a feature are difficult to clearly attribute to either the product or the technology. Engineers who have attempted to re-architect something while adding new features can explain firsthand how rapidly feature cost can grow.

![A thread through a needle](https://user-images.githubusercontent.com/1795/146839619-b9d544d3-8f4d-4ae6-9c68-49724b40f40f.png)
_There's an analogy here, but let's just settle on "the cost of an engineering decision has business impact"_

Coupling engineering decisions with the product makes it impossible to control for cost. Being unable to control for cost then creates an unmeasurable amount of risk. Aversion to this risk, the likelihood that the benefit will no longer outweigh the cost, especially when it is poorly quantified or largely unknowable, drives us towards Type 1 decisions.

But if we [change only the technology](https://engineering.gusto.com/the-shortest-path-is-the-scariest/) without changing features simultaneously, we return to a manageable cost and therefore a manageable amount of risk:

`Cost of Engineering Decision = k * Cost of Technology`

`Cost of Technology = Time in Production * Scope of Deployment`

When we are not iterating on the product `(k)`, the cost of an engineering decision is proportional to the technology cost. And as engineers, there are two levers we use to control technology costs: How long the decision is in production, and how widely deployed the decision is. These can be controlled for by placing caps on decision time and scope of deployment.

Limiting the time in production ensures that even less than optimal decisions will be revisited after a known interval of time, while limiting the scope of deployment ensures that the number of systems affected by our decision remains small until the change has been validated. This is critical should we revisit the decision and decide we need to reverse or change course.

However, just controlling for time and scope by themselves will not make Type 2 decision-making possible. We also need to eliminate that one-way door: If a decision does need to be reversed, we must be able to reverse it.

## Reversible Engineering Decisions

"We can't undo the change" is a statement based in fear. The idea that you cannot return to a previous state is nonsensical. It might take a tremendous amount of work, but it's never impossible.

However, without a realistic plan to go backwards, any engineering decision will suddenly look like a Type 1 decision, regardless of how well we have controlled the costs of the decision. The problem of reversing engineering decisions is solved with the domain of engineering:

- Is there a backwards compatible way to do this?
- Can we minimize the number of impacted systems?
- Can we reverse the code without negative repercussions?

![Signs pointing in various directions](https://user-images.githubusercontent.com/1795/146839761-c03f0c02-0dce-4925-90bb-1d1c9fbf799a.png)
_Again, with the stock photo analogy. Seriously though, knowing how to **get back** makes going forward easier_

For most changes, even complex ones such as selecting cloud providers or introducing new languages within a company, these questions are finite in scope and straightforward to answer.

First, we should always consider whether there is a backwards compatible way to accomplish our goal. Any decisions that are backwards compatible with existing systems are inherently reversible. An API, database, or other system that can be disabled without negative side effects means that reversing the decision is as simple as changing a configuration.

Then, we need to limit the number of systems involved. Decisions that limit the number of impacted systems will be easier to reverse should we decide to. Large technology efforts can be broken down into individual systems to test and validate. Should we decide to reverse our decision, this reduces the number of steps we must take to undo a change.

Finally, we need to articulate and document the steps involved in reversing the code. In simple cases, this might be as straightforward as ramping down the traffic to a service or endpoint. In more complex cases, it may involve invalidating caches, notifying business partners, or doing the reversal outside of core business hours. If you've been here a while, you know I'd [recommend RFCs](https://codedrift.com/thunked/rfcs-ftw) for the job.

By making it easier to to reverse an engineering decision, we make it easier to treat the decision as a Type 2 decision.

Now we have answers for the scope, the shelf life, and the reversal path of our decision. To actually carry out the Type 2 decision, we must now write it down, act upon it, and report on the results.

Putting Type 2 Engineering Decisions Into Practice

Let's return to our earlier Clojure example. An organization focused on helping people get to "yes" instead of saying "no" wouldn't stop the deployment of Clojure into production. Instead, the group would facilitate the answering of important questions:

- Why are we making this decision?
- What is the maximum amount of time we will run with the decision before reevaluating?
- What is the minimum scope necessary to produce sufficient learnings from our decision?
- How will we return the systems to their original state if necessary?

Accountability would necessitate that if you're the individual who wants to bring Clojure to the company, you've spent some time thinking about these questions and have made an honest effort to answer them. Once these questions are answered, estimating the risk and making the decision becomes much simpler.

![A remote showing a prominent Netflix button](https://user-images.githubusercontent.com/1795/146839850-d9e40817-a6f3-4b81-86e7-3c10b2e2ff6b.png)
_Netflix (featured here) does Type 2 decisions well_

There is no better example of Type 2 decision making in practice than at Netflix. In Los Gatos, the company champions a culture of Freedom & Responsibility. Outside of some basic guardrails (don't create irrevocable disasters; don't cause moral, ethical, or legal issues), engineers have the freedom to make whatever engineering decisions are necessary in order to move the company forward.

At Netflix, [engineering teams make their own decisions](https://medium.com/netflix-techblog/engineering-trade-offs-and-the-netflix-api-re-architecture-64f122b277dd) and are responsible for their own code from inception to deployment to operations. Instead of losing themselves to an endless debate around whether an engineering decision is correct, the company prioritized the ability to recover quickly from wrong decisions.

And it worked.

Netflix Engineering has continued to grow and innovate, winning [numerous awards](https://www.comparably.com/companies/netflix/awards) and strong employee scores for its culture all the while.

You don't have to be Netflix or Amazon to get your engineering team back to making Type 2 decisions. Start simple by asking folks to get their reasoning behind proposed changes down in writing using the questions above as a guide. Answering "why," "how long," "how much," and "how to return" goes a long way towards controlling the cost (and concomitant risks) of decisions and ensuring you can have the same kind of rapid response that companies like Netflix enjoy.

In answering these questions, insist on written communication over oral communication. Systems like Architectural Decision Records or a RFC can help you capture debate, discussion, and your learnings. When other engineers understand what you are doing and why, carry out the decision.

Then, when a decision reaches the end of its shelf life, revisit it. If it was the right decision, share what you learned and determine your next steps. If it wasn't, do exactly the same thing, but activate your plan for reversing or changing the decision.

Record it, do it, revisit it.


We can always go back, if we plan just a little ahead

code

Reversable Engineering Decisions

```yaml
---
slug: training-vs-coaching
published: 2018-04-17T00:00:00.000Z
description: The difference between telling and showing
changelog: ~
---
```

A question I frequently get is about the relationship and the differences between coaching and training. I don't believe coaching and training are either/or solutions to most engineering leadership problems. When used in the right context, both coaching and training can be powerful tools for building leadership skills. The critical difference is that coaching focuses on attitude, while training develops adeptness.

## Coaching Develops Attitude

Coaching helps employees overcome obstacles caused by attitude. In other words, when a leader's behavior is creating issues, a great coach provides a mirror that allows the leader to reflect on their actions, motivations, and impact on others. Through well-timed questions, thoughtful suggestions, and sharp insights, a coach helps leaders change their behavior through self-awareness. Coaching doesn't tell you exactly how to be a leader, it allows leaders to develop their unique leadership style.

Coaching, however, must build upon a skill-based foundation.

## Training Develops Adeptness

The foundation for successful coaching is effective training. Excellent training focuses on instruction, skills, and practice to develop the core competencies that create great leaders. Through instructional models and curriculum design, an effective trainer helps leaders reach a baseline in capability. Through training, leaders acquire good habits that are expanded upon later in their career through coaching.

To understand how coaching and training work together to develop talent, let's take a look at two hypothetical leaders on your team, Jan and Sara.

## Helping Jan Overcome Challenge

Jan's a manager on your engineering team, and in this quarter's 360 feedback, you confirmed your gut feelings. Despite having managed teams before, Jan needs help. Jan's feedback packet contains several concerns raised by engineers in his group. The team's concerns focus on the fact that Jan is still writing code and making technical decisions; one employee referred to him as a micromanager. To help Jan, our first instinct is to consider getting him a leadership coach because we see these problems as issues with Jan's management style.

Unfortunately, bringing in a coach to "fix" Jan's problems without any other development plans will fail every single time. Coaching will fail because Jan's issues are likely not rooted in attitude, but in adeptness. Even though Jan has managed teams before, his behavior implies that he does not understand his role as a manager. Coaching excels when self-reflection can be used to initiate change; however, it struggles to provide reflection when the underlying fundamentals are not in place. Getting Jan into a training program for managers that focuses on the expectations and skills associated with his role will give him the tools he needs to change the behaviors that are most damaging to his team while he develops his management capabilities.

Coaching still has an essential role to play in Jan's development. As Jan begins to put his training into practice, he will need the support and insight of a neutral third party who can help him develop his attitude and enable him to see the impact his behavioral changes are having in his team. This development of attitude is where coaching can soar, as the coach no longer needs to focus on skill development.

## Expanding Sara's Expertise

Sara is also a manager on your engineering team. Similar to Jan, you conducted 360 feedback for Sara, but unlike Jan, Sara's feedback was overwhelmingly positive. People on the team felt that Sara was developing their careers, they felt confident in her abilities, and they trusted that she was keeping the team unblocked. To continue to grow Sara's skills as a leader, we absolutely should pair Sara with a coach that can accelerate her development even further.

This situation is ideal for coaching: extending and fine-tuning an individual's existing skills.

Sara could also benefit from the same training as Jan. Failing to include Sara in the leadership training would deprive both her and Jan of valuable growth opportunities, for Sara to [develop her coaching skills](https://www.huffingtonpost.com/entry/the-best-leaders-develop-others-by-coaching_us_58975fc4e4b061551b3dffeb) working with Jan and for Jan to learn from Sara's skillful management practices. Studies have shown that [educational cohorts build significant bonds](http://education.gsu.edu/4-ways-cohorts-models-benefit-graduate-students/) between learners that last beyond the instruction period. Through training, Sara can practice the skills she's developed as a leader and help others in her cohort do the same.

## You Need Both

The decision between training or coaching is a false dilemma. Ideal development happens when you combine both the consistency and foundation of training and the self-reflection of coaching. Adeptness and attitude play equal roles in developing talent. When you embrace both, your leaders can reach their full potential.


The difference between telling and showing

Training vs Coaching

```yaml
---
slug: positive-feedback-matters
published: 2018-03-08T00:00:00.000Z
description: Why giving positive feedback is as important as the critical
changelog: ~
---
```

*Mike spent three days agonizing over the critical feedback. When I caught up with him for coffee, he told me that "giving folks difficult news is awful" and that he often loses sleep over these kinds of feedback sessions during his company's yearly review. To take his mind off of the negative feedback, I asked about Sarah, one of the engineers on his team who performed well above the expectations for her level. "What are you going to tell Sarah?" I asked.*

He hadn't thought about what to tell the folks he valued most.

## The Absence of Positive Feedback

Positive feedback is missing in the workplace. In an HBR self-assessment [survey](https://hbr.org/2017/05/why-do-so-many-managers-avoid-giving-praise), the researchers discovered that one in three managers don't give positive feedback at all. In that same report, researchers demonstrated that managers who felt they gave "honest" feedback strongly correlated with managers who gave any negative feedback. A reasonable conclusion is that, like Mike, most leaders believe that their job is to be critical.

Believing that as leaders our job is to be the voice of criticism is a mistake. Not only does a lack of positive feedback result in less engaged employees, but it also affects employee's relationships amongst one another. High performing teams [share six times more positive feedback](http://journals.sagepub.com/doi/pdf/10.1177/0002764203260208), while low performing teams share twice as much negative feedback as their peers.

Thankfully we already possess all the tools necessary to deliver effective positive feedback. They're the same tools we leverage when we need to have our more difficult conversations.

## Prepare

**Make The Time:** The most critical thing you can do is allocate the same amount of time for positive feedback as you do for negative feedback. [Scheduling time on your calendar](http://www.lifehack.org/articles/productivity/scheduling-time-blocks.html) is consistently the most efficient way to ensure uninterrupted time to focus on feedback, both positive and negative.

**Involve Others:** While most companies have formal peer reviews as part of their performance cycles, there is no reason to limit feedback to only those channels. Seeking out folks impacted by the team's work will help you share praise through the eyes and words of their peers. Direct quotes are even better. 76 percent of people surveyed in a study by Make Their Day/Badgeville found that peer recognition was extremely motivating. Anecdotally, just need to reflect on the last time a peer told you how much value you were adding and how that made you feel.

## Deliver

**Be Precise:** Be as specific as possible when you are identifying positive feedback. A generic "good job" doesn't explain to an employee why their work mattered, the importance it had, or the impact it created. Just as negative feedback explores consequences, so too should the positive things that folks do. When involving others in collecting feedback, ask them first for specific details and second why it mattered.

**Be Sincere:** Just as when you deliver critical feedback, you must be genuine. Being insincere about positive feedback [can be worse than no feedback at all](http://connection.ebscohost.com/c/articles/20185233/cognitive-asymmetry-employee-emotional-reactions-leadership-behaviors). In the study conducted by Dasborough, she observed that when an individual delivered positive feedback with a critical tone, individuals felt worse about their performance compared to individuals given straight critical feedback. In short, the delivery matters as much as the message itself.

Positive feedback isn't optional. Similar to how we [recognize and reward employees](./recognize-and-reward), it's a valuable action that we can use as leaders to help reinforce the culture and behaviors we want to see in our organization. Spending as much time on positive feedback as critical feedback not only helps motivate the team but keeps them engaged and aware of the value they're providing every day.


Why giving positive feedback is as important as the critical

Positive Feedback Matters

```yaml
---
slug: reward-and-recognize
published: 2017-10-12T00:00:00.000Z
description: Why your spot bonus program might be hurting, not helping
changelog: ~
---
```

![Pinterest's recognition coins](https://user-images.githubusercontent.com/1795/146831832-f140bae4-ef9e-46cf-abc2-3196000051b4.png)
_Pinterest recognition coins. Personal tokens that carried important meaning._

It's deceptively simple. Your employee survey says folks don't feel recognized, and so your HR team helps you develop a bonus program. In rolling it out, you tell your leadership team this bonus is for folks who go above and beyond the expectations of their role. Fast forward a few years, and we're horrified to learn that the bonus program is at best ineffective; at worst it became a point of toxic culture itself! We just wanted to help people feel like their work was appreciated, but nearly every reward program contains one of the following mistakes.

**A Purely Monetary Reward.** Unless the bonus is a very significant amount, bonus reward dollars get lost in the pay stub. As a leader, you owe it to your team to seek out better ways to recognize folks in line with the values of your company.

**Lack of Input.** If we are only recognizing the individuals we see, then we are ignoring a large portion of the work (and the individuals) we don't see regularly.

**Rewarding Above and Beyond.** Finally, the criteria often used to define these recognition programs is incredibly subjective. To make matters worse, we often describe it as going "above and beyond" expectations without defining either "above" nor "beyond". As a result, we end up subjectively picking conditions that may not emphasize the culture we want.

None of these by themselves will kill an engineering organization. But here's an actual cause and effect. A company I wager most folks are familiar with built a spot bonus program where the manager had a $3000 use-it-or-lose-it budget to issue bonuses to any employee they felt was "exceeding the expectations" [sic]. Nearly every manager used this system to reward employees in $500 increments for shipping large projects, regardless of the project's success or adoption.

Today, the company is struggling with leverage and a massive culture of Not Invented Here. Asked to dig into why this was happening, I sat down with the engineers to learn why there was so much value placed on new instead of existing solutions. Immediately, the problems with their bonus program emerged.

1. The $500 award meant nothing to the employees. The "reward" as engineers saw it was a letter they could include in their promotion application which was the key reference point for career advancement.
2. In the larger teams, the extroverted folks were consistently the the ones receiving the recognition.
3. The reward considered "exceeding expectations" as building something new as opposed to using existing solutions.

While this company accidentally made all three mistakes, you don't have to. But if you want to roll out your recognition idea well, the process is going to take both research and time.

## The Reward

The foundation of any recognition program is the recognition, but the vehicle for that recognition is the reward itself. A reward needs to be meaningful, significant, and relevant. If the reward isn't something people actually desire, the program will do a poor job of selling itself. Some of the best rewards reflect the company culture in the award itself.

- Rackspace has a [Straightjacket Award](https://blog.rackspace.com/and-the-straightjacket-goes-to-drum-roll-please), given to only to those who "do whatever it takes to bring Fanatical Support to life."
- A group at Pinterest uses Recognition Coins (pictured at the top of this article) with an antique silver finish, given along with a personal thank you conversation from a skip level manager.
- Blizzard makes sure that employees who stay with the company through the highs and lows of game development take home a [piece of the magic](http://us.blizzard.com/en-us/company/about/service-awards.html) they helped create.

There's no real guidelines on cost here, but seriously, don't cut corners.
If you're having a hard time being creative, sites like [The Noble Collection](https://www.noblecollection.com/), [Thin the Herd](https://www.thintheherdguitars.com/buy-now), and [Ichiban Toys](http://www.ichibantoys.com/) are all great places to start the brainstorming. Involve the team, and you'll end up with something that people want to earn.

## The Visibility

Getting visibility into your organization means doing more than just asking everyone a few days before the next all hands and hoping for the best. It needs to be systematic, consistent, and low friction.

By far, the most common solution to visibility is to get more people involved in the process. With the increased popularity of Slack, tools like [HeyTaco!](https://www.heytaco.chat/) and [Propsboard](http://www.propsboard.com/) make it easier than ever to thank someone. As an added bonus, these newer tools give you a log of every person in the company doing amazing work. (Don't forget that you also need to be using these tools if you want them to become a norm at your company.)

One of the coolest solutions to a lack of visibility I've seen over the years is a physical wall at Pinterest where people pinned up weekly achievements, complete with lighting and sound effects. When visibility is something that feels fun to do, you'll see a lot more involvement from everyone.

Finally, I can't stress the importance of keeping first level managers engaged throughout the process. With weekly 1:1s, and sometimes also being hands-on in the code, these folks have a much better pulse on all the engineering happening in the company and why it matters. Find or make the time in your regular organizational meetings to connect with these folks and feed their information back into whatever universal system for visibility you've adopted.

## The Consistent Criteria

By now, you have something worth earning, and insights into who could be doing things that you'd like to recognize as an organization. It's time for the single most difficult part of the reward system: clear and transparent criteria. It starts with answering the following questions.

- What about this work was significant?
- Who (person or organization) was this work important to?
- If anyone else in the company did this work, would it be just as significant? Why or why not?

What you're trying to do with these questions is identify what specifically is the behavior you are trying to recognize as a company. The number one way criteria systems break down is by rewarding people for going "above and beyond" expectations; it's a vague statement that doesn't consider the value generated or the business importance. The other thing you are trying to do is normalize the criteria. If your company wants to reward leverage, then the criteria for the reward should specifically state that.

Make a spreadsheet if it helps with planning out the criteria. List every criterion down the left hand side. Then, when you evaluate based on this criteria, you can see prior decisions. When (not if) you find a misalignment in your decisions and criteria, flag it, address the difference, and reevaluate everyone with the new criteria.

And if multiple people satisfy your criteria? Then multiple people receive the reward. Consistent criteria ensures you're constantly recognizing people for the right reasons.

## Private Recognition, Occasionally Public

You'll need to select whatever delivery style makes sense for your program and your company. Remember, not everyone wants to be singled out in a company all hands. Before you drag someone up on stage, thank them privately and ask them if it is okay for you to point out their work.

Done right, you can reward the culture you want to become and begin affecting change.


Why your spot bonus program might be hurting, not helping

Reward and Recognize

```yaml
---
slug: the-stairway-problem
published: 2015-05-26T00:00:00.000Z
description: How 12 steps can feel like 12 miles apart
changelog: ~
---
```

One of the biggest transformations a company goes through isn't financial, but physical. Adding, changing, moving, and creating new physical space in an office will change the dynamics of how work gets done. People are at new desks. Things feel fresh. There's reclaimed wood everywhere. There's also 12 steps between two teams that despite their new-found distance are still working on the same goal. It may as well be 12 miles.

Welcome to the stairway problem.

![image](https://user-images.githubusercontent.com/1795/146829468-ef2f5005-8090-43e6-ac9f-bd2957f167fe.png)

The addition of a stairwell in a company is the second biggest physical change a company faces. The largest is moving buildings, but that is more like an organizational blender with four walls and a roof. Physical space separates and divides. As shouting distance becomes impossible, the cracks in communication begin to show. Teams that are autonomous and given enough isolation will evolve independently. Soon the common thread everyone was working on gets lost. You'll find yourself with silos. Most companies solve this breakdown with, you guessed it, a [Status Report](./fix-the-status-report).

## Talent Transfusions

The solution that keeps everyone from building up silos is obvious in hindsight: shifting roles. If a company embraces having people try new things (and creates the means for them to go forth and do so), the silos never get a chance to form.

Transfusion in an organization has some hidden benefits. It forces you invest in onboarding, it makes you have come-together meetings so vision can be shared, and it creates deeper threads that run between the different parts of the organization. You may not have the answer to your scaling problem, but Sally does. And because of transfusion, someone that worked with Sally on another project knows she's a badass and can solve this exact problem you are having. Don't limit yourself to just contributors, either. Management should be moving around as well. Everyone should have the opportunity to see more of the organization.

That doesn't mean moving people ad-hoc and causing disruption. To make transfusion natural, there needs to be some lightweight structure or ground rules.

**Own the transfusion.** Tie up loose ends and provide enough time that leadership (tech and people) can try to find someone else who loves the role you are vacating.

**Be a knowledge bearer.** Understand that not everything is written down. Because you did good work, people will have questions you'll need to answer. There needs to be time made for these opportunities as part of your new role.

## Embrace Your Space
[![The GitHub offices boast casual spaces near meeting rooms, creating accidental spaces for creativity (and communication) to happen. Photo by Ben Scholzen CC by 2.0](https://user-images.githubusercontent.com/1795/146829512-4545e15b-2a8d-4f42-9663-0351477c99e8.png)](https://www.flickr.com/photos/dasprid/8148010408/)

Unless you're Apple, you're probably not going to have the resources to create a [campus free of physical space divisions](http://appleinsider.com/articles/15/02/09/exclusive-february-aerial-tour-of-apple-incs-campus-2-shows-spaceship-ring-rising-theater-progress-more). In addition to a healthy transfusion process at the heart of this, you can steal a page from Apple's philosophy. Make happenstance happen. The more chance encounters teams have, the more likely big problems get caught early.

If you're fortunate enough to be able to reconfigure your space, create natural space that people want to spend time in. Small (unbookable) 2–4 person areas will encourage people to go somewhere to talk, away from their team and into the big bold world.

If you can't knock down walls, you can at least put meetings on another floor. Getting out of your area means exploring and learning where other teams are and what they are doing.

## A Daily Habit

Transfusions and changes in physical space share a common goal: communication. Mixing people up through space, teams, and layout all contribute to the mesh of conversation in the company. It requires rigor until it becomes a behavior.

A post-it on your monitor serves as a good reminder. Make an effort every day. Spend at least a half hour making happenstance happen.

You won't fix all of a company's silos, but you can certainly reduce those that interfere with your team's ability to do amazing things.


How 12 steps can feel like 12 miles apart

The Stairway Problem

```yaml
---
slug: fix-the-status-report
published: 2015-04-18T00:00:00.000Z
description: There are better things for everyone to do on a Friday
changelog: ~
---
```

"I'm sorry, but" I find myself beginning with my team, "we need to do a weekly status email." I feel defeated. Five years into helping people amplify their careers and the best tool I have for sharing our success with the organization is a three-bullet-point mess.

Status Reports (capital S, capital R) are nothing but a source of loathing. They represent a lumbering beast of a company, rife with bad communication and people no longer knowing what the person next to them is working on.

I believe we can fix this.

First order of business: Status Reports are terrible. I'm not the first [[1](https://marklewis3.typepad.com/blog/2014/07/status-reports-are-bullsht.html)], [[2](https://foredecker.wordpress.com/2011/03/05/status-reports-suck-and-everybody-hates-them/)], [[3](https://randsinrepose.com/archives/status-reports/)] person to make this observation. I'd wager there hasn't been a mention of them that isn't met with sighs and eyerolls from engineers. A Status Report represents a weekly interruption where everyone scrambles to remember how they spent the last 39.75 hours of their week.

The Status Report is well deserving of the ire it gets. I have been on both ends of it. It's frustrating. Every other tool we use as engineers already captures what we are doing, so why the Status Report?

We lose a lot of time to these things.

Consider that the cognitive load of simply switching into Status Report mode is [23 minutes and 15 seconds](https://www.fastcompany.com/944128/worker-interrupted-cost-task-switching). To get back on track, we're butting against an hour of time. That is an entire hour your organization is going to grind to a halt. Engineers will instead be scouring the bug tracker, emails, and wiki history in an attempt to reconstruct the work week.

Engineers do this out of fear. They believe that a Status Report lacking in status will impact their career, earn them questions from their boss, or otherwise make their life even more difficult than the time they are expending on the Status Report. So the engineer diligently assembles as many bullet points as necessary to avoid making themselves look bad.

This process exposes the two major flaws with how we do Status Reports. First, we use them as a snapshot in time, capturing only the world as we knew it at the time the report was due. Second, we have an unhealthy obsession with only the "what" part of our progress, removing key information around why we undertook the tasks we did or how we moved forward.

## No Snapshots

Status is not locked at 4:45pm on a Friday. Status is a flowing state that changes from day to day. Trying to get a clear picture of all of the moving parts is like capturing a photo of a sprinter using a polaroid camera. The larger the organization, the more lag that gets introduced into Status Reports. Your boss wants to share the status on Friday, so you ask for everything Thursday; by the time everyone finishes their status, something really important that happened isn't in anyone's report.

Status needs to be queryable and searchable. Tools such as Slack and HipChat can make this possible. A properly set up instance of one of these tools is already listening to all the work you are doing. It's a stream of consciousness is one of the purest forms: data.

## Why is it Important

Right there are the four magic words. The thing you're working on in that other browser tab, do you know why you are doing it beyond the ticket having your name on it? Does it map to the Really Big Problems your company wants to solve? When your boss asks for more details about something, does the importance come attached? Adding the phrase "it's important because" on both sides will lend a natural structure and meaning to the work.

And honestly, sometimes it's hell to finish that thought. Maybe you don't know why the work you are doing matters. Make a point of resolving that.

In fact, let's just document the "why" as it happens and be done with status as we knew it.

## Whydoccing

I usually hate creating new terms for things, but the replacement of the Status Report deserves a less toxic name. You're welcome to call it whatever you'd like, but the goal is to make status something anyone can pull; it never was supposed to be something people "pushed" to their manager. While the formula I present below is applicable to Slack, you can tweak it to any other real time "feed" system you have (HipChat, Hall, etc).

1. Make the tracking automatic. Take advantage of Slack's webhook framework. Capture events from all of the tools you are already using.
2. Create Whydoc channels. I like "Y[GOAL]" both for meme amusement and the Y items being sorted much lower on the channel list. For example, "yjsframework" is all about why we need to choose a JS framework and how that moves the business forward.
3. Curate the meaningful events. When important things happen that affect the Whydoc, post the permalink (right click the timestamp, copy/paste) and drop it into the channel. If you're really big on automation, feel free to make curation an automatic #hashtag operation.
4. Steer 1:1 conversations away from the generic status. Simply changing "what are you working on" to "how are you solving this week's problems" will tell you much more about the real problems and why they are important. The work being done is progress for the company, so find what problems the work is currently solving, understand why they matter, and capture that. Then, share it in a private group channel between you and your employee so everyone has a record of the why behind their work. For now, I just call them "Udocs" for consistency because I'm bad with names.

We have now turned the Status Report into a self service model. We not only know what's being done (date searching), but why it's important (Whydocs), and all of the other value people are creating (Udocs) that may not have been immediately obvious.

*Fun trivia bonus:* The name "whydoc" came from the idea of putting "why_blah.md" in the root directory of a software project that was Not Invented Here. This provided an in-repo rationale for why we needed the custom solution, and also assisted with onboarding.


There are better things for everyone to do on a Friday

Fix the Status Report

```yaml
---
slug: mistakes
published: 2018-02-21T00:00:00.000Z
description: The obligatory new manager "three things I fixed" post
repost:
  url: https://simpleprogrammer.com/engineering-management-mistakes/
  text: This article was originally written for Simple Programmer, and appeared under the title _[Engineering Management Mistakes and What To Do Instead](https://simpleprogrammer.com/engineering-management-mistakes/)_. It has been reproduced here as part of my own writing.
changelog: ~
---
```

As a company grows, senior engineers are asked to be lead developers on key projects. You might even be one of these [Accidental Lead Developers](https://simpleprogrammer.com/accidentally-lead-developer/) who has unknowingly dipped their toe into the world of engineering management. When the company grows again, you may be called upon to make the single biggest change of your engineering career.

A change where you stop engineering.

Engineering management is daunting. Suddenly, you're no longer writing code. You're the one overseeing the team. As an engineering manager, in addition to project planning and resourcing challenges, it's your job to make sure everything and everyone is working at their best. A significant part of that directive is the role you play in growing the careers of the other engineers.

Regrettably, there probably hasn't been any training to help you with the basics. Even worse, you're also expected to be competent in this role from the very beginning. This lack of training with unreasonable expectations is likely why [60 percent of all new managers fail](https://news.cebglobal.com/press-releases?item=67148) within the first two years.

Every manager that makes it long enough will eventually develop their own leadership style. Unfortunately, "long enough" is defined in years, not months. While you find your footing as a manager, you'll still be expected to carry out the responsibilities of the role. Your team needs you to be strong today despite your lack of experience.

Let's not be the [bad managers](https://simpleprogrammer.com/dealing-bad-managers-development-world/) we hear so much about.

To help, we're going to dig into the three most frequent communications you have with your team, the One-on-One (1:1) Conversation, the Team Meeting, and our Email Habits. For each of these, we're not only going to cover the common errors but focus on changes we can make that will help you find your footing quickly.

## The One-on-One Conversation

Your current 1:1 meetings with your boss probably aren't great. If your meetings follow the pattern of nearly every other engineering 1:1, your boss asks how you are, you share your project status, and you both call it a day. If you're in the minority, your boss may have also provided you with some feedback. If you're really lucky, you've had in-depth conversations with your boss about your career, the company, and how those two align.

It begins with making enough time. The single biggest mistake engineers do with their 1:1s is to attempt to shorten their duration. Anything less than an hour is actually a waste of both you and the engineer's time.

In High Output Management, Andy Grove explains that the first 20–25 minutes of any 1:1 conversation are filled with the small talk of status reports, general sentiment, and light conversation.

That fact means that if your 1:1 is only 30 minutes long, then you are going to hear how your employees are burnt out, unchallenged, or excited about a new project in the final five minutes of your conversation — as a manager, that's not enough time.
This is why your 1:1s require an hour or more. With a large team, it may feel like weekly 1:1s consume your entire calendar, which is an indication of the second mistake: the frequency.

New managers assume that a 1:1 conversation must be weekly. They mistakenly believe that frequency is more important than depth, opting for shorter (and thus more frequent) 1:1s, when the opposite is more beneficial to the team.

Short 1:1s, no matter how often they occur, will do nothing to help employees work on the larger issues that they've entrusted to you as their manager, and repeating the same 30-minute conversation weekly is a fast way for both you and the employee to get caught in a rut.

The frequency of 1:1 conversations should be scaled based on how much support an individual employee needs. If they are a junior engineer or new to their role, weekly may make sense. However, if they're a senior engineer that knows what needs to be done, you can scale back your 1:1s appropriately.

A good 1:1 goes deeper than status reports and updates; it focuses on in-depth discussion. You'll even put your [coaching skills](https://simpleprogrammer.com/2018/02/07/coaching-programmers/) to use. Instead of asking how a project is going, ask the employee what the most interesting thing is they've learned while working on the project. Ask for the employee's opinion on recent news instead of sharing the news itself. If it helps, use a template to keep things on track.

Being subjected to bad 1:1s is why so many new engineering managers view and value 1:1s poorly. In truth, the 1:1 meeting is the one of the most important tools you have as a manager to help the individuals on your team through meaningful conversations.

## The Team Meeting

You get everyone into a room, and…? Nobody looks forward to a bad team meeting, yet everyone can cite an unproductive team meeting they've been party to. As a new manager bringing the team together to talk about issues, it's easy to devalue your own meeting by not planning it out.

The number one mistake new engineering managers make with their team meeting is not making it clear why a team meeting needs to exist in the first place. Meetings without a purpose often feel like a waste of everyone's time. Just like the rules for any effective meeting, the team meeting needs an objective.

A great objective for a team meeting not only outlines what you hope to solve, but makes it clear that every concern will get equal attention and be acted upon: *"The objective of this meeting is to discuss concerns and challenges within our team because the challenges within our team are best solved face to face. This meeting succeeds if every concern raised in the meeting has clear and actionable next steps."*

By setting an objective like the one above, you'll also go a long way towards avoiding the other mistake engineering managers make: excessive planning of their team meeting. As former engineers, there is strong temptation to plan out the entire staff meeting in advance, but doing so robs the meeting of the organic discussion and debate that a healthy team has.

It is impossible to know how much time a team needs for any given topic, and when we allocate 100 percent of the time, either the discussion is absent or the final agenda items never see light.

Having a rigid agenda neglects the natural way concerns get discovered and raised in a team setting. Frequently, these over planned meetings result in the engineering leader talking at the team instead of discussing topics with the team.

Instead of trying to architect the entire meeting, ask for topics ahead of time and place those on the whiteboard in the meeting room. Then, before the meeting begins, go around the room and solicit topics a second time.

When the team meeting is [owned by the team instead of the manager](https://www.amazon.com/exec/obidos/ASIN/B00DQ845EA), employees will be more engaged, discuss their concerns more openly, and offer suggestions to the team's challenges. You can then focus on facilitating the discussion and capturing the actions the team needs to take. As an added benefit, a healthy team meeting means that your 1:1s with the team no longer will require updates and project status.

When employees value their team meeting time, you'll know that as a manager, you're doing things right.

## Our Email Habits

Everyone can recall at least one evening ruined by an email from their boss. As a newly minted manager, the shoe is suddenly on the other foot. Yet despite our newfound responsibility, we don't stop. More than [50 percent of our industry](http://www.careerbuilder.com/share/aboutus/pressreleasesdetail.aspx?sd=7%2f23%2f2015&amp;id=pr905&amp;ed=12%2f31%2f2015) (including new managers) are guilty of sending emails outside of work hours. Looking to stay in good favor with you as a manager, expect your team to respond.

This always-on culture of email has two major negative impacts on the team. First, because folks are tethered to work 24/7, we've [erased their downtime](https://hbr.org/2012/12/the-upside-of-downtime) — a disconnection from work that's vital to healthy productivity and creativity. While we may believe that we are creating velocity by following up on things immediately, we're actually hurting our team's ability to tackle difficult problems.

The second problem with emailing after hours is that it is actively destroying your team. A [study by Lehigh University](https://www.sciencedaily.com/releases/2016/07/160727110906.htm) directly links after-hours emailing to emotional exhaustion and burnout. [Burnout is responsible for almost half of all employee departures](https://www.kronos.com/about-us/newsroom/employee-burnout-crisis-study-reveals-big-workplace-challenge-2017). So, the cost of sending emails and interrupting personal lives is high.

While the cost in productivity and attrition seem insurmountable, the fix is not. We simply stop sending email outside of work hours. However, that doesn't mean we can't work on email if the urge strikes us. [A quick search on Product Hunt](https://www.producthunt.com/search?q=%22send%20later%22%20email) reveals that there's an email client for nearly every platform that comes with a feature called "scheduled sending." The ability to schedule communications lets us delay our email, sending it out once the workday has started anew.

We have a fix for the timing of our emails, but the content is just as important as the delivery. Good emails make clear to the reader what they need and ask for accountability. This is especially critical when forwarding emails. Email threads are notoriously difficult to follow, and asking your email recipient to parse the thread and identify the action they need to take is fraught with assumption.

To make your emails clear and actionable, literally write down your expectation at the top of the email: *_"$name, can you $expectation."_* If you are having trouble nailing down the expectation, then maybe the content isn't meant for an email.

At a team meeting, inform your team of your new email habits. As you keep your commitments to the team, you will see a noticeable boost in creativity, productivity, and trust. When something comes up that requires action outside of the working day, you'll find that your emails are highly valued and acted upon quickly.

## Your Next Steps as an Engineering Manager

While there are dozens of areas a new engineering manager can focus on, these three communication points stand out because of the impact they can have on your team.

More importantly, once you have built trust in your 1:1 conversations, team meetings, and email rigor, these become the forums your team can use to help you become a stronger engineering manager.

Don't be afraid to use these channels to ask your team or individuals "how am I doing?" and listen to their feedback. Your team wants you to succeed, and once they know you're committed to helping them, they'll work to make you successful too.


The obligatory new manager "three things I fixed" post

This article was originally written for Simple Programmer, and appeared under the title _[Engineering Management Mistakes and What To Do Instead](https://simpleprogrammer.com/engineering-management-mistakes/)_. It has been reproduced here as part of my own writing.