Makers vs. Managers

I recently read an article about the sharp divide between how different people use their time.  It divided people into two general camps: the “maker” and the “manager”.  People who fall into the former camp have work which requires large blocks of time which they can dedicate to a single concentrated task.  Engineers, authors, designers and the like all fall into this camp.  On the other hand, people in the “manager” group have work which requires them to constantly shift their focus from one task to another fairly quickly. Program managers are the quintessential profession in the software industry, but supervisors in nearly any field, people managers, and executives all of this pattern of work.

Unfortunately, makers and managers often need to work closely together, and often don’t really respect (or possibly even understand) the differences in each other’s mode of operation.  Managers will disrupt makers by scheduling meetings at whatever time works best to get the meeting scheduled soonest, without regard for leaving two funny 30 min chunks on either side of the meeting (which does a lot to kill the maker’s productivity).  On the other hand, makers will frequently drive managers right up the wall by failing to respond to a requests in a timely manner, or getting buried in one task and letting the schedule on another one slip.

There are two specific practices I’ve used which work well to smooth things out between these two groups: “Daily/Weekly War Team Meetings” and “Maker Time”.

A war team meeting is a routine standing meeting which the decision-makers of the team are required to attend, and which everyone is invited to attend.  The agenda for the meeting is decided in the first few minutes of the meeting.  Everyone present is welcome to add an item to the agenda, and request a certain amount of time for it (e.g., 5 minutes for a fast time, and up to 15 minutes for a long one).  The facilitator will put it up on the whiteboard.  Once the agenda is set (i.e., no one has any further items to suggest, or the duration of the meeting is spoken for), the facilitator starts walking through the items on the list.  Their job is primarily to keep the discussion on topic, capture items for future discussion, and keep things running on schedule.  If an issue cannot be resolved within the allotted time, it can either be settled privately between a few individuals who become empowered to settle the issue, or it can be brought back to the next meeting. Once all of the items which interest a person have been discussed, that person is welcome to leave.

This technique works fantastically well when coming up to a deadline, but is generally a good practice at any time (the closer to release, the more often you generally want to have the meeting).  The first positive effect is that it gives everyone on the team a forum and a voice on how decisions are made.  They don’t get to make the decision, but they can be part of the process.  That goes a long way toward improving morale on the team (especially one with really passionate, dedicated people).  The second effect is that it tends to consolidate hours of meetings into a much shorter span.  The vast majority of meetings take much longer than is required because they don’t have a really tight agenda, and because there is no strict timekeeper to keep things on track.  The third effect, and most important to makers, is that it makes the time of meetings predictable and consolidated.  This technique eliminates the need for many other meetings, and therefore gets rid of those odd little chunks of time which are hard for makers to use effectively.  Finally, and this is most important to managers, it creates a forum in which blocking issues can be resolved quickly and often. If your team does this daily, then the majority of issues which require a meeting can wait until the already-scheduled meeting the next day.

The second technique I’ve used for this kind of issue is “Maker Time”.  This is where makers are invited to block their calendars, reject meeting invites, close their doors, put on headphones or whatever else they need to do to put the world on hold for a few contiguous hours each day.  On one team I ran, we decided that we would prohibit meetings after 14:00.  In other situations, the team would pick a “meeting-free” day of the week (i.e., no meetings at all on Thursdays every week).  Whichever way, the leadership of the group made it clear to makers and managers alike that this time was to be set aside for makers to get their jobs done, and no one was to interrupt them (except for clearly defined emergencies).  This allows makers to have their dedicated time without completely blocking out managers for long periods of time.

Breaking Out of Consensus Deadlock

Back when I was working in a very small start-up with only two other people, we would often have a great deal of difficulty coming to decisions.  We would have seemingly endless meetings where each person would express their viewpoint, then someone would rebut that viewpoint, then the first person would express it again in slightly different words.  On and on, and sometimes about things which wound up being pretty trivial.  However, since there were only three of us, it felt like we ought be able to come up with some kind of consensus, but seldom was it that easy.

We had fallen into the trap of consensus deadlock.

I think of consensus deadlock as being any time a group of people gets stuck on making a decision because:

  1. there’s not enough data to make a clear decision obvious
  2. everyone feels that a unanimous decision is necessary
  3. no one is willing to ceed the decision to someone else
  4. there’s no clear owner for the decision

