The COSTCO management method

Engineering management is easy. All it takes is providing six simple things to your engineers: context, order, space, tooling, connections, and opportunity.

Introducing the COSTCO system.

(No association with the Costco Wholesale Company)

Context

If you have an experienced engineering team then this is the most important role of a manager. When the engineers on the team are capable, then the role of a manager is more focused on giving them context so they build the right solutions than mentoring any specific technical skills. Context represents relaying information about business priorities, user needs, technical background, timelines, and scope. In practice, this means I spend a lot of time in meetings so my team doesn't have to.

In the last quarter, my team took on 20 projects ranging from major refactors to small UI changes. For each, I worked with the product and design manager to understand the context so I can staff the project properly. Who is already involved? What is the planned timeline? What APIs already exist? How does the value of this project compare to another? What user research has been done? Do we have any existing documentation? How does ths fit into the company's larger strategy? Do we have success metrics? I'm not accountable for answering any of these questions, but I am responsible for understanding the answers so I can make project staffing decisions, push for a smaller scope, pull in additional engineering teams, or balance the priorities with our technical roadmap. For example, if the project is large and ambiguous I might reach for one of my staff engineers who are comfortable running teams, making decisions, and getting to an outcome. Or if the design manager plans to staff a project with a designer that works well with one of my engineers then I might ensure they are partnered up.

It's an elegant dance, or sometimes an inelegant dance, but if I'm doing my job correctly then each of my engineers join a project knowing the background for it, who they will be working with, and the role they need to play in order for the project to succeed. We staff projects quarterly, sometimes across organization, and across engineering teams. Every once in awhile the dance steps come together and I enter a flow state. In fact, it's the only flow state I ever enter with management.

Actions to establish context

1. Stay connected to stakeholders to understand upcoming projects and priorities.
2. Stay connected with your engineering team to understand who they work best with and which areas they have an interest in.
3. Decide project staffing based on the above information.
4. Pass along the context to the engineer as they pick up the project

Order

More often called priority in the corporate world, but CPSTCO just doesn't have the same ring to it.

Order is about ensuring your engineers have a clear understanding of their project priorities. No matter how experienced, it can be difficult for engineers to context switch between multiple projects at the same time. My goal is to provide a prioritized list of projects for each of my engineers and then the space to focus on the top priority without interruption, more on that next. My current team is highly experienced and works across 7 product managers, meaning I focus more on providing project priorities than managing ticket priority within each sprint, but the importance of order can apply at any level of granularity. It'll just depend on the team's need.

For the Staff engineers on my team, I have slightly higher expectations for context switching, typically prioritizing one development project and one planning project, but in general the engineers shouldn't need to be switching between development context.

Actions to provide order

1. Provide each engineer with a clear list of project priorities. Don't expect the engineer to take on more than one project at a time.
2. Check in with the engineers on a regular basis to ensure they are focused on the top priority and not stretched too thin.
3. Be comfortable with reevaluating priorities and shifting when needed.

Space

Even with the latest AI coding tools it still takes time to develop a solution. For engineers this might be aligning on an architectural pattern, discussing edge cases with design, or most commonly writing code. Engineers need space to focus on the problem in front of them and engineering managers need to ensure they have that space.

Part of this role is attending meetings so the engineers don't have to, but I actually think engineers should be involved in meetings if the meeting is relevant to the project at the top of their order. Once an engineer is staffed to a project it is no longer my role to provide context. As we're planning it's okay for me to represent the team and the work, this allows me to protect my engineer's space, but once the project is in motion then there's no reason for me to act as a middle man for information that is critical to the project's success. Instead, I've focused on growing my engineer's time management skills and empowered them to utilize meetings to get what they need instead of attending them blindly.

