View: The Software System
There is a system of interacting people and computers that creates value for your employer. As a software engineer, your job is to improve this sociotechnical system so it nets more value.
Improving the system might mean writing code, but it might also mean:
- Reporting a bug
- Learning a new skill
- Teaching that new skill to someone else
- Configuring your development environment to make your work easier
- Rethinking how your team prioritizes and assigns tasks
- Studying the business domain you're working in
- Talking to stakeholders to clarify feature priorities
- Setting up a recurring meeting
- Canceling a meeting that's no longer useful
These are all examples of changes to structure that affect the system's behavior.
If /Software.html is structure that has behavior, then your organization is software, though it runs on people instead of silicon. Its code is the policies, Incentives, habits, and communication pathways that shape its employees' behavior. If no one engineers that system to work well, then—surprise surprise—it will work poorly.
Designing an organization's "software" is very different from creating software to run on a machine. Engineered systems of every kind must take into account the strengths and weaknesses of their materials, and humans and computers have very different strengths. So the success of an organizational design depends, crucially, on a recognition of the fact that people cannot be made to act like machines — Humans.html (ambiguous link).
Since the whole system, people and computers, is structure that has behavior, the economic points in StructureAndBehavior apply. Structure is what we can control, but behavior is what generates value. Our ideal should be to create more valuable behavior with simpler and more economical structures. For example, consider the CostOfMeetings.