How To Create a High-Performing Product Development Organization
A year ago, I joined Condé Nast Entertainment (CNÉ) to head up product. Today, I lead both product and software development — a team of approximately 15+engineers, product managers and designers.
As a product leader and manager, I’ve had the opportunity to create the blueprint of what a high performing team looks like. In this paper, I will detail that blueprint (which has created what my team at CNÉ describes as the best place they’ve worked so far) and how other companies can use my learnings to create their own high-performing product development organization.
1. The Usual Fear of Change
When I arrived at the company, I learned my new team had been working in a very traditional organizational model: product on one side (comprising of product managers, designers, etc.) and technology on the other. A physical Kanban board was in the middle of the open space. The team held weekly meetings to review the workflow presented on the board.
But as a product leader, (a) not having an electronic version of this Kanban board accessible anywhere at anytime was ineffective for the business and (b) I didn’t think we were ready for Kanban. In my experience, to apply such methodology successfully, you need to have a very strict input queue system which didn’t fit with the maturity of our product suite.
(our 1 year old Kaban board, kept like a museum piece)
So, I tackled my first challenge: the fear of change. Changing the way people work is always a challenge. But, change was needed.
Transitioning from Kanban to Agile
First of all, we looked for a tool that could handle Kanban boards digitally, and could move to Agile Sprints easily. We decided to use Jira.
Secondly, we wanted to keep a weekly pace to show transparency about the velocity of our work. Therefore we chose to adhere to weekly sprints and to create as many cards required even if the epic lasts for more than a week.
I cannot stress how routines are important in any line of work. Whether it is for a child or in aviation. Having a clearly defined routine in how you work is critical. In terms of routine, we are doing the following:
- Weekly roadmap meetings to approve the list of deliverables expected. This is followed by story grooming with as many technical stakeholders required.
- 10 a.m sprint meetings every day (not exceeding 20 mins) complete with meeting notes to make sure communication is clear and consistent.
- Demos & Retros every week with follow-ups.
As a manager, the first pitfall I had to avoid was to create stress on the software engineers to develop features on a weekly basis, forcing us to cut corners and commit bad code. The second one was around delivery dates. I had to get the team to start looking at delivery dates as an objective, so I involved more people at the story grooming stage to gain early support across the company.
I had to make it clear that this transition was necessary to give a sense of pacing and tempo more than anything else, and that we will create as many cards required in a given week to show progress on the different epics.
We were able to demonstrate that very quickly.
To date, we have never had to cut corners to deliver, as the business is made aware of our progress on a weekly basis.
2. Implementing Simplicity: Organizational Setup
Keep it Simple:
- Product managers are tasked to deliver the features that will grow our business. They write epics and cards into Jira with requirements and goals for each feature. They work with many business stakeholders and, most importantly, the research & analytics team to make educated decisions.
- Designers are briefed by the product managers on the features they need to design and goals expected. We follow a very lean design process and our designers are doing both UX and Visual Designs. This process eliminates back and forth. Product managers are also responsible for conducting research — and are doing regular surveys to guide their choices.
- Software engineers pick up the cards that are in the sprint, code the feature, send a pull request (PR) to one of their peers for review. Then the feature gets deployed.
Our software engineers are full-stack and cross-functional. It allows them to pick any cards available on the sprint and, from a management perspective, we avoid the pitfalls of having siloed expertise.
One thing that I love about this setup is that engineers are empowered. They are responsible for the code they push to production.
In our setup, the development operations team is consulted on the design of a feature at the beginning. We don’t bring them in at the end just to debug.
The only mission of DevOps is to make sure that we have a scalable, stable and up-to-date platform.
And when it comes to bugs and code maintenance, we dedicate a software engineer per week, known as Batman.
3. Merging Product and Technology Teams, a good idea?
In our experience, we’ve seen only benefits by switching to a merged organization:
- Decision making is really quick — as the leader of an integrated team, it forces product managers and engineers to work as one group to find solutions. No more competitive debates between departments — it’s not about which team wins.
- Engineers love working in this environment as it removes friction and, most importantly, conflicts out of the way. Since I took over this team and put in place this setup, employee retention has improved drastically. We haven’t had any employees leave the business despite being in the very competitive New York City market. (In fact, people who left the company before I took over came back!)
I have to caveat that merging those teams requires a leader not only with strong product experience but also with a good technology understanding.
Above everything, implementing these processes has created a cohesive team. Our Morale Code: “We wake up together, We have lunch together and We commit code together” — and we take great pride in that. If there are issues, we do not shy away from them and everyone is empowered to raise a red flag.
It’s been a year since we implemented those processes and way of working and we have no plans to change it.
Nathan is a Fellow Member of the Chartered Management Institute in the UK.