What’s the Most Important Artifact in Your Job?
As I reflect on my professional journey, I’ve identified key artifacts that have shaped my roles:
✨HW Design Engineer: The Schematic - foundational for effective design.
✨Safety Engineer: Safety Analysis - essential for identifying and mitigating risks.
✨Safety Manager: The Safety Plan - crucial for proactive risk management.
✨Process Engineer: Process Framework - vital for efficiency and consistency.
✨System Engineer: Requirements Specification - the backbone of successful project outcomes.
✨Safety Assesssor: Impact Analysis- critical for understanding potential implications.
Each of these artifacts has not only defined my responsibilities but also guided my decision-making and collaboration with teams.
What about you? What’s the Most Important Artifact (MIA) in your role?
Share your thoughts in the comments! Let’s learn from each other’s experiences and insights.🙌🙏
Interested in ‘big picture’ and connections
Retired from Rolls-Royce and offering ‘Systems Advice’ to help you understand Systems Engineering and / or your problem / system of interest - see
See the RBSystems website
I’d say for Systems Engineer it’s the SEMP - how the project / system development is going to proceed / be done applying the systems approach
Requirements, whilst I agree foundational, are only one artefact I’d Systens practice, and in many instances it is better to get the designers to do it (helped by SE) so they properly understand what is wanted / needed and ask all the important unasked issues
Validation criteria:I’m not the only one defining them but I put pressure to the team to ensure validation criteria are clearly defined and tracked. It may seem trivial, but extracting them from the non-functional requirements is quite challenging.
Without validation criteria you don’t even know what you’re developing.
How do you prioritize your engineering work?
It’s not always an easy question to answer.
Often, it’s dependent on a combination of many things:
-- Customer Priority
-- Emergencies
-- Quality Control Issues
-- High-Value Projects
-- Time Dependencies
The list goes on and on.
What’s important is focusing on the work that needs to be done to keep the projects moving forward.
Unfortunately, untimely things love to come up that get in the way of this “zone of genius” work.
And this leads to the hard question:
𝘋𝘰 𝘐 𝘥𝘰 𝘵𝘩𝘪𝘴 𝘯𝘦𝘸 𝘶𝘳𝘨𝘦𝘯𝘵 𝘵𝘩𝘪𝘯𝘨 𝘯𝘰𝘸, 𝘰𝘳 𝘴𝘩𝘰𝘶𝘭𝘥 𝘐 𝘸𝘢𝘪𝘵 𝘢𝘯𝘥 𝘨𝘦𝘵 𝘣𝘢𝘤𝘬 𝘵𝘰 𝘵𝘩𝘢𝘵 𝘶𝘳𝘨𝘦𝘯𝘵 𝘵𝘩𝘪𝘯𝘨 𝘐 𝘸𝘢𝘴 𝘸𝘰𝘳𝘬𝘪𝘯𝘨 𝘰𝘯 𝘣𝘦𝘧𝘰𝘳𝘦 𝘵𝘩𝘪𝘴 𝘯𝘦𝘸 𝘵𝘩𝘪𝘯𝘨 𝘥𝘦𝘳𝘢𝘪𝘭𝘦𝘥 𝘮𝘺 𝘥𝘢𝘺?
You could use Eisenhower Matrix to help rank the new problem.
But what if the new problem and your current task both rank as important and urgent?
I’d love to hear from experienced engineers and engineering managers on this one.
I know newer engineers will experience this more and more as their careers progress.
How do you prioritize your work?
I've just written up a detailed description of the weekly report practice that I've introduced at nearly every organization that I've been at. It's hands down the most effective tool in my entire engineering management toolbox.
It's a bit long, weighing in at 3500 words, but every time I tried to document the process in a short one-pager, I've had to answer the same questions multiple times verbally. So to save time, I wrote it all down.
I firmly believe that it's worth a read.
https://lnkd.in/e88Sx53c
How to deal when there are conflict between “insist on high standard” and “deliver result on time” ?
My way :
Generally you will have enough time to deliver on time with best quality by following engineering best practices.
But whenever there is conflict.
First : Make it work.
Second : Make it optimal.
Because nobody gonna appreciate your work, no matter how better you are implementing, if your system is not ready when needed.
PMs: Here's how to win over any engineering team you work with:
1) Be competent
2) Work to do your best work from Day 1
3) You do not know who they worked with before so realize there may be baggage
4) Get to know them and find your advocates on the team quickly (ie- getting buy in 101)
5) Care about their concerns and really listen
6) Be a constant voice for the customer and business interests, and make it clear that’s what you’re doing, not just blasting your opinions.
7) Know your data and customer interviews cold. The more you can cite them, the more credibility you’ll have and respect you’ll earn (relates to 6.)
8) Embrace it will take time to win some engineers over. Don’t take it personally.
9) Keep in mind some of the orneriest engineers will quietly respect you, but not show it other than by working hard on the next item you agreed on.
Building engineering progression - Part II
Examples, tips & pitfalls while building effective engineering progression framework for your organization
https://buff.ly/4fueymi (via @pdolega)
Highly effective yet under used principle...
All SE teams need a heavy dose of this:
KISS - Keep It Simple, Silly
Engineers get so attached to their work it’s impossible to see the forest from the trees.
Engineers “internalize the complexity”, as I like to say.
Brilliant and talented engineers push black boxes that the rest of us mere mortals on the team will fail to understand.
Complex, confusing and error prone processes are bestowed from high for us to “just figure out”.
All of it is a waste of time.
In all cases:
-provide visual diagrams
-automate when possible
-keep relevant code together
-share documentation and hand-off notes
Keep it simple. Your team is depending on you.
What else would you add?
Where have you seen unnecessary complexity?
Requirements Engineering Plans for engineers is not only unique in the market, it is already helping engineers to improve their daily work.
Many engineers face problems of the first steps.
They simply just don't know how to start and lose time....Thats usual.
Generating something to hate and improve it over time has always been the most suitable approach.
Starting from a point which was generated out of experiences from different world leading companies isn't the worst start to create a requirements engineering plan.
When even other folks from big companies in the automotive and tech industry buy the products, it proves that we offer the right things.
So here it is:
The Requirements Engineering Plan Template
https://lnkd.in/gajj4B39
Use it for your projects and tailor it for your purposes!
Systems Engineer - Eurodrone Program @ Airbus Defence and Space | Aspiring SE Expert | Model Based Systems Engineering (MBSE) | Aerospace & Telecom Engineer | M.Sc. in Systems Engineering | INCOSE | "Magic Engineering" |
Hi LinkedIners,
𝗡𝟭𝟭𝟱/365 Daily Posts #challenge
"𝗠𝗼𝗿𝗲 𝗧𝗵𝗮𝗻 𝗕𝗼𝘅𝗲𝘀 𝗮𝗻𝗱 𝗔𝗿𝗿𝗼𝘄𝘀: 𝗧𝗵𝗲 𝗘𝘀𝘀𝗲𝗻𝗰𝗲 𝗼𝗳 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴"
A few days ago, I came across a post that reminded me of a lighthearted moment in the office when I first joined my team as a Systems Engineer. Being new, I was explaining to some colleagues what I do and the tools I use when someone, in a friendly manner, joked:
"Ah, so you connect boxes with arrows!"
This made me smile because it’s not uncommon to hear this kind of comment about Systems Engineering or MBSE (Model-Based Systems Engineering). Of course, I took the chance to share what SE and modeling truly involve.
𝗦𝗬𝗦𝗧𝗘𝗠𝗦 𝗘𝗡𝗚𝗜𝗡𝗘𝗘𝗥𝗜𝗡𝗚: 𝗠𝗢𝗥𝗘 𝗧𝗛𝗔𝗡 𝗔 𝗧𝗢𝗢𝗟
For many (myself included before diving into this world), the scope of SE can be misunderstood. Connecting boxes and arrows is part of the process, but there’s so much more:
🔹 Understanding stakeholder needs and defining clear requirements.
🔹 Functional and physical architecture development.
🔹 Verification, validation, and ensuring the system achieves its goals.
🔹 Applying structured processes and frameworks to solve complex problems.
Modeling? It’s just one of the tools in the toolkit — a powerful one, but only a piece of the bigger picture.
𝗟𝗘𝗔𝗥𝗡𝗜𝗡𝗚 𝗔𝗡𝗗 𝗘𝗡𝗝𝗢𝗬𝗜𝗡𝗚 𝗧𝗛𝗘 𝗝𝗢𝗨𝗥𝗡𝗘𝗬
As someone still new to SE, I’ve been thrilled to explore each step, method, and tool in this field. Every day, I realize how interconnected and essential it is to approach problems systematically. It's not just about what tools you use; it’s about how and why you use them to create efficient, reliable systems.
💬 Have you ever faced similar misconceptions about your role or field? How do you explain what Systems Engineering truly means to others?
Let’s keep demystifying the amazing world of SE! 🚀✨
Thanks for reading, and here’s to reaching for the stars! 🌠✨
Stay curious, stay inspired, stay focused, and become Indistinguishable from Magic! 🚀🧙♂️✨
P.S.: Thank you for your insightful reflections, Alex Toth, CSEP! Truly inspiring and packed with valuable insights!
https://lnkd.in/dzcwhFDa#MagicEngineering#Systemist#LinkedIner#SystemsEngineering#MBSE#Tools#SysML#Challenge#Wizard
What are the 𝗣𝗶𝘁𝗳𝗮𝗹𝗹𝘀 𝗶𝗻 𝗺𝗼𝘃𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗰𝗲𝗻𝘁𝗿𝗶𝗰 approach to engineering to an 𝗠𝗕𝗦𝗘 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵?
My simple thoughts, 𝘢𝘴 𝘢 𝘴𝘵𝘢𝘳𝘵𝘦𝘳: ⤵️
Equating MBSE with drawing diagrams in a tool and SysML. Because only some architecture diagrams and maybe requirements are artefacts that find their way into the model.
It's much more than that in a organisational development model. Oh, and even that little is not consistent.
𝘛𝘰 𝘴𝘶𝘮𝘮𝘢𝘳𝘪𝘴𝘦:
"We are doing MBSE because we draw some diagrams in a tool."
Very similar to another one I heard previously:
"We are doing Systems Engineering b͟e͟c͟a͟u͟s͟e͟ ͟w͟e͟ ͟w͟r͟i͟t͟e͟ ͟r͟e͟q͟u͟i͟r͟e͟m͟e͟n͟t͟s͟ ͟i͟n͟ ͟D͟O͟O͟R͟S͟!"
Interested in ‘big picture’ and connections Retired from Rolls-Royce and offering ‘Systems Advice’ to help you understand Systems Engineering and / or your problem / system of interest - see See the RBSystems website
2moI’d say for Systems Engineer it’s the SEMP - how the project / system development is going to proceed / be done applying the systems approach Requirements, whilst I agree foundational, are only one artefact I’d Systens practice, and in many instances it is better to get the designers to do it (helped by SE) so they properly understand what is wanted / needed and ask all the important unasked issues