Close Leadership & Management

What are the best practices you follow to cultivate ownership on your team? Where did you learn these practices?

Fostering ownership in engineers has always been important to me. It helps individual contributors grow professionally and fosters pride in the systems they build. At Close, we use Basecamp’s Shape Up software development methodology. In our six-week build cycles, we designate an engineer as the project lead for each cycle project. As project lead, this engineer is empowered to take ownership of the project, starting with initial product requirements and working them through to build and deliver a new feature to production.

Owning a cycle project means the engineer must consider numerous factors beyond just the technical implementation. Leaning into their leadership skills, they must now weigh decisions against schedule, feature priorities, people resources and organizational as well as technical aspects. They are no longer just responding to assigned issues; now they must think more broadly to ensure the project’s success.

How has a culture of ownership positively impacted the work your team produces? 

I believe this holistic approach helps improve the overall quality of our work. Changing the mindset from merely completing a project to taking ownership of it inevitably brings to light issues that might otherwise remain hidden. Whether they are performance issues, code quality improvements or even longer term thinking like how to improve our diagnosis for future projects.

Another crucial perspective, particularly important for a backend team, is that project leads should take ownership of delivering the technical aspects of the project and providing customer value. This helps remind everyone that we want to remain a customer focused engineering team. We want to push everyone to consider how our work impacts our customers’ experience.

What advice would you give to other engineering leaders interested in fostering ownership on their own teams?

Inspiring ownership in others can be scary since it may feel like you are giving up control and reducing your ability to influence the final outcomes. A normal reaction to this might be to put in more controls in an attempt to keep things on the tracks you believe are best. A more productive alternative is to think of what kind of guardrails can be put in place that allow teams some flexibility but still ensure everyone is generally heading in the same direction.

For us, guardrails might be a menu of patterns that can be used or a tech stack that includes a couple options for each resource. Maybe using Mongo or PostgreSQL is fine but choosing some other database platform needs a larger discussion. 

On the project management side, perhaps leads can make changes that don’t impact more than some percentage of the planned work or time allotment. We have a milestone in the middle of our cycles that requires each team to give an update to the entire team and show what has been built so far. 

Finally, architecture documents are a great resource that allows multiple teams to work independently but have enough guidance to help ensure work is delivered with a consistent technical approach.