The most important action I take as a manager to provide my engineer's space is to proactively provide an estimated timeline to my team's stakeholders, primarily the 7 product managers, but occasionally a director of engineering or someone like a security analyst. I can't prevent stakeholders from contacting my engineers directly, and I can't prevent, no matter how hard I try, my engineers from responding. I can though, provide an estimate on when the engineer will be available to work on a project. I've found that if I'm proactive in giving stakeholders a timeline then they'll leave my team alone until the team is ready to take on the project. What this looks like in practice is a loose timeline created for planning at the beginning of each quarter. The timeline never matches reality, and I don't even necessarily want it to, but it does give stakeholders an overview of who is working on what and in what order each of them will be involved in projects. This is enough for the stakeholder to know when to engage and if they disagree with the plan they can always come talk with me.

Actions to give space

1. Proactively set expected engineering availability with stakeholders.
2. Stay connected with your engineers to understand how often they are context switching.
3. Reevaluate priorities as needed.

Tooling

Management is often described as unblocking your team, or streamlining their productivity. Tooling represents that. At it's simplest form, a managers role is to ensure their engineers have access to the right tools. That could mean a powerful enough computer, licenses for specific software, even a comfortable working environment. Most of those tools are handled by a companies HR and IT department. A manager may be able to influence it, but in my experience these are outside of any individual manager's control.

There's another type of tooling though, one that is broader than specific hardware or software. That tooling is processes. If we think of tooling as anything that streamlines your team's productivity, then the real bulk of a manager's role in regards to tooling is defining, tweaking, and maintaing the team's process. Process is talked a lot about within companies. Sometimes, in highly compliant companies, heavy process is necessary to meet regulations. In smaller companies process might be a bad word as it gets in the way of the team's agility. However, I think a team's process needs to be looked at more granularly.

In order to be effective, a team's process needs to be grounded in the people on the team, the specific project work they are tackling, and the team's they will interact with. Processes should be bespoke to the team and rooted in industry practices. It's more effective to adapt a process to the people than to adapt the people to a process. People have different personalities, skills, goals, and perspectives. Before defining any process start by deeply understanding each of the team member's needs. Then take a look at the roadmap and upcoming work, talk with the dependent teams, and start mapping out a plan of action. You'll get this wrong. And that's okay, the goal isn't to perfect a process, it's to take a best guess and to establish an anchor that can be iterated on. Similar to software, you want to fail fast and the best way to learn is by trying. After a few months, iterations, you and your team will have a good sense of what works and you'll be able to settle into some patterns.

Processes should also never be static. There's a few reasons you should revisit, maybe the team structure changes, the project work changes, or the dependencies change. Or maybe time has just passed and what used to require a meeting is now second hand nature for the team. That's another key, you'll most likely start with too much process. Regularly (maybe quarterly) asking yourself if a certain meeting or expectation is still needed. This is a good way to make sure you are still finding the right balance for productivity. Besides, process exists to ensure people take a specific action they otherwise wouldn't, if over time that action becomes part of subconscious behavior then the process expectation may no longer be needed.

Actions to implement tooling

1. If you are missing basic software engineering hardware or software, work with your company's HR or IT departments to purchase the right equipment or licenses.
2. Once that's out of the way, start by interviewing your team on process. Ask what they've found successful in previous jobs.
3. Connect with product leaders to look ahead on your roadmap and set up process conversation with peer managers of other teams your engineers will work with.
4. Try something. By understanding your team and company's needs you should be able to take a good stab at this, but if you are still unsure reach for an industry established pattern such as scrum.
5. Iterate, tweak, question, and keep communicating with your team. Don't be afraid to remove process either.

Connections

Engineers are often stereotyped as introverts, and it's often assumed their work can be done in isolation. Think of the stereotype of an engineer in their basement doing nothing, but pushing code. True or untrue (it really depends on the person), the best engineering solutions are solutions that are shared and understood by others. As a manager, your role is to maintain a high level understanding of the product's architecture and other team's skillsets and roadmaps. This allows you to see opportunities for connections that will accelerate team's understanding and shared context. There's two types of connections managers are responsible for faciliting, direct connections and unexpected connections.

