As a developer, it's common for you to balance sometimes opposing priorities. Stakeholders want you to create high quality software quickly. We're trying to do the same thing. We aim to build product capabilities that are automated and programmable, self-service, and very scalable. We want to be developer friendly, while staying enterprise relevant. Those are all big goals that are tough to balance against one another. To accommodate all of those requirements simultaneously, we needed to make a change in how we utilized our resources and in how we prioritized our work in order to become more effective.
To get where we needed to be we had to undo some of the old-school, more traditional boundaries that we had created over the last several years. We needed less functional management – what we call overhead – and more focus on getting the work done. In order to catch up to the market demand, we had to move fast and produce high quality products.
Several months ago, we made the move to organize in a DevOps fashion in order to emphasize some of the key values on which our teams are built. We acknowledge that organizational culture matters. We operate with an expectation of high trust within cross-functional collaboration and through open communication to create a shared consciousness regarding our vision. This approach creates a strong feeling of empowerment and enablement throughout the team, as we constantly strive to improve what we do by learning from failures and embracing new ideas.
Our typical team structure consists of the following roles: Product Owner, Product Analyst, Engineering Manager, Engineers/Developers. Each role has its own well-defined responsibilities and expectations, and all are expected to be accountable for the success of the team. The Product Owner determines the “what” and the prioritization as to when those things should be taken on. The Engineering Manager leads the team in discovery and in decisions on how to technically build and implement what the Product Owner has determined will create value to the customer.
There is significant value to having a strong, well-functioning relationship between the Product Owner and the Engineering Manager. A strong and supportive relationship between the Product Owner and the Engineering Manager keeps the team tightly aligned and working in the right direction effectively. A sturdy relationship between the Product Owner and the Engineering Manager increases team velocity and can also reduce the time-to-market for the product.
The following philosophies are key tenets to how we have created resilient Product Owner and Engineering manager connections on my teams, which has enhanced team performance and resulted in a better customer experience.
- Maintain personal integrity at all times.
- Demonstrate confidence and reliance in each other’s value and abilities.
- Debate the approach or value of a specific story when needed.
- Within cross-functional teams from different disciplines, it’s critical to be specific. Don’t lose the technical detail in the translation.
- Share and agree on expectations for each other and for the team. Update and refine those expectations regularly through honest retrospection.
- Compromise when appropriate to keep the team moving towards the vision.
- Open communication on time, every time.
- Give and take real feedback constructively.
- Active listeners. It’s critical to ensure that we understand the heart of the issue in order to best relate to one another.
- Talk about assumptions. Don’t just let them go unmentioned and risk being misaligned.
- Shared Vision
- Well-understood mission and vision for the product we are creating. Ensure that the rest of the team shares that understanding. Revisit this discussion often to maintain alignment.
- Constant Improvement
- Aim to uphold Agile and DevOps values for how the team operates. Using these philosophies, we strive to become more efficient and effective with each iteration.
Every team needs leadership. At CenturyLink, we expect that our team leaders provide guidance, direction and instruction for the rest of the team. While we anticipate leadership qualities will be demonstrated by all members of the team, the two primary leadership roles within each team are those of the Product Owner and of the Engineering Manager. This DevOps approach, in which the Product Owner and Engineering Manager model the way by their actions, enables each team member to contribute their assets at a very high level.
As we venture on this DevOps journey we will be sharing our milestones as a company, but more importantly, as product teams. The stories will be told from different perspectives within the team from Product Owners to Developers, each outlining the tools and processes that we adapt along the way.
If this approach to leadership and team-building is appealing, perhaps you want to work with us?