Meetup: Building a Developer Centred Company Culture

Jun 19th, 2014 By Pere Villega

Today I attended a meetup in StackCareers office in London. I’ve attended a few meetups (less than I’d like!) since I came to the City and joined Gumtree, but I consider this one to be one of the best. The subject was Building a Developer Centred Company Culture, which is of particular interest to me, but the speakers did good presentations and the ideas they shared captured my attention more than other events I’ve attended.

I took notes during the talks and I’d like to share a summary of the main points, as it is a relevant subject for many developers.

First of all a disclaimer: the text below tries to be a raw summary of what I understood. Any errors are mine and of my transcription. That said, I hope I could capture the more relevant parts.

There were three speakers so I created a section per speaker: the heading of the section explains who the speaker was and the content the main points of their presentation.

Emre Baran — CTO, Qubit

The first speaker was Emre Baran, who over the course of working 4 years at Google and 5 years as consultant with some big companies, has learned a lot about company culture.

His first rule is that he doesn’t hire developers, he hires engineers. The difference is the approach: developers do what they are told, engineers are challenged with a problem and find a way to solve it. The culture of engineering is a culture of long term, where he invests in the future of the engineer, helping them to grow, and that effort and selection bias is repaid. As a consequence, he doesn’t deal with contractors as you can’t invest in the long term growth of a contractor.

An important part of this culture is a very careful hiring process, with a low percentage of hires relative to applicants. The culture of hire fast and fire fast is contrary to long term growth, but to find a good fit for the team and their culture, they take time in the hiring process, which is (in his own words) slow and careful.

They look for self-starters, in fact the first question to a prospective applicant is always: “Have you ever built something, besides school tasks or work assignments?” They look for self starters, doers, people that will own and drive their own projects. Another question asked during the selection process, this time to people who interview a candidate, is: “Would you like to report to him in 6 months?”.

Talking about engineering management, Emre describes it as anarchy. Technology is anarchy, prone to constant change (new releases, tools, frameworks, innovation). They acknowledge that and are not averse to change, they embrace it and adapt. This makes them faster.

As an example, they are using Rust in production environment. It’s a scary approach in the short term, but it pays off big in the long term. It enables teams to have and own new ideas, removes constraints and fear. In the company, they consider that a happy engineer means a happy product. They know they will break things, it’s normal, they just work with that in mind.

Another particularity of his company is that engineers don’t report to a team lead on any HR related matter, they report directly to an engineering manager which has regular 1-on-1 with the engineers and works on the feedback received. This separation of powers helps people to speak their minds.

The final topic was frugality, something Emre believes VC don’t promote. He mentioned that having an engineer maintaining legacy code 10% of the time means that after 10 projects, the engineer is maintaining legacy 100% of the time — a write off. To avoid this, they have a 0 tech-debt practice and 0 QA — engineers own the code and test it. The company has only 1 SiteOps person, who spends most of the time benchmarking new stuff. They achieve this via automation, they choose to be frugal and they innovate to stay that way, automating everything possible and reducing the need to waste time on those processes and getting more time for new features.

As a summary he mentioned that investing in engineers, in people, pays off.

There were a few questions at the end:

• About compensation: he explained they give salary (based on experience and skills), bonus (one based on company performance, another on individual performance) and equity
• About communicating their culture: Emre acknowledged it’s a challenge and they have not done much until now, but they want to improve this area due to changes coming with their relation to third party developers
• On the reporting to the engineering manager: he clarified that this is only for HR issues and affects 26 engineers, and it may have to be slightly modified (more layers) if they grow much more
• The interview process was summarised as 6 steps: head hunting and selection of candidates, an initial phone interview, and a second phone interview with a senior member to check for culture fit, next there is a technical challenge for the applicant followed by an on-site interview with 2 or 3 members. The last step is a meeting to ensure everybody involved agrees with the hire.

And that was it. Short but interesting talk that gave a glimpse on the internals of a modern company.

Douglas started by announcing he is leaving Secret Sales and joining Osper.com. He explained a bit about his professional history and explained he thinks there are 3 key characteristics to a good culture.

The first is “being humble”. He told us how when he joined as CTO he was taking some tasks to free developers time and allow them to focus on what was important. The idea is that no job is beneath you, if there is an issue to solve (and that has to be solved, an important detail) and you can do it, you do it. Even if it means cleaning the bathroom before a visit of an important client (a situation he mentioned). Douglas also said that people must have all the information, even about uncomfortable things like the areas where they need clear improvement.

The second characteristic, and key to attracting people, is a “secret sauce”. This means something different and unique that nobody else does. As an example, he explained that in Tim Group they were doing pair programming and continuous integration back in 2005 when this was not so popular. In Secret Sales they were doing continuous deployment (5 times a day) in 2008. In his new company the sauce is Microservices.

There was a small technical detour when he spoke about Microservices and how they go to the level of releasing even components (like a report) several times a day. But not only releasing, also killing them even if they have been alive only for one day. Douglas mentioned that in this environment you don’t want many unit tests, you rely more on A/B testing, metrics and monitoring to avoid problems in your application.

