I’ve been advocating for giving space to the people and creating an ownership culture in the team for a while. I’ve seen many managers fail in these and become micro-managers and get stuck in the same role, failing to grow as a leader, too.

I had some concerns about creating this culture when I formed a new team before. The real challenge behind forming a new team is the absence of a common culture, but it is not an empty canvas. The team members inherit the culture from their previous teams (even within the same company, teams have their own cultures). Yet, the team still needs to find its own. I did some research, observed other leaders, and learned from them.

The path I took and the applied strategies worked. I then reused some of these strategies in two other (existing) teams and also worked. My sample size might still be small, but I can say that it works for different organizations, teams, and people for a reason.

I realized that the strategies give people a purpose and motivation. Once they catch that hook, they become intrigued by what they are doing, and their engagement increases.

Of course, these strategies are still not everyone’s trait. We also had a few people who left because they wanted something else. And that’s okay—it will always be.

It is time to talk about our path and the strategies I used and still use. Each of these strategies can be found in books, nothing novel. I will keep them short and focus on their essence, as they can also become their own articles.

The best leaders I’ve observed aim to create a culture where people

• take full ownership proactively (accountability + responsibility),
• learn (growth mindset),
• help each other (trust),
• bring themselves to work as they are, and
• help others deliver work effectively and efficiently.

If the team is immature or full of inexperienced people, creating this culture takes immense time and energy from the leader. Leaders have to let go of many responsibilities, one by one, to succeed. Without having experienced engineers helping, they won’t be able to delegate anything. However, they have to find a way to let things go to increase their impact on the organization.

I get help from individual team members to manage the technical side. I provide them with context, bring clarity to the work, and make prioritization clear. Then, I coach them to find their way around. It’s not as easy as it sounds, and I’m still trying to find the balance here. However, it all starts with holding regular 1:1s.

Leading Through 1:1s

A while ago, I wrote about how I hold 1:1s with my team and what I expect from each team member. I won’t repeat it here, but I focus mostly on how to lead people through 1:1s.

As an engineering manager, I put a lot of work and energy into 1:1s instead of day-to-day hands-on software development (unless/until it’s needed). 1:1s are the best way to build trust and rapport, exchange feedback, and create alignment.

After a certain amount of regular 1:1s (my sweet spot is between 2-3 months), people start bringing up problems and sharing information without me asking anything. We discuss those problems and exchange opinions. Once I understand the person’s background, skills, and capabilities, these discussions evolve into a different shape as I nudge them to bring recommendations along with the problem.

If someone sees a problem, they almost always have an opinion on how to approach it. My goal, as a leader, is to quickly set the stage for them to share those opinions freely and seek feedback as early as possible. Then, I can guide and help them grow. If they don’t share any opinions and, instead, expect a command, it indicates that they either don’t have the skills and experience yet or are hesitating to share their thoughts. For the former, we invest in building their skills. For the latter, we go back to square one. Hence, 1:1s are the single place where these things become apparent, and without 1:1s, other strategies will never work.

When I said, “I put a lot of work and energy on 1:1s instead of day-to-day hands-on software development (unless/until it’s needed),” it doesn’t mean that I am away from discussions, problems, or building solutions. I still challenge their recommended solution, nudge them to consider alternatives, or offer an alternative if they can’t find one. I offer my help, and we work on it together until the team evaluates trade-offs and is comfortable with the solution.

Some people still feel lost with me guiding them. In this case, I handhold them, and we really work together as close as possible. However, if they know what they are doing and are experts on the topic, I leave them as free as possible.

Adjusting the 1:1 strategy is the demanding part of leading because every person is unique and needs different levels of guidance in different stages of their careers. However, the most rewarding part of this is seeing people grow with purpose.

Another side effect of 1:1s is extracting new mechanisms that can be implemented in the team.

Implementing Mechanisms

