Category Archives: Management

The fractal box model of companies

Companies are boxes. Customer feedback and market data come in through one side of the box; employees come in through another side; product goes out a third side; and (hopefully) profits redistributed to shareholders go out the fourth side.

The company’s job is to make sure that it uses its two main inputs — its market understanding and its employees’ skills — to most efficiently produce its major outputs — product and profit.

You might think of the company box as being “thin” — opposing sides are close together — if the company’s product is  easy to produce. This can be correlated with, but is not the same as, the technical complexity of the product.

The company box is large if the company’s product is hard to replicate — either because it’s highly complex (Tesla), or because it has some other attribute, like a large userbase, that are hard for a competitor to gain quickly (Instagram).

The model is fractal. Departments and teams are boxes within the larger company box. They have a similar structure to the company box, including market intelligence about their customers (internal or external), a set of employees to produce their products, and their (hopefully positive) contribution to the bottom line.

Different levels of managers operate at boxes of different sizes. The CEO is responsible for the entire company box; a VP might be responsible for a large box that holds several smaller boxes inside it.

The key thing for each manager is to realize that their job is really to most efficiently produce their box’s outputs from its inputs.  Managers often define their role as simply the “human resources” part of management: performance reviews, 1:1s, skills development, etc. It’s easy to forget that if your box isn’t producing anything useful, you’re not doing your job, even if you’ve got the employee development part of your job down pat.

“Managing” a team really just means “being responsible for delivery” of that team, and while the human aspects of management are important, they are in service of the goal of creating the team’s product as efficiently as possible.

Advertisements

Straddling product and technology in large companies

Many roles at startups are for generalists. Most (good) startups want people who are interested in, and have ideas about, the product as well as the technology. This is partly because the product side of startups is generally immature — a consequence of not having reached product-market fit — and also because smaller teams make it easier for people to voice opinions outside the area for which they were hired.

As companies grow, this fluid movement between product design and implementation slows and becomes more formalized. Larger companies break down product development into product managers, who have responsibility for product spec, and engineers, who control how the product is built. Good product managers don’t try to influence technical decisions, and many engineers are uncomfortable providing opinions on user-facing product features.

For people who move from startups to big companies, it’s hard to find a role that provides the same mix of product design and engineering work that you might do as a founder or early employee at a startup. The roles have simply become too specialized to allow for hiring a single person with impact on both areas.

While some of this specialization is inevitable to allow the company to grow, I think the best teams have a strong product orientation among all team members, whether their job involves programming, QA, or product management. The more the team leadership can do to extract product opinions from everyone on the team, the more invested people will be in the final outcome.

I’ve found the following techniques work well to get even introverted team members to voice opinions about the product:

1. Regular free-form brainstorming sessions about the product. It helps if these are focused on a few product areas, identified in advance, that you are soliciting opinions on.

2. Team-based playthroughs or walkthroughs of the product. Many team members have a hard time seeing the product in its entirety, and are focused on their piece of the whole. It’s useful to get the team together on a regular basis to try out the product. For things like multiplayer games, you can have the team simply play the game together for an hour. For less social applications, one person can demo the product to the rest of the team.

3. Feedback sessions about product roadmap, hopefully before it is committed to outside the team. Providing a coherent vision brings the team together and gives people a shared goal that they can stand behind. It’s even better if the roadmap incorporates suggestions from across the team, for greater shared ownership of the product.

High performance teams

I had an interesting discussion with someone recently about what “high performance” means in the context of development teams. Specifically, I mentioned to this person that I thought I had been able to build a high performance team at my startup, to which he immediately countered: “So what do you mean by high performance?”

I had used the phrase somewhat casually, as though it was obvious what it meant, but I realize that the term can mean very different things to different people. Everybody’s trying to build (or be part of) a high performance team, but how do you get to one?

In my experience, a high performance team has the following characteristics:

1. Lightweight processes are enough to maintain progress. A light agile process may be sufficient.

2. Everyone has a rough idea of what everyone else is working on

3. Made up largely of generalists. Specialists may be necessary for some functions, but most engineers are comfortable working on the front end or back end, and artists can be given work as far apart as UI or character animation.

4. People are curious and eager to take on new challenges; they have the “get stuff done / JFDI” trait

When hiring, I generally found that what I call “context-free programming questions” were effective only as a base-level filter. These are questions that test the interviewee’s ability to write code on a whiteboard, often after thinking of an algorithmic solution to an abstract problem: “Write a function to print a matrix in spiral order”, “Write an iterator which implements the next operator for a binary search tree” etc.

Programming problems can serve to show that the candidate has a base level of programming ability. I’d generally ask Fizzbuzz type problems which are even simpler than the ones above — they helped weed out people who were out of touch with programming in general. For artists, I’d ask them to sketch a background on a piece of paper in 30 minutes; this assumes that drawing skills are highly correlated with digital art skills (which is generally true in my experience).

Questions more complex than this run into issues of people getting nervous and freezing up, or simply being unable to think of the right solution to the problem in a limited amount of time. Either way, there isn’t much point in trying to infer a person’s long term fit for a job from such a small set of observational data.

The most high quality predictor of productivity on the job that I’ve found for programmers is to ask them in detail about their past projects, preferably ones that they did as side projects.

I interviewed mostly people at or close to the start of their careers, where side projects are an indicator of whether they are curious enough to do things that are not strictly necessary to get their college degree.

Questions like the following are very useful:

1. Describe one of your side projects

2. How big was your team? What did you do, specifically?

3. Why did you pick this problem?

4. Why did you pick this set of technologies to implement this project?

5. What was the most difficult technical challenge in this project? How did you solve it?

6. Describe the most complex bug you had to fix. How did you debug it, and what did you do to fix it?

New questions naturally emerge from the candidate’s answers to these questions, and are a good way to further drill down into their experience.

If a candidate answers “I don’t have any side projects” to question #1, that’s a strong indicator right there (although it’s typically not sufficient to simply stop the interview there).

I found over time that refining these questions, and maintaining answers from previously successful hires as a benchmark, helped me get better at determining who to hire or not.