How I Do Good Work
Job hunting has given me plenty of time to think about what I want in a job. As much as I'm tempted to joke about this and say, "money and plentiful ping-pong tables," taking this exercise seriously seems worthwhile.
I've been reflecting on patterns in team, system, and organizational structure work that I'm productive in, which brings me high satisfaction. These patterns have changed as I've grown in seniority and responsibility, but the fundamental pillars have remained relatively consistent.
Team
This concerns the people I work closest with on a day-to-day basis. Typically, these are a group of engineers who work under a single manager and perform various agile ceremonies together.
Whether the team is small or medium-sized, the size matters less than whether I collaborate closely with them. The cohesion of the team's goal is essential to me. The nature of software teams means this is only sometimes possible, but I'm at my best when it is. Clearly defined responsibilities when implementing technical projects are critical. As I've grown in my career, I've realized I have an obligation if a project manager or engineering manager hasn't delineated it.
- Frequent communication between collaborators, whether structured or not, is essential. This may as well be an adage of any workplace, but it seems worth mentioning.
- Aside from emergencies/outages, strive for predictable work. If some project has been planned for days or weeks in quarterly planning, abandoning that project because of changing headwinds is demoralizing.
System
This concerns the technical work that an engineer would be engaged in regularly.
- A clear understanding of who to talk to regarding a specific blocker. Unfortunately, this often comes with experience at a company, but the less friction there is, the better.
- A clear understanding of services and tools available. I've spent months trudging through CloudWatch logs before discovering logs are collected and indexed in a third-party service.
- Cohesive tooling and "best practices" across projects. This is often aspirational, and many organizations do their best with the available resources. For example, if some projects use Jenkins for CI/CD and some use CircleCI, unifying those reduces the cognitive load for folks trying to contribute.
Organizational
This concerns organizational culture beyond engineering-specific concerns.
- Psychological safety is paramount. All contributions deserve a respectful response. I will never again work somewhere that shrugs away abusive language towards myself or my coworkers.
- Siloed knowledge should be avoided as much as possible. While there are exceptions, as a rule, every engineer should be able to examine code from every codebase at the company. Aside from security or data governance concerns, engineers should have access to runtime configurations and logs for every service. If an employee in finance wants to see the current sales pipeline, they should also be able to do so.
- As a principle, be plainspoken. There should be a culture of directness and honesty from the C-Suite on down. From an individual contributor's standpoint, this is especially important during one-on-ones with management.
Self
What about myself? Presumably, I have some influence over how productive and satisfied I am at a job, right?
- Some degree of autonomy. For instance, if I have some reason to believe that we should use AWS Glue for ETL instead of AWS EMR, I want to be able to have a conversation about that. Even if the answer is no, having an idea heard and considered is vital and is part of a healthy engineering culture.
- A direct manager who takes my concerns seriously and gives frequent, direct feedback from them. This shouldn't really need to be said. I'm at my best and most motivated when I'm doing work for others. Whether that's a customer success manager asking for help with a client's data or an engineer from a different team asking how to modify a data pipeline, that's when I'm most satisfied. There's a line where requests like that interfere with scheduled work, but those requests can also produce more robust systems. Similar to what I mentioned under team, I work best when I'm in frequent communication with other teammates, stakeholders, and others.
What does this all mean?
This should be shorter and narrower. Going through a 14-point list of things I need to be successful with a potential employer could possibly come off as slightly needy. My goal is to nail this down to something more digestible. Regardless, writing helps me think, so it's a start.
Thanks for reading. Love you all.
❤️ Go Nuggets.