Last week, Entelo attended Developer Week 2018 in Oakland, California. I had the fortune of attending this high-energy event with a few other co-workers.

Our primary purpose for attending was to hire software engineers. We’re growing quickly as a company and are hiring for a number of engineering positions. Also, Entelo’s very own Ryan Booth and Vlad Tsvang hosted an open talk titled Reusability on React without Compromise.

The Entelo team at the booth. Photo credit: Jesse Buesking (Entelo)

The Booth

Entelo had a booth conveniently set up close to the prize booth. Attendees could exchange their points for prizes such as gaming headsets, drones, and other goodies. To earn points, attendees had to scan a QR code present at each one of the booths. For companies like Entelo that are well-known in their industries but not so much generally, we appreciated this fun incentive, as it gave us the opportunity to pitch Entelo to more people.

Our booth attracted quite a bit of attention. Photo credit: Jesse Buesking (Entelo)

Many people were interested in learning about Entelo, and I was able to practice my pitch for the company. People from a wide variety of positions approached our booth: company founders, students, recruiters, software engineers, and others. After my first few pitches, I learned to look at the title on the individual’s badge so that I could tailor my pitch accordingly. I had pitched Entelo to a few people with the hopes of hiring them only to realize that they were founders of their own companies.

Overall, we generated quite some interest in our company from a hiring perspective…and a lot of people now have some really nice Entelo shirts!

The Keynotes

While the event featured talks on a large number of topics related to engineering, the agenda was heavily focused on talks and workshops on AI, blockchain, and quantum computing. Because our booth was quite busy, I spent most of my time there, but I was able to attend two very interesting keynotes: one on quantum computing, and another on scaling your engineering team, a problem Entelo will be faced with very soon.

Keynote #1: The Role of Developers in the Age of Quantum Computing

I was intrigued by this keynote. We all hear about the potential power of quantum computing, but what is the state of the technology today, and what are the challenges associated with it? This keynote, run by Andrew Schoen, a Principal at NEA, and David Moehring, the CEO of IonQ, addressed some of those questions. Despite some of the physics details that were over my head, I went into the event with little knowledge of quantum computing and came out of it with more than the average person.

Takeaways:

1. There are currently several approaches to creating a quantum computer, each with its own pros and cons. IonQ uses the Trapped Ion approach. IBM and Google each have their own approaches.
2. The most powerful quantum computer today has about 50 qubits. David stated that we’d probably need hundreds of thousands or even millions of qubits to break modern encryption, so quantum computing is at least a decade or two away from making irrelevant modern cryptography.
3. A standard measure for the performance of a quantum computer has not yet been developed. Going simply by the number of qubits is not a good indicator of performance. The quality of the qubit and the connectivity of each qubit to all the other qubits matters.

Keynote #2: Reddit — Triple your Team Size without Losing Control

The topic of this keynote is especially relevant to Entelo, as we’re scaling, so I am going to dedicate quite a bit of this post to it. VP of Engineering at Reddit, Nick Caldwell, walked the audience through how Reddit handled tripling the size of its engineering team. The team faced very high growth: from about 40 to 120 engineers in a single year.

When Nick started at Reddit, the product and engineering teams lacked structure, clear roles and responsibilities, motivation, and accountability. The team had 30-person daily standups, and engineers did not appear motivated to complete engineering tasks: they played Super Smash. Bros for hours each day. As a competitive Super Smash Bros. player, I wondered which version of the game they played. Regarding team structure, they had no engineering managers but quite a few tech leads and program managers.

Nick implemented significant changes to the team in order to double its work output without adding any engineers. Here are some of his changes:

1. He used the R.A.C.I. technique to splitting program managers into product managers and engineering managers. This forced the team to move towards specialization and accomplished the goal of setting clear roles and responsibilities for everyone.
2. Removed tech leads since their roles and responsibilities weren’t obvious in the new structure. Many of the tech leads moved to an engineering manager, and some left the company.
3. Implemented enough process to keep the team organized by introducing better product management tools such as JIRA. Previously, they wrote down their sprint on a Google Doc and spent quite a bit of time deciding which superhero to put in the background. There were multiple versions of this document circulating around the company.
4. Gave his team meaningful work — he expressed the value that their work has on the company, and more generally, their users.

With those changes in place, Nick began to scale the team. I thought this was an interesting statistic:

According to the Startup Genome Report, 92% of startups fail within 3 years, and 43% of them fail with issues due to scale.

Here are the highlights from the talk about the challenges of scaling, along with some warnings:

1. Awareness, coordination, and bottlenecks get harder as you scale

A slide about the challenges faced when scaling a team. Photo credit: Jesse Buesking (Entelo)

Awareness: Everyone wants to know what everyone else on the team is doing, but that’s not always possible.

Coordination: How do you ensure that different people aren’t working on the same task? How do you ensure that some work does not conflict with other work? How do you ensure that there is communication when similar work is being performed on different teams?

Bottlenecks: How do you ensure that one team does not block another team?

2. A bigger team results in higher coordination cost

More people on the team doesn’t necessarily equal a higher velocity. Scaling has diminishing marginal utility unless you implement a sound process to handle it. If engineers are stepping on each other’s toes, at some point adding more people will reduce your velocity. Nick refers to this concept as coordination cost. Coordination cost can be reduced and “fixed” with process.

3. Avoid process junkies

Ease your team into process, and don’t become infatuated with it. Your process will become your culture over time.

Developer Week was an incredible event. I spent only a couple of days there, but I learned about quantum computing, scaling teams, and more about the very company that I work for, Entelo.