All models are wrong

Forming thoughts on how to run Software Teams

November 08, 2021

Goal

I wish to produce a framework on describe how software development should be managed and its relationship to other departments in an organization. It will mainly be drawn from my experience and thus be biased, but I will try to challenge myself so that I avoid making blanket statement.

Guiding questions

  1. How to run software development, Waterfall, Kanban, Scrum
  2. How to run software research?
  3. How should Product and Engineering collaborate and engage?
  4. How should software development team report?
  5. How should software development team evaluate self?
  6. How should a tech company organize itself? (what is a tech company)

Core concepts

Software company

Let’s categorize Software Companies as companies that build focus on delivering value by building and operating Software Product.

Typical Process

Software company is a very broad categories, I will hereby arbitrarily define the key competency of Software Company as being able to iterate quickly to test different hypothesis.

Idea Generation

This is a creative process, sometimes people identify a problem that isnt obvious, sometimes people come up with a solution to a long-standing problem.

Creative process is difficult if not impossible to be converted into pure algorithm, but I think its worth to point out some conditions that can help:

  1. Good understanding on the business, this is obvious.
  2. Common understanding on the business among people, this might be less obvious, I hypothesize that cost of communication has a big impact on group’s creativity, they need to have enough of shared contexts to be able and willing to build ideas on top of each others, if sharing an idea requires sharing 20 other concepts as a pre-requisite, people will prefer to not talk about it or keep it to themselves.
  3. Willingness to challenge ideas, even from authority, good ideas withstand scrutiny.

Idea refinement

This is an operational process, it is more rigid and typically discipline is more important. We need to figure out how to convert the idea into actionable plan

My random thoughts

  • Efficient organization should be organized like clean code, leader should be able to use people like an API, where implementation details are hidden, and only results are reported back
  • Code architecture is more important than code style
  • Sometimes you have to make decision without all information you need, this is almost always better than not making decision
  • The fundamental benefits of software is that software is extremely malleable, and we should focus on flexibility when building software
  • Ability to write well is key to scaling engineering organization
  • Knowledge is one of the most important asset of a software engineering organization, organization should have a strategy to store, retrieve, and communicate knowledge, and code is NOT the best way

profile-pic
I like to talk about stuff I have no idea about. Sometimes I even write about them.