Month: March 2015

(Technical) Recruiting is Broken

Itamar, 1 Comment
“The software developer job interview doesn’t work. Companies should stop relying on them. The savviest teams will outcompete their peers by devising alternative hiring schemes.Years from now, we’ll look back at the 2015 developer interview as an anachronism, akin to hiring an orchestra cellist with a personality test and a quiz about music theory rather than a blind audition.” – The Hiring Post (Thomas Ptacek, Matasano)
“No one ever offered me a book. No one even offered advice, or suggestions on what was interesting in the field or what was not. No one ever said, “Here is how we are going to bring your skills to the next level and ensure you will be quickly productive on our team.” The only answer I ever got was, “We expect every employee to be ready on day one.” What a scary proposition! Even McDonalds doesn’t expect its burger flippers to be ready from day one.” – On Secretly Terrible Engineers (Danny Crichton, TechCrunch)
Let’s face it, recruiting today, and especially technical recruiting is terribly broken.
The two posts above, published recently, suggest that a differentiated recruiting process can be a substantial competitive advantage in competing for top talent. If you still need persuading that there’s a real problem here that needs fixing, they both make a pretty compelling case for that. The latter a bit more hyperbolically than the former.
They propose the following outlined process, leveraging behavior science throughout the process:
  1. (offline) Resume screen by recruiter
  2. 30-45 mins phone screen by director-level or above: [liking, authority]
    • Anodyne questions
    • AMA-style AMA
    • Exhaustive explanation of the selection process and what to expect at each stage
  3. Prep for on-site:
    • Send candidate a study guide and a couple of free books relevant to the work-sample test (see below) [reciprocity]
    • Extend an open-invitation to proceed with the process whenever they are ready [autonomy, commitment]
  4. On-site interview:
    • Work-sample test: NOT a whiteboard exercise or a generic coding exercise. An actual, hands-on, standardized exercise in the environment and the stack that the candidate will be asked to work in, ideally using a crippled version of the actual code base. More details in the first post
    • Cultural fit: by team members + one of a small subset of cultural bellwethers (usually “old guard” folks).
Generally speaking, they make the case for creating an interview process that is much less adversarial and much more collaborative, without compromising the rigor of the technical assessment (if not improving it at the same time).
I’ll leave you with one other good quote:
 
“The reality is, few professions seem so openly hostile to their current members as software engineering. There is always this lingering caution when interviewing a new candidate that somehow this individual has gotten through every interview process and team review without anyone realizing the incompetence before them… We can talk about interview strategies and coding reviews and take-home fake assignments all day, but nothing will improve until we have learned to address our own fear that we are going to hire an idiot.”
Advertisement
(Technical) Recruiting is Broken

Spotify

Itamar, 1 Comment

Henrik Kinberg‘s seminal work at Spotify has made real waves in the community when Scaling Agile at Spotify started making the rounds. More recently, Henrik put out these two videos outlining the key components of Spotify’s engineering culture:

Spotify Engineering Culture – Part 1

Spotify Engineering culture – Part 2

The thing I found most impressing about these videos is the connection between the high level, abstract culture, and the more pragmatic set of business practices that it was broken down to.

As Henrik mentions in a different post, there is no right or wrong answer here. Every cultural decision has a trade-off built into it:

rightwrong

What’s really unique about the Spotify case, is the way they acknowledge and own up to the trade-offs that their culture embodies, and fully align their business processes with it. This tight alignment between culture and process/structure is rare, and in my opinion, one of the key ingredients in what makes Spotify so successful.

Spotify

Leading Without Coding

Itamar1 Comment

Aaron Schildkrout published a lovely piece recently:

Leading Without Coding 

It’s a little long, but completely worth it. It it, he reflects on his experience, as a non-technical co-founder, leading the engineering team at HowAboutWe and what made him an effective leader despite being “non-technical”.

His summarizes his experience through six pieces of advice:

  1. Know the stack
  2. Become an expert facilitator
  3. Run the smartest ship
  4. Master the data
  5. Hire great people and replace yourself
  6. Ready yourself, inside

It’s a wonderful read but I actually think that Aaron’s overall framing is too narrow.  If you’re bought into the thesis that management is a career change, not a promotion, then managing people that are better individual contributors than you is the norm. Therefore, this is a much broader manifesto on how you, as a leader/manager, should be spending your time, focus and energy, regardless of the type of team that you lead and your personal background.

Consequentially, my only qualm with this piece is that “replacing yourself with a more technical leader” should NOT be the end goal.

BONUS: in this piece Aaron also references a 7-piece series about product leadership that he’d previously written starting with Unblocked: A Guide to Making Things People Love.  I’m not going to cover it in depth in this blog because while the principles that start in piece are great, the process implementations themselves vary in quality and broader applicability.

 

 

Leading Without Coding

