The 5 Levers to Address “Org Smells” and Ship Higher Quality Software (Faster)

By Lara Hogan and Deepa Subramaniam    |    September 29, 2019
GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

There may come a time when you can sense that your organization’s performance isn’t optimal, but you can’t quite put your finger on it. Something just smells off—in fact, Lara Hogan and Deepa Subramaniam call these symptoms “organizational smells.” These ‘smells’ hold back the strategic execution of the organization’s north star vision. And Hogan and Subramaniam thrive on helping organizations overcome those hindrances.

“We love partnering closely with leaders to help coach them and help make sure that they understand exactly what they need to do to build foundational skills and lead their teams successfully and confidently,” Subramaniam says.

Previously, Deepa Subramaniam led Product and Design at Kickstarter, Hillary for America, charity: water, and Adobe, and Lara Hogan was the VP at Kickstarter and Engineering Director at Etsy. The two have since partnered to co-found Wherewithall, where they help other leaders build, mentor, and grow their product and engineering organizations.

“When we get called in, there’s usually an executive or a really senior leader within the engineering organization can tell that something’s off, but doesn’t know what it is,” Hogan says. “We get brought in to see if we think this is weird, too.”

“On the product and design side,” Subramaniam adds, “folks reach out because they’re shipping product, but they think they could be shipping a lot better or a lot faster. Or shipping products that have a stronger impact on the business, or that better solve customer problems. It’s exactly what Lara was saying. There’s a smell that feels a little off, and they just want some external opinion to come in and check it out.”

There are all kinds of smells that can be haunting your organization. Fortunately, you don’t have to identify each one of them to apply the five tactics — or “levers” that leaders can pull — to revitalize and help your organization ship higher quality software, faster.

Clarify roles and responsibilities for teams and individuals alike

In the early days, organizations often don’t have (or require) a career ladder or skills matrix. Team members tend to wear lots of different hats. That works fine in a small organization. But as the company grows, Hogan says, it becomes increasingly challenging to distinguish between what someone wants to do, what someone should be doing, and what someone is doing but doesn’t really want to be doing.

“Clarifying roles and responsibilities tends to be the thing that structurally can create a lot of change throughout an organization,” Hogan says.

Whether you want to support your people’s ability to advance in their careers, to recognize their growth, or to make sure that responsibilities are well understood, clarifying roles for teams and individuals alike clears up job overlap and greases the interactions between functions.

To illustrate clarified responsibilities, Hogan likes to draw a Venn diagram the leads on a feature team — like the one below that clarifies the roles of an engineering lead, an engineering manager, and a product manager.

Lara Hogan’s Team Leader Venn Diagram

Each role will have overlapping responsibilities, and each also has its distinct domain. “If you draw this Venn diagram or some other clear visual representation like it, it can be used as a tool to help those three peer leaders decide who’s doing what, who people can go to for questions regarding those areas, and which responsibilities should be shared,” Hogan says. “As long as there’s that genuinely shared understanding, not just with those three people, or however many people, but with the entire team that needs to work with them and rely on them, that is the holy grail of clarification of rules and responsibilities.”

Once you achieve a greater sense of clarity, Subramaniam adds, you’ll see greater accountability across teams. People don’t waste time wondering what’s expected of them. And you’ll see people producing better work, and at a faster pace, which elevates the organization’s performance as a whole.

A lack of clarity can cause attrition

You can also recognize when your organization lacks this level of clarity because it manifests in poor accountability—in other words, you develop inertia. “Nothing is happening with any sort of urgency within the teams,” Subramaniam says. “There might be controlled chaos. Maybe too much is happening, but it actually doesn’t have a lot of impact. Or maybe everyone’s checked out and feeling ambivalent. Nine times out of ten, the diagnosis that we’ve come up with when we start experiencing that and seeing that on the teams that we’re leading, it’s that folks don’t understand what they’re responsible for and they want that clarity. Our brains need clarity so that we can have a sense of stability.”

