Nicole Keith is Chief Product Officer at Omnicom Health Group. Her varied career spans product, IT, sales, and marketing roles — not to mention receiving a “secondary education” from her software engineer husband.
In our conversation, Nicole explains how reducing the time engineers spent writing code made her team more collaborative and, ultimately, more productive. She also touches on the delicate conditions required to develop mature teams and how, often, the best thing middle managers can do is step out of the way.
It was a really good opportunity for us to self-reflect on our ways of working and look at some habits that could be updated to be stronger.
For example, when we’re working across teams, we have multiple project managers. So then the question is, which project manager is responsible for the project management duties, especially at those interaction points? We had an opportunity to examine how we’re interacting with each other, where those redundancies are, where it makes sense to add more people, and where it actually helps to have fewer people.
One of the key lessons we learned was to reduce the number of middle managers as much as possible. We had some managers who did their best job managing the project, but what we really needed was for the people on the team to get together in a room and sort it out directly among themselves.
I think it was insightful for project managers to realize, “The best thing I can do, actually, is get out of their way.”
If we don’t do that as part of a rebrand, what’s it for, anyway? The purpose of the rebrand is a renewal of working together.
One of the main themes that we call out on our site is “Uniquely powerful. Together unstoppable.” That is a really important part of the messaging that we wanted to convey.
Through the development of this website, we found instances where fragmenting the conversation through multiple PMs was not a way to come together. But we noticed that when we got in the same room, when we’re speaking directly one-to-one, that’s when we became more powerful.
Through the rebranding, we also galvanized our team and renewed our appreciation of the team’s respective contributions.
Because so many people were excited to get involved in the rebrand, there started to be this monkey-in-the-middle game, and we could feel that we weren’t operating super efficiently, so we had a conversation.
We realized that we had so many people involved, people weren’t sure who to talk to. The team came to a common understanding that the people doing the work are the people who need to talk, and the people managing the work are more effective as enablers than problem solvers.
Yeah, there was a little bit of friction though this conversation, but it helped us realize that we as managers don’t actually have to try that hard to fix things. What we would be better served to do is enable the team to find its own solutions.
I grew up in the software development industry from pre-sales, into professional services, into product development, into program development. The scale just kept growing and growing. I do think that gives me a unique perspective to see the forest for the trees — understanding the pieces, the constraints, the pushes and pulls around the team and the system of the team.
As a senior leader, if you make a small change, it can have big impacts downstream. So I am very sensitive to how we interact as managers. It’s about doing what the team needs rather than having a self-serving agenda.
I like to think I’m a selfless leader. I’m leading a team, but, frankly, the team does the work.
My husband is a software engineer. We’ve been together since high school. We went to college together. I audited some of his classes and took notes when he wasn’t able to attend. I listened to him download on all the cool things he learned in class. I’ve almost received a secondary education through him. We’ve really grown up together.
I know as well as anyone what developers need to do good work. So, a lot of my perspective is around what we, as managers, need to do to make the developers’ lives easier so that they can just pump out really good work for us.
As managers, what do we want? We want to have high-performing teams. We want high-quality output. But we can’t simply say, “Here’s the thing — go!” because of sensitivity to initial conditions.
For example, if we have a vague idea and ask the development team to run with it, it could essentially go one of three ways. One, they could be completely off track because it’s vague and they really had nowhere to go. Two, they could end up doing something awesome because they’re a great team and they know what they’re doing. Or, three, it somehow ends up on target, but that’s a small chance. So how we set up the conditions as managers to be clear and focused pays out in the end.
The team has a lot to do with it, because if we already have a team with a strong project manager and/or scrum master, a strong architect, and a strong product owner, give them a general direction, and they’re probably going to come up with something really good, maybe even better than we initially thought of. Those are initially good conditions.
If the team is the type that likes to have complete requirements, they’re more into implementation than solutioning, you’re probably not going to have a good outcome if you only give a general goal because they want to know exactly what they need to do, and they’re not used to guessing what their owners are expecting. They’re used to working against documentation rather than working against a concept.
Whether a team grows into a stronger or less mature team depends largely on the conditions that we as managers put forth.
It was actually the first project I took on when I joined this company. We had an internal development project, and we had requirements, but we weren’t having good conversations.
The first thing I did was remove the development team from coding for two hours a week so we could talk.
When I mention this to managers who are used to the waterfall methodology, the concept of taking the entire development team offline for two hours a week is blasphemy. But the thing is, we’re using that time anyway. If we don’t talk upfront, the team will have questions. The developer’s going to talk to the project manager, the project manager is going to say, “I don’t know, go talk to QA,” but QA isn’t quite sure either, so then we have to go back to the business owner…
Even though it’s scary to take the development team offline for those two hours, it is really an optimization technique.
The team loved it. We got to know each other as team members. Not only were we able to accelerate our delivery because we knew what we were doing and what it would take to be successful, but we also learned from each other.
As we were having conversations, a little joke here and there would come up. That human element has many benefits. Even though it’s in service to the output of the work product, it supported the team in softer ways as well.
The best structure depends on the organization, but I have often found the trifecta concept to be extremely effective.
In my experience, having a team of three is the most powerful structure we can arrange, because with three people, you only need two connections to make sure everyone’s in sync. But when you add four people, you need six connections.
From there, it just explodes:
You have to have the right people in that trifecta: the project manager or scrum master, if you’re working in agile; the technical architect; and the business representative, which could be the product owner or a subject matter expert.
Within those three people, you need the technical know-how, which the architect brings, and some element of project management — that can be the project manager or the scrum master. Sometimes, the product owner might fill in on some project management tasks.
You also need the subject-matter expertise. The product owner, or even the architect or PM, may have that subject-matter expertise already. Otherwise, you need to bring that expertise in somehow.
At the end of the day, you need those three roles — business, tech, and management — but those domains may shift among members depending on their skillset.
A project manager and a business owner without an architect are dreamers. They lack the expertise to actually execute.
An architect and business lead without a PM are, potentially, drifters because you don’t have the rigor and governance of that management piece.
A PM and an architect without the business lead are drudgers. They’re not always sure whether they’re delivering the right thing for the business. They’re making things up without making sure that the course is sound with that business lead.
So, you are going to have a different flavor of imbalance if you’re missing a given person:
Our organization does the broad strokes of innovation really well: the flashy, the cool, the up-and-coming, the cutting edge. But I think there’s an opportunity to lean in on micro-innovations. Those are things that come from the team level, ground-up, that the innovation departments don’t have insight into because they’re working in a very different space.
The work I’m doing now is figuring out how to give a voice to those micro-innovations so that we can not only capture the big wins, but also accumulate a series of smaller wins.
It requires coordination with essentially the entire organization. We need cooperation with finance to align that a certain percentage of our funds is going to go towards R&D innovation, essentially. We need cooperation with both legal and security to ensure that the new technologies we are evaluating are safe. We need to coordinate with the actual teams doing the work — some kind of mechanism to submit ideas, rank those ideas, surface those ideas.
In turn, we need coordination with leadership to understand those smaller opportunities, their value, and to help support them moving toward a real implementation.
That’s a lot of people already, but we can even take it a step further: we need support from our clients in investing in new ideas and adopting a different way of doing things.
These micro-innovations are, again, sensitive to the conditions. All those things really need to be aligned to enable those things to happen.
With big initiatives, of course, you’re going to involve all of those people, but it’s much more difficult to coordinate all those stakeholders for a micro-innovation. That’s where having those three key stakeholders in place makes the difference.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
The globalization of your product opens up opportunities for growth, however, every new market comes with its own challenges.
Hypergrowth happens when a company experiences an exceptionally rapid rate of expansion, typically more than 40 percent annual growth.
Detractors have long-term effects like negative brand perception, reduced customer loyalty, and a decrease in sales.
To proactively address liability concerns, you can create an internal product recall team for dealing with risks and ensuring quality.
Learn more →
