Over my software career, I’ve built software apps and systems. As an engineering manager, I’ve noticed a pattern — a phenomenon. Teams get their work done guided by philosophies. This essay identifies this behavior, questions its origin, and how it’s a powerful force through repetition. Let me highlight an example next.
Recently, my team had a featured product heading to production. It was evident they needed to monitor the system before deployment. However, the goal was unclear. What are they optimizing?
Some weeks into it, I began repeating to the team that in monitoring, we should trace the customer’s pain throughout the system (the philosophy). We would tease out the essential artifacts of the customer that made sense in an digestible format (the framework).
Of course, there wasn’t a meeting stating this precisely, just informal discussions and natural consensus-building. A pattern was emerging, and it became the philosophy because of stickiness.
As work was underway, I’d test out the dashboard. The team readjusted when we discussed the SLAP principle. It was hard to reason what was on the screen because the context was mixed. Taking this feedback, the group split infrastructure health and customer pain.
What I learned is that principles (unchanging rules) help guide the philosophy and framework. Reevaluation is needed every so often. And the team continued to move it forward without the manager being there — they had agency.
In my opinion, this is a natural phenomenon of building software in teams. These types of events happened many times in my career. And the origins are difficult to pinpoint.
In my experience, teams desire a single direction, not directions. In software engineering, defining direction is difficult because the process is intangible. Software is a young profession, and there are many trade-offs. So how does one clarify an approach?
All people (the team, engineers, managers, architects, designers, and product managers) develop direction. Their path is summarize by multiple discussions between involved parties (engineers, leads, product people, designers, and stakeholders). Someone in the group will discover the philosophy and drive it. And that direction is an agreement between parties.
In my opinion, it is beneficial that the engineering manager steers this ritual. Taking on the work may be a no-no (such as building the framework); the last thing the team wants is a manager blocking them. In exchange, they can identify and rally the philosophy.
The environment in which we work and the constraints around us shape philosophies. We are optimizing for something. Knowing how to drive is where intuition is needed. The inputs are broad, but the software requires discreteness. Philosophy is theoretical and sticky, and the framework is practical and bedrock.
In the case above, we realized the items flowing through our pipes in a B2B system were constrained, leading to mapping customer pain on one monitor. Additional inputs came from the environment around us. One such example is heightened organizational sensitivity of observability throughout all systems — and the abundance of external support.
Philosophies crystalize delegation effectively because if a team believes in the ideaology, they will work furiously in that direction. Like software delegation, a team’s signature resolves by design. This design is the commander’s intent. Software engineering is often opinionated, so philosophies matter. The repeated statements are virtual commanders.
By stating the philosophy, every engineer in the team has a unified mental model. They work through a potential framework to satisfy it. And if there is disagreement, the philosophy needs to be retooled. Ideally, anyone on the team can reshape and re-delegate.
What are the origins of philosophies? They are sourced by those that aggregate knowledge. Member who have experience can bring forward a library of available pivot points.
In a previous role, my team would say, “let’s keep our apps as dumb as possible.” I realized this was a philosophy. It had an immense impact on qualitative construction through delegation.
And recently, I’ve had a conversation with an engineer about unit tests. What we realized is that the philosophy of testing our software had shifted. No longer was it about “every pull request has unit tests,” but it was “test to the design, not the implementation” — and that framework of integration tests made sense. The structure solved the problem faced by the engineers - in a monolith by the sheer exhaustion of dealing with over-engineered unit tests.
To the point, in software, philosophies appear portable and repeatable. I have a growing list discovered in each project. Only experience will unlock these opinions in the dimensions of technical, product, design, and meta (how teams do their work).
Finally, I’d like to leave with a thought about how I’ve seen software built. Metaphorically, someone in the group muttered something resoundingly impactful about plans in a software system. Without wood, hammers, and nails in the office, philosophy is a virtual foreperson and delegates in software engineering.
Philosophies and frameworks are born out of problems that need solving — an example is found on the Internet.
In a video, Louis Castle explains avoiding artificial idiocy (theory) and layering the edge cases (framework) to make an RTS (Real Time Strategy Game) pathing mechanic smart enough. As he explains subtly, "always tell(ing) people if you spend more time making sure it doesn’t do something stupid, it will look smart."
Those that believe in a way are repeating the mantra over and over again. This behavior is an example of the transmission of philosophical delegation..
War Stories on Command and Conquer
On how teams do their work in software:
- Teams get their work done guided by philosophies.
- Philosophy is Direction.
- A team's signature resolves by design.
- Philosophies appear portable and repeatable.
- Philosophy is a virtual foreperson and delegates in software engineering.
Thanks to Hazem Saleh
#effectiveness #teamwork #philosophy #softwaredevelopment