Two attempts to define the job of a CTO, one by Camille Fournier, from Rent the Runway, and one from Greg Brockman, from Stripe.

The bottom line from Camille:

My advice for aspiring CTOs is to remember that it’s a business strategy job, first and foremost. It’s also a management job. If you don’t care about the business your company is running, if you’re not willing to take ultimate responsibility for having a large team of people effectively attacking that business, then CTO is not the job for you.

Greg’s post is more about how to adapt within your job to say happy and productive in a rapidly changing company. One thing’s for sure, it sounds like Camille is probably writing a lot less code than Greg.

I think that Camille’s description of a CTO is actually a solid description for any engineering management job, at the scale at which the manager works. Managers should be thinking about the business strategy for their team, and should take responsibility for applying the resources they can muster toward that business.

(by way of @scienceporn)

The news story of the week is the Greek elections that put the left wing anti-austerity Syriza into power. The Economist has a useful article on the implications for the broader Euro-zone. As Paul Krugman explains, the austerity measures Greece has imposed at the behest of the institutions that bailed it out have been ruinous for the Greek people. The best overall article I’ve read on what happens next is from the New Yorker’s John Cassidy.

SoundCloud has released a new, open source timeseries database and monitoring system called Prometheus. It’s an interesting amalgam of Graphite, Statsd, Nagios, Grafana, LogStash, and probably other things as well. It will be interesting to see if such a comprehensive tool will catch on.

For the record, poor people taking out mortgages they couldn’t afford were not responsible for the housing crisis.

Judging from what I’ve seen on Twitter, the McSweeney’s bit Reasons You Were Not Promoted That Are Totally Unrelated To Gender is resonating for a depressingly large but not unsuprisingly large number of women.

Article I wish someone would write – a think piece on weather forecasting, hype, and cynical reactions to missed forecasts. This blog post by Washington Post weather editor Jason Samenow gets pretty close, just ignore the inflammatory headline.

I have a couple of long posts in the works. The first is some thoughts on Peter Seibel’s essay on feedback from a manager’s perspective. The other is a post that I started writing on Martin Luther King Day but didn’t finish.

Today I caught Jason Kottke’s post on link blogging, and it got me thinking about links as well. While I don’t publish as many posts as I once did, for a number of reasons, I do still churn through a lot of interesting links every day, and there a variety of places you can go to see them.

I have a link blog of sorts in the right sidebar, which just republishes my shared items from NewsBlur, my newsreader of choice. (They’re also published at rafeco.newsblur.com.) I also share a fair number of links on Twitter, and on Pinboard as well. To make things more confusing, Pinboard also scrapes all the links I publish on Twitter, and all the stories I save on Readability as well.

Maybe it’s time for me to get back to republishing those links here on the main blog.

Everybody is talking about the New York Times op-ed, Why Some Teams Are Smarter Than Others, because everybody wants to talk about the fact that it says research shows that teams with more women perform better. My anecdotal experience aligns with the research, but I want to talk about another point that the article makes. Here’s a snippet:

Online and off, some teams consistently worked smarter than others. More surprisingly, the most important ingredients for a smart team remained constant regardless of its mode of interaction: members who communicated a lot, participated equally and possessed good emotion-reading skills.

I think that the biggest mistake people make when hiring remote workers is in thinking that remote workers don’t need to be as social as people who work in the same office. The research seems to confirm what I already thought, which is that people working remotely need to be even more communicative than people in the office. In the office, there’s really no place to hide, even people who don’t communicate that much are still in the physical presence of their colleagues. If you’re remote, it’s much easier to disappear, so it is more important to find remote workers who strongly prefer to be present in whatever medium the team uses to communicate.

Matt Mullenweg of WordPress on Paul Graham’s argument that we the government needs to grant far more U.S. visas for software engineers:

I agree that the US deserves dramatically better immigration policies, but in the meantime I’m confused with the head-in-the-sand approach most tech companies are taking simultaneously complaining that there are lots of great people they can’t bring into the US, but being stubborn on keeping a company culture that requires people to be physically co-located.

Recruiting is about tradeoffs. One of the easiest ways to expand your pool of potential applicants is to remove the requirement for physical proximity. Managing a fully or partially remote team is a different and in some ways more difficult job than managing a group of people who all show up at the same office every day, but seems more feasible than changing U.S. immigration policy to make it easier to bring more engineers from overseas to the Silicon Valley.

I’ve read two really excellent posts about hiring engineers lately. Both of them are aimed at adding nuance to the discussion of “hiring the best.” The first, from Cate Huston in Model View Culture takes this on directly in her essay, We Hire the Best. Here’s her rephrasing of “hiring the best”:

Among people we know, we hire “the best” (as determined by our subjective process), who are willing and able to work in a specific place (or remotely), and who accept our offer.

She then goes on to survey the space that exists between “the best” as defined by the company itself and the candidates who wind up accepting offers. That space also happens to be where most of the industry’s worst hiring practices live.

Jocelyn Goldfein’s piece, How To Hire Engineers: Step 0, What To Look For, goes on to demolish the idea there’s a definition of the “best engineer” that works for choosing who to hire in the first place. There are a large number of positive characteristics an engineer might have, and some of them are in opposition with one another. Building a good team is about assembling a group of people that collectively exhibit all the strengths you’d hope to see.

The risks of emphasizing a few strengths to the exclusion of others are high. Here’s one end state:

If you elevate your “hiring bar” to religious status, and represent, say, coding speed, not as a means to the end of shipping great software, but instead as the gold standard of What It Means To Be A Rockstar, you’re going to have a lot of trouble hiring for anything else. Your existing team (who have all been selected for coding speed) will view this as “lowering the bar” and the consequences could be severe — anything from griping and loss of morale, to blocking or undercutting new hires, to quitting.

I have seen this happen, and it’s not pretty.

As a manager, I think it’s important to think about the next hire rather than the ideal engineer. What does your team lack right now, and how can you address it by hiring someone? Maybe you need someone who’s more collaborative, or maybe you need someone who really likes to dig into deep problems. Maybe you need to hire a more junior person to take some work off of a senior person’s plate, or maybe you need to hire a senior person to tackle big projects. When it comes to hiring, you have to blend these requirements with the attributes that you consider to be non-negotiable and then apply those wishes to the pool of candidates who are available.

It is incredibly tempting to think about hiring the way colleges think about admissions – ranking the candidates and hiring the “best.” This is a very common approach to scaling up the hiring process at tech companies. I don’t think that it’s the path to building solid teams as opposed to groups of solid individuals.