Your team is the product.

As a manager, it’s easy to feel helpless, randomized, and like you aren’t accomplishing anything. Suddenly, your day is full of meetings that others have put on your calendar. There are constant interruptions and a million tiny things to keep track of.

You keep checking things off and showing up where you’re supposed to show up, but you never feel like you’re building anything anymore.

And, you probably miss building things.

It’s easy to feel like you’re constantly pulled every which way and lose any sense of control or direction. If that’s where you are, please stop for a second, take a breath, and remind yourself that you have more power than it feels like you do.

You’re still responsible for building something awesome.

Instead of being responsible for developing software, you’re now responsible for building a team. If you know what to look for, you can still find that high you get from seeing something you did work. The results of what you’ve built show up differently, but they do still show up, and they’re just as important as the results your team achieves in the software.Imagine that your team is a product.

Your people are the helper libraries that make up that product. The processes and culture on the team are the code that connects those helper libraries together to make a cohesive unit. That system is the one you’re responsible for maintaining, building, and improving. How much do you know about it? Can you define the interface between your “product” and its users? That is, are you clear on how outside people request work from your team and how you provide updates to them? Do you know what each “library” does — what it’s good at and where it’s lacking? That is, can you list the strengths and weaknesses of each of your team members and what they contribute to the team? Do you know the overall concept of your product? That is, do you know how your team operates?Software teams are products where the input is requirements, and the output is functional code.

The difference in software teams tends to be the attributes they prioritize in that transformation.

• What kind of software team are you in charge of? Do they prioritize minimizing the number of bugs?
• Maximizing the performance of your software?
• Employee satisfaction?
• Low turnover?
• Reliability and uptime?
• Velocity? Maintainability? Individual heroics? Collaboration? Compliance? Innovation? Transparency?
• Something else?

Take a few minutes to come up with some adjectives to describe your team as it exists today — some about traits of the resulting software, some about how you work together as a team, and some about how you interface with other teams.

Then, take a few minutes to come up with adjectives that describe an idealized version of your team, and compare the lists. This should inform your direction, and I hope that it’s the first step toward a sense of grounding in your leadership career.

Next, identify work items for yourself.

• What is frustrating you at your job?
• What’s frustrating your team members?
• What’s slowing you down?

Treat those things as bugs in your “product.” If it helps, make yourself an actual list of them in whatever tool is comfortable for you.

Then, identify things you think could make your team better. Use the adjectives from the previous paragraph as a starting point — what “user stories” can you come up with to move your team away from traits they currently have that you dislike and toward traits you’d rather your team have? Add those features to the list of bugs, and now you have a pretty clear list of work items for yourself. There are probably more than you can address right now, and while you’re getting used to an entirely new set of tools and expectations, I recommend choosing one at a time and starting with things that seem subtle and simple.

As work items get close to the top of your list, try to come up with a way that you’ll be able to identify when you’ve succeeded — essentially, an “acceptance test.” This should be another step toward more comfortable territory. You’ll still have a lot to learn, and the feedback on whether you’ve made the tests pass is delayed, but it should let you leverage some of your previous mental models.

You still have a day packed with meetings.

1. You still have frequent interruptions. Hopefully, most of them fall into one of the following categories:Discovering new work items for the backlog (not the backlog for the actual software your reports build. The backlog for how to create a better team)
2. Addressing one of your work items
3. Fulfilling the communication contract that is the interface between your team and the rest of the world

Most 1:1s with people below you in the hierarchy should fit into category #1, though some will be category #2.

Planning meetings should largely be in category #3. 1:1s with people beside or above you are probably in category #2 or category #3.

If meetings in category #3 are consuming soul-crushing amounts of your time, that’s probably a bug in your team’s interface.

If things are constantly on fire, that’s also probably a bug that you should look for ways to address.

There are a million different ways teams are broken, so I can’t tell you how to fix yours, but taking the time to cultivate awareness is a good start.

For things that are demanding your time and energy that don’t fall into any of the above categories, figure out what’s going on. There will always be some, just like when you were an engineer there were always some things that didn’t contribute to coding.

The following questions may be helpful in figuring out what’s going on.

• Is this meeting part of the communication contract that you forgot to account for? If so, update your understanding of how your team interfaces with other teams.
• Is there an opportunity for this interaction to directly or indirectly address one of your work items? If so, take the opportunity. Do you understand why this is a good use of your time? If not, consider asking for clarification.

Remember to stay attentive to your team, so you recognize new issues or opportunities for improvements as they come up, and so you can monitor whether the ‘acceptance tests’ for previous changes are passing. Take the time to be proud of what you’ve built.

Remember to invest in both the individuals and the glue between them. I hope this will help you get your feet under you as you begin to understand your team as the product you now build, and where it’s at.

I hope it will help you establish a positive direction by deciding where you want to take your team and creating work items to get there. I hope it will allow you to feel more control over your life as you understand how your daily professional activities relate to what you’re trying to achieve.

Your team is the product. was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.