Layers of Design
I am not a designer. But I think about design quite a lot. Because things should be designed, even if I'm not the one doing it.
Most companies understand the value of design at the presentation layer. It seems sort of obvious that the ways in which people perceive and interact with a product are vital to the product's success. Whether that's a chair or a webpage or a lamp is somewhat incidental.
Some aspects of design seem rather arbitrary. Why is it that every piece of software puts the Okay/Accept/Continue button in a dialogue box on the right side of the modal window? And the Cancel/Stop/Don't Do This! button on the left? Is it because Apple wrote in their Human Interface Guidelines that this is the way to do it back in 1977? But Microsoft was also doing things the same way in very early versions of Windows. Was that a case of multiple discovery the way Newton and Leibnitz came up with calculus or the way oxygen was discovered at pretty much the same time by Priestley and Lavoisier?
If I knew more about design, it's possible that I would understand that these interfaces were modeled on some deep layer of human instinct or possibly on some older physical device interactions that were similar in some key way. But I don't know that.
It seems plausible to me that this was an arbitrary decision, but the need for uniformity of interaction demanded that a consistent standard be developed and enforced.
But consider something like a lamp. I'm also not a lamp historian, but it seems likely to me that the earliest version of a lamp didn't have a switch. You might have had to plug it in to the wall to turn it on and unplug it to turn it off. In that kind of a situation, a switch to turn it on and off isn't an arbitrary convention. It's a legitimate innovation that makes interacting with the lamp an objectively better experience.
These are both aspects of design that you could reasonably dump into the user interaction or user experience buckets. But they are fundamentally different approaches to design. One is maintaining a convention and status quo to avoid confusing people with a certain habit, and the other is a measurable improvement in the value of a thing. Now that I think about it, I might have just defined the difference between user interaction and user experience. I never really understood that before.
There's another layer of design—I won't say if it's higher or lower because I don't know. But it's a different layer. It's the layer I think Steve Jobs was talking about when he said, "Design is how it works." It's the layer that technologists are thinking about when we design software. How do you build a thing that's well-suited to solving a specific domain of problems? Answering that question is designing "how it works."
Many companies are also heavily invested in this. Software architecture is an important component of most tech companies, and this isn't usually a particularly hard sell . . . until you bump into how a company is designed.
Designing a company is yet a different layer of design, and it's a layer that most companies pay zero attention to. Especially startups.
There is an obvious conflict between intentionally designing a thing and having the freedom to be flexible about what the thing is. Companies need to be flexible enough to respond to market conditions, changes in competition, and supply chain fluctuations.
But companies need to be designed with the same care and consideration that web apps do. We all know the story of a company that starts out with a few cofounders, they build an MVP, get some clients, get some funding, and from there it's just chaos. Oh, we need a sales team now. Hire some salespeople. Oh we need more engineers. Hire some engineers. Oh crap, we aren't 6 people anymore. We're 50. We need managers because the cofounders are too busy to actually engage with what's going on. So you hire some managers. People are burnt out, they quit, there's contention between teams, lots of awfulness.
Some people call this growing pains and think of it as a natural part of the process of building a company.
I submit to you that this is wrong.
Companies need to be designed.
This is a hard thing to think about because when your company is very young there's no time to think about anything but product-market fit. It's bare survival. And once you figure out how to survive, you're too busy growing to think about it. I'm not unsympathetic to founders here. It's hard.
But I'm arguing that this layer of design is just as important as the presentation and architecture layers.
When you're 12 people and close-knit, titles don't matter. So you don't use them. You're building trust, product, and process. When you're 50 or 100 people a year later, all three have eroded without you noticing. It's a mess if you haven't designed your company.
What do I mean by design your company? I don't have a prescription that fits everyone, but I have a list of questions that you should answer as part of your design process.
Who is driving the product? Is it sales team? Is it a product team? Is it your engineers? Do you even want a product team? Is it always going to be the C-suite?
Related, what are the relationships between teams going to be? They could be front and backend, or it could be sales and developers, product and marketing, or supply chain logistics and developer relations.
What is the structure of management that you want in place at 20 people? 50? 100? 500? 1,000? People will get increasingly distanced as the organization grows. Design ways to keep key people in touch.
How do you expect employees to grow and progress over time? You need to design a career path, even at small companies. Good individual contributors don't automatically make good managers, and vice versa.
What processes do you have in place that support and enforce your mission and vision? Missions and visions and values are meaningless without intentionally designed processes that support them.
How are you planning to recruit? This also needs to be designed. Many prominent tech companies have kicked the can down the street by saying that they can't hire with diversity and equality because there aren't enough diverse and equal people graduating from CS degrees. That's stupid, but it's their argument. Is your company going to try something different? Break the pipeline? Hire women and minorities as apprentices and train them up? Great. Design that process. Just doing it with no plan is chaos.
What kind of management hierarchy do you want? Do you want small clusters of teams led by subject matter experts? Do you want departments and divisions led by directors? Again, it seems like a silly thing to ask when you're 12 people, but it is vitally important for companies to figure this out as early as possible.
Companies that aren't designed—that "evolve organically"—suck. Especially if you're a part of them while they are violently evolving. But a company can be designed to prevent that pain if the founders are willing to take the time to be thoughtful.
In VC-backed economies, the focus is always on explosive growth. But I think there is a way to design growth that is healthy and sustainable.