On onboarding and time management

We recently onboarded two new devs on the team (remotely!) and they’ve been fantastic. I was super pleased with how fast they picked up issues and started taking on tasks that would have otherwise bogged me down in minutiae. It was also a great feeling to see all our preparation pay off.

As a result of this in a place where I’m spending a lot more time doing philosophical work, either being asked how to solve a problem, or given a solution that causes more issues than it fixes. In these cases I can either propose a workable solution, or ignore the issues and do the bare minimum to get the change out the door. The third and more depressing state is when we literally can’t fix the problem because it is stuck in a tech debt dependency hell: something that is impossible to fix now without taking on the larger structural problems which we don’t have time to fix yet either. Business loves quick fixes, developers love abstracting problems away, but everybody hates being deadlocked by tech debt.

At the moment I’m struggling because I’m spending a lot of my time supporting the team and keeping a lid on our issues, while at the same time trying to manage a regular ticket workload. Obviously the latter is suffering, and I’m feeling anxious about that, even though I know these are unreasonable expectations to have for myself.

I suppose it takes some getting used to, and I’m sure as the new starters get up to speed it’ll be less of an issue. But it’s made me realise that my “architectural” role at a previous company really left me with some anxiety about the knowledge component in knowledge work, after 90% of our time was spent in planning and 0% of the work ever made it to production.

I should really write a post mortem on that.

Leave a Reply

Your email address will not be published. Required fields are marked *