I’ve had a pretty unconventional career path. I started by dropping out of high school at sixteen to focus on my college courses. After I finished my masters in math, I took a role building common fintech software components. Years later, when I was promoted to principal engineer (PE), the idea of extending the software engineer role to a career position was very new. Before then, engineers transitioned into managers at that point in their career, and my PE role took years to evolve from a matrix manager into the modern PE.

After a decade as an engineer, I had the opportunity to retire, but I was a terrible retiree. I did some real estate investing, opened a retail shop, took a role on a congressional campaign, went from adjunct to full-time faculty at my local university, and started a political consulting business. After 7 years of experimenting with these domains and roles, I went back to what my father calls, “that thing I do with computers.” When I returned to enterprise software development, I had changed focus. What I had been learning to do during those “retirement years” is build businesses and teams, and I really love it.

Since then, I’ve built a lot of teams to solve all kinds of problems. I’ve done massive cloud migrations, globalization and localization, delegated payments, machine learning, cryptography, programming languages, and nonprofits. When I started building my current team, a leader asked me, “What makes you think you can do this? You have no relevant technical experience.” My answer is that I’m good at building great engineering teams, and that’s my role. I’m not the technical expert anymore.

In 2019, I was asked to build the Encryption in Transit team for AWS Cryptography and solve some really hard problems that we’d been stuck on for years. A couple of engineers had worked with a partner team to build a prototype, but it didn’t satisfy most of the hard requirements for our product.

Getting started with a team always begins by deciding why we’re creating the group. As Simon Sinek famously said, “People don’t buy what you do; they buy why you do it,” and “encryption in transit” is what the team was doing. Understanding why a team exists is a bit more complicated and critical to team alignment and long-term success. The “hard part” of cryptography is correct use and operational excellence. The team’s mission was to make it easy for our users to have awesome security without negatively impacting their services’ operations. I came to that conclusion by asking my engineers, my leadership, and my customers and then re-framing the opportunity and the problem over and over again until they all agreed.

This mission statement is important, because it communicates why the team exists. Knowing your purpose helps answer questions about why the team’s work matters and what work is within the team’s scope. In the absence of clear purpose, team members will work toward individual goals rather than combining efforts for higher impact, and sometimes, they’ll even find themselves working at cross purposes and sabotaging each other.

The open source community I’m part of has made non-goals the goal. The project’s single objective is to enable individuals to satisfy their own objectives without negatively impacting others. It’s hard to be effective in that kind of environment, and it hurts our ability to recruit and retain maintainers. Individual community members experience high levels of confusion and friction that can make their roles feel overwhelming.

Over the last year, I’ve interviewed open source leaders from dozens of communities and projects, and one of the things I heard from them is that in open source, the community is the product, or mission. I see that taken quite literally in my open source community, and I’ve thought a lot about how to reduce the negative impact of that. I recently asked a long tenured community manager for advice, and he pointed out that there is no community without a shared purpose. A group of people without a shared mission is not a community, not a team. Building a great team always starts with a clear mission statement.

Drawing a line from the mission of the team to goals and solutions is a multi-step process. The next step in building a great team is a mechanism I learned at Amazon. We define tenets. A tenet is a unique core belief of a team. Tenets define scope, priority, and methodology. Tenets never say the obvious or common; they provide the yardsticks and litmus tests for team specific decisions. One of our tenets was, “We make the right thing easy to do, and the wrong thing hard. We work to deliver safe defaults and the lowest possible threshold for adoption.”

We also had tenets that acknowledged where our boundaries were. For example, we weren’t experts in algorithms, and there is a team that is. There’s an algorithms team. Writing tenets that specified our scope gave us the opportunity as a team to decide what elements of a customer’s cryptographic experience we were responsible for and identify the partner teams we would interact with to support the balance of that customer experience.

We don’t declare tenets that aren’t meaningful to our team, like “security is job one” or “the customer is always first”, because those are not helpful in making individual and team decisions. They don’t align the team members, and they don’t communicate anything to our stakeholders. They’re also not derivatives of the mission statement, and tenets should reflect how we’re going to deliver on a mission. In the absence of a mission, it is impossible to declare tenets.

Once the team agrees on tenets, or principles, we reflect on what we’ve learned. Documenting lessons learned is an exercise in identifying the challenges and opportunities in our space and then pairing them with goals or changes. In 2019, I wrote that the team had been chronically understaffed, and that attempts to onboard loaner engineers from other teams had failed. Our prototype was written in the Rust programming language, and the learning curve for experienced engineers took more than 3 months. I wrote, “We will establish ourselves as Rust engineering community leaders at Amazon […], and we will grow the Rust engineer [hiring] pipeline.”

The lessons learned process will define some goals for the team, but probably not all of them. Input from leadership, stakeholders, customers, and the members of the team provide additional data for prioritization and goal setting, and the goals that come from all of those sources always add up to more work than the team can afford to do! The prioritization calculus is an act of working backwards from the customer. Goals should always deliver value to the customer, and the highest priority goals are the ones that deliver the biggest customer value.

Goals are specific priorities for the team, and the work the team does throughout the year should contribute to delivering on those goals. That’s something the team has to monitor and reflect on. If you find that non-trivial amounts of team capacity are being spent on other things, the team needs to figure out why that’s happening. There could be goals that your team has taken without explicitly expressing them in goal language. That’s ok except when it puts your existing goals at risk. Then you have to have a candid conversation about whether the team has gotten distracted or needs to change the stated goals.

Like all good mechanisms, the mission, tenets, and goals of the team should be regularly inspected and iterated on. I like to do this at the end of each year, and most Amazon teams have formalized that process.

In 2021, I had a very “when in Rome, do as the Romans do,” approach to open source, and what I learned, or proved, is that taking the non-goal of my open source project as the mission of a corporate engineering team leaves the team without alignment both internally and across stakeholders. Our mission was essentially “make Rust all the things for all people,” and it was impossible to know why we would choose one goal over any other. In the end, our goals had wildly variable customer value and wildly different customers, creating confusing stakeholder conversations. It wasn’t awesome, but it was an incredible learning experiment.

This year, my team’s mission is to deliver the features and tools strategically important projects at Amazon need to launch and operate their services for their customers. We’ll still do our part for the project and community, because that is part of how we deliver on our mission. And that mission isn’t really new. That’s always been why our team existed; recognizing that truth will make it possible to clearly communicate that mission (why we exist), our tenets (how we execute on our mission), and our goals (what we’re delivering). That’s how you build a great engineering team.