Students of computer science get taught, at places like Stanford and MIT, how to make things. But they don’t get taught — at least not in a traditional computer science curriculum — how to decide what to make. This is because, in the industrial model of work, they would not graduate into a world where they had much of a choice. They would work for a company that would tell them what to make.
But as software has gotten less expensive to make, so, too, has it become more entrepreneurial. We find ourselves responsible not only for building things, but for deciding what to build. And in doing so we face a question that we were not taught to answer in school: how do we decide?
- by Sep Kamvar in Make Space for Beauty
I’ve been thinking about teams, organization structures and focusing on what to learn in the months ahead. It is interesting to look around few more dimensions and evaluate if they fit in our framework.
Tools are the most exact amongst the pivots. We have been trained in this dimension in school. We will find languages, frameworks and patterns of problems. E.g. Scale problems, or react/redux and styled components. Computer science has codified the various kinds of problems we see in the world, and it teaches us specific solution aspects. We take the abstract thinking and apply to variations in real world.
Business is slightly more ambiguous. Problems and solution specifics in this area are not taught in engineering schools. Business thinking is not an inhibitor for the first 5-7 years of an engineering career. A learning opportunity comes our way with the choice to choose between engineer or manager career. We start thinking about economics of impact in this dimension.
Domain represents the problem context. E.g. productivity, communication, devops, security, compliance and so on. These are abstract and agnostic to solution space. It is unclear if we can create a business out of these problems. Domains are a choice. Each domain is a narrow and homogenous set of concepts. Too specific to be taught in general curriculum at schools.
Let’s come back to our decision framework.
As we grow in career ladder, it is important to shift focus from tools to business and further to a domain. The rationale is simple: people grow on the basis of the decisions they make around a given context. E.g. someone fresh out of college decides which algorithms to use. You decide which design patterns to use after a few years. Down the line decisions comprise quality, shipping, rollouts and which features to build. At this point, you have to choose: (a) decide which products to build, or (b) decide how to architect products.
Both these decisions have a significant impact on the cost of business and how we make money. Note that now your decision context has grown from a specific feature team to an wider organization. A generalist profile still works well at this stage. And it keeps getting harder here on.
Business sustains only in the constraints imposed by the domain. So the rules of
game in devops significantly differ from those in productivity and so on.
Decisions are not really codified. Deep expertise matters and is often
considered to be a function of years in the industry vertical.
We should take a stock of our circle of impact. Understand the kind of decisions we will be making in near future. Decide the domain/industry we want to stick to. Not surprisingly all this is hard. Job descriptions keep business or domain to two lines. Our product pitches start and end with kafka, internet scale, top notch security, react, no-sql etc. We have to make a mindful effort to get the big picture.