Naturally, there are a bunch of techniques to break out of the deadlock, and they all involve removing one of the things in the list.  The best thing to do, when it’s possible, is to figure out what information would tip the scales, and then go get that data (#1).  Of course, that’s not always feasible.  In that case, you might stop to consider how strongly you each feel about the issue, and choose to go with the approach someone feels most strongly about (#2).  You might also try thinking over the reversibility of the decision, and allowing someone else to give their idea a shot (#3).

Those are all good ways to break the deadlock, but perhaps the best way is to assign the decision to someone, and then hold them accountable for making a sound decision.  Of course, that doesn’t mean letting them simply go do whatever they want.  In order for this to end well, owning a decision involves a lot of responsibilities.

The decision owner’s job is really to pull everything together, and then follow the data where it leads.  First, the owner needs to ensure that all the available data has been gathered and is available for consideration by the team.  Depending upon the decision, this may be more easily said than done.  Second, the owner needs to collect feedback from everyone affected by the decision and give full consideration to each point of view.  In particular, this means that they should be able to represent each point of view as well as they represent their own.  Finally, the owner must be able to weigh the pros and cons of all those positions, measure them against the available data, and then present a clearly reasoned rationale for choosing a particular course along with its strengths and weaknesses.

The job of each other team member is to help the decision owner reach a good decision.  This may be offering up what data they have (all of it… not just what leads to a certain conclusion they support).  This might be to pose questions which are critical to understanding the problem.  This might be to help brainstorm various possible options and their pros and cons.  At all times, though, each team member needs to remain supportive of the process and the decision owner’s authority over that particular decision.

✧✧✧

The only way this technique works is for every member of the team to act in a mature and responsible manner.  The decision owner has to be able to step back from a pet idea to consider all possibilities, and the rest of the team has to trust that the decision owner is honestly considering all points of view.  If, at any point, someone on the team feels this isn’t the case, a discussion becomes necessary about whether process is being followed faithfully—not about the particular details of the decision at hand.  That makes it much easier for everyone to start from a place of agreement, and to get back on track.

Avoiding Us vs. Them in Problem Solving

I can’t count the number of times when I’ve seen two people trying to solve a technical problem where the real conflict is anything but technical.  Often, this starts when one person brings an idea to the table, and is trying to promote it to the group.  Then, someone else proposes a different idea.  Each goes back and forth trying to shoot down the other person’s idea and promote their own.  Perhaps there was a pre-existing rivalry, or some political maneuvering, or private agenda.  Whatever.  Sides form, and before long, the debate isn’t really about a technical solution anymore… it’s about who’s going to “win”.

Of course, no one “wins” such a contest.  It’s stressful to be part of.  It’s stressful to watch. And, worst of all, it kills the collaboration which could have produced a better solution than either “side” was proposing.  Fortunately, I’ve run across an excellent way to avoid the problem nearly 100% of the time.

The Technique in Theory

The key is to get everyone involved in the process to bring multiple ideas to the table.  This seems too simplistic to possibly work, but it does.  It could be that they come with these ideas ahead of time, or that they come up with them in a meeting.  That part doesn’t matter.  What matters is that each person comes up with more than one.  The reasons this works have a lot to do with how it forces people to approach the whole brainstorming / problem-solving process.

The Opened Mind

The first thing that happens if you insist on each person bringing multiple solutions is that it opens up each person’s mind to the possibility of there being multiple solutions.  If you, yourself, brought three different approaches to the table, it’s very hard to imagine there’s only one way to do it.  And, if you’ve already formed favorites among your own ideas, you’ve probably started to develop some criteria / principles to apply to making that judgement.  At that point, it becomes a lot easier to weight the pros & cons of another idea you didn’t originate, and fit it into the proper place among the rest of the ideas.

Breaking Up False Dichotomies

The second useful trait of this approach is that the decision is no longer an either-or decision (a “dichotomy”).  Instead, you, yourself, have already thought up a few different approaches, and your thought partners probably came with a bunch of their own.  With that many potential solutions on the table (even if some of them are obviously very bad) it becomes a lot easier to see the complexities of the problem, and how there are a whole range of ways solve it to a better or worse degree: or even solve parts of it to a better or worse degree in a whole variety of combinations.

Cross-Breeding Solutions

Another handy aspect of having a lot of potential solutions, and seeing the many different aspects of the problem they tackle, is being able to mix and match.  Perhaps you grab a chunk of your solution, throw in a little bit of someone else’s, and then add in a piece which neither of you thought of ahead of time.  And again: but with a different mix.  And again… and again.  Before long, you’ve all moved past the original set of ideas, and have generated a whole bunch of new ones which are each better than anything in the original set.  At this point, the question of “us vs. them” is impossible to even identify clearly.  And… you’ve got a much better solution than anyone generated alone.

Goodwill Deposits

In my last post about “goodwill accounting“, I talked about how fun experiences strengthen relationships.  The process of brainstorming with an eager partner who isn’t defensive, and who is eager to help is extremely exciting and fun.  This makes substantial “deposits” for the future.

 

The Technique in Action

In practice, the technique is dead simple.  Guide your problem solving with three questions:

  • How many ways could we do this?
  • What does a good solution look like?
  • How do these potential solutions stack up?

 

When I find myself in a brainstorming / problem solving context, I’ll often start out by literally saying: “Okay… so how many ways could we do this?”  Then, I’ll start to rattle off, as quickly as I can, every different solution I can imagine: even really obviously bad ones.  Sometimes, I’ve come with a few I already thought of, but very often not.  Others soon join in, tossing out more ideas.  I keep pushing everyone (especially myself) until everyone has given 2–3 solutions.  At this point, we really do want all the possible ways: even the ludicrous or impossible ones.

Once everyone is mute & contemplative, I’ll echo back all the ideas.  At this point, the order is so jumbled, it’s impossible to tell who added which.  Then I’ll ask: “So, what does a good solution look like?”  Now that we’ve had a chance to see some proposed solutions, it’s a lot easier to figure out what we like about some and not others.  This rapidly crystalizes into a set of criteria we can use to rank the various options.

At this point, I start pointing out how various solutions match up with our criteria.  Some get crossed off right away, and others take some discussion and even research.  We might even loop back to re-consider our criteria.  The major difference is that everyone is focused on the problem, and not on the personalities or politics.

✧✧✧

I use this technique a lot.  Early in my career, I was (embarrassingly) often one of the pig-headed people at the table insisting on getting my own way.  Now, I jump in with my “how many ways…” question, and I’m almost never even tempted.  My own relationships with my teammates are better, and I’m often able to use this technique to help smooth over difficulties between other members of my team.  I find it invaluable, and I think you will, too.

Sending Cold Emails

This is part 2 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.

✧✧✧

At a rough guess, I get about 4–5 recruiting emails every week.  Sometimes more, sometimes less.  I only bother to even say “no” to perhaps 1 in 100.  The others go straight to the trash: often unread.  For the benefit of all my recruiter friends, I’d like to explain why.

First, I should mention that I’m a software engineer with roughly 20 years experience.  In that time, I’ve worked up and down the technology stack from web to mobile to back-end to dev-ops: you name it.  I’ve also worked for companies from IBM to a freshly-minted startup.  So, I imagine I’ve gotten on a lot of lists.

 

Getting it Wrong

The common thread in the 99% of emails I don’t answer is that they’re really just spam.  They obviously take no time to pitch me on why the job fits my interests, talents, or would be better than the job I currently have.  The worst offenders are the bulk emails which invite me to peruse a “jobs” page and apply.  Slightly less obnoxious are the “we saw your resume and think you’d be a good fit…” emails. However, they all focus on what the company wants: not what I might want.  Fire and forget may be a good tactic for filling some positions, but you’re never going to pull a qualified senior person out of their current company that way.

 

Getting it Right

The tiny fraction of emails I do answer have at least one of the following traits:

  • they come from the hiring manager / founder
  • they clearly demonstrate some specific knowledge about me
  • they clearly tell me why I—me in particular—would enjoy the work
  • they clearly reference that this is a referral from someone I’ve worked with

 

An Example

One email I recall getting recently was from Matt Lott, the co-founder of CodeCombat: a startup which is trying to help kids learn coding by making a (really cool) game out of it.  He nailed nearly every point on my check-list. Here’s the actual text:

Hi Andrew,

Fellow co-founder here. I checked out Crafting Guide – kudos on
building a really cool guide to everything Minecraft-related :). I
also read on your LinkedIn profile that you enjoy mentoring others so
I thought I’d reach out. Our “World of Warcraft”-inspired game teaches
kids how to become programmers; to climb between levels, students
write code to navigate mazes and defeat savage monsters. More than
20,000 teachers currently use CodeCombat, and our investors include
Andreessen Horowitz and YC.