I was inspired by the book Turn The Ship Around when I read, “Instead of preaching, implement mechanisms that will support ownership.” I implemented several strategies, such as auto-vacation approval and expert decision-making. The team members are free to take a vacation anytime they want; they can make their own decisions with a condition: instead of asking for approval, they look at our roadmap and commitments and decide whether they can take a vacation or not. If they are unsure, they can ask for it anytime.

Expert decision-making was another strategy that allowed people to decide on the approach, solution, and next step on their own if they were domain experts. Everyone on the team has access to every system and data and can use whatever they need for their work. Moreover, they can also decide how a feature should be implemented. We, as a product manager or an engineer manager, rarely write granular requirements (except business rules) for the engineers; we want them to discover and ask questions. If they need guidance, they reach out. At first, this looks like wasting engineers’ time, but it’s quite the contrary; once they understand why and what they are doing, they produce better work. And we give them the why and what part of the problem; they focus on how.

These are just two mechanisms and not the only ones. The trick is showing them that they have the power to decide on more than they think they can and guiding them through risks. This takes a lot of effort to establish and demands adjusting the team’s rituals and processes as well. But before all, it requires transparency.

Transparency Means Context and Clarity

Every time leaders talk about transparency, they struggle to understand what people expect from them. There is always a question in their minds: how much can I share?

The most suitable answer I’ve found to demystify transparency is about giving context and providing clarity. If people don’t know what’s around and what’s coming next, they can’t decide whether to take a vacation or not. If they don’t know the mission, strategy, and roadmap, they can’t decide how to implement a feature or design a system. If the person has enough context to make an informed decision, that is enough. If their decision is too risky without knowing certain things, I focus on bringing them context and clarifying every open question they have in their minds.

I learned that giving a person every possible piece of information equips them to solve a problem (and that’s what matters). Transparency is not about unhidden things; it’s about sharing the proper context with people and equipping them to solve a problem or make a better decision.

Once they are equipped with information, the next intuitive step is setting clear goals and keeping people accountable.

Setting Goals and Accountability Cadence

In this stage, there are three aspects of a team: having individual goals, team goals, and, in their intersection, an initiative ownership mindset. These should be established simultaneously in a team. Only after having these established can we talk about accountability.

• Individual Goals: During our weekly or biweekly 1:1s, we focus on anything my direct report has in mind (I start the meeting with the question, “What’s on your mind?”). 1:1s are sometimes day-to-day work and sometimes challenges they face. However, I set separate 30-minute 1:1s recurring every 6-weeks dedicated to personal development. I first understand the person’s background, wishes for change, and lacking skills while assessing the organization’s needs in my mind (in the best scenario, they should be aligned; however, it’s difficult to always achieve this). Then, together with the direct report, we develop a maximum of two to three goals with a target date set after six months. During the six-month period, we review the progress in every 1:1 and identify if the person needs any additional support. Having goals and closing them after six months helps people form an accountability cadence. As they are responsible for their own development, when they don’t achieve goals, together, we look for “the why” and change what’s needed.
• Team Goals: Besides individual goals, we have quarterly OKRs (Objective Key Results) set for the team. We often split an OKR into milestones. We then split these milestones into two-week-cycle (or sprint in Scrum) goals. The cycle goals are focused on achieving something by the end of the cycle. Having three levels (OKR, milestone, cycle) of team goals helps the people structure their work. Also, cycle goals give a constant feeling of achievement, which motivates people, drives them, and makes them feel valued. When we don’t achieve them, it becomes good feedback for which we can act.
• Initiative Ownership: In staff planning, I assign a dedicated person responsible for an OKR and its progress, splitting the work into milestones (and correctly sized smaller chunks) and ensuring the milestones are achieved. Each quarterly Objective or Key Result has an owner from the team. These owners also own the project’s milestones, which are represented by Epics on Jira. Epics are a chunk of work that should be completed within a certain timeframe. The initiative owner is responsible for splitting the epic into tasks/stories together with the people working on the feature/project and reducing the risks by making initial discoveries. Furthermore, initiative owners also manage stakeholders up to a certain point (e.g., communicating blockers and sharing progress). The whole system helps the team learn how to lead without authority and be accountable for the milestone’s delivery.

