When you’re part of a team with a vibrant culture, like the one we have at XWP, you owe it to your teammates to give your work your absolute best efforts, even if things don’t shake out perfectly.
A big part of this is identifying your role, the one you will own: And when you do, championing it from the perspective that you have and seeing it through to completion.
This post was sparked by a great discussion in a recent XWP Product Owner’s sync. These kinds of meetings are open to anyone at XWP to attend and are important for the growth of the company and we encourage team members to attend!
Following is my summary of the points we discussed and callouts that I propose for our team to use in terms of ownership: This can help guide us in the process of doing our best work and understanding each other.
So let’s answer this basic question:
How does ownership of your role help facilitate positive creative tensions in a project’s team structure?
Ownership in this context means “arguing for and taking responsibility to make sure a particular perspective is respected.”
We all have a defined ownership in our jobs: Just as a librarian might support their community in navigating the annals of a collection, they own the library visitors’ experience and when they don’t, patrons suffer. An an accountant might regularly complete the bookkeeping duties that a company requires, but they own the responsibility to explain fiscal direction to better inform higher level accounting decisions, and when they don’t, dire mistakes can be made.
In other words: We do our teams and projects right when we treat what we do like it’s ours. We don’t just “do tasks,” we own perspectives.
Outlining roles in our team as “owners” means we can create positive tension to ensure each area of focus gets advocated for in our projects and teams. This tension allows people with two different ideas to find a reasonable resolution.
Who owns what?
It’s amazing what we have here At XWP: We have folks in many disciplines who care passionately about their work and fight for the best interests of the project from their perspective. Here is a brief summary of the roles most of our projects have and what many of us own in our projects and teams:
- The Product Owner (PO) owns the product. The purpose of a PO is to advocate for the best product possible for the client’s project given the constraints of priority, user needs, and what the development team can do in the timeframe and resources available.
- An Account Manager owns growing and maintaining the account. They care about the future of the business we’re working with and value opportunities to help that business grow and benefit from our work. They also care about giving our service delivery teams the best projects that will set us up for success, while looking to match us with what the client needs.
- A Team Lead owns team interests. They iterate and actualize the client’s requests but also works to minimize scope creep and team burnout. Not only does a Team Lead track the account’s budgets and manage the project’s timelines, they also ensure delivery of the experience and results that clients value with a focus on a holistic performance.
- The Architect owns technical excellence. They are responsible for ensuring a vision for the project from a technical perspective; setting the guidelines for how the platform will be built, what technologies should be chosen, and the workflows and best practices for the technical team. Ultimately they’re helping to advocate for great code, project documentation, and elegant solutions (but with scope kept in mind.)
- The Developers (FE + BE) own actualizing the Architect’s direction. They help support by developing a product or project that meets the clients needs, while helping to flush out and define the work with the Architect, Team Lead, and Product Owner. Based on those needs they work to develop using coding standards and best practices that set the project up for success.
- The Quality Analyst owns quality and advocates for the user. They fight vigorously to ensure that the product will meet the criteria we agreed on, that it works for all types of users, and that we’re not releasing something that’s broken. It goes beyond code; they make sure the things we’ve done work.
The roles I’ve just mentioned are integral to our company, and the fact that we have so many people who care deeply about them is a huge part of our success, and this structure has led to great results. It allows us to bring together incredible web engineers, clever team leads and fantastic client projects to realize elegant solutions (often re-released as free, open source software for the WordPress ecosystem.)
When I joined XWP, I didn’t fit neatly into any of the above boxes neatly, but it was clear that I could help (and I think definitely have!) with helping own a new perspective that enhanced feature completion and client satisfaction. This path, along with parallel efforts internally, has led us to experiment with a few other roles to further our ability to provide value and serve our clients. Some of these include:
- The Search Engine Optimizer owns SEO (and sometimes social media, too.) They help confirm best practices are made in FE and BE code so that robots crawl pages correctly. They share a similar responsibility to QA in that they’re a validation role, concerned that content is structured the right way so that users click on search engine results and robots crawl sites, further helping bring value to our clients.
- The Visual Designer (Both UI and/or UX) owns form and function. They visually actualize the architect’s plan, consider the client’s goals, and look at what is needed to bring it all together into a cohesive plan. Problems can and should surface, and multiple solutions should always be tried. Without a designer, APIs can miss features and interfaces can become too complicated, or just not make sense.
- The Product Designer owns iterative design thinking. They seek to find (and ultimately resolve) the problems that surface. Currently, we piggyback this on the Product Owner role, but there’s a key difference: The PO champions for the customer (or client) to identify needs and criteria, and the PD seeks to surface problems and actualize solutions. Many traditional “designers,” including myself (and my XWP colleague Joshua Wold) approach every problem with this product design methodology in the back of our minds as we believe something can evolve, change and improve with the right adjustments. This is an era of transcendence, and the only constant is change.
Design is not just what it looks like and feels like.
Design is how it works.
– Steve Jobs, Apple co-founder
On these points, a Designer might recognize the importance for a change that could require hundreds of hours of extra development time. An SEO might spot dangerous technical pitfalls with potential to damage website rankings. A Team Lead can support and encourage the team to and through a Sprint, looking for opportunities to ensure that the team isn’t burning out and is thriving and excited for future work. A PO should advocate on behalf of building the best product possible and representing the stakeholder’s vision, while also consider the end users needs.
In all of these conversations between our team members there should always be an element of tension: When disagreements inevitably arise, healthy debates and discussions should help the team identify the best path forward, and when that path is decided it should be one the whole team can support, even if they don’t all agree with it. And this sometimes is a compromise, but it’s always a result of holistic thinking. It’s a beautiful thing we see happening every day: It should be our goal to facilitate more of it.
I’ve written this post with the hopes that you’ll better understand where a Team Lead, a Product Owner or some other future role might come from when they challenge an idea. And I want you to challenge when you think you should. I also hope you’ll advocate for an SEO, a Designer, a QA or any other role if necessary on your projects, and I hope you’ll help us invent a new role when something isn’t being owned, but should be.
One other element we discussed about this is role sharing, where someone is two of the above roles on a project by choice or necessity. It’s best that some of these key roles are different people, so understand what might happen when a team implements role-sharing. For example:
- A PO/TL can lead to a deprioritization of the PO role.
- An architect is often a FE/BE dev, too.
- A PO can write really good acceptance criteria for the QA to evaluate, especially if they’re the same person. But not having fresh eyes on the project may mean that things get missed.
A classic example I’ve seen at other agencies is the healthy tension between account managers and project managers: the AM’s job is to get as much work to the team (broadening scope) and validate the work the team has done to clients. A PM’s job is to make sure the work gets done as completely as possible with the most targeted measurable delivery (reducing scope). But a hybrid AM/PM works all hours of the day with less efficacy than two people working together.
I believe these creative tensions are healthy, normal and important: The best way to grow our budgets without burning up our resources (and ship the best work possible) is to have this tension holding accounts-vs-projects responsible to each other. We should understand these tensions and protect them.
The best “owners” will also be open to listening to any perspective, especially if it’s got someone primed enough to say something about it: Collaboration means the whole team should speak up and listen to those who’ve spoken up, so ideally any gaps in the overlapped role should be spotted.
That being said, role ownership can have fluidity. We have a few good examples of this at XWP: Some engineers write documentation, some team leads who do design or strategy work. Ownership should be discrete (own what you should) yet fluid (you can do different things, especially on different projects) to allow you to focus on what tasks you’ll deliver for a given project so you don’t have to worry about the rest.
Making our Work Better
Even though we have a few already, our working group believes that XWP projects could benefit from even more Product Owners to help teams advocate for better products, and the ecosystem would further benefit from not only more POs, but also more SEO and design conversations to help deliver better results from all of us.
But we also need to advocate the other side of the product life cycle – QA – as it helps actualize the goals of improving the products we’re building and ships the best stuff possible.
In summary, “owning” your perspective should guide you toward the best possible collaborative results for your team. I hope this post has inspired you take the time to develop an understanding of what your ownership covers and how you can help support your team and project better cover what’s actually needed.
We’d love your feedback on this notion of ownership in projects. Here’s a few questions for discussion:
- Do you find role tensions to bring a positive or negative effect?
- What in this post resonated here with you the most? The least?
- Did this post bring clarity to your role and its purpose on the team?
- What role do you feel could most benefit your team by adding it?
Note: this post was originally shared internally in January and we’ve republished to share our perspective outside of XWP.