Once someone truly understands their individual responsibilities and the role of their team, as well as the shared responsibilities within the team and cross-functionally across teams, they can deliver on that understanding. They can be more accountable in a safe, secure, and easier way.

And speaking of clarity in roles and responsibilities: it’s the leader’s place to take responsibility for their people’s clarity or lack thereof.

“That stops with you,” Subramaniam says. “You and your leadership team working together to create a healthy, clear, shared environment where people want to do their best work. Everyone’s showing up every day wanting to do their best, but do they have the framework and the guardrails in place to do that best work?”

Create living product documentation to share insights and stay aligned

A lack of accountability can also manifest because of communication breakdowns. Of course, communication and transparency build clarity. So when it appears that people or teams are failing to accomplish what’s expected of them, it may be as simple as the absence of a paper trail demonstrating the work they’re actually accomplishing.

“Something that I think a lot of companies don’t do well enough, especially as more and more companies build remote or distributed teams, is creating the documents, the meetings, and calling out the milestones that keep the product development train on track,” Subramaniam says.

The problem is typically not that the work isn’t happening—it’s that the work is invisible. Leaders and other stakeholders aren’t aware of it. So Subramaniam recommends having living product documents and living processes that make it easy to find that information when individuals and teams need it to coordinate. That level of documentation and visibility can actually boost accountability.

“I work a lot with teams to make sure that they’re checking in on their product development processes, and making sure that that’s well documented,” she says. “Those integral documents like roadmaps are up to date always and are living — as in they never go stale and other people can reliably make plans against them.”

The best documentation is regularly tended to

What exactly does it mean, though, to have living product documents and processes?

“Your product development processes, your key product documents, like your strategic objectives and your roadmaps—these are documents and processes that need to be tended to,” Subramaniam explains. “They need to be updated regularly. Especially as the organization might grow, might add on more remote team members. If you don’t take the time to document your product processes, individual teams end up reinventing the wheel, duplicating efforts, or they have unnecessary and wasteful disagreement. A lot of time, companies don’t spend enough time really explicitly calling out what their product development life cycle is, and where these critical documents live.”

So these documents—whether strategic plans or archives of experiments run and features launched—enable leaders and ICs alike to locate assessments of the work that’s happened and the impact it’s had. Furthermore, documenting meetings allow teams to conduct retrospectives of the development workflow and decide what to do next.

Subramaniam finds documented milestones helpful to clarify and track the progression of projects. Is discovery complete? Design? These are critical milestones that you’ll want to share broadly within the organization, rather than just with the product or engineering team. You want everyone to know, or at least have access to knowing, the state of your projects.

“There are a few critical meetings that can really keep that sort of flowing smoothly and making sure everyone has access to all the information they need,” Subramaniam says. “Not just the team building the product, but leadership and stakeholders.”

Facilitate productive and engaging meetings

Ah, meetings. Many of us are leery of meetings because we’ve experienced so many unproductive ones. Fortunately, you can learn to lead and facilitate more effective meetings that are actually beneficial uses of everyone’s time, without snowballing into half their work week.

First of all, meetings really can be useful. “There’s that old adage, ‘this could have been an e-mail,’” Hogan says. “A bunch of studies have shown that usually it can’t be an e-mail. Humans are so bad at understanding context and understanding tone and understanding normal human things that you get from using your words. Often important context or important tone is going to be lost if you just have an e-mail.”

So if you’re going to have meetings, you might as well make them work for you.

“The first thing I recommend is to separate the meeting facilitation and the meeting leading responsibilities. The person who’s leading a meeting usually also can’t facilitate it. They’re using their brain power on making sure that we’re accomplishing the goals of the meeting.”

“The first thing I recommend is to separate the meeting facilitation and the meeting leading responsibilities,” Hogan says. “The person who’s leading a meeting usually also can’t facilitate it. They’re using their brain power on making sure that we’re accomplishing the goals of the meeting. It can be really helpful to distinguish between those two roles and get yourself a meeting facilitator. That way, you can actually focus on leading that meeting and leading that group of people.”

