My goal: bring the idea of basic rules about systems. And nudge to think about the decision effects.
Audience: senior engineers, engineering managers, and product/project managers.
There are many overcomplications in the Tech industry regarding how to work well. There are too many “new” concepts, manyP bestseller books, many conferences and many talks with some “new” ideas. We think we missing something we run into it trying to implement things without going deeper into some basis. Let’s talk about the basis.
I draw some context: I am talking about not-so-small not-so-big teams focused on one product or project. A group of people should at least have a goal to be named a team e.g. for commercial: earn more money in the long-term. For non-commercial: make people happier.
Let’s little generalize our team word. Let’s talk not only about people, but about our product, processes in the company, code, and how everyone communicates. For simplicity let’s call mentioned things a System.
Will make two statements: Keep the complexity of our System as small as possible. Fewer people are involved, less communication is required for decision approval, and fewer steps for releasing with the same quality. Handle the feedback loop of our System as fast as possible. We want clients’ responses faster, and more often retrospectives of our processes and experience. So-called PDCA (Plan-Do-Check-Act Cycle). Original idea from Allen Holub1.
That’s some text with a footnote.
Let’s look to examples:
- We add new features to the product, we earn more money and also we increase technical complexity. The more features we add the bigger complexity we have to maintain and support.
- Removing feature, which seems working not so useful. Possible positive outcome: decreased technical complexity.Possible negative outcome: some clients may be relied on this feature and could be upset. Upset can be silent or can be with PR risks.
- We hired a new Product Manager. We increased complexity, we tried to hire him for a long time, and we spent our efforts. We onboarded him and he started to work, we have more long communications (more complexity) and then-then after a few months, we hope we get better results, earn more money, implementing better hypothesis.
We always have some Context in the current point. We have the morale of the team and current company communication links, the state of tech debt or tests in the codebase, and financial issues.
To be most effective, we can find the most complicated and painful things. For example, we have too many production incidents. How will we solve them? What are the reasons from the top level? What are the reasons which affect others? What suits us better in our case: more services alerting, more design reviews or more tests in dangerous places? Need to think and research what gives the most impact. Gives the most impact with our understanding of the current Context and plans. We can’t predict the future and often don’t know what we don’t know. And it’s okay.
To decrease overall and technical complexity we definitely need to educate the team. The whole team. Let’s imagine only one member of the team educates and become a senior. He is more productive and he might not delegate some simple tasks to members, without understanding the situation. He is started to be the bottleneck, with more tasks waiting for him, it’s a longer feedback loop. And we didn’t consider here the motivation of team members, who feel they are not growing and reducing their productivity or finding another job.
More examples are shorter which can be generally true, but can be false for some of the cases:
- Better communication in the team → less complexity, faster feedback loops
- Cross-functional teams → same
- The more open-minded atmosphere in teams → same
- Rational conflicts about solutions → same
- Implemented CI → same
- Do we bring without waiting for retrospectives → same
- Working and solving problems together for a better time to market → same
Finally, the idea we can derive from this basis many good appropriate decisions, e.g. Collaboration, Leadership, Self-ownership, Curiosity and many more. To find new approaches to solving, to get better understanding pros and cons of decisions, what effects what impact the current system will make.
Do I mention here the words DevOps, Agile, Scrum or Kanban? No, except for the previous sentence. But without these words, it’s difficult to sell and reason to other people. So you always can say it’s the Agile way. Unlikely someone catches you :)
Resuming again we can filter decisions with two principles: keeping complexity as small as possible and thinking about how we can handle feedback faster. Our decision might make some improvements to this or makes it worse, but we have to understand outcomes either positive or negative.
Systems thinking is essential. But, I've worked on very agile teams for decades—long before "Agile" was a thing—and most of those teams weren't thinking about systems. The key is: work small, release frequently, get feedback, adjust, repeat. Systems emerge to support that.
— Allen Holub (@allenholub) October 15, 2022
-
Original idea from Allen Holub: ↩︎
Comments & email subscription
wholesystems.substack.com
I’m Alex, a software engineer with technical and engineering management experience from startups to middle-sized and big-tech companies. Loves to make effective and friendly team processes.
You can freely drop a message to [email protected] or linkedin.com/in/aptakhin to greet and ask questions about any topic.
I’m also mentoring pro bono at meander.so/m/aptakhin