QCon New York Day 3: Humans and engineers, Career Development, Remote Teams and Culture

Building a NoSQL database

Man, my brain still hurts from the first two days, especially around all the clarities of micro-services. But, longing for more information, day 3 started with another keynote. Not as good as yesterday's, but the story about how Amazon build their own NoSql database contained some nice lessons. For starters, they insisted on planning for both scalability as well as failure. The former is usually something that doesn't get immediate attention, but that's usually still more than what we do with the latter. And again, Netflix is being mentioned since they invented Chaos Monkey and Latency Monkey. Another thing that I do agree with is consistent performance. How many companies actually monitor performance day by day? In my experience dev teams only start addressing performance when there's an immediate issue. One interesting concept they introduced is the Blast Radius. During their failure testing they explicitly analyze how far that failure reaches into the application landscape. With that information, they've tried to tune the interfaces between components to become a bit more resilient.

Mentoring engineers

To my surprise there was an actual TypeScript session in this slot, but the title of another session -- Mentoring Humans and Engineers -- sounded too interesting. Daniel Doubrovkine showed us how he approaches mentoring new employees within his current organization. They've based their approach on his experience that getting the strongest people at any level and keeping them is the single hardest thing in any organization.

This all starts by promising an interesting learning experience, both on the job as well as outside the job. For instance, new employees are also shown around in New York. What places they should visit. Where to find a nice place to stay. How to meet-up with new people. Next to that, they pick their mentors from the most experienced, pragmatic AND patient people that understand starting with clear milestones and then gradually moving to goals is the best. They know that fostering ownership and trust is essential, the room for self-exploration is required, while not overwhelming them with both information and too much freedom.

Even more important (and something I often forget in my desire to help teams) is that failing is okay, as long as you learn from it. You should really create an environment that provides feedback, but take responsibility to protect them from anything that would de-motivate them to try new things in the future. At the same time, teach them how to fail by given them an assignment that is difficult or impossible to do. And don't forget to advertise them within your organization. Always introduce them to whoever you run into and openly praise them for any accomplishments. Daniel's closing statement was particularly interesting since he warned us not to underestimate a young new colleague. They might be much smarter than you are….

Climbing off the ladder, before we fall off

Spotify has been a big example for us, especially through Henrik Kniberg's excellent book Lean from the Trunches. And QCon wouldn't be QCon if they would not have a Spotify session. Chris Angove, a chapter lead from Spotify New York explained how he tried to find the balance between alignment and autonomy (or "do what I say" vs "do whatever"). They quickly discovered that this is destined to fail, simply because these two ends should be orthogonal. Instead of that, they tell their engineers what to do, but don't tell them how to do that. Somehow this freedom brings along a lot of responsibilities. To help the teams know their part in the big picture, they can give them missions, short-term goals and a product strategy.

This is all fine and well, but after more than two days of sessions, this is not what sets them apart from the rest. But what did is the way they approach career development. Traditional companies generally use a linear ladder where a software engineer can potentially climb to senior software, architect or even CTO. This provides a clear structure for promotion, and thus more salary and status. However, according to Chris this model can also be a factory to eject people due to limited management positions or by promoting people beyond their capabilities. In short, it provides simplicity for the manager, not the engineer.

Alternatives exists. For instance, some companies use two ladders; one for management positions and one for software engineering positions. Although it provides a technological track, and it clearly sets up easy ways to recognize accomplishments, it still looks like a linear ladder. Similarly to the previous model it assumes that the only way to grow is to take more responsibility or control. It still doesn't answer how to experiment or switch between roles.

Spotify believes that people that add value should be paid more money regardless of their role or position. To support that they stimulate engineers to try something new, which doesn't necessarily mean they stop what they are doing. In other words, they try to get them out of their comfort zone, to acquire a new skill and to push themselves in a new direction. More specifically, to shake things up a bit and see what talents or skills somebody really has. So instead of this rather rigid ladder, they've introduced add-ons that add both personal value as well as business value aligned with the skill-set and interests chosen by the engineer. In a sense it is engineer-driven but supported by company. The manager must work with the engineer to help him or her to find those challenges or even define a completely new add-on, or even giving them some time off to attend trainings, sessions or workshops. And those add-ons don't have to exist upfront. It is perfectly fine for an engineer to come up with another add-on that adds value to the company. Some the add-ons currently being tried at Spotify include a speaker, a road manager, coach, evangelist, mentor, trainer, writer or even open sourcer. Even an architect is treated as an add-on, simply because they help in alignment rather than to make decisions. If you ask me, this sounds like a great model.

Interviewing for culture

Another slot in this awesome conference with an open-space session on culture. This included a great discussion on mentoring and how important this is for your career. Several of the participants shared their opinions on how a junior engineer needs to be taught on how to get the most out of this skills and how to advertize him- or herself within an organization.

Another discussion was about how to determine if somebody is going to match your organization's culture during an interview. Inviting somebody for lunch helps to see how somebody behaves in a new group was one suggestion. Having full-day interviews to allow the person to relax was another. However, one participant said they stopped doing that because candidates would be completely drained at the end of the day. Another participant told us that upon arrival of the candidate, they first asked about there private life, kids, etc and then came back after 5 minutes or resulting in a much more relaxed interview. Doing code assignments from home is also very popular, but some mentioned they were worried the candidate would game that system.

The final topic dealt with introvert colleagues. I explained how something like Flowdock seems to help those people that have great ideas, but just don't feel comfortable enough to share that in an open discussion.

Remotely working at Github

Last year's talk by Github employee Zach Holman already showed many of the merits of that company, and this year Matthew McCullough continued by elaborating on some of the things they do to foster remote working. I already knew that Github employees can spend 20% of their time on innovations, learning new things, but I didn't know that on average 70% of the people work remotely. That explains the amount of energy they put on building tools and offices that support that.

For instance, they've build an internal app that provides a central location for discussions, sharing ideas, their internal communications handbooks and having live video chats. They also organize mini-summits where two engineers can do an internal talk which is then shared through that same app. Even cooler, they build tools to allow them to listen to the same music all over the world. So if somebody makes a remark about a cool song at the other side of the world, it's almost as if they work at the same office.

They also pro-actively build small offices with a living room or café-styled look as well at different places in the world to allow people to have a nice place to meet informally. Those offices also have some kind of phone booths to work in In fact, to better understand how it is to live outside of the US and in a different time zone and to work on a global project, the CEO decided to move to Paris for a year or so. They also organize beer:30 meetings where teams have informal virtual meetings with other global teams.

While discussing the communications guide, Matthew shared some of the foundational principles Github. First of all, teams make decisions about what they do, not committees of carefully selected people. Egos are not allowed in discussions. In the end, the best argument wins. That's an interesting statement, especially considering my own challenges to give somebody enough room to make their point sometimes. But even more striking is that everything is open within Github. The financial situations, salaries, expenses and even meetings that deal with the future and strategy of the company.

That's definitely something I have never seen before and from which a lot of organizations can learn from…