Software engineering isn’t easy. After the first couple of years in the industry, you get the hang of writing “professional” code, using best-practice patterns and architectures, and researching new tools that can help.

Eventually, you get diminishing returns for learning new architectures and paradigms (but please do continue to learn them!). At that stage, your growth and value as an engineer will happen mostly from “moving the needle” on projects.

In other words: holistically understanding the “what” and “why” of your projects in order to make them successful (or learn from their failure, which might happen).

Once you deeply understand why your project is important, you can bring your own perspective to the table on how it can be completed in the event that your team hits roadblocks.

Often, this understanding takes the form of being empathetic with your users. Your users and customers have a pain point, and your software should help them alleviate that pain.

Basically, listening to users makes you a better engineer.

There’s a reason there's book after book espousing the need to listen to your users, customers, and the market you’re going after. It’s what the YCombinator’s most popular and titular lessons and lectures focus on.

It’s what causes companies to be an overnight success, and what causes many others (who ignore it) to ultimately fail. Entire business units are devoted to listening to customers and helping them find success (Customer Success Managers).

But how can you gain this experience? How can you become close to customers? How can you grow to understand and internalize their pain points such that you can truly empathize with their problems?

You might work at a company that has multiple layers of employees that are closer to customers than you, and you may have a hard time directly reaching them. Typically, roles like support, UX researchers, product managers, and customer success managers are all closer to the customer than you are.

There might not be a way to break through those layers to have direct communication with them, which is necessary to build empathy with them.

I propose instead: having your company’s employees be your customers.

Taking a customer-centric approach to engineering

On your next lunch break, make friends with people from another department. I suggest trying customer success. Listen to the problems that they have.

I point out customer success because they have skills and practice listening to customers that you can leverage. Specifically, they:

• Have continuous, tight feedback loops with customers
• Build specific solutions by focusing on the problems the customers face
• Monitor and react to changes in customer engagement to proactively prevent churn

Do they have back-to-back meetings with no way to cut out repeated, mundane tasks? You might hear them talk about needing to check Zendesk, Salesforce, and previous email threads with a customer before they can properly support or onboard them.

This should pique your interest. They have a task that:

• Must be performed every time
• Involves gathering information from the same places, and
• Takes time away from them completing their important work
  

Sounds exactly like a problem that software engineering should be able to solve! Try your hand at writing a script that does what they need.

Keep in mind that other opportunities might not be exactly like this - they could be doing things like copy/pasting information from one website to another, but ultimately something that can be done with automation.

If you write a script that does what your new friend wastes time doing, and can give them a way to easily make that script run, you’ll be their hero. More than that, they’ll likely share your work with their colleagues. You’ll start getting “thank yous” and will (hopefully) hear something like “it would be great if it could also…”.

You did it! You solved somebody’s problem and got a feature request.

This is what tech entrepreneurs dream of: you found a problem, solved it with code, and now have engaged users. Next step: make it even better.

Prioritizing your new product

Instead of creating a whole new product and trying to bring it to market, you did a miniature version of that inside of your company. There are a lot of things you don’t need to worry about by being an internal entrepreneur, such as: securing funding, finding beta users, and keeping user feedback channels open.

However, there is something you do need to worry about that other entrepreneurs don’t: making time to work on your product.

You’re a software engineer. You have planning meetings, retrospectives, and you need to make sure your day job is still being done.

If you’re not somebody that wants to take their work home and do extra hours on nights and weekends (I’d recommend avoiding this), you’ll need to make the case that you should prioritize supporting other teams in the company by continuing to work on your product.

This is where you’ll need to convince your manager that this is worth prioritizing. You should talk to the people who use your work and ask them what they think of it (testimonials from users).

Ask them how much time it saves them. Multiply that by the amount of people using it. Then multiply that by a ballpark number of their hourly pay. That’s the return on investment (ROI) of working on this.

After that, use your imagination: where can you take this project with 3 months of full time work? Can you make it into an internal web app? Can you make it useful for more people in more departments? Last, pick an end goal for 3 months of work: what will it look like if you’re successful? What does failure look like? Do you have more internal users? The same number? Fewer?

Congratulations! Once you answer all these questions, you can format the answers in a slide deck. You made your first investor presentation.

To summarize, you have slides for:

• A need: you identified a problem and validated there is a solution that works for people
• Market opportunity: the number of people you could help in the company
• ROI: you’re saving the company $X per hour of people who use this product
• Ask: 3 months of your undivided attention
• Vision: In 3 months, this is what will change if you’re successful
• (bonus) failure criteria: if you’re not successful, here’s how we know

This might seem too formal for your company. If you don’t need to pitch how to spend your time to your manager, power to you! If you do, the format above will help drive that conversation.

At the very least, you can say something like “If we focus on reducing $X wasted dollars per week, which is less than my goal, we can afford another full time software engineer.”

They’ll love hearing that. Managers always want more software engineers.

Want more time to focus on the stuff that really matters to you? Try Classify. It’ll help you stress less.