<i>”My emails produced only well-worded refutations. They explained quite factually why the setup is the way it is, and implicitly therefore why it could not change”</i><p>This landed so truly for me,
it felt like a punch in the stomach.<p>I wouldn’t dare count the number of times I’ve been told the technical details of why something is the way it is, without anyone ever saying the reason why we actually wanted it to be this way. My thesis was usually:
<i>we don’t</i>.<p>In my career I feel like I have seen hundreds of examples of me saying the systems equivalent of “lets put the dining table indoors?” to be told that the dining table is outside because the original budget meant the front door could only be yay wide so we had to leave the table in the yard and put a tent over it. And I’m just left standing there agape at how we eat in a cold wet tent every night instead of fixing it.<p>Except it’s usually more like: why do we have to spend $9k on a commercial dishwasher repair contract? Because we have a commercial dishwasher … to get the rust off the silverware … because we eat outdoors every night … because the front door was too small to get the dining table in the house.<p>Somehow, when the real examples of this stuff are clever engineering around build / docker / polyrepo / release / feature flags / third party bugs, the cleverness makes people think the existence of the workaround should be tolerated. It’s infuriating to join a new team held hostage by years and years of band aids because they never suffer the bigger picture consequences.<p>The whole article was fantastic. I hope the author has the engineering leadership role they deserve. We need more people like this.
I work in a small organization which is kinda chaotic, meaning we have a lean process. Very agile, short standup each morning, but nearly no sprint planning.<p>I think, it's liberating to work in such a company as an experienced developer. You get difficult tasks sometimes, where you need to be the System Engineer and understand the system fully. But you're free to approach the problem in any way you see fit. This requires a lot of trust from the company and your team, but I believe that's a good thing.<p>It's also a nice for customers, who sometimes have crazy requirements, but they still get results in a reasonable amount of time.<p>On the other hand, this approach completely destroys newcomers. It's nearly impossible for them to approach a System which they can't fully grasp and is in constant flux. We mentor them, give them easy and introductory task, review their code, but still... It takes a massive amount of time. And I think, it's one of the reasons a company like this has a hard time growing.<p>And there's the risk of the 'not so competent programmer', who knows how to fix stuff, without thinking far enough.<p>I don't know, if I'm a System Engineer, but I think it aligns with the description in the article. However, I fear the day, we all agree to overhaul our processes, after which we need to plan and document and review everything.<p>It seems to be a necessary evil for a company to grow, but at the same time we would also destroy a lot of the liberty we currently have and I don't know which side is worse.
I work within an organization resembling this, and yet it has remained profitable for multiple decades. I forever wonder when the technical naked short options[0] will get called, but they never have in a serious way. My suspicion is that the chaos is S.O.P. among peer companies, so the market has never experienced a competitor not so hobbled. It may also be that controlling chaos is so expensive it's a non-obvious competitive advantage not to do so.<p>[0] technical debt is when you have a plan to pay it down. A technical naked short option is when your plan is to hope the subsystem goes away before its deficiencies have catastrophic effects.
> the curse of systems thinkers is to be correct, but never valued.<p>"Systems" are a mixed blessing, but system thinking is almost always
good and useful. We can add value but not bask in it. As a someone
invested in the _idea_ here are a few of my favourite quotes that
illustrate:<p>- People don't like systems. Especially new ones.<p>- Systems ossify and become the problem themselves.<p>- The ideal system exists only in the mind of its designer.<p>- The ideal systems designer is invisible and can never take credit.<p><pre><code> "I mistrust all systematizers and avoid them. The will to a system is a
lack of integrity." -- Nietzsche
"The English have a system, which is *no system*, which is also a
system, only better." - (?? British political philosopher c 1900 -
does anyone know this one?)
"A complex system that works is invariably found to have evolved
from a simple system that worked. A complex system designed from
scratch never works and cannot be patched up to make it work. You
have to start over with a working simple system" -- Gall
</code></pre>
Overall, I think the thing is that systems are brilliant, until you
try to actually build them and encounter _people_, who have other
ideas. Neither the force of the better argument, nor punishment,
reward, bribery, or flattery will move things. This is neither the
fault of systems thinkers nor people but the misunderstanding that
(outside the immediacy of war) systems can be imposed. Working
systems evolve and are, if the individuals are mentally healthy and
motivated by good attitude, generally such that people are doing the
thing they would naturally be doing anyway were a formal system not
there.<p>A good system is like cat that falls off a tall building and by luck
lands on its feet in a box of wool, and licks itself as if to say -
sure I <i>meant</i> to do that.
I think cross-discipline training is really under-rated and important. For instance, as a 3.5th year civil engineering student, I’ve been taught systems engineering and project management multiple times and in multiple different contexts. These are integral to ‘physical’ engineering, but seem (to me) to be missing from software engineering. I’m dabbling in programming and software eng now and I’m constantly surprised by the lack of standardisation and the sort of ‘wild west’ approach to things. This is fine for getting things done, but in terms of liability and responsibilities (like what the post talks about), it seems that many jobs are ill-defined and poorly scoped.<p>Overall, I think software and ‘physical’ engineers should swap experience. Physical engineering could use a tech-injection, and software could use a ‘structure’-injection.
Before clicking, I thought the article is about someone who only thinks in "system" and not able to deliver concrete things. How wrong I was.<p>"Give yourself permission to let the organisation fail".<p>I agree. As someone is similar situation, the job is to let the "design of system" be heard, be debated and be implemented once green-light. You cannot convince the decision making body (be it the CEO, management, or a design committee) that your idea is the right one for 3 reasons IMO<p>- idea could be wrong<p>- People won't know what you are talking about unless they had the first hand experience. (A la you don't know what it is like to be a bat)<p>- Your meritocracy is limited to a small group of decision making body<p>If you see the "system" broad enough, you will see a market. It is essentially preaching your "system" to a wider audience. Your system maybe wrong, for which your start up will die or you devise another system. Or you are reaching whole bunch of people who understands your (the initial niche), and your living does not depend on a single decision body but a market.<p>Convincing one body is hard, but broadcasting whatever you believe, some will respond eventually. This is why start up is great.
>Steve recommended investigating Systems Engineering as a distinct subject. Specifically, reading the engineering histories of the Gemini and Apollo projects, and especially about the culture clash between the experimental aircraft guys who built Mercury, and the ICBM teams.<p>Anyone know any good books covering this history?
Wow, this whole thing sounds exactly like me. I'm definitely at the stage where I've given the organization permission to fail and am just drudging on now.<p>I mean, the system I started working on 2 years ago was using a business text field for processing decisions. That caused changes to the system when the business wants to make changes. If they do make changes, the reporting queries have to be modified to look for all the historical versions of that text for audit reasons. If the team asking that change forgets to tell one of the numerous other systems that also uses that field, then there are errors. I proposed we add a field with a code that represents this field so that the business can change the display text without affecting the systems that currently use it. It's been at least 18 months, and nothing has changed. You would think that this is a basic design best practice that should have been implemented from the beginning...
This rang so true. I recently left a large multi-national aerospace company where I and my team had developed local processes that put systems engineering first.<p>Unfortunately our main contract was developing a component of a larger system being developed by our parent organisation who didn’t have a concept of systems engineering. We tried for years to educate them and I watched aghast as their program costs and schedule continued to spiral out of control.<p>Basically a bomb burst of engineers all doing what they thought was the right thing but no one owning the system design and saying no to good ideas.<p>In the words of their chief engineer “its like 10 different black boxes, I don’t know what I’m getting and I don’t know when it’ll be finished!”
There’s much to dive into here — ty — from Steve’s “Systems … where it is all about interfaces and trade-offs” to points you make throughout supporting his conclusion<p>> we define a stable interface
> reproduce behaviour reliably
> Predictability is great<p>Within being believed and valued for protecting engineers and organizations, so much progress applying these principles relies on individuals’ and teams’ readiness to adopt and advocate for them. Hope to see your experience with that in part II.
<i>[My colleague] would appear to see time spent in planning and writing documents as essentially wasted time, since he asserts that without process we are faster. We are not faster in reality. We are merely faster to say we're finished. That is not the same thing as actually being finished: we can all think of examples of that. And the uncertainty induced by the unknown magnitude of correction required is, IMHO, the biggest contribution to our inefficiency and ineffectiveness.</i><p>I've spent my entire career working for a medium sized organization and in the past few years it has tried to become "agile". Most of this push is predicated on the idea that we will be able to go faster this way. As a result we have deconstructed ourselves. What's weird is that now we aren't actually even "faster to say we are finished." No, now we are only faster to say that we are going to be faster to be finished. We still end up taking a long time but as long as the slide deck says we are going to be done in a short amount of time, then all is believed to be running smoothly. It's very strange/depressing/unsettling.
Systems thinking is great but he way we reason about organizations and systems in a pretty medieval way.<p>Most systems are described in a simple way: box and line charts which are just voodoo.<p>We need to develop a algebraic notation for how to represent the various configurations/states of an organization, along with its operations.<p>With a notation, you can describe what you “feel” and share the knowledge and improve on it. You can also define the organizations desired state and track your progress. You can plop a new manager in it and they will know what to do. You can also do basic engineering like pick a configuration that has the desired cost, throughout and latency that you need.
The author is Irish, and as an anglo-saxon who has lived in Sweden for the last 17 years, I can relate. We get more systems engineers in the Anglo-saxon world because in part because our education at university tends to be more generalist and also in part because of our more hierarchical organization does not involve everybody in decision making, so people at the bottom let their "mother hen" boss take more responsibility. In strong engineering cultures like Sweden and Germany, we tend to have more specialization and consensus building. There will always be systems engineers, but they are more prevalent in some cultures (anglo-saxon).
The most successful companies I have ever worked for hired smart developers and got out of the way. The least successful company I have worked for spent a huge amount of time in meetings, planning and documenting everything, while failing in the market place against competitors that didn’t. The more structure you impose, the less competitive you are. It is OK if you are a monopoly (NASA) but if not then be careful what you wish for.
Thought it was a post arguing AGAINST Systems Thinkers. Was slighlty provoked and curious to read it, since I’m a fan of systems thinking. Found out it was arguing FOR Systems Thinkers…
consider a slow-growth company free of a title system (e.g. where every engineer is just a "member of engineering"). the less-credentialed nature means you don't have to be as specialized to float ideas. the slow-growth nature allows the company to prioritize process over chasing chaotic payoffs to stay afloat. YMMV and i'm not sure all slow-growth, titleless engineering organizations turn out this way, but there's some correlation.
Added to <a href="https://github.com/globalcitizen/taoup" rel="nofollow">https://github.com/globalcitizen/taoup</a>
On the flip side: I am not saying this is the case with the author, but in my experience a great number of believers in systems and processes are people who struggle to solve any problem, and therefore want to have a system where most of the problems will be solved by the system. But that's not really possible, since if you struggle to solve a problem in any way, you will not be able to create a problem solving system, which is a next level problem. Systems thinking is a good idea, but at the end of the day, things need to be done by the people and this can be messy and chaotic, and people are different so making a system that works for everybody is impossible.