Direct connections are well direct. "Have you talked to Jimmy about the work they're doing? You should set up 1:1 time." These happen when you become aware of two people doing work that would directly benefit each other. This could be sharing code patterns, solving similar problems, complementary skillsets, or my favorite, shared gripes. Good work is done in collaboration, and as a manager you should stay up to date with work happening across the organization so you can force direct collaboration. This can help accerlate projects, build alignment, or at it's best, motivate engineers to solve each other's problems. Problems they may have thought were unsolvable as an individual.

Unexpected connections are more ambiguous. The outcomes are the same as direct connections, but in these cases you aren't aware of who needs to be connected and why. Instead as a manager you need to be creating environments where your engineers can make these connections on their own. This is most important in a remote enviroment where an engineer may not even know a potential connection exists. Managers need to establish cultures that enable engineers to discover each other's work, interest, skills, and personalities. There are a number of ways you can approach this, and similar to tooling I encourage you to experiment. Things I've seen successful in a remote enviroment include, weekly demos, keeping Slack channels public, creating non work communication channels, sharing team roadmaps, developing a Slack bot that randomly pairs engineers for a coffee chat once a month, and bringing engineers together in person. Culture building is hard and requires continuous attention. It will often feel like no progress is being made at all, but every once in awhile you'll be hear of an unexpected connection caused by the environment you created and that's where the magic really lives.

Actions to build connections

1. Talk to people, like all of the people. Get a sense for what work is being done, what people are passionate about, and what their skillset is. You'll naturally find opportunities for connections.
2. Create environments for unexpected connections. Host regular meetings, make your team's work visible and asks others to do the same, schedule time for engineers to get to know each other on a personal level, and try new things. If it feels quiet at your company, find ways to make it noisy.

Opportunity

Opportunities are the key to growth for engineers. As a manager, your focus should be on providing opportunities for your engineers that align with their career goals, give them a chance to do their best work, work with new peers, and develop new skills. You can't control how they handle an opportunity, but if positioned correctly and with the right support they'll often surprise you.

Companies are filled with opportunities. Some are defined by the business and placed on a roadmap, but others are more ephemeral. Those ephemeral ones are where real growth comes from. Maybe an engineer mentions they have interest in a new testing library and because of the connections you build you are aware of a different team that's already using it. That could lead to a conversation, which could kickstart a POC, which could turn into a project, and subsequently, growth.

That's not to say the business, roadmap opportunities aren't valuable for growth as well. They are more standardized for the role the engineer was originally hired for, but new projects, changes in architecture, or changes in team structure can provide a lot of similar opportunities for engineers to step up, learn new skills, and prove themselves. When planning for a new quarter I make sure I go into the conversation with a strong understanding of my engineer's career interests and their current skillset. Depending on the business timelines you may sometimes need for an engineer just to do what they already do best, but often if positioned with the right context, you can use business roadmaps as learning opportunities while still delivering on time.

But, not every opportunity has to be about growing skills. Sometimes the opportunity is to just gain more visibility or create new connections. One of the tricky parts about career growth is that it also requires support from the larger organization, particularly in the case of promotions. The engineer may already have the skills, but have not yet been given the opportunities to demonstrate them on a high enough impact project. Therefore, it's important to also consider opportunities that might not be for personal growth, but instead position the engineer for organizational growth.

The engineering manager role is about finding the correct balance between an engineer's career growth and delivering on the business' goals. It's hard to get it just right and requires constant re-evaluation. When an engineer feels they are growing then they are more likely to stay committed to the company and be able to take on more valuable work. And if you are doing that while also delivering on the companies needs, then you're also succeeding in your job as well.

Actions to provide opportunities

1. Talk about long term career growth at least once a month in a 1:1 with engineers. Ask them about new technology, about problems they see in the product or codebase, and about what team or person inspires them. The better you can understand these things the easier it will be to match an opportunity to an engineer.
2. Keep close with work happening outisde of your team. At a high level this could be paying attention to commits going into the repo, looking at in progress Jira epics, or simply asking peer managers about what projects their team's are taking on. Use this to build connections and context and then encourage your engineers to find opportunities within that.

See, just six simple things. That's all it takes to manage engineers.