The third and last characteristic is to not create a developer centric culture. This seemed like a contradiction with the theme of the day, but he explained that if your company doesn’t have a full technology focus, it doesn’t make sense to focus only on that. People who runs the business must understand why we do what we do, and business issues must guide the decisions. If something is not a problem for the business, however technically interesting or challenging it may be, just don’t do it.

As an example he mentioned pair programming: in an environment like finance codebase where an error can cost millions, pair programming is a business need. When doing a non critical component, it is not necessary. In general, Douglas considers overselling technology-related stuff to be bad in the long term. It’s better to closely integrate technology and business.

There were no questions (it was pizza time, people were probably hungry). Probably the talk I liked the most as it gave an uncommon point of view.

Joel Spolsky — CEO and Co-Founder, Stack Overflow

The last speaker was Joel Spolsky, who doesn’t need much of an introduction in the developer world. He started by mentioning that the phrase “culture fit” is hard to explain, and too often is used as a reason to not hire somebody.

Joel explained that the motivation to found Fog Creek was the lack of a place that put developers first in New York City. Microsoft, Facebook and many other successful companies have succeeded due to the quality of their staff. So he founded a company with no product in mind, where a developer is not an appliance but the key piece of the company. The have been asking themselves again and again “How to make this a great place to work for a developer?” and they act to keep it like that.

He also mentioned that they focus on developers even if the change is not optimal for non-developers. This strategy has borne fruit.

For example, in the early days, they gave every developer private offices. It is justified given how hard is to recover from an interruption, which equates to wasted time and productivity. Giving an office reduces interruptions and promotes more productive ways of work (asynchronous communication, looking for the answer yourself, etc). It has a downside though, there is a certain lack of flexibility related to adding more developers to the team.

The solution to that lack of flexibility has been remote working. For years Joel thought it was an inferior option, given all the prominent outsourcing failures in the industry. But, as it happens, the failures were due to the way remote working was approached. You can’t consider remote working to be a black box, this will fail. The open source community had been showing (for years) that it is possible to develop complex software remotely. We just had to learn from them.

Joel explains the way they work in Stack Overflow: they are on Google Hangouts all the time, they have chat rooms, they require some overlap between developers (for meeting purposes, everybody is online during New York afternoon time), and they are extremely picky on audio quality, to the point of shipping $XXX headsets to developers to ensure proper sound quality. All these together make the developers “live in the cloud”, on a virtual environment that is (work wise) no different from an office.

Meetings are one major concern for managers implementing remote working. He said that he wanted to talk about pro and cons, but he could only find pros. Developers have a computer accessible during the meeting, they can lurk while getting things done if the subject is not relevant and side-comments don’t interrupt the flow of the meeting. The key part is to avoid conference rooms, as they remove the benefits of a real remote meeting. And this goes back to the need of private offices: you don’t want a developer speaking to interrupt the flow of another developer in the same room.

They also organise social face-to-face meetings every 6 or 12 months, to build a stronger sense of community between the workers.

One benefit of remote workers has been finding talent. Joel explained how they had an issue with some legacy code (Fog Creek) as it was hard to find people in New York that wanted to work with a 14-year old codebase. Once they went remote, suddenly they found a pool of senior people with very high skills that were ok with working in legacy code in exchange of getting the freedom remote working provides. The quality of the developers they can hire has increased substantially.

After that there were some questions:

• About how does he measure productivity: the answer was that he knows it when he sees it. Joel explained how supervision of a remote worker is a legitimate fear, but it’s much easier to judge when you don’t see the person but the effects of their work (commits, delivery, etc). In the end, it is all about judgement, as any measurement can be gamed (and good developers are great at gaming stats)
• On how are tasks assigned to remote workers: he explained that everything was quite ad hoc. Some teams lean more towards Scrum, other go other paths. But they try to avoid real code ownership, as ownership implies ego, and ego is bad for development.

A good talk with a good view on how Stack Overflow operates.

My Conclusions

Recently, there has been a surge in talks about engineering culture, or at least it seems so. Things like this meetup or the Spotify engineering culture video are trying to make developers aware of how they work internally.

When you think about it, the reason seems obvious: good developers are hard to hire, and showing an appealing culture will make them more eager to join the company. But if you go with this initial impression, it’s telling that only good companies have good developer cultures. As the speakers mentioned (all of them), there is a direct correlation between the success of a company that relies on technology at its core and how happy their developers are. And happiness comes from a good culture that cares about the employees.

So it’s not just a consequence of “the IT Bubble” or VC money turning developers into spoiled hipsters. It’s a business decision with business consequences, very important ones. But that doesn’t need to be expensive: a developer may not be happier for having an expensive chair, maybe they just need a more flexible schedule. The key is to understand what they need, and act on it as if your companies depends on it. It does.

Now I should probably say something about Gumtree’s culture. But we are busy releasing stuff before getting ready for the summer party tomorrow at Royal Ascot. Is that enough? ;)

Originally published at www.gumtree.com on June 19, 2014.