We spoke with Dana at the Shift conference in Zadar, where we discussed AI agents, the evolving role of developers, and the future of software teams.
The structure of software teams is one area where Dana already sees a noticeable shift. Larger teams traditionally split these roles among several people, but much smaller groups can now handle them together:
The biggest difference is the empowerment that teams have. Before, you would have teams of 5, 6, 8, 10 people that all had very distinct roles in the software development life cycle, and I think the biggest shift is the enablement that people that are enabled solo, or two or three, can do everything end-to-end.
That shift has also influenced how Netlify organizes product development. Dana says the company no longer relies on sequential handoffs between product managers, designers, and engineers.
Instead, Netlify gives teams more autonomy through a narrative-driven product roadmap. The company sets the broader direction, while individual teams decide how to shape what they build next.
To stay aligned without introducing additional layers of coordination, Netlify combines familiar tools and routines with AI agents:
We really let our teams have some personal take on what they’re going to build next, but we utilize systems like Linear and stand-ups, and honestly agents to keep us all in line so that we can move at the speed of machines.
More autonomous teams also change what Netlify CTO expects from the people leading them.
When asked which leadership lesson has stayed with her through roles at GitHub, Heptio, New Relic, and Netlify, Dana returned to two ideas, trust people and recognize expertise regardless of title:
Low ego. You are going to have people smarter than you in the room just because you have the amazing title and you are marked the leader. Your job is to be humble, build connections, and really learn, and be a part of your team and not just mining your team, and I think the biggest lesson is to trust people and allow them to be adults.
That principle becomes even more relevant as the work itself changes and developers increasingly operate alongside AI agents.
When we asked Dana what a great developer experience looks like today, she framed the question around a different relationship between engineers and code.
For her, the developer’s job is increasingly about enabling agents to act safely on their behalf:
A great developer experience is an agent experience. No longer should my developers be writing code. They should be enabling agents to do stuff safely and on their behalf.
That kind of environment also depends on developers being able to understand what those agents are doing.
Dana points specifically to clarity, signals, and telemetry as the mechanisms engineers need both to help agents complete their work and to understand what they have done once changes reach production:
A good engineering experience is ensuring that we have clarity, signals, and telemetry so that their agents can get the job done, and so that they can know what the agents did in production.
If agents take on more of the direct implementation work, Dana sees engineers spending more of their attention at the system level.
She describes that change as a move away from creating code itself and toward designing the environment in which software is built and operated:
We’ve moved it from creating code to really architecting systems and allowing engineers to do what they do best, which is build trust within the systems.
In that framing, the impact of AI is not limited to making individual development tasks faster. It also changes where engineering judgment is applied.
Dana is also cautious about one of the most straightforward ways companies can approach AI adoption, taking an existing process and simply inserting an agent into it.
Instead, she argues that teams should reconsider the workflow itself:
Agents can’t do everything. They can do everything, but they shouldn’t do everything, and it’s a trap. Don’t start building things on existing workflows. Change your workflows.
That becomes even more relevant as Dana expects engineering roles, tools, and workflows to change significantly over the next few years:
Enable an agent experience, because in two years, our jobs will significantly change, and some of the tools that we’ve been building and some of the workflows will be commoditized.
At the same time, Dana is not arguing that teams should replace technology simply because something newer exists.
She specifically points out that tools such as Bash can still have a place when they remain appropriate for the problem.
Her advice is: “Keep it simple.”
