Episode 121: Working Remotely Without Hating It and Managing Rotating Engineers

Soft Skills Engineering

• Episode: Episode 121: Working Remotely Without Hating It and Managing Rotating Engineers
• Website: Soft Skills Engineering
• Feed URL: https://feeds.feedburner.com/SoftSkillsEngineering
• Duration: 00:32:28
• Published: 2018-08-27 21:00

In this episode, Dave and Jamison answer these questions:

1. I used to work totally remote, but found myself absolutely hating it. The lack of office culture and human interaction.

   The problem is that in my area there are few local development jobs that match my skill set. I work in a large but heathcare heavy town, and their tech does not blend with my skill set.

   All to say. When it comes time to find my next job I’ll probably be looking for remote again. How can I come to love remote jobs, or at least survive?

   Maybe my previous companies remote culture was terrible. Is there any advice you can give when evaluating a remote culture at a company?

2. Love the show! I had a question on how to effectively manage of team of engineers who have only partial allocation to my project. I am a project & technical lead for a team of ““8 FTE””, which is composed of a rotating cast of engineers who are allocated to my project in small percentages (most commonly between 30-80% of their time).

   This has a lot of challenges which you can imagine, but the one I am most interested in your thoughts on is the struggle with other projects about ““whose deliverable for a given engineer has priority””.

   As an example an engineer with 50% time on my project and 50% on another project will give me feedback that his immediate tasking between projects is unclear, he knows he has to do both workloads but feels they are uneven, or he is under more pressure from one project than the other. My company stack ranks during performance reviews and competition between leaders of matrix organizations (such as myself) in particular is fierce, so discussions between projects on how to effectively tackle this problem does not yield constructive agreements (in my experience). I’m at times guilty of trying to ““squeeze”” more than my designated allocation out of engineers to deliver on agreements for timing, scope, etc.

   Any thoughts are appreciated!