It’s not a Promotion – It’s a Career Change

Itamar, 2 Comments

Lindsay Holmwood wrote a lovely piece about the common misconception of management being a promotion rather than a career change:

It’s not a promotion – It’s a career change

Lindsay covers two contributing factors for first time managers being woefully unprepared to their roles and managers:

  • Systemic undervaluation of non-technical skills , which is probably most pervasive in Engineering, but almost just as common in other disciplines.
  • The Dunning-Kruger cognitive bias (90% of people think they are “better than average” drivers”)

Which unfortunately tends to have a multiplied impact given the role of a manager.

He also suggests focusing on three key levers for improving your skill as a manager: professional training, mentors and self-education.

A highly recommended read, especially for aspiring managers and managers who often times get frustrated about not being able to do “real work”.

I know this all sounds rather trivial, but in places where management is not proactively positioned as a career change, and a an “individual contributor” promotion path is not well defined, management easily gets perceived as the “only way up”. Which is, as Rand Fishkin suggests, not a good situation to be in:

If Management is the only way up, we’re all F’d

It’s not a Promotion – It’s a Career Change

It’s a Pie, not a Queue!

Itamar2 Comments

On mistaking investment mix decisions for prioritization decisions, and getting out of that mess

  • IT can’t grant account access because they are building self-service capabilities
  • R&D can’t fix bugs/address client requests because they are building new features
  • Ops can’t do technology migrations because they are launching new clients
  • The business doesn’t invest in building tooling for operational efficiency and quality because we need to capture more revenue

What do all of these these trade-offs have in common?

  1. They are not sustainable in the long run – leading to an outcome that is clearly far from the global optimum
  2. They are likely an outcome of falsely identifying an investment mix decision as a prioritization decision

#1 is pretty self-explanatory, so let’s focus on understanding #2.

When we prioritize items, we determine their sequence. We start with the highest priority item and only move on to the next one once the first one is completed, regardless of how long it took. If we would not get to the lowest priority item – we would still consider the overall outcome a success.

When we set an investment mix, we determine the percentage of time allotted to each investment theme. If the theme that received the smallest time allocation will not be addressed at all – we will fail in our mission.

When we mistake an investment mix decision for a prioritization decision, we set the sequence when we should be setting time allocation. As a result, the item that should have received the smallest time allocation becomes the lowest priority item. Since it’s unlikely that we’ll get to the lowest priority item – we’re essentially setting ourselves up for failure.

How to get out of this mess?

Identify when we’re conflating investment mix and priority – here are a few “red flags” which may help us catch ourselves in these situations:

  • Everything in our backlog feels like it’s priority #1
  • Comparing backlog items feels like comparing apples to oranges – there is no good comparison criteria. The items feel too different.

Set investment mix first, only prioritize within each investment theme

Investment mix guidelines:

  • Choose investment themes – good (differentiated) investment themes typically differ from one another in either value time horizon (will start generating value in 3 months vs. will start generating value in 2 years), business outcome (increase revenue vs. cost reduction, for example) or stakeholders served (external vs. internal, for example). Some combination of all three, as well as more use-case-specific attributes is possible.
  • Use one backlog – if the same team is working on items from multiple themes, keep work items from all investment themes in one backlog. Use filtering for internal prioritization in each investment theme
  • Set, track and revisit – The mix we choose don’t have to be the right mix forever, we can re-evaluate and change it on a cadence that seems appropriate. For example, on a quarterly basis. We should track and course-correct variance from the desired mix throughout the quarter.
  • Allocate people, rather than time, when possible – our actual investment mix can easily drift away from the desired mix. The best way to avoid the drift is to assign specific people to do work on each theme. At a large scale, we can form stable teams around each theme. At a small scale, we can designate a person to only be working on items from a certain theme at a given iteration/time-period. Note that this approach trades off collaboration for predictability. Highly mature/disciplined organizations can avoid that trade-off.

Prioritization guidelines:

  • Leverage experts – different roles may be better suited to prioritize items within each investment theme. An architect would have more valuable input on prioritizing tech debt that on prioritizing client requests. An account manager will have more valuable input on prioritizing client launches than on prioritizing operational tooling. That’s not to say that if you’re not an expert, your input is worthless.
  • Use a framework – if we chose good investment themes, we are comparing apples to apples within each investment theme. Which means that we can use a framework to ensure that our prioritization stays disciplined and consistent over time. Cohn and Leffingwell suggest several financial and non-financial frameworks. Model-based financial approaches are very sensitive to explicit and implicit assumptions and therefore should be avoided if the revenue impact of the investment is not direct.
  • Exceptions are allowed, if we learn from them – no framework is perfect, so sometimes going with an expert’s “gut feeling” would be the right thing to do. These are also typically good opportunities to see if the framework can be refined to more accurately reflect the true value equation.
It’s a Pie, not a Queue!