In my second in the Staff Engineer Series , I want to write about a skill that I had been practicing unconsciously, but didn’t expect to make it a core part of my job: making my own work. Making my own work started small with research on my own, then progressed to creating an initiative on standardizing our database source control as Liquibase, automating manual processes, and helping define our IaC stack.
What does “making your own work mean?”
“Making your own work” means in a sense, no one is going to lay out items A, B, and C in a sprint for you to work on. It will either become “we need to work on initiative A for the next 6 months” or worse yet, there will be an elephant of a project in the room that no one wants to tackle. In the first scenario you’re expected to deep dive and gain context to what the underlying problem is and formulate a plan to solve it. Then you begin writing your own tickets and working towards the goal. These types of problems aren’t going to be confined to a sprint or two, they usually take months to complete. The other scenario I mentioned is tackling a piece of tech debt that no one wants to fight or modernizing an orphaned app. No one is going to break down the work for you and if its up to you to identify it. If you’ve made it up the chain to staff level, you’ve already learned to pick up on things that range from “not quite right” to “ultra janky”. These are the issues you identify and the type of work you make for yourself. Once you identify it, you work with your leader ship team (your manager or other staff+ engineers) to gauge the impact of the work. From there you either begin working on it or backlog the problem with enough documentation to pick it up later.
How do I decide what work to take on?
Once you have a healthy backlog of problems and have identified the impact, it will mostly be up to you to decide what to take on. You will usually focus on the high impact work, but what is “high impact” ? High impact work means that what you complete becomes a force multiplier for other developers at your company. This can be things like defining new standards, such as Liquibase mentioned above, pioneering and defining libraries for new auth mechanisms, or developing a CICD system for company wide adoption. One important thing about high impact work is it can be contextual and time sensitive; i.e. the work’s impact can change based on business needs. For example, some work you identified might be to move to a more scalable database technology. This work may become more impactful if a new contract with an enterprise customer is signed.
A secondary part of deciding what to work on is taking into account the time it will take. You only have so much time to work on things in a day, and staff engineers have many people and things competing for their attention. Determining if something can be tackled now without having other projects suffer is one of the largest decisions about taking on certain work. You have to learn how to gauge not only how much effort your own work will take, but also the work others ask for help with, as well as the general chaos of a day. It’s useful to measure different types of work that occur day to day to get a feel of how much you can handle and track how things are going across the firm.
In conclusion, when you reach staff+ level, don’t expect to be handed a set of fun new problems. You have to be able to identify, organize, and execute on the work yourself with little, if any guidance. You’ll be expected to have know the technical landscape of your company enough to know the pit falls, the sore points, and the opportunities to make things better.