So far, we’ve built a popular single-player game, and we have many
cool challenges on the horizon – like building real-time multiplayer
mechanics and revamping our graphics engine. With your experience, I
thought you’d be interested in leading these initiatives.

If you’re interested in helping kids learn, I’d love to chat. How
about a phone call or coffee next week?

Matt Lott
CTO, CodeCombat

First, this is clearly coming from the hiring manager / co-founder.  This means that someone who has many other responsibilities thinks there’s a good enough chance that we’d want to work together that it’s worth his time to contact me in person.

Second, Matt clearly did his homework here.  He obviously read my LinkedIn profile carefully; he noted that we’re both co-founders, and that I mention enjoying teaching.  He also found the gaming-related hobby site I made, and he obviously spent some time figuring out what it is all about.

Third, while a big chunk of the email is clearly pretty general-purpose, he starts by calling out the why my specific interests—teaching & gaming—would lead me to being interested in working on their product—which is all about teaching through gaming.  Then, he gracefully transitions from the more personalized part to the less personalized part.

In fact, the only point he didn’t hit was mentioning this as a referral, but hey… sometimes that’s just not the case.  Still, 3 out of 4 is better than 99.99% of recruiting emails I get.

And, for the record, while I didn’t accept Matt’s offer for coffee, we did have a very nice email exchange.  Of greater importance, though, is that if I heard back from him under different circumstances, I’d be happy to renew the acquaintance.