Facilitators can focus on all the non-content-driven aspects of the meeting. They can make sure everyone has equal access to participate. They can make sure everyone has what they need to attend the meeting. They can verify that enough context has been shared beforehand, and that there’s an agenda laying out what the meeting aims to accomplish. Within the meeting, the facilitator needs to be able to stop steamrollers from talking, make sure that participants are being engaged, and keep track of the meeting’s end time.

“That facilitation role is so critical,” Hogan says. “It can be the difference between a really powerful meeting in which stuff gets done, things are decided and people can go back to their days, and a meeting that just feels completely useless.”

Her second piece of advice is to distinguish between what work can happen asynchronously outside of a meeting and what work can happen synchronously inside of a meeting. Meetings can do wonders for making decisions, unblocking people, and sharing and receiving context.

“You’ve got to think about a meeting as unlocking people to go back into the next week of work so they can do a ton of stuff,” she says.

That’s the real rub with meetings, of course, particularly for ICs: Meetings are time spent not actually coding. We’d love to tell you that there’s a formula for how much of an engineer’s week should be carved out for meetings, but the reality is trickier than a magic number.

Especially as more companies have distributed teams, it’s helpful to think of meetings not as a quantity of hours but rather as a means of collecting information. “I think that the better way of thinking about it is, are you getting the information that you need to do your job?” Subramaniam says. “And are you able to provide the information that you need in order to do your job and help your team be successful?”

If the answer to either of those questions is no, then look at the communication flow. It could be that what should be written down isn’t being written down, like those living documents. It could be that the venues and the forms of (as Hogan says) using your mouth words and digesting topics in more detail isn’t happening. So Subramaniam recommends, if your communication flow isn’t functioning, that you start reverse engineering from that pain point.

Sometimes, meetings aren’t the best avenue—and that’s why we all feel some disgust for them. Some results can be discussed via Base Camp or other tools. Figure out where folks on your teams can share their thoughts synchronously or asynchronously, and what will serve the flow of information best.

Again, it is a leader’s role to set expectations for communication on a team. How much should an IC expect to invest in meetings, and to what purpose? How are team members expected to communicate within the team and across teams?

There’s still no magic number, but you can give your engineers realistic expectations so they have clarity on their responsibilities. And if that changes for one week or for a year, let them know that too—it doesn’t have to be a fixed number.

“It helps product managers and engineering managers and tech leads estimate work better once you’ve set some of those expectations,” Hogan says. “It really is on a manager to set those expectations for their individual teammates as much as possible.”

On a final note, meetings are also your team’s chance to come home and regroup together. “Sure, you can go as an engineer and work siloed on projects or work with new teams, rotate on and off different squads,” Hogan says, “but actually, what’s most critical to your success and your team’s success and the project’s success and the company’s success is developing those relationships with those people around you.”

Practice and lead difficult conversations

One reason—though certainly not the only reason—to develop relationships with your team members is that you will inevitably need to lead difficult conversations with them.

“It could be a performance conversation,” Subramaniam says. “It could be hey, we are organizing layoffs. it could be, we need to completely throw out all of this work that you’ve been doing for the last two years because now we’ve got a new company direction. Difficulty comes in all forms.”

Big surprise—holding difficult conversations comes back to the idea of clarity, and how important it is to establish that right up front. Subramaniam first strives to develop empathy with the people she’s conversing with.

“So often when we need to communicate new information that’s going to be hard for someone to hear, we know what it feels like in our own bodies and heads, but we can’t empathize with this other person,” she says. “Everybody has an amygdala, which is responsible for the fight or flight responses. They’re taking in information from outside and they are categorizing it as either threat or reward. And if a threat feels threatening enough, our amygdala will tell our prefrontal cortex—that super logical, super rational, complex problem-solving part of our brain—to go on standby, which means all you’re left with is an amygdala-driven human in front of you.”

