Building your foundations
Software engineer work can roughly be split in two buckets: product launches and infrastructure. I’ll put privacy, security under infrastructure – basically anything that’s not directly product related. Infrastructure work can easily go unnoticed unless something goes south – especially if your leadership isn’t technical enough to understand the value of this work.
This is where as a senior engineer you should make sure your leadership understands the value of your work. This isn’t just about communication but also education – e.g. if your leadership doesn’t grasp how important some work is, it’s on you to explain it in a way that they can understand and prioritize appropriately.
A few tips/lessons I learn across my career working on privacy and other infrastructure efforts – most of them revolve around building your foundation ahead of time:
- Write about important problems even if you know they won’t be staffed. This serves multiple purposes:
- In case of an outage, people understand that the incident isn’t because you (or your team) didn’t know about the risk but because it wasn’t prioritized or appropriately staffed. So this basically prevent people from blaming you
- In case the work is prioritized, you probably get first dib on executing it, getting headcounts or being given resources
- Don’t get overly attached to issues – as much as I genuinely care about privacy, I’m also aware that my proposals may not be staffed right away and that’s OK. If your proposals matter, they will eventually be prioritized – just wait for the planets to line up. There should be enough things for you to do in the meantime
- Don’t miss your opportunities – like mentioned above, if one of your proposals would have avoided an outage, don’t just move on after the outage happens. Make noise to make sure your proposal moves forward
- Build trust with your leadership – the premise is to execute and solve every problem you touch but more importantly, make sure people know you are a thoughtful engineer with balanced opinions. For example, as much as my focus is on privacy, I won’t discount engineer productivity, stability or other concerns. I strive to reach whatever conclusions I think my leadership will end up (because I have the chance to work under a good leadership, so they will reach the conclusions they should)
What interesting tip worked for you to schedule non product work?