Upcoming Webinar: Scaling Alignment in Engineering Teams Register Now

When Your ‘Database Problem’ is Actually a Communication Problem

Perspectives in Engineering

When Your ‘Database Problem’ is Actually a Communication Problem

Database operations Senior Manager with Tesla on communication problems
GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

Your database used to run fast as can be. Now, it’s dragging its feet through molasses. No matter why your development is outpacing your technology choices, the immediate impulse is to upgrade your database.

But not so fast—your tech problems may not have tech solutions at all.

The key is recognizing when your problems are technological, and when they are a matter of human communication. Making that distinction is Deirdre Bachman Haggmark’s specialty.

Haggmark, a Senior Manager of Database Operations with Tesla, knows how to fix both kinds of problems once symptoms start revealing themselves. When a database isn’t responding well. When a company doesn’t have metrics or monitoring. Essentially, the point when there’s pain and no one else sees how to fix it from the technological side.

That’s because Haggmark observes that many of the common problems slowing down engineering teams have human-centric solutions.

Every database is different. But human behavior is much more universal.

Haggmark points to three recurring problems she encounters. And in an environment where everything is connected, it’s no surprise that those problems play off one another:

    • Developers aren’t talking to production. “We all follow the same patterns when we’re building up,” she says. At the start, there is no production for the developers to talk to. So once a product moves into production, there’s not a culture of communication already in place. Which correlates with the next problem…
    • There’s not a strong reporting environment. “You have all this data,” she says. “You think it might be valuable. But you don’t have a good way to access it.” For all the good this inaccessible data does you, it might as well not exist. And this unused data leads to the third problem…
    • Performance runs well below peak efficiency. Without a lot of data-driven insight, your performance problems become mysteries. “What you get is so-and-so saying there’s nothing going on. Or so-and-so says they don’t know what’s going on,” she says. “If you don’t know what’s going on, you cannot fix it.”

While these problems have technical roots, they are truly cultural issues. Left unchecked, they can flower into a full-out denial culture. And that is toxic to all kinds of productivity.

Fortunately, your leadership culture interacts with your productivity. So if you can set the right tone, there’s pretty blunt solutions to these problems.

Accountability and transparency

Essentially, you foster transparency by acknowledging that there’s a problem, and accountability by taking responsibility for fixing it.

The admittedly more human approach—assigning fault and avoiding responsibility—is often more destructive. “It’s not productive,” Haggmark says. “And it certainly doesn’t put anybody in the mood for cooperation. But when I say, ‘Hey, my stack is having a serious issue, here’s how I think we can fix it,’ that helps us prevent these kinds of issues moving forward.”

“I find that when I own my problems, other people are a lot more comfortable owning theirs,” she says.

Bear in mind that the intent is to address present problems and improve future processes. If you can improve a system because of previous mistakes, great. But pointing fingers to the past doesn’t nurture ownership. Emulate the accountability you want your developers to embody.

“I find that when I own my problems, other people are a lot more comfortable owning theirs,” she says.

Taking ownership

This culture of accountability and transparency leads to more and better communication. There’s less desire for developers to protect information or shield themselves from blame. But the increased communication can also have the undesirable effect of reducing responsibility. In a sense, if everyone is answerable for everything, then there’s no boundaries around responsibility.

“The diffusion of responsibility is a big deal,” Haggmark says. And the solution here, which she touched on earlier, is ownership.

“Bring them chocolate, bring them bourbon, bring them whatever. Facilitate a conversation that is helpful.”

Even if a problem didn’t originate with you or your team, if it impacts your work, it is your problem. In a sense, taking ownership of the problem gives you the authority to fix it.

“You should stay on top of everything in your area of influence,” she says.

That doesn’t necessarily mean that you accept responsibility for fixing everything yourself. No one expects a database administrator to take on design work. But you *are* owning the responsibility of facilitating the necessary fixes.

“There’s a lot of people that react, ‘Damn it, Jim, I’m a doctor, not a project manager.’ That’s not helpful,” she says. Instead, do what you know, and take charge of enlisting the people who can assist you.

“If someone else can help you, go walk over to that person’s desk,” she says. “What do they need? Bring them chocolate, bring them bourbon, bring them whatever. Facilitate a conversation that is helpful.”

Special ops teams

Haggmark typically works with small teams. She admits it’s a different sort of challenge when you’re with a huge company where punting to someone else is the norm. Her solution here is to carve a large engineering staff into smaller, micro special forces teams.

“I work with a development team of fifty people,” she says. “But I don’t work with fifty people. I work with ten teams of five people. And I know who leads each pod. I know the points of contact. That’s very important.”

“Communicate, and you will save time and money and resources by fixing your problems.”

She points to Extreme Ownership by Jocko Willink and Leif Babin, two former Navy SEALs, who stress the importance of limiting team size. “It’s a great read,” she says. “They write about ownership, accountability, and applying what they learned in training and on the battlefield to leading a team in business.”

Willink and Babin state that you can be directly responsible for only six to ten people. Haggmark mentions additional studies including ones from ERC and Harvard Business Review that discuss optimal spans of control, putting the number anywhere from five to twenty team members. In her own experience, she finds her most effective team size is from five to seven people.

Your ideal team size may depend on your organization’s needs and demands. But if you can ensure each team leader is directly responsible for only a small number of team members, the team is likely to work more cohesively. And then the manager above those teams is managing only as many team leads as there are teams.

The idea is not only to foster accountability and transparency, but to build your structure in such a way as to facilitate their success. We’re all in business, so transparency and accountability are not the end game. But they certainly enable a more effective and nimble flow of productivity and development.

Or, in Haggmark’s succinct terms: “Communicate, and you will save time and money and resources by fixing your problems.”