At Datadog, our employees act intentionally to foster a culture of open communication, healthy collaboration, and mutuality. In this post, we’re highlighting the efforts of Staff Engineer Drew Csillag to accomplish broad, cross-team projects with ample buy-in from our engineers. Drew does this by practicing what he calls influence without authority: a set of strategies for persuading engineers to help out on projects for the greater good.
In this post, you’ll learn about Drew, his ideas, and how he puts them into practice to support a healthy and productive work culture.
Drew joined Datadog in January 2021 following a 20+ year career in software development, with key roles at places such as Google, Spotify, and Dropbox. Over his career, Drew has led a number of broad, complex engineering projects to completion, including massive file storage and data center migrations as well as projects optimizing testing, maintenance, and production changes that involved many different teams.
As a Staff Engineer at Datadog specializing in developer experience, Drew continues to lead projects that improve the productivity, efficiency, and overall satisfaction of our engineers. These include streamlining compliance tasks with the Vulnerability Management team, developing new practices for automating the software lifecycle (ASLM), and improving testing. Like many staff engineers, Drew must rally many stakeholders across disparate teams to keep his initiatives moving forward. Drew is committed to doing this in a way that respects these stakeholders’ time, energy, and interests.
Recently, he coalesced his strategies for fostering collaboration into the concept of influence without authority—a managerial model popularized by the 1989 book with the same name. These ideas developed both from his more recent managerial experiences as well as his earlier junior roles, where he would occasionally struggle to kick off new initiatives that could expand his impact or be solicited by other teams to take on extra work and feel uninvested in it. “As a more junior engineer, I would propose things and they wouldn’t go anywhere,” Drew says. “I [also] started thinking about when I was on the receiving end of these things, and why I would respond the way I did.”
These were problems Drew needed to solve in order to grow his career. “As you get more experience in being a software engineer, companies look for you to expand your scope. If I wasn’t good at this, I’d be dead in the water.”
Influence without authority, then, is Drew’s philosophy for bringing colleagues on board as he pushes projects and initiatives to expand his scope and make a bigger impact at Datadog—doing so in a way that equally benefits everyone involved.
For Drew, influence without authority is about how to persuade people to help you with work without manipulating or strong-arming them. It requires soft skills and a sensitivity to developers’ bandwidth, incentives, and desire to make an impact. He boils it down to a few key tenets:
- Talk in terms they care about
- See if they’re already inclined to help you
- Find a way to minimize their effort
- Offer to do something in return
- Give as generous of a timeline as you can
“All of the [tenets] stem from a few basic ideas,” Drew says. “To seek the other person’s good, to allow them to retain their agency, to have skin in the game, to tell the truth, and to set things up so everyone will feel good about it not just now, but later.”
For Drew, getting stakeholders on board with an initiative is all about how you appeal directly to their persona. “[I need] a reason to see why your opportunity is an important opportunity to me,” he explains. “Part of the reason I’m at Datadog now is because the recruiter read my LinkedIn profile, and in her original pitch to me, she made it obvious that she paid attention to it by pitching directly at the things in there.”
Drew calls this talking in terms they care about. He sums it up with a related Japanese concept called nemawashi, or the practice of talking to the stakeholders of a proposed change or project, gathering their support and feedback, and taking this into account before the formal announcement. This pillar often comes into play for Drew at Datadog while he’s writing RFC documents. “I find that if I’ve spoken to everyone involved and heard their concerns before putting pen to paper, it’s less likely that I’ll be shot down [in review],” he says.
Aside from appealing to stakeholders’ concerns, Drew also recommends thinking about their interests and incentives to see if they’re already inclined to help you. It involves having a keen awareness of social capital and mutual incentives in the workplace. Drew paraphrases his former Datadog colleague Ian Nowland to define social capital as “the currency of trust, earned by contributing to the common good.” According to Drew, if you focus on building social capital by helping your coworkers and solving problems, they will in turn be inclined to help you with your initiatives based on your existing working relationship.
For Drew, influencing colleagues to help with his initiatives is all about putting forth his own effort. “If your coworkers feel you have skin in the game, they’ll feel more like a teammate than an adversary,” he says. “They’ll feel that you’re not making the request of them lightly but rather with consideration, as you’ll have to bear some of the load.”
Along with having skin in the game, Drew’s next two pillars—find a way to minimize their effort and offer to do something in return—emphasize the need to get your own hands dirty when driving collaborative projects forward. “If you need someone to do development work for you, make an offer to pitch in,” Drew suggests. “Perhaps rather than having them write the code, they can tell you what you need to do and you can write it instead, with them reviewing it.”
Drew finds that these efforts are particularly useful when working with teams that have pre-existing interpersonal friction. “I used this technique at one job where my team and an ops team had been butting heads before I got there,” he says. “I needed things from them, and while I could appeal to management to get it done, I chose not to make a power play—that would solve my immediate problem, but would only damage the relationship more. Because I volunteered to chip in on the work, the ops team saw me more as a friend rather than an adversary, and it got our teams to have a much better relationship.”
Drew finds it important to do his part to preserve the agency of the stakeholders he works with—this is the goal of his last pillar: give as generous of a timeline as you can. “If you don’t give [stakeholders] enough time, it can wreck their schedule and cause them stress that didn’t need to happen,” Drew explains. “And they’ll associate that stress with you.” In past roles, Drew’s seen people try to influence others to work for them with “false urgency, where they say they need it by the end of the day, but the actual deadline is considerably longer.” He finds that this ultimately “erodes the trust you need to make these kinds of deals work.”
Drew recently presented his ideas in an open forum by hosting a “Brown Bag Talk,” which is a series of volunteer talks Datadog organizes to help employees share their ideas and expertise with one another. He has also recorded many of these ideas and others in an internal Udemy course called “A Non-Technical Guide to Technical Leadership,” so that new Datadogs looking to improve their leadership skills can learn from his experiences.
By practicing influence without authority, Drew fosters a healthy culture of collaboration at Datadog, and in doing so accomplishes broad, cross-team projects that improve developer experience at our organization. And by sharing his philosophy, he helps other managers and personnel at Datadog learn new soft skills, become more effective in their roles, and nurture Datadog’s positive work culture.
Datadog is growing, and we’re looking for people to join our teams around the world. Learn more about open roles—and #DatadogLife—on our Careers page.