How to scale DataCamp’s engineering group?

This post focuses on how to scale the people building the tech behind DataCamp, not on how to scale the actual technology (for the latter, I refer to our CTO’s technical vision). Scaling the engineering group in a smart way is essential for the company. The goal of this post is to lay the foundation for a structure that will allow DataCamp’s engineering group to double or triple in size in the next 12 months.

DataCamp right now

The simple fact that I’m writing this is a testament to the fact that we’re missing a key position on the DataCamp management team. We won’t be able to scale the team engineering team unless we have an end responsible for the people in the engineering group.

On the one hand, we want to grow the engineering group in a highly decentralized fashion with fairly independent teams, who can use different technologies, development practices, etc. (similar to spotify). On the other hand, we’ll have quite a few team leads and product managers over time, which will create a decent amount of chaos. Chaos is good and intended as innovation needs freedom and chaos. The remainder of this post focuses on how we can control that level of chaos and freedom. We need just enough people and process management to avoid total anarchy while maintaining innovation.

Current problems

Let’s start with a few examples of what’s currently not going well:

• 2 of our engineering teams have become less productive in the last few months. No one addressed that.
• There’s no one to coach new team leads on how to do their job well.
• One team lost 2 people unexpectedly (which meant the entire team except the team lead was gone).
• In the org chart all engineering team leads still report to the CTO, while the CTO wants to minimize time on people management, and spend more time on technical vision, architectural changes and building MVPs.

To be specific, the key problem is that there’s no clear end responsible for:

• People related performance issues (of team leads)
• Speed/quality related performance issues (of teams)
• Big projects that span multiple teams (e.g. gamification)
• Structure of the engineering teams (when to split them etc.)
• Engineering hiring flows: people will fit multiple teams often in the future with the micro-services architecture and someone needs to determine how these choices will be made.

To sum all of that up:
While the technical vision is set by the CTO, someone else ultimately needs to own execution of the technical vision and hold people accountable to execute the technical vision. As the engineering team grows, ensuring the execution of the tech vision will become less straightforward, while it’s obvious with just a few engineers. And…

We’ll be growing teams and adding teams in the next few months. We’re moving to a situation with at least the following teams by our next company gathering in October:

• GE (Growth engineering — building all growth and marketing related initiatives)
• CE (Community engineering — building DataCamp’s community)
• EE (Enterprise Engineering — building DataCamp’s groups product)
• ME (Mobile Engineering — building our mobile app (launch Oct 16 ;-))
• LE (Learn Engineering — building the actual learning experience)
• TE (Teach Engineering — building our course authoring environment)
• EXE (Excel engineering — interactive learning for Excel #futuremusic)
• IE (Infrastructure engineering — building the infrastructure that makes all of the above run smoothly and gather data about it)

An assumption that’s no longer true…

Given our focus on decentralization, ownership and microservices, we mistakenly assumed that close to zero management of engineering team leads and coordination between team leads was OK. The examples above & future growth plans indicate that we’ve reached the stage where this is absolutely no longer true. The role of the CTO at DataCamp has changed recently and I have moved away from regular check ins with engineering team leads some time ago, essentially leaving people & project management of the engineering group to be owned by no-one.

By consequence, we now miss a position typically referred to as: VP engineering. Most companies create this role much earlier, our focus on ownership and decentralization has allowed us to postpone filling this role until now.

So… what’s a VP engineering in a decentralized organization?

I have always compared them as that a VP of Engineering wakes up each morning concerned whether he/she has the absolutely best engineering team and the CTO wakes up concerned whether they have the absolute best technology.
— Werner Vogels — CTO Amazon

“A VP Engineering is ideally a great manager and a great team builder. He or she will be an excellent recruiter, a great communicator, and a great issue resolver. The VP Eng’s job is to make everyone in the engineering organization successful and he or she needs to fix the issues that are getting in the way of success.”

For more context, please read:

• CTO vs VP Engineering (AVC blog)
• Defining roles: CTO and/or VP Engineering (from Sanford Dickert)
• Want to Know the Difference Between a CTO and a VP Engineering? (from Mark Suster)
• CTO vs VP Engineering: What’s the difference?

Image from Mark Suster’s blog on this topic

Both the CTO as well as the VP engineering should be part of the senior management team. To make this very tangible: In senior management meetings, the CTO will answer questions and bring up concerns related to the technology (e.g. technical vision around microservices, what technologies should we use, what’s the feasibility of certain new projects, etc.). The VP engineering should be able to answer questions related to people and process of the engineering group (e.g. who’s ready to become a team lead, what’s the status of projects across teams, why have certain aspects of the tech vision not been implemented yet, how can we improve communication with product managers, etc.).

DataCamp’s engineering group (by end of October)

We believe scaling a decentralized engineering team will work best if we ensure that:

1. Every Team Lead (TL) performs well and is held accountable: (i) the speed at which technology is being build (ii) the quality of the new tech.
2. There’s good communication between every TL and Product Manager (PM).
3. There’s enough coordination between groups at the engineering level, while maintaining a high level of freedom at the team level. I think the default should be that we delegate all responsibilities to the team level, unless there’s a really good reason not to do so. For example: teams should be able to chose their own technologies, but having decent API documentation for example is not a choice but a clear requirement.
4. A good infrastructure team enables the entire engineering group.
5. We keep teams small (say max 4–6). This will help combat 2 challenges:
   (i) We’re very open to remote work at DataCamp and think it’s an essential ingredient of our strategy to hire the best engineering talent. That said, communication becomes slightly harder when people are remote. It takes a really good people manager to manage a remote team of 10 people. Our current thinking is that it’s easier to avoid that situation altogether. As we want to be very flexible on remote work, the choice is to keep teams smalls.
   (ii) A lot of (our) software engineers don’t enjoy a lot of people management (and it often doesn’t come natural to them, so there should be little risk of micro-management anyway). Keeping teams small ensures a manageable amount of “management” for every TL on the one hand. On the other hand, it makes it easy to evaluate if a team is still performing well (you can just look at the delta in features and code quality over a period of time for a few apps).
6. We hire engineers with product feeling who can manage the fact that they’ll get ownership and be the end responsible for one or more apps fairly fast. This will remain a big challenge as we haven’t found a good way of testing for it (except for internships). We should filter as much as possible for people who have a demonstrated ability to self-manage and build projects independently. Furthermore, we should clearly set expectations that if people can’t self-manage and take ownership of an app, DataCamp is not the right company for them.

The VP Engineering at DataCamp

We’re very excited to welcome Filip Schouwenaars in this new role. He’ll be transitioning into the new role in the next few weeks. At a high level, we envision his key responsibilities in the next 6–12 months to be the following:

• Responsible for the engineering team (people)
  - Attract new talent:
  (i) Recruiting flows, coding tests, ..
  (ii) Key point of contact for HR
  (iii) Decisions in case people fit multiple teams
  - Retention of talent:
  (i) Make sure everyone is happy and aware of what their goals are
  (ii) Weekly one-on-ones with team leads
  (iii) Make sure people stay up to speed by going to conferences, etc.
  (iv) Resolve communication issues with product managers
  - Promote internal knowledge sharing:
  For example: initiatives like lunch & learn, etc.
• Responsible for the output of the engineering group
  - Make sure speed of execution remains high
  - Balance engineering priorities with product management priorities
  - Implementation of systems to ensure high code quality (testing, .. )
  - Ensure good practices around documentation, internal communication, etc.
• End responsible for execution of projects across teams
  For example: Gamification, moving to a complete microservices architecture, …
• Representative of the engineering group at senior management level