✧✧✧

I don’t need to tell anyone that there’s a lot more open headcount for senior people than there are actual people willing to join your company.  I also don’t need to tell anyone that, in general, we are well-paid, and have our choice of jobs.  Naturally, that implies that everything in recruiting is backwards compared to other more junior positions.

If I could make every recruiter understand one thing about recruiting senior-level professionals, it would be: you are in sales.  I’m a prospect, and you’re pitching a product to me.  You need to learn enough about me to understand what will motivate me to buy, and then sell it to me.  You’ve got one email to convince me that you’ve made an effort to pitch me on something that I actually want.  Don’t blow it on cheap form letters or junk mail.

Conducting an Interview Loop—Part 1: Setting up the Team

I’ve worked at a pretty diverse range of companies from the massive (IBM, Microsoft) to the merely large (Amazon, Groupon), to the small (Boom, Pelago), to the positively tiny (Kima Labs, Redwood Labs).  In every place I’ve worked, interviews are conducted according to the same general pattern, but with a lot of differences in the details.  This series will explore what I think are the best practices I’ve seen across all those different places.

✧✧✧

Even before a candidate has been identified, the hiring manager should have prepared the team for the potential interview loop(s).  The first step is to actually have a team.  That is, a dedicated group of people for interviewing all the people coming in for a certain position.   This has several advantages:

  • the team can form a “group memory” of all the candidate who have interviewed
  • the team can coordinate on “focus areas” and even individual questions
  • the team will get to know each other’s questions, and therefore save time in debriefing about the candidates

I’d like to talk more about assigning “focus areas”.  Each member of the team should be assigned a couple of very specific areas to focus on.  For example, in the case of hiring a software engineer, one person might be asked to look at algorithms, another object-oriented design, and yet another front-end development skills.  In additional to technical areas, people are generally also asked to investigate some cultural value of the company’s.  For example, at Boom, we value people who like to make things in their spare time, so we might have someone assigned specifically to dig into that a little bit.

Once assigned an area(s) to focus on, each interviewer should plan out what questions they want to ask in order to learn the most possible about that area.  Here it works best to develop questions in two different ways: a simulation of actual job skills, and asking the candidate to relate a story.

Simulating actual job skills works best for technical areas of focus, and the best questions are those which are closest to the real task involved.  So, in the case of assessing programming skills, I’ll always make sure to have a computer on hand, and a set of real development tools installed and ready to go.  Finally, I’ll have made up a question which is a simplified version of some actual challenge I’ve had to solve at work.  The goal is to come up with a question which, as nearly as possible, uses the tools and skills the candidate will actually have to demonstrate at work every day.

Asking a candidate to tell a story (i.e., Behavioral Interviews) work very well in cases where a skill is hard to demonstrate on the spot, or when trying to understand a candidate’s culture fit.  In this style of questioning, you ask the candidate to tell a story about a time when… you fill the blank.  These are often things like: you had to deal with a difficult customer, you missed a deadline, you were forced to be innovative, etc.  These can also be much more specific.  For example, I might ask a software engineering candidate to tell me a story about when they had to fix a particularly nasty bug in a piece of code they weren’t already familiar with.

It’s extremely helpful for each member of the interview team to use the same questions for each candidate for a particular position.  This allows them to:

  • get better at asking the question in a clear way
  • get a sense of what good and bad answers look like
  • figure out what guidance works to help a candidate if they get “stuck”
  • be able to compare answers directly between individual candidates

This also allows the other members of the interview team to plan their own questions to avoid any possible overlap: especially when multiple people share the same areas of focus.

✧✧✧

At this point, you’ve got your team together, and you’re ready to start talking with candidates.  In future posts, I’ll talk the best practices I’ve seen around getting candidates to show up, what to do before they arrive, how to conduct the loop, etc.