The Myth of the Tech Lead

One of the biggest early mistakes startups do is to have a “tech lead”, i.e. someone who does both the programming and the managing. The idea behind this is when there’s only 2–3 people, someone can simply be a part time manager.

Separation of Concerns

There’s a bunch of roles that go into tech:

1. Product: The link between tech and customers/users. They grab a wishlist from one end (marketing/users) and figure out whether it’s technically possible. They also deal with budgeting resources and try to make a best guess which features to release within that budget.
2. UX: Someone responsible to make sure that the user never see a tutorial. They make it clear to the user what’s going on before the user needs to ask. This job can’t really be outsourced as UX means understanding the product more than any set of principles.
3. UI: Someone who makes everything pretty and legible.
4. Architect: Someone who views things from a higher level, see what is done where. Let’s say you have a filter or search feature. Is this done on the app or on the server? Also things like spotting the bottlenecks.
5. Developer: Person who builds stuff. Usually one takes responsibility for their own platform, e.g. iOS developer, Android developer, web developer, back end developer, API developer.
6. Documentation/Analyst: Doesn’t necessarily have to write docs, but they have to make sure that everything is clear, that things do what they say they do, and everything is up to date. At early levels the code is self documenting, but when things get big enough, there is someone who you need to ask, “Where do I find the parameters for this API call?”
7. Tester/QA: They decide what the code should do. What exactly is a login? What are the conditions of logging in? Which logins should be rejected? They also make it clear to a client, if any, what the features are, in unambiguous terms.
8. CTO/Project management: The link between the tech team and the visionaries. They report to the outside how much it costs to build something, and when it will be done. They also need to request/manage other resources, monitor the project, update the timeline.
9. Scrum master: Someone who keeps everyone on time, almost to a daily basis. They keep the developers on the right scope. They also help manage accountability. For example, back end and hosting are accountable for a lot of things on the front end, and the scrum master helps to identify that.
10. Code quality: When you have a bunch of people committing code at the same time, even the best will commit critical bugs to the database. A second eye is needed to catch them.
11. Recruiting: Someone who is responsible for funneling and filtering new talent to the team.
12. Training/Mentoring: Someone who basically helps someone get unstuck, teaches them better tricks, improves the team as a whole.
13. Infra: Someone who manages the hosting side, CDNs, bandwidth, optimizing and monitoring use, and so on.
14. Devops: Someone who handles that pipeline from development to release, making sure it is smooth with as few bugs as possible.

Other people may split it up differently, but this is what I think works.

Managers and Makers

If you look at the list, it’s not all simple. So you can’t have a single tech lead doing every one of these. At best, I’d split it further into two types:

1. Manager — someone whose job is to handle communications.
2. Maker — someone who locks themselves in a room, and thinks a lot, free from all distractions.

Both of these roles directly conflict with one another. You can’t have someone who is constantly refreshing email producing quality code or wireframes. Some of these roles require weeks of meetings. It’s hard to get back into flow when you have something half done at 6 PM, then come back to it 4 days later.

But you can’t have a line of code pending approval for 2 hours just because the person who needs to approve it has blocked off all access to the outside world. Someone needs to make sure that the databases are constantly backed up, that everything is paid for, and deal with those sales people from some enterprise company trying to arrange Skype calls.

So, on a tight budget, I’d split it into two types… one who keeps development running and another person who’s dealing with people.

The one who deals with the customers is often the CEO. They have the best vantage point. They need to understand the product well and the roadmap, in order to pitch it or hire people. They can also easily approve budgets for external services.

You need at least one tech manager

On a team of 10, you might want one manager and 9 makers. But on a team of 3 tech, ideally there would be one manager and 2 makers.

It seems absurd — how much managing can this person do with only 1–2 subordinates?

This is where a lot of startups fall apart. When there’s nobody around to take responsibility for managing, anything involving communication falls apart. Suddenly you have a lot of undocumented code. Services are not being paid for. Or some critical part of the API is not done because nobody agreed that this was top priority.

You can expect developers to communicate with each other, but only to a certain extent. Everyone has their own accountability.

If I’m a tech lead and the sole Android developer, my 100% responsibility is on Android development, and I’m not as responsible when two team members don’t talk to one another. If the Android development is behind schedule, I’m just going to focus on my work first, and let the rest of the company catch fire.

Let’s say someone is responsible for hosting, back end development, and web development. They need to make sure all of these keep running.

But suddenly a junior app developer comes in who doesn’t know how to connect to the server.

The hosting guy is already overworked. He has no time to babysit. His job scope doesn’t cover training. He’s not accountable for the app side. So he shares some link to a documentation and gruffly tells the junior to figure it out herself.

But the documentation is out of date, even if the hosting guy wrote that code a few months ago. Nobody was accountable for documentation. She experiments with a lot of things but gets nothing out of it.

Eventually it turns out that the problem was a bug on the server access. But because there was no one in between to prioritize this problem, and the junior had nobody to ask, it was never sorted out.

tldr: Have someone responsible for managing, and make this their top priority.