jamesmunns

Doing embedded stuff

Be nice, work hard. Build tools, tell stories. Start five year fights. Kein Ort für Nazis.


A list of all the other services I'm on around the internet


Posts with code highlighted with codehost by @wavebeem.


All posts licensed under CC-BY-SA 4.0, unless otherwise stated.


Today was kind of a tiring day, and had a project delivery I was pushing for, so no full text today for NaTeReMo.

(edit, this ended up being a decently long batch of mini-posts. oops.)

I figured instead I'd list out a couple of ideas bouncing around in my brain for next articles, because I have done no actual planning for this and am sort of flying by the seat of my pants.

Here's a couple shot/chasers for topics I want to write about, but don't know how yet.


Good systems engineering means thinking about people

A lot of systems engineering is in response to the fact that people make mistakes, and are fallible. Lots of the process is just trying to mitigate these common failure modes.

Also any time you have a "cross cutting concern" like system engineering, where you are working with many people, or even multiple teams: listening to people, having empathy, finding the problems they have, and the solutions that work for them, will make you much more effective.

Also also you almost certainly will find yourself in the face of "politics". You are asking people to do "extra" work, like writing/maintaining a spec, or following a process, etc.

(writers note: much like testing, this work is not generally "extra", in the same way that changing your oil or doing regular maintenance is not "extra". you might be able to skip it in the short term, but it will murder you in the long term, and it will cost more to fix later)

Systems engineering is about often about addressing the "system of people" that are building many smaller things, just as much as it is about keeping the "system of systems" that larger projects are, in motion.

Making changes in a team with no "systems culture"

This is one where I don't have great answers. I don't have a to-do list, or diagnostic tool, or templates for the parts I suggest

I can point people at the "pros" or "all the bells and whistles" approaches, like the NASA systems guide, or even formal frameworks, like EN61508 (for functional safety) or DO-178C (for avionics software development) that have more rigid ways of doing things.

But honestly, that's not super helpful for teams that need help now, and don't actually need all that formality.

I spend a lot of consulting time:

  • Figuring out where people are, maturity wise
  • Figuring out where people are struggling
  • Figuring out things to fix NOW
  • Figuring out what things to start incrementally improving over time

A lot of this depends on the project (domain and progress), the team, their knowledge, etc. I write a lot of guides and templates "on the fly", which end up being a sort of simplified version of more formal structures.

How to make changes "as an individual on a team"

As a sort of combo of the above two items, I pretty often talk to "individual contributors" who want to start improving things, but:

  • Don't know how to approach this
  • How to "sell" the need for change

Honestly, my job as a consultant is a bit easier here. I have experience helping teams with a pretty wide range of experiences, and know what stuff (typically) helps or doesn't, to get a best "bang for the buck". I can suggest things that pay off quickly, to get in a good improvement cycle.

Also, as a consultant, you get to exploit the fact that (for better or worse) the more a business has paid for someone's opinions, the more seriously they take those opinions.

It would probably be beneficial to write a "Guerilla Systems Engineer's Field Manual" for making changes incrementally from within an organization.

You can't system engineer yourself out of a dysfunctional company culture

This is more of a passion topic for me.

Sometimes people have problems because they've grown beyond their ability to solve certain problems of scale or complexity. These folks are great to work with, because they see the value of doing things in a slightly different way to make their lives easier. They might be a little stubborn to change at first, but usually are receptive to changes that bring value.

Some companies have other dysfunctions, that can't be systems engineer'd away. There are too many dysfunctions to list, but things like:

Companies where one team has an outsized influence on the whole project/company. Sometimes this is marketing/sales making changes at every stage of the project. Sometimes its management pushing for deadlines above all else. Sometimes it's an engineering organization that stubbornly refuses to change "how they've always done things".

Individuals who are just plain assholes. Again, assholes can exist in any part of the company. But when it becomes a blocker to making positive change, "routing around" them has diminishing returns.

Companies where everyone is chronically overworked. If there is no room to stop/slow down and improve, higher-impact improvements are nearly impossible to make, and even smaller improvements become much harder.

Again, as a consultant, I have some tools in my belt for dealing with problems like the ones I've listed above. Sometimes you can help the root cause, or "as a respected consultant", you can say the things that have been said before (maybe in a new way), and finally knock some sense into a dysfunctional org. Sometimes you can help one arm of the company, and hope the rest of it sees the value of doing things less dysfunctionally.

But if an organization decides it will stay dysfunctional, there is only so much improvement to be made.


This post is made available under the CC-BY-SA 4.0 license.


You must log in to comment.