Technical-organizational balance ⚖️

I recently started focusing on technical work after several months of organizational work and it’s been a lot of fun. I explicitly missed a couple things: being directly involved in a project, especially focusing deeply on a problem, and working closely with a small team.

A manager friend half-jokingly described the switch as career-limiting. He also joked we’re not paid to work only on things we enjoy. I can see his point, but there must be a balance. We are paid to do things well, and I think that’s difficult when we don’t enjoy what we’re doing, at least in part.

This recent switch has me thinking of “The Engineer/Manager Pendulum” and the follow-up “Engineering Management: The Pendulum Or The Ladder”. All the quotes below are from these essays.

If management isn’t a promotion, then returning to hands-on work isn’t a demotion, either.

I prefer the term “organizational” to “management” for the non-technical work I do because most people think of the latter as people management. I wasn’t a people manager, but I was focused on project management, spent most of my time in meetings and learned to avoid any technical work in the critical path because I had no uninterrupted time to focus on it.

A tech lead is a manager … but their first priority is achieving the task at hand, not grooming and minding the humans who work on it.

The author provides appropriate advice:

Stop writing code and engineering in the critical path

The author mentions skill erosion after two years, but I experienced something similar after just a few months. Perhaps because I needed to make room in my head for a diversity of projects, I lost the context to go deep on any one of them. My activities were described as “leadership”, but I felt like those more directly involved were actually leading in a technical sense. I can see a need for leadership that stays out of the weeds, eg to avoid the sunk cost fallacy, but my role felt like an awkward middle-ground.

I think of this dichotomy as “technical” vs “organizational”. Both are important, but difficult to do well at the same time.

Management is highly interruptive, and great engineering — where you’re learning things — requires blocking out interruptions. You can’t do these two opposite things at once.

“Maker’s Schedule, Manager’s Schedule” is an essay I think of often on that topic.

Anyway, I think this feeling of fun is positive feedback that it was time for the pendulum to swing from organizational work back to technical work.

… you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love.

I find the phrase “career growth” often refers to increased prestige, rather than fulfillment.

Try to resist the default narratives about promotions and titles and roles, they have nothing to do with what satisfies your soul.

Batch interviewing

Problem

Interviewing can be expensive for a number of reasons.

For interviewees:

  • Traditional hiring pipelines are at risk of institutional bias, which decreases efficiency when sourcing candidates from diverse backgrounds.
  • Accumulating experience interviewing, a key factor for success, is hard when each company has a different process.

For interviewers:

For recruiters:

  • Scheduling several people at arbitrary times is also costly (unless interviews have top priority, in which case this cost is pushed onto the interviewer).
  • Motivating everyone on an interview panel to submit feedback quickly is hard, which delays hiring decisions.

(Thx, Megha, for feedback regarding problem/solution presentation!)

Solution

Schedule interviews in blocks, eg 5 back-to-back interviews in a day.

Perform a quick evaluation after each interview, eg 45 minutes of interview, 10 minutes of eval, 5 minutes to transition.

Huddle at the end of the day, ask each interviewer to vote, stack rank candidates, and make hiring decisions.

Benefits

Enable interviewees to efficiently gain experience, and administrators and recruiters to efficiently schedule, by adding interview blocks to a standard process.

Eliminate a source of institutional bias in the hiring pipeline by moving interviews to the candidate.

Amortize warm-up cost and increase evaluation accuracy by asking the same question repeatedly.

Discussion

Batch interviewing, aka on-campus interviewing, is common at some schools, notably Waterloo, which in my experience consistently produces high-performing candidates. (Students also gain an uncommon amount of practical experience through their co-op program.)

Uber runs a day of batch interviews at CSUMB in the spring for summer internships.

My experience with batch interviewing came from a two-day interview batch in Japan.

All these examples involve travel, which may have an impact on the value, ie would batch interviews provide the same cost/benefit when used at a business’ location?

One of the primary concerns I’ve heard expressed is the cost of finding a time that works for candidates, ie traditional scheduling seems optimized for meeting candidates when they’re ready. I’m curious to experiment with publishing a interview block, eg we hire on Fridays, to test this.

Ashwin Raghav shared his experience (thx!):

  • I have participated (as an interviewer and as an interviewee) in batch interviews in India. Very common practice in engineering schools.
  • I did not go to an elite school, which meant that everyone wanted to participate in any company’s recruitment drive.
  • This was often tiring for the interviewers because of the sheer number of interviews and for the interviewees because giving them accurate time slots to take interviews was not easy – meaning they waited for their turn.
  • A lot of the candidates are friends among themselves. They share their interview experience once they exit the interview. This forced us to keep changing questions as interviewers to keep up the difficulty level.
  • I always remember these being very intense emotional experiences compared to industry hire interviews because of the scale of participation. It helped if interviewers were “nice” / “not assholes”
  • Always helps to have a college alumni in the team. I would have never known about sharing interview questions if I did not go back to interview as an alumni.