Everyone is a Builder

The dynamics at organizations that build their own software are changing. As someone coaching traditionally non-technical professionals to get more value out of AI in their work, I have a front-row seat.

The conversations are all quite similar.

Our processes are such a headache. The tools we have just don’t work for the job.

I’ve written a proposal for what a better version would look like, but I can’t get the resources to execute on it.

I can’t get funding.

I can’t get my work on the roadmap.

I can’t get procurement to approve the purchase of what I need.

In the past, these non-technical contributors received a rough deal. They were beholden to technical teams and capital allocators to solve their problems. In most cases, the tradeoff they were given was

1. deal with the subpar situation, figure out a way to make it work
2. find another role

However, there has been one part of software-building organizations where this has historically been less common. Where ICs hold much more influence and control their own destiny. That has been within engineering.

Engineering wasn’t always a panacea, but the reason engineering controlled more of its own destiny was that capable engineering teams brought one thing to the negotiating table that non-technical ICs did not: they could build solutions to their own problems themselves.

As a non-technical IC, take note: the ability to solve your own problems changes the standing you have at the negotiating table in an organization.

The old world

Say you were part of a customer support team and your team continued to be flooded by irrelevant support requests. These waste your and your team’s time because you still have to read the request first to figure out if you need to handle it. You’re forced to wade through these irrelevant tickets to find the tickets you actually need to work. You now work 25-50% longer to accomplish the same amount of work.

In the old world, you’d open a ticket or engage a product manager and try to get engineering to prioritize a solution to this problem. Maybe you yourself would poke around your ticketing system to see if you could implement some stopgaps and hacks to deal with some of the load. You’d do your best, but in the end, a real solution could only come from a fix in the system itself.

This world has changed.

What made engineering different

In the before days, there were always too many problems and not enough people to solve them. But if you happened to find a team that wasn’t pushed to the limit, it was almost always an engineering team.

When faced with the challenges of the software-building organization, the best engineering teams could take ownership of solving their own problems. Even if they didn’t get funding, organizational buy-in, or dedicated time, they could still make calculated and strategic decisions about what software to build to solve the problems they were facing, often while still delivering on most of the goals asked of their team. This varied by company culture a bit, but a great engineering team could do this in most organizations.

If an engineering team was being overwhelmed by oncall, they could make investments in improving their software systems so that they were more reliable and would cause less burden to the team. If their deployment process was flaky and error-prone, they could dedicate time and energy to fixing it. It’s the simple math of spending a few days now to eliminate many more days’ worth of irritation. The best engineering teams wouldn’t even ask for “dedicated time” to do this. Their product stakeholders might not even be aware the work was taking place.

Leverage

Because engineering teams can often solve their own problems, they’re able to negotiate for what is important to them differently with the rest of the organization. Stated simply: it was harder to bully an engineering team or org into doing what you wanted because they could always opt out of the conversation and solve their problem themselves. This dynamic was the case even between engineering teams. If teams disagreed strongly enough on a decision and no mediation took place, they would go in different directions and serve themselves, for better or worse.

This stood in stark contrast to non-technical roles that could identify and highlight challenges, but had far less ability to ensure the issues could actually get resolved.

Where we stand now

Traditionally non-technical professionals can now solve their day-to-day problems using AI tools. I do not mean prompting AI to go do the job you were doing before. What I mean is doing what you were doing already in advocating for engineering teams to solve your problems. Identifying and describing the issue, scoping the impact and who is affected and how, and describing what a solution would look like. This work — the definition of what good looks like — is what you provide to an AI agent. From here, the agent can empower you to solve your problems within your constraints.

Take that support team, working 25-50% more due to poorly routed tickets. With an understanding of the problem, instead of writing a detailed ticket for the engineering backlog, never to be worked, they can now pass that same problem statement to an agent and get a PR to resolve the issue, often in a day or less.

Your newly acquired leverage

In the same way software engineering teams had an escape hatch to solve their own problems, you now have this too. And you don’t just have the ability to solve your own problems. You also now have negotiating leverage in the organization to get what you want and need to do your job.

You are now a builder of the systems that allow the company to get work done. Build the tools you need. Advocate for what you need. If your peers decide that they don’t want to compromise or help, opt out and build for yourself and your team. Prior to AI agents, it wasn’t credible that a non-technical team would build fully operable software to solve their problems. Now that it is, engineering and product teams are on notice. Serve the needs of the organization or be bypassed entirely.

The coming shift

It’s not going to be pretty, and product and engineering orgs are going to fight tooth and nail over what was previously their area of exclusive ownership. But you no longer need to accept being treated like a second-class citizen after product and engineering. You can build for yourself and solve your own problems.