```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

Document

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

Link

strong

blockquote

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: human-centered-instruction
published: 2004-12-02T00:00:00-08:00
description: When learning & development focuses on learner needs
changelog: ~
---
```

The way many companies approach Learning and Development (L&D) today is ineffective. In an attempt to bring development to the workplace, L&D and human resource teams frequently apply generic training in the form of offsite programs and seminars. These outdated methods of instruction are hurting companies. [Employees retain less than half of all instruction and training they receive](http://www.hci.org/blog/close-ld-effectiveness-gap-design-thinking), and in engineering, where I focus my training efforts, retention is even worse.

Over the years, I've found that there are three distinct reasons for low retention and failed training.

First, there is little attention paid to the relevance of materials. When materials are not rooted in the company's culture and norms, employees assume that the materials were not intended for them. Second, materials are rarely real or based on pragmatic examples. When content is abstract, it not only has lower relevance but it frequently contains no practical examples or situations to which learners can relate. Finally, instruction is not designed to be repeated. Many companies create training only to perform it once, failing to do additional training as new employees join the company.

It's [proven that when training isn't relevant, real, or repeatable, it is less effective](https://www.hrdive.com/news/effective-training-is-more-than-just-business-its-personal/514019/). Companies that have invested in modern Learning & Development strategies have discovered an alternative approach to building instruction.

That approach is called human-centered instruction, and it optimizes for a high signal-to-noise ratio, crafting content specifically to learner needs.

Human-centered instruction (HCN), developed in 2015, uses cognitive theory and adult learning principles in a three-phase approach to create high-relevance training materials. Through the three phases of **Exploration**, **Creation**, and **Integration**, HCN strives to make corporate training relevant, real, and repeatable. As shown in the following examples from LinkedIn, Nav Inc, and Google, the value HCN provides at every step of training development results in more effective instruction.

## Exploration: Creating Relevance with HCN at LinkedIn

Building relevant instruction begins with understanding both the desired outcomes for the company and the needs and goals of the learners. Conducting interviews, involving subject matter experts, and understanding company culture are necessary steps to creating relevant training that learners can relate to.
LinkedIn's Human Resources and Learning & Development teams discovered a consistent trait in their management team. In a survey of their engineers, employees pointed to their manager's inability to adapt to individuals in the team whose personalities didn't align with the manager's personal style. This behavior resulted in several instances where extroverted managers unintentionally silenced team members and employees felt less valued.

In interviewing these managers, LinkedIn discovered that leaders were unaware that their actions were problematic. LinkedIn developed a program called [ManageIn](https://learning.linkedin.com/blog/engaging-your-workforce/how-linkedin-works-to-make-its-managers-best-in-class) around this central behavior in order to educate first-time managers about their new role. As [Pat Wadors, former VP of Talent, describes the results](https://learning.linkedin.com/blog/engaging-your-workforce/how-linkedin-works-to-make-its-managers-best-in-class), managers who went into the training "were better prepared and eager to change. They recognized that diversity of thought and creating a high performing, engaged team was critical to all of our success." By asking the right questions at the outset, LinkedIn was able to craft their training around a single management behavior and create a program that was relevant to their specific context.

As the ManageIn training program grew, LinkedIn's L&D group identified another need. New engineering managers who had completed the training continued to struggle with the fundamentals of management. Focusing specifically on the engineering organization and employing the same strategies used to develop ManageIn, LinkedIn discovered that as the more general ManageIn program grew, the influx of non-engineering managers into the program was making it difficult for engineers to talk candidly about problems specific to managing engineers.

In response, LinkedIn collaborated with their engineering team and created the [Apprentice Management Program](https://engineering.linkedin.com/blog/2016/02/7-tips-for-aspiring-managers-in-engineering), a cohort-based model that focused uniquely on engineering management issues based on interviews conducted by L&D with engineering managers. Engineering managers who completed the program described it as "transformational," "the best training I've been in," and "all the stuff I wish ManageIn could have taught me."

By caring deeply about the learner's needs, LinkedIn was able to create two new training programs that really met those needs. The company saw more than an eight percent increase in how highly employees rated their engineering managers. Over time, this has directly resulted in higher retention and longer tenure among employees.

## Creation: Real Instruction with HCN at Nav

Human-centered instruction goes beyond the creation of a simple slide deck. Based on the learnings gained during the Exploration phase, a slide-based presentation (or even getting the team together for in-person training) may not be the right kind of instruction. Modern workforces are increasingly relying on "snackable" videos and putting skills into practice as a form of homework. Remote workforces make traditional instructional styles difficult. Building the right instruction requires an iterative approach.

As participants begin learning and new understandings emerge, training must evolve to meet those emerging needs. By adapting the material and the delivery methods in concert with these changes, training can remain relevant and grounded in the current company culture and values.

At Nav Inc, the company was migrating from Angular to React. To prepare junior engineers for the transition, the company created time for employees to learn the new framework through blogs, video presentations, and the online learning site Lynda.com. As the migration progressed, junior engineers continued to struggle with migrating and managing code in transition.

When I [created custom technical training modules for Nav](https://web.archive.org/web/20200108233815/https://www.leadsv.com/stories/nav), we believed from interviews and code samples that the learner problem was rooted in a lack of understanding about why the organization was moving from Angular to React. To test this theory, the first instructional module of React Ready focused on the history of React and the unique approach that the framework took to solving UI problems.

By the end of the first session of React Ready, it was clear that the problem was more complex than what was discovered in the original Exploration phase. During workshops, junior engineers struggled to create working code specifically within the Nav environment. A series of conversations and evaluations after the first training pointed to the next hurdle: proprietary code built by senior engineers to ease the transition from Angular to React.

Without an iterative approach to instruction, the second training module would have focused exclusively on extending the knowledge of the React ecosystem, and it would not have met with much success. Instead, we adapted the training.

In place of workshop instruction, individual one-to-one training was used to reinforce React fundamentals and ensure that all engineers had a shared understanding of the original framework before modification.

Once a baseline understanding was reached, the second workshop focused on the reality of the Nav codebase. Checking out code from git and applying it to their branches, junior engineers followed the same integration steps that ultimately led to the proprietary code that the senior engineers had created.

The final result, a training course called [React Ready](https://web.archive.org/web/20200108233815/https://www.leadsv.com/stories/nav), taught the theory of React and Redux, provided hands-on workshops for applying React to the existing codebase, and prepared the organization to complete their conversion to React with confidence. While slides were valuable for context, the majority of learning and education occurred in workshop pods where developers paired up to implement code and follow the path taken by senior engineering.

## Integration: Repeatable Training with HCN at Google

Instruction that ends when the training session is over holds little value for most organizations. The process of learning is evergreen, and the educator must not only work to train the organization but must also "train the trainers", increasing the number of in-house instructors available to the organization. This is the only way instruction can be sustainable, adaptable, and scalable. Scaling requires subsequent iterations of training programs, allowing them to both grow and more deeply address learners' needs.

There is perhaps no better example of scaling instruction than Google's [re:Work](https://rework.withgoogle.com/) project. Started in 2008 under the name [Project Oxygen](http://www.nytimes.com/2011/03/13/business/13hire.html), Google undertook one of the most extensive Exploration phases imaginable. The goal was to understand what engineers wanted from their managers. Using data from over 10,000 employees, Google arrived at a series of key behaviors shared by all strong Google managers.

In the Creation phase, Google followed a path similar to LinkedIn by creating their own [New Manager Program](https://www.fastcompany.com/40405205/five-things-ive-learned-as-a-new-manager-at-google). When the program launched, Google saw similar improvements to employee satisfaction, retention, and growth. Unlike LinkedIn's approach, when scaling up presented a relevancy problem to engineers, Google did something unique to Google's culture.

Instead of creating a separate training custom-tailored to the needs of the engineering organization, Google opted to equip senior employees with the skills they needed to conduct the training themselves. Provided through the company's unique [Googler to Googler](https://eleaptrainingsoftware.com/how-to-incorporate-elements-of-googles-training-and-development-into-your-business/) sessions, instructors were given latitude to adapt and evolve the company's training materials to their learners.

By combining formal and informal courses, as well as formal and informal teachers, Google was able to train many more engineering managers at a quicker rate than they could have otherwise. To scale the training further, Google formalized the tools and materials for teaching Google's unique style of management and leadership. Released as ["re:Work"](https://rework.withgoogle.com/), Google made it possible for other companies to leverage the work of Google and create their own customized training experiences.

More than a [half dozen companies](https://rework.withgoogle.com/case-studies/) have shared their re:Work stories, applying their own unique Exploration and Creation steps and leveraging Google's fantastic Integration work.

## Bringing HCN to Your Company

While the stories of human-centered instruction shared here focus on larger organizations, technology behemoths like LinkedIn and Google do not hold a monopoly on excellent training. Nav Technologies, the company I highlighted above, has 25 folks in engineering. At all sizes, getting engineering teams aligned helps companies move quickly and deliver value.

Size isn't a barrier to great training and developing talent. Any company can create training that is relevant, real, and repeatable. When training is "relevant", retention is higher. Training that is "real" will adapt with the needs of the learners and changes in the company. "Repeatable" training ensures that anything built can continue to grow, adapt, and scale to the company.

The three facets of human-centered instruction, Exploration, Creation, and Integration, map directly to the goal of creating relevant, real, and repeatable instruction. The result is a more effective way to approach Learning & Development at any company. Whether you do this with your in-house L&D team or with a consultancy that specializes in human-centered instruction, applying these principles will improve your training programs and transform your employees for the better.


When learning & development focuses on learner needs

Human-Centered Instruction

```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: introducing-lead-sv
published: 2017-10-16T00:00:00.000Z
description: Helping engineering teams help themselves
changelog: ~
---
```

Over my career, I've had the fortune of meeting hundreds of unique companies in the technology space. Consistently, I've found that engineering organizations struggle with the same three problems regardless of size:

1. onboarding and training new engineers and leaders
2. performance and talent management
3. cultural "norms" that didn't align with the company

Every single engineering group wanted to invest more in the above, but fell back on the same pair of reasons for why they hadn't addressed these problems.

**There's no time:** The pressures of funding and execution has left the organization no bandwidth to develop the team or culture.

**What exists is not specialized:** Even when a company has a Learning and Development or Education team, that group lacks an understanding of the unique problems Engineers and Engineering Managers face.

My new journey began when I offered to help one company build training materials for their core in-house technology. I worked with another to do a management training cohort for their 4 newly minted managers. By the third engagement, it was clear engineering organizations wanted to solve these problems, but didn't know where to begin.

I decided to become a force of change for these companies, and founded Lead SV.

![Lead SV Logo](https://user-images.githubusercontent.com/1795/146832043-1687c945-0e3b-41b7-8de6-d10ae7db0e52.png)

If you put people first, grow them, and give them the space to flourish, engineers will build something amazing. If you do the same with your engineering leaders, you'll create something truly unique in our industry.


Helping engineering teams help themselves

Introducing Lead SV

```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.

Engineering Management Mistakes

Posts during my time doing L&D consulting and training