After CompSci

It often surprises people entering the field that you are not paid to simply knock out code. Yes, you will produce software as part of your job, but the software itself is not why your work is valuable. Your work is valuable and earns you a paycheck because you are using your skills to help solve an underlying problem that users are willing to pay for.

Understanding business context

When working at a company, you should understand the business context at a high level. This understanding should be for the company as a whole. You should then hold a deeper understanding of the business value your team and team’s products bring. If you are entering a new job, try to figure out what they have launched in the past year, what current project you will be working on, and what is on the roadmap to be launched in the next 6 to 12 months. This will give you a good view of the business, and where you can then see where you can plug in and help.

How to gain business context

Ideally, you should try to understand some of the business context before you join the company. This is only sometimes the case though. When you need to gain context, you should rely on team members who may have been there longer than you. Talk with the Product Manager or Owner(s) of the product. See how they view the world in regard to your product and what they see as the current problems your team is solving. Also, talk with some of your go to market or sales folks who specialize in your product if you have access to them. Most of these people will take calls with you, especially if you are new to a company or role. Start listing their pain points and what they are trying to do. These can be helpful projects to solve later, but make sure they are significant pain points or easy to solve.

Take notes of each of these perspectives from each of these different groups: engineering, product, and sales. Take each view with a grain of salt, as each has a different perspective on the problem, and some people tend to have tunnel vision about their particular craft. From these notes, try to get a better picture of where the product is now, what its impact is on the company, and what can be added or made better. Being able to take a look from a perspective that is outside of just your own discipline will help you more as you grow in your career.

Identifying impactful work

Now that we have the above business context, we can see if we are applying our skills and tools to do impactful work. This will become even more important as you rise through the career ladder. Figure out what your team is working on or will work on next that can help improve the product in a way that will benefit the business. This can include building out new features, improving flakey CI/CD pipelines, or stabilizing infrastructure to prevent outages. Remember, not all impactful work is feature work. Sometimes the enablement work can do just as much good if you help unblock or make the engineering organization more effective, think a rising tide lifts all boats perspective.

Getting impactful work done

Now that you have identified a piece of impactful work, it’s time to get buy in and get it done. You will need to see how your company plans out work. This is sometimes more formalized, but there is generally less process at smaller/earlier stage companies. Team up with your Engineering and Product managers and propose the impactful work. Generally, the best way to do this is to write a short doc or product proposal outlining the business need, why it should be done now, the value it will bring, and a small overview of how it might be implemented. Once this is in place, you can work to get buy in on the piece of work. Once you have the buy in then, you need to plan what will need to be done for the piece of work to be completed and then execute the work. Ensure that the scope of work does not increase as much as possible during this period. If you can somehow decrease the scope during the implementation phase, that would be even better.

Once the work has been done, make sure that you circulate it to the broader organization. This might seem like a brag, but ensuring that completed work is seen is helpful. Showing off a new product highlights new capabilities at the company and can lead to other teams having ideas for other work. Doing something like a project retrospective writeup of any new tech and learnings can also help the whole organization grow.

If you have any questions head over to the After CompSci Discord server. For those looking to learn some more real world engineering skills to help get that first job take a look at the After CompSci course.