Finite Time as a SWE

Dated Oct 20, 2024; last modified on Sat, 16 Nov 2024

Deliberately choose what to work on. Part of that is getting priority communicated by interested shareholders.

Empower less-experienced engineers so that they’re confident tackling different problems instead of me having to pick up said problems.

Improve my investigation and writing skills so that I can give folks enough context to execute on their own. Mostly communicating intent and trusting others to figure out the nitty gritty details.

Origins of Projects

  • You’re invited to join. Organization already cares about this. That someone thinks you’re a good fit might mean it’s similar to work you’ve done before and not an opportunity for growth.
  • You ask to join. Even if it’s obvious that you’re the best fit, don’t wait for someone else to notice.
  • You have an idea. You need to convince others to care. Might get mired in politics, but once it’s underway, you have lots of control and can have huge impact.
  • The fire alarm goes off. Goals are usually very clear and there’s a bias to action. However, there are fewer opportunities for growth.
  • You’re invited to join a grassroots effort. Working groups can be effective if there’s organizational buy-in, a clear time commitment, exit criteria, and a process for making decisions.
  • Someone needs to… Volunteering can build credibility and goodwill, but watch out for doing too much of it at the expense of other results people are expecting from you.
  • You’re just meddling. Make sure you’re not getting involved long enough to cause chaos and then disengaging without sticking around to experience the consequences of your changes.

Don’t be one of those people that always drop their own work to help with even a minor outage, or respond to IMs within seconds, no matter what else you were doing. Other people have limited access to your resource dashboard.

I feel like I built a lot of credibility helping others in Teams threads and such, but at the expense of my own work. Need to minimize this, e.g., turning off Teams until deliberate blocks, e.g., 11:30am (sometime before lunch) and 3:30pm (once I’m mostly done with my core objectives).

Time

Time is your most finite resource. Everything that you commit to has an opportunity cost. Put specific, deliberate non-meeting items on your calendar, e.g., “review proposal for authentication system”.

An automated mechanism for analyzing your days seems apt. For companies with M365, Microsoft Viva Insights seems like it’d fit the bill. Will review my Viva Insights weekly, and see if there are improvements that I can make to my workflow.

Don’t allocate 100% of your time lest something unexpected happens and you either need to drop something or run beyond capacity. You won’t succeed unless you can defend your time. The number of demands on it will increase and the number of available hours will stay the same, so be deliberate about what you prioritize.

Also need to defend my time for future me. My backlog currently has +150 items, of which a sizable portion of them come from improvements that I think could be worth it. Pruning that list every month or so should help. The moment I reach for a separate list because my Azure Dev Ops list is intractable is a sign that I’m over-extending myself.

An alternate phrasing is lead time: time elapsed between the identification of a requirement and its fulfillment. An ever-increasing backlog is a symptom of saying “Not Now” instead of “No”. Maybe asking myself if something’s worth waiting 3 months for, and if so, allowing it in my backlog. I don’t want a graveyard of unfulfilled promises.

Questions to Ask Yourself About Projects

Energy

The energy to stay focused on a piece of work and do something useful with it. How many things are you currently doing? Does this kind of work give or take energy? Is this fight worth it; what else could you be doing with that extra energy?

Quality of Life

We spend a lot of our lives at work, and you should want to feel good about it. Every project needs core technical skills, project management, product management, and people management. Do you want it intense and high stakes? Do you prefer to work alone or collaborate? Do you like being on call? Are you open to travel? Does it provide opportunities to share learnings, e.g., conference talks? How do you feel about the project’s goals?

Credibility

Do others think you’re capable of doing whatever you’re trying to do? You can build credibility by solving hard problems, being visibly competent, consistently showing good technical judgement (no absolutism), taking on a chaotic situation and making it easier for everyone else to understand. Does the project use your technical skills (implement something concrete or make it tractable for others)? Does the project show your leadership skills (taking responsibility for outcomes; communicating frequently and well; giving the right level of detail around what’s going well and what’s not and why)?

Social Capital

Do others want to help you do whatever you’re trying to do? In general, work that matters to the people in your reporting chain is work that builds social capital. Spend your accumulated social capital wisely. With a high enough star, you can often get away with chartering an initiative that others don’t really believe in, just on the strength of their faith in you. Managing up includes understanding your boss’s priorities, giving them information they need, and solving problems that are in their way.

Skills

Any technical skill set slowly becomes less relevant. Increasing skills in your career comes from three main ways:

  • Deliberately setting out to learn something, e.g., hacking on a toy project.
  • Working closely with someone who is really skilled.
  • Learning by doing; taking on projects that need that skill.

What stories do you want to be able to tell on your future resume (e.g., debugging something difficult; driving a major culture change; turning junior engineers into senior engineers)?

What If It’s the Wrong Project?

Do It Anyway?

What are the exit criteria and when do you expect to get there? If there’s no end in sight, talk with your manager; hiring staff engineers is difficult and expensive and most good managers will help you find something more compatible.

Compensate for the Project

Can you add a side project that gives you the enjoyment, skills growth, or credibility that you’re not getting from your main project?

This suggestion seems prone to over-extending oneself. Assuming that the project is a full-time commitment, then a side project on top of it can cause burnout.

Let Others Lead

There’s guaranteed to be work that shows up on your plate on which you can “get an A” every single time, and if you give it to someone else, they’re probably going to be a B. However, a B is a pretty good outcome for their first time doing it. If you’re the most senior engineer, make sure you’re not taking all of the opportunities to be publicly competent.

Resize the Project

Join for the first month to evaluate the direction for feasibility. Recommend someone else. Care about it for the duration of a meeting and offer advice on how you’d proceed?

Just Don’t Do It

Either you’ll get to it later, or someone else will, or it will stay broken and that just gets to be OK.

Does this imply some seniority to be able to make that call with authority. I’d expect junior devs to incline towards implementing rather than declining. As a tech lead, do you avail room for this option for junior members?

References

  1. The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change. Chapter 4: Finite Time. Tanya Reilly. 2022. ISBN: 9781098118730 .
  2. Large Product Backlogs: A Scrum Anti Pattern | Scrum Alliance | Transforming the World of Work. resources.scrumalliance.org . www.agilealliance.org . Accessed Oct 26, 2024.