While three parallel approaches stretch the team’s and individuals’ skills, bring a sense of achievement, and give them “a seat on the table,” not everyone has the skills to work in this system. Moreover, most of the individual goals demand acquiring new skills or learning something more deeply. That’s why we invest in building expertise.

Investing in Expertise

People are often left alone when it comes to becoming experts. Many managers don’t take the time to help others become experts at something. As the managers are less knowledgeable on the deep topics engineers do, they feel lost in supporting their team’s individual goals.

In our case, once people started building up an ownership mindset, I realized that they lacked expertise in various skills, albeit being good at their jobs. The knowledge they had was good enough for day-to-day work yet not deep enough for solving complex problems. Simply put, they didn’t have enough tools on their tool belt. And that’s where we put focus.

Defining individual and team goals helped us see where we lack the expertise. Then, we gave people time to research and learn and also created opportunities to mentor each other. When these were not enough, we found trainers within or outside the company.

In one example, we realized that a team was missing deep knowledge—a granular understanding of Coroutines work in Kotlin. While improving our systems, they struggled to find good solutions due to a lack of knowledge. We tried to find mentors at first, but we needed a quick solution that would work for engineers across teams. Mentorship wasn’t a good choice. There, we also realized that people spending their education budget on getting individual training would cost more than group training. This is why we organized a few hands-on workshops with an external trainer over a few days to ramp up the knowledge as a group. After the workshop, they were confident about tackling the challenges we faced, and this also gave everyone a base to talk about and solve common problems.

While we invest in people’s expertise through mentorships, workshops, and more, I believe the real deal is learning by doing. Anyone can learn the theory if they put in the time and energy, but if they can’t practice those skills, they will be unable to retain the information. This is the place where the delegation comes into play. It’s not easy, but it brings remarkable progress.

Delegation for Career Growth

Once people started building expertise and stepping up to lead initiatives, the next logical step was creating opportunities (especially for individual goals) through delegation. Delegation also has a side effect: investing in our own growth as managers.

As leaders, we often deliberately focus on things we do well. We take real care of our responsibilities, but these do not always necessarily contribute to our career growth.

Tasks such as meeting facilitation, backlog refinement, feature delivery planning, or technical refinement can be delegated to senior/staff engineers depending on people’s career plans and skills. If the manager already knows how to facilitate meetings, refine the backlog, or plan the delivery and did it many, many times, it’s a good starting point to delegate. Once the team members work on these tasks, they also learn how to approach holistically, the complexity of work, the details of the feature/product, and how to manage stakeholders.

This delegation is not restricted to “soft skills.” For example, we delegated Observability improvements to one person who wanted to improve their knowledge around observability, monitoring, and alerting. That helped the person to develop, and the team closed their gaps. And now, when someone has a question or struggles with something in that area, this person jumps in and gives them help and mentors them.

Conclusion

All of these may sound like a lot of work. All I can tell you is yes, it is. It’s a long journey, and we put a lot of energy and time into working through all of these and more others that I didn’t mention here. We had many frustrating moments, failed remarkably in each section, learned a ton, and tried a few things differently. But isn’t this the work of engineering leadership? I think it is. You plan long-term, take a step, adjust it until it works, and take another step while keeping your head up and focused on the future. Once I put a holistic picture and long-term vision in my head, all of the small actions we took were aligned and aimed at the final picture.

Needless to say, the whole process is not (and will never be) a set-once-and-forget-it. It’s a continuous process and adaptable to anyone. You need to be resilient, relentless, and focused.
Moreover, you have to have the people who want to put the work together with you. If you have a team of missionaries who just implement the code and don’t care about the rest, then you won’t get any results. Also, you have to have the right organization—not every organization is the best candidate to implement the whole system. However, if your organization develops its own product, then you can probably apply a few things from here to your team, if not the whole system.

I’ll finish with a quote I love and keeps me motivated to look and learn more things:

“If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” — Abraham Maslow