How to demand from a developer according to Elon-Roig

At Squadmakers, we often mentor clients who struggle with managing their development teams, leading to demoralized teams and clients unsure about project timelines. To address this, we’ve outlined simple rules inspired by Elon Musk.

Not every programmer is a developer.

As Murphy’s Law states, “What starts badly ends worse.” Therefore, carefully select team members, and if you’re unsure, let an expert choose them. Squadmakers recommends developers who embody Elon Musk’s belief: “I think it’s possible for ordinary people to choose to be extraordinary.” Being extraordinary means loving your profession and taking pride in writing excellent, though always improvable, code. This ideal combines technical excellence with humility and a passion for learning. According to Elon, “Most people can learn a lot more than they think. They just don’t try.” A good developer is among those who at least try.

A good developer isn’t just technically skilled; they possess principles and values often taught at home, intrinsic to the person. This is vital for forming an Agile Squad. Without shared principles, it’s impossible. Elon notes, “My biggest mistake is probably weighing too much on someone’s talent and not someone’s personality. I think it matters whether someone has a good heart.”

“People work better when they know what the goal is and why.”

To achieve excellent results, provide developers with high-quality documentation. Unfortunately, the opposite is common, evident in artificial intelligence: “Garbage in, garbage out.” Similarly, if a developer lacks clear, concise documentation, they shouldn’t start working.

The first step is defining the goal in detail, considering main use cases, data to be used, and expected actions. A common client mistake is thinking, “I have a developer; I’ll tell them what I want, and they’ll do it.” That’s not how it works.

“We’ll find a way or make one.”

Developers develop; the plan shouldn’t come from them. The plan is a roadmap of iterations, evolving the product from a minimal version to a complete one that maximally satisfies your client. It’s naive to think a developer can produce a perfect product in one go. Everyone should perform the role they’re prepared for. A developer isn’t a manager, researcher, customer experience expert, tester, CTO, or Product Manager; they’re just a developer.

In another famous quote, “Some people don’t like change, but you need to embrace it if the alternative is disaster.” A project starts one way and ends up entirely different, and that’s necessary. Your project evolution model should anticipate changes that render certain requirements obsolete. The biggest disaster is discarding all work and starting over. To prevent this, both client and developer should work within an agile model that minimizes losses in such cases.

“I always have optimism, but I’m realistic.”

Being overly optimistic is another mistake by clients and developers, especially when estimating time. Developers aim to please but often don’t realize the complexity until halfway through. Therefore, development speed shouldn’t be established until after at least three sprints in a controlled, consistent environment.

“Pay attention to negative feedback and solicit it, particularly from friends.”

Elon adds, “People don’t usually do that, but it’s very helpful.” This is especially true in complex work like software development. Working solo is a mistake but sometimes unavoidable. Therefore, if you don’t have a colleague for code review, it’s beneficial to have pairs in squads: frontend and backend. This allows for quality methodologies. Your partner doesn’t have to be your friend but is a teammate you interact with daily, and your work depends on their performance. Dedicate time to improve software quality, pointing out errors or bad practices. If that’s not enough, after trying unsuccessfully, seek help from the ScrumMaster.

“Give, Ask, and finally Demand”

One of our successful entrepreneurs, Juan Roig, owner of Mercadona, managing thousands of employees, is clear about managing people: first, give what’s needed to do the job well; then, ask for a previously agreed-upon result; and finally, demand it if the result isn’t met. This seemingly obvious approach isn’t practiced in most developer or squad requests.

Elon Musk reinforces this: “People work better when they know what the goal is and why. It’s important that people look forward to coming to work in the morning and enjoy working.” His message represents Giving, though he also practices Asking and Demanding, as demonstrated at X or SpaceX.

“The only reason I was able to accomplish things is the great people willing to work with me…”

We can demand professionalism and dedication but not enthusiasm or commitment if we can’t inspire it. Ideally, the entire team is motivated and committed to the project’s goal, the selected methodology, quality controls, and their assigned teammates, but that’s rarely achieved.

Whose fault is it? Not the developer’s; it’s always the project leader’s, the client’s, or the project manager’s. Elon adds, “A company is a group of people organized to create a product or service, and it is only as good as the people and how excited they are about creating. I want to recognize a lot of super-talented people. Without them, I would have achieved very little. I am just the face of the companies.”

How do you manage your team? Are they committed? Do you practice Give, Ask, Demand? Share your experience.