Leading up to a difficult conversation, she suggests keeping in mind the core needs that humans have at work. Hogan and Subramaniam borrow from the model that Paloma Medina developed to represent people’s core needs (called the BICEPS model). The core needs in the BICEPS model are:

  • Belonging. We need to feel like we belong to this larger group of people.
  • Equality/fairness. We all want to believe that people are treated fairly and have access to the same things in a fair way.
  • Improvement/progress. Whether it’s an individual or a company, we want to feel that we are moving forward and our work is accomplishing something.
  • Autonomy. We all want to have a sense of choice, balanced out with direction. We thrive when we have a sense of what to accomplish every day.
  • Predictability. We want to feel like it’s not just constant waves of change coming at us. We like clearly knowing what to expect.
  • Status. We want to feel like we understand our place in the hierarchy and that we’re continuing to grow—or at least that our standing isn’t threatened.

So in approaching difficult conversations, you’ll be well served if you keep a lookout for potential threats to these six core needs. You can also take care to ensure that you are helping people understand how this conversation affects their basic needs—after all, if the conversation didn’t touch on these ideas, it wouldn’t be difficult in the first place.

Once you enter the conversation, Hogan suggests remembering that the amygdala benefits from a little hit of dopamine. That’s the benefit of a compliment sandwich used well.

“I don’t think that compliment sandwiches are good if you’re trying to hide bad feedback. However, I really like to frame feedback in terms of observation and then impact, and then a request or a question.”

“I don’t think that compliment sandwiches are good if you’re trying to hide bad feedback,” she says. “However, I really like to frame feedback in terms of observation and then impact, and then a request or a question.”

In other words, feel free to offer the other person positive feedback to start the conversation. But make sure it’s genuine. We can all smell blow-softening praise a mile away, and you cannot stall the difficult conversation.

You can, though, structure the difficult conversation productively. Hogan coaches leaders to enter the conversation with an observation. Think of this as behavior that can be recorded on a video camera—the who, what, where, when, why of the situation. It should be fact-based and openly apparent, without being based on assumptions or feelings.

“The example I usually like to give is someone has been sending me e-mails that only have three to five words in the body,” Hogan says. “It seems like they’re angry all the time and they’re being really short with me. Maybe they’re mad at me. The observation I have for them if I’m delivering feedback to them about this can’t be ‘It seems like you’re mad all the time,’ or ‘Your e-mails are really short.’ Those are judgements, those are assumptions, those are not observation. An observation is, ‘Routinely, on average, your e-mails contain three to five words in the body. I have observed this to be true.’”

Once you’ve established the observational basis for the conversation, then you can couple it with the impact of that behavior. This is where you can begin to insert your interpretations and feelings about that behavior. So in the case of the 3-5 word emails, you could say, “I wonder sometimes if you’re mad at me when I receive these emails;” or, “When you send these emails, I have to respond and ask more clarifying questions because I don’t fully understand what you mean.”

Then Hogan likes to ask, “What is the impact of that?”

“It’s helpful for the other person to understand what’s the impact of their behavior,” she says. “Then you cap it all off with a request for them to change their behavior, or a question.”

Requests are handy when you have a very clear and obvious change they can make; however, Hogan recognizes that requests seldom help people grow and learn. That’s why she encourages leaders to ask a question instead.

“Not a loaded question, like, ‘Why do you seem mad all the time?’” she says. “That’s not a question that’s going to be helpful. But a question like, ‘Can you help me understand why you choose to write emails with three to five words in them? What were you hoping to accomplish with this email? Or what were you hoping I would glean from this e-mail?’”

Open-ended coaching questions tend to help the other person think about their behavior and the impact it has. Such questions also motivate them to form their own solution to the problem because you’ve equipped them with knowledge of the impact.

