This week’s newsletter is sponsored by Blitzy.

Blitzy is the first autonomous software development platform with infinite code context, enabling Fortune 500 companies to ship 5x faster from Figma design to production code.

It’s engineered specifically for enterprise-scale codebases due to its deep understanding of your codebase and design standards. This can clear years of tech debt, execute large-scale refactors, or deliver new features quickly.

Some of Blitzy’s core features:

• Self-improving knowledge graph: Maps millions of lines of code and their dependencies to create a live understanding of your codebase.

• Figma integration: Turns Figma designs into responsive, pixel-perfect frontend code that connects to your backend.3

• Agent orchestration: 3,000+ specialized agents plan, build, and validate production-ready code.

Result: 80% of the work delivered autonomously, 5× faster. If you are working on an enterprise-scale codebase, I’d definitely recommend checking them out!

Sign up for free and start building

Thanks to Blitzy for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

The way we build software has been changing now for quite a while, and it’s really important that we acknowledge this shift.

I remember 2 years ago, when I was a full-time CTO, we were talking with the team about whether we should be using GitHub Copilot or not, and if it even helps.

Today, that conversation is totally different, and AI-assisted engineering is the standard in how we build software these days.

In this article, I’ll be sharing the changes happening to the way engineers work, and the most important skills to focus on. The insights are based on my conversations with many engineers and engineering leaders across different companies, both in the EU and the US.

Let’s start!

The engineering process has been quite straightforward for a while

When I started my career as an engineer 13 years ago, we had quite a similar software engineering process to the one we had 2 years ago when I was a full-time CTO.

Here is the process explained in a few simple steps (you are most likely fully familiar with it):

1. Someone creates a (Jira) ticket

That would be either the Tech Lead, PM, Manager, or an engineer themselves.

2. Someone works on the ticket

Engineers pick the ticket based on priority and implement the required changes/additions based on requirements.

3. Code review

Adding at least 2 engineers to review the code, with 1 approval needed in order to unlock the merge button + passing the (unit, integration, and e2e tests).

4. Merge the change

Either the PR author or assignee merges the change and pushes the change to the main or any other relevant branch.

5. Deployment

Deployment was either on specific times, some teams had it daily, some weekly, and some teams did continuous releases based on every change.

Over time, there were certainly optimizations to the process, but fundamentally this is how the process looked likes for a while.

Such process made it easy to just focus on finishing tasks

What felt comfortable in the process is how easy and clear it was to just focus on “doing your job”, which was picking a certain ticket, doing it, and then you got the satisfaction of completing something.

A lot of the hard work has been done before picking that ticket, thinking about design patterns, architecture, creating good practices, etc., by someone else before you.

Much of the work based on these tasks was: build something based on the pattern that was already created.

Additionally, many times someone else also asked all the business-related questions to validate whether that specific thing was the right thing to build.

Not every task was like that, but a lot of the tasks definitely had such a sentiment.

Such work can be very comfortable, as you just needed to focus on the “how”, because you know exactly what needs to be done, and you just need to do it.

And you aren’t taking any risks, as normally the tech lead or a PM took the accountability for whether that work was impactful or not.

This varied based on the size of the companies and the culture

The structured process, with a low amount of ownership, was quite common (still is, to some extent) in bigger companies with a lot more older systems that didn’t have such a huge pressure on delivering.

Smaller-to-mid-size companies always had a lot more ownership and responsibility attached to specific individuals, because when there are fewer people, you are automatically expected to wear more than 1 hat.

And of course, Big Tech has always been known to have a certain pressure and competitiveness among people working there, so there’s always been a structured process, but it had a forcing factor for people to be overachievers and take more ownership and responsibility.

What changes today?

This image is a really good representation of what has changed:

As you can see from the image, there’s a lot more (mobile) apps being built and released, but the apps with significant usage have actually dropped.

This means that pure building is worth less, but WHAT to build and WHY to build it so that people will care is worth so much more.

There’s a huge need for companies and products to stand out from competitors in a certain way, and just pure features and tech is just not going to cut it anymore. That’s already expected.

With this in mind, the work of engineers is shifting a level upwards, as pure building based on requirements is worth less, but great decision-making is worth a lot more.

The work is shifting a level upwards

I like to say that a lot of the engineering work is becoming engineering leadership. The Software Engineer role is becoming more like a Tech Lead role.

Engineers are writing code less, but generating it more with AI, therefore, reviewing code a lot more, which makes decision-making a bottleneck:

• choosing the right problem,

• making good trade-offs,

• collaboration + communication,

• validating assumptions,

• deciding what not to build.

All of these are very crucial things to focus on these days as an engineer at any level.

Spec-driven development is also becoming really popular these days, so focusing on creating good tech specs and ADRs is becoming more and more important.

And more and more engineers are expected to own projects end-to-end, so good planning and stakeholder communication are more important than ever.

This is how it looks like in practice

It’s also important to keep in mind the distinction between the sizes of companies and the culture, because that matters a lot for what the expectation is of your work as a software engineer.

I’ll go through all 3 different cases:

• Bigger companies (outside of Big Tech)

The shift in such companies is a lot slower, and the work + the process might not be that much different than the one that I’ve mentioned above at this time.

A lot of such companies haven’t even adopted AI properly and are still evaluating whether the security is a big risk if they use AI. However, there certainly are companies who have made the shift.

With time, in my opinion, all of the companies will adapt and adjust the way they work as well. So, if not already, I don’t see the future where engineering work will just look like: “Taking the next well-defined task and finishing it, without taking ownership and accountability of the project”.

If you’ve been doing work based on well-defined tasks, now, you need to start defining tasks yourself, that’s going to be more and more expected.

• Small-to-mid-size companies

If you’ve been wearing 2-3 hats as an engineer in such a company, being a backend engineer, frontend, and QA, it’s more and more common to be expected to wear 3-5 different hats, including product, FDE, and/or customer support.

A good example is the company PortKey, which has 24 engineers and 0 product managers, where every engineer is expected to wear many different hats.

And at the same time owning projects end-to-end. Really good examples are both OpenAI, and Anthropic, where most of the engineers are already owning or are expected to own a certain project end-to-end if needed.

• Big Tech companies

As mentioned above, there’s always been pressure to deliver in such companies, but now the pressure has just increased a level. We see a lot of layoffs happening, and people are often expected to deliver miracles these days, especially using AI.

Being able to manage expectations well, building a narrative around your work, and ensuring that your work is visible are key things to do well if you are a Big Tech engineer these days.

My advice for all the engineers is to really focus on building up your people skills

Many people advise engineers to focus on getting as good as possible with AI, getting to know all the latest tools and what’s possible to do with them.

While that’s important, I fully believe that the biggest upside in skills you can have is to focus on developing your leadership skills, communication, empathy, and overall emotional inteligence.

The reason is that you are most probably already good at tech skills, as that’s what you’ve been doing for quite a while now. But in order to make the shift to being more like a tech lead, you need to work on your people skills.

And that’s going to make you a lot more valuable, being able to lead projects end-to-end, while managing expectations correctly and ensuring that your work is impactful.

Last words

Let’s end this article with the following:

Technical skills are very important, but good judgment, being able to communicate well, and being a great leader are becoming THE skills.

My recommendation: really embrace the shift. And the sooner you’ll embrace it, the more valuable you'll become.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.