Real alignment is now our biggest challenge
Anton Zaides& Francisco Trindade I see it everywhere around me - the PR volume goes up 4-5x, but the actual software barely improves (and even degrades). A QA automation lead put it best: “Your tests will pass, they’ll be green, but it wasn’t what you wanted.”
The Qase team spent 9 years building a software testing platform used by 2,000+ teams. Last year agents started producing most of the code, but the rest of the processes didn’t speed up with it.
So they built Tiden. It keeps your intent as requirements that branch and merge like code, and checks every change against that record.
With every engineer creating much more output, small misalignments can quickly turn into stuck projects or even disasters. Especially across disciplines. Getting engineers, PMs and designers on the same page was always a challenge, and now it’s even harder.
Francisco’s approach to this: before debating what to do, build a shared picture of what actually happened using visualizations.
He’s a VP of Engineering at Braze in New York and the author of “Leading Effective Software Teams.” He writes about what makes software teams effective through a systems thinking lens, and I’m very glad he agreed to write this guest post!
Passing the mic to Francisco! 🎤
A couple of months ago, a Staff engineer in my team told me: “We seem to be going backwards in how we manage projects”.
He was working on a project that was just stuck.
- The engineers felt blocked because design wouldn’t provide enough direction.
- The designers felt they were being rushed to deliver suboptimal work.
- The product manager was in the middle trying to coordinate a path but also struggling to keep up with all the possibilities.
The situation escalated to me and my peers in design and product management. We couldn’t agree either: there were lots of opinions and not many facts. We were now in a six-person asynchronous discussion, going in circles.
This problem wasn’t unique to this project.
We can now deliver output in many areas much faster than before. Prototypes are easy to build, code is easier to write, testing is easy to execute. But all that extra output comes with extra noise:
AI speeds up some parts of the process much more than others, and we rarely look at what that does to the whole.
We speed up code delivery but don’t think about how that affects reviews.
We speed up prototyping but don’t think about how we are going to decide amongst all of the options.
That’s exactly what was happening in our project: there was a lot of output from everyone, but no agreement.
As an industry, we are building a lot of great tools to align agents. There are new harnesses coming out every week. But we don’t seem to be spending much time discussing how to better align people in the new context. And the people are the ones driving the agents. When each of them can produce ten times more, any misalignment between them gets amplified too.
Take technical design documents for example.
Before AI, design documents were the way to align a team around how a feature or solution would be implemented. They would bring opinions together and drive the group toward a common vision.
Design documents were far from perfect as an alignment tool, but they were good enough. With AI, we now have very long documents generated by agents that not many people can read and even fewer understand. Instead of aligning the group, they became a tool to disengage engineers from a conversation, making the process less effective.
Here is my perspective, in a twenty-page document (A)I just wrote
- Your Colleague
Draw it instead of debating it #
To solve it, we first had to stop and agree on what had actually happened. The simplest tool for that is still a visualization. Documents got longer and more confusing, but a visual can be understood in a few seconds.
Information radiators, the big shared displays a whole team looks at (like an agile board), bring perspectives together. They matter even more as complexity grows.
We kept discussing in circles until we got together and mapped the project timeline: what happened, and when? We built it from documents, Slack conversations, Jira tickets, and code commits:
When we did, the alignment came almost naturally.
It had taken us a month to plan the project and a month to write the code for it, and we all agreed that was not the right balance. The design leaders agreed we should iterate faster, but we also all saw that the team was not collaborating closely across disciplines. That gap matters much more in the AI era: a few weeks of planning was noise when execution took months, but it’s a major bottleneck when building can take days.
The timeline also put the blame where it belonged: on a broken process (and not finger pointing at people). It was now easier to get agreement since we were all discussing based on a shared reality instead of a lot of competing opinions.
With the problems clear, it was much easier to align on the solutions.
Fix 1: Don’t wait for final designs
The timeline showed we were spending a long time planning before development started, so we agreed that designs didn’t need to be final before engineering work began. Before AI, that would have meant a lot of rework for engineers. Today, that rework is much cheaper. It also gave designers room to finish their work in the time they needed, without blocking engineers.
Fix 2: Kick off together
The chart also made it obvious that the team was working sequentially: product defines the requirements, then design creates the visuals, then engineers build them. None of us wanted to work that way. So we changed the kickoff: the product manager, design lead and engineering lead now finalize the requirements document together, forcing the cross-functional collaboration to start from the beginning of each initiative.
Both changes made the next project much smoother, with the team moving faster in planning and in execution.
None of this was a new concept. Iterative product development is what everyone involved was aspiring to in theory, as a ‘best practice’. But this is an example of how the practice can drift far away from the theory as everything is moving faster. People become busy and distracted, and it becomes easy to miss the forest for the trees.
The same idea fixed the design documents problem from earlier.
We defined a stronger rubric for technical documents, built around one goal: an informed discussion and a shared understanding among engineers. Docs are now shorter and higher level, and use architecture diagrams to explain the end-to-end system instead of twenty pages of implementation details. The rubric works for AI-written docs too, and our documents are now far easier to read (and understand!).
Try it on your team #
A huge benefit of AI is that it makes this type of analysis much easier to achieve. Our chart took a few prompts and a few hours of fact checking (it was mostly right). The data is already sitting in the tools your team uses every day.
Pick a project your team recently delivered and build its timeline, from the first time it was discussed until it reached production. Pull in the docs, Slack threads, tickets and commits, ask an LLM to lay out what happened when, then fact-check it with the people involved. If you haven’t done this before, I guarantee you’ll find it interesting!
What I enjoyed reading this week #
- I'm not doing 996 by Elena Verna. The best article on work culture written this year, by the head of growth of Lovable. Every part resonated with my own experience.
- Why Everything Feels Harder Than It Should by Suzan Bond. A great refresh on organizational debt! Closely related to the misalignment problem we discussed here.
- The manager who committed the team overnight by László Szabó. A great real example of how to NOT behave as a manager (loved the memes and blog style!)
Get the next one in your inbox #
One email a week for engineering managers. No spam, unsubscribe anytime.