“Usually people’s amygdalas are so much more open and receptive to this form of feedback, because it doesn’t feel threatening,” Hogan says. “You’re not passing judgment, you’re not making assumptions. All you’re doing is saying here are the facts on the ground of the observation and the impact. What can we do about this together?”

For leaders, communication means handling the tricky balance between creating clarity—which can include honest and difficult updates—and motivating people. When this happens most successfully, Hogan sees that it’s because everybody has a shared understanding of where the organization is trying to go.

“It’s helpful for the other person to understand what’s the impact of their behavior. Then you cap it all off with a request for them to change their behavior, or a question.”

That north star gives your team context for every decision. When you have to share hard news, the recipients can more deftly shift from taking it personally to understanding it in a broader context.

Offer context broadly and indiscriminately to the entire organization

“Lara and I learned this lesson together when we were leading teams at Kickstarter,” Subramaniam says. “To give context, and to give context often and in a unified and consistent manner, we shared communication updates together. I mean that literally. We would stand up there together to co-lead all-hands meetings with the entire product, design, data, and sharing teams. We would co-author emails together, signed by both of us, to announce strategic changes or staffing changes or anything like that.”

The reasoning behind this strategy is that you want all of your leadership to bang on the same drum and make sure that you are communicating a unified message. Implicit in that is that you want your leadership team communicating context to the greater organization whenever possible, so that everyone understand the greater perspective of how the company is accomplishing its goals.

“We did a lot of things where we would communicate together to avoid giving disjointed communications or communicating in a siloed manner,” Subramaniam says. “We did that by leading cross-organizational meetings or writing cross-organizational emails, or opening those organizational office hours. When our team saw us coordinating together, they got that shared context. It wasn’t just me giving an update to the product and design team, Lara giving an update to the sharing team, but us tying it all together.”

What that meant for the broader mission, she says, is that cross-functional communication translated down to specific functional teams in drastically helpful ways. People finally started understanding the reasons behind the things that leadership was asking for.

Receiving that broader, transparent context makes changes in roles, responsibilities, and expectations less concerning and more understandable.

“So many times leaders don’t share the reasoning behind their decisions, the path that took them there, the other options that may be discarded along the way to making that decision,” Subramaniam says. “You’ve got to share that backstory. Share that journey to the decision, because that buy-in comes when people understand the thought process that brought you there.”

This strategy goes for just about any and all decisions—not only ones that are strictly cross-functional. Whenever Hogan and Subramaniam relayed information that affected only one subset of teams, they still shared talking points with each other and with the other leaders in the organization so that everybody still received that context.

“Because we had these honest, candid conversations, our team started having more honest and candid conversations with each other in explaining the path to their decisions,” Subramaniam says. “In our product and design reviews, I started seeing more explanation around discarded design choices and the way that someone landed upon the solution that they were presenting. Because we were really good about sharing the pathway, the narrative, the history to a decision, the team started mimicking that behavior, which was really good and helped improve accountability and trust.”


Whatever smells you’re sniffing in your organization—and even if you don’t yet catch a whiff of anything fishy—you can start pulling these five levers to improve your cross-functional organization’s performance:

  • Clarify roles and responsibilities for teams and individuals alike
  • Improve documentation so everyone can understand your work
  • Facilitate meetings that genuinely share information and value everyone’s participation
  • Develop empathy in order to give sense to difficult conversations
  • Offer context broadly and indiscriminately to the entire organization

By offering your teams these conditions, you remove countless blocks and hindrances to their effective workflow to revitalize the cross-functional organizational productivity across the board.

GitPrime’s CEO, Travis Kimmel, interviewed Lara Hogan and Deepa Subramaniam for the SE-Radio podcast. They discussed evidence-based tactics that leaders can use to increase clarity and build healthier, high-performing organizations. You can listen to the full episode here.

About the author

Lara Hogan and Deepa Subramaniam, Engineering Leadership Coaches and Consultants at Wherewithall