Our field has recently been involved in an uproar of AI-powered tools that promise to accelerate—or even replace—the parts of our jobs that we’ve traditionally have been trained on. Traditional training for software engineers puts an emphasis on syntax knowledge, data structures, and algorithms. While this knowledge is still important, the future lies elsewhere.

Regardless of the clear deficiency of the methods and materials employed to grow professions capable of writing software, tackling this educational problem won’t be the main point of this article. Instead, I will explore the benefits of adopting a different mindset.

A mindset shift

The practices and skills involved in building useful software revolve around a single sentiment: Think about the user experience.

While it is a simple phrase, the implications it brings into the entire software development lifecycle are vast. To better explore these ramifications, I will talk about the techniques and practices in three contexts: before, during, and after. Keep in mind that this sentiment applies to every single person involved.

Before

In most environments where code is written there is a significant amount of effort exercised even before a single key is pressed. The main goal of this preliminary work is to identify what should be worked on next, and (if possible) eliminate wastage and uncertainty. In a more traditional environment, these aspects would fall under your Project Managers, Product Owners, Business Analysts, etc.

The traditional responsibilities of these individuals includes discovering problems, designing solutions, and creating a comprehensive plan with all the tasks that need to be executed for said solution to be delivered. However, since plans rarely work (here is an interesting take on how to make plans better), this approach is inefficient.

To be very clear, I am not advocating for you to go fire all of these people and ask your development team to take care of that workload.

Know your users

Learn how thigns are or will be used

Identify the value of initiatives

Guesstimate or measure the impact of a change

Explore the nuance of value estimation with multiple streams of work.

Prioritize your efforts

Use the impact and value to strategize on which things are the most important. No need to plan them extensively, just capture their relative precedence order

Highlight the need to think beyond a singular feature

Propose managing own backlog and roadmap as a way to clearly communicate value, as well as how that allows teams to propose solutions to multiple problems at once.

Highligh how this can help make informed decisions regarding tech-debt.

Communicate with your team

Clearly communicate this information. The idea is to give a clear directive so others are empowered to make choices that deliver on the most important things and deprioritize less important stuff.

This also helps teams avoid multitasking (the definition of “fuck multipe things at once” and focus on the important parts)

Plan for complex execution

Find safe approaches, validate ideas earlier, minimize end-user impact while maximizing value.

Maybe this really is “risk management”/“think about risks”?

During

Communicate with stakeholders

Constant channels of information are needed to keep everyone involved in the loop.

Not excessive reporting, but transparency is important. This means transparency on roadmaps, metrics, and work done.

This channel is also important because enables everyone to share insights and refine the value-add of initiatives. Otherwise, this is pretty much waterfall.

Clarify how having a clearer picture of the value-add for each change can help on moments of crisis, when things change, or when new things need to be tackled.

Leave room for creative solutions

Avoid prescribing solutions too early, leave your smart engineers to find oportunities to solve multiple problems at once or to revolutionize.

Manage your tech debt wisely

Recognize that “quick fix” is a tool to be employed for a reason, but sometimes we need to go back and properly fix stuff to avoid losing velocity (or encurring risk).

Encourage tech excellence

In line with the two previous things… encourage to do the right thing in the first place. Avoid at all cost creating a culture of “fast” before “right”. That will cause problems down the line.

After

Understand you might not really know your user that well…

Let them talk to you and give quick feedback.