How do you explain technical progress to non-technical people?

[-]

UntestedMethod@reddit

You need to provide them a high level plan of the entire project - think in terms of broad-scope milestones.

The details are all inside those milestones. The non-technical stakeholders only need to understand each milestone enough to feel comfortable approving the time and cost proposal.

If you're unable of thinking about the project from different levels of detail, then I feel like you're probably not qualified to be in the role where you would need to do so.

[-]

CodrSeven@reddit

By tying it to improved financial/organizational outcomes, things they care about.

[-]

i just started using metaphors that sound slightly dumb but actually work. like "we rebuilt the plumbing so the water flows faster now" for a database migration. stakeholders dont care how, they care what it means for them. also learned to lead with the outcome not the work. "page loads are 2x faster" hits way harder than "we optimized 14 database queries"

[-]

dacracot@reddit

Yes. Analogies is the correct answer. Don’t jump around either. Pick an analogy and stick with it. Even briefly explain what you’re doing.

[-]

leeharrison1984@reddit

This is really the only way to bridge the gap without completely breaking their brain. I use construction analogies constantly to explain to stakeholders, and it gets the message across.

The one downside is the audience needs to understand whatever you are holding up as the example, but I find it lands in nearly all cases. If it doesn't, take a step back and try again.

[-]

MaximeGosselin@reddit

I prefer gardening analogies to construction ones because they normalize continuous change, make technical debt intuitive, and encourage a long-term maintenance mindset. That said, if a project is fully defined upfront with little expected evolution, the construction analogy can make more sense.

[-]

Wide-Pop6050@reddit

I'd give people more insight into the process than you think, but don't get too technical. "Since we are processing more clients we had to do XYZ data migration. New database is better because its faster for this type of data. Once we do the migration we'll be able to handle X amount of data per day". Or whatever. Explain whats going on in simple language and explain why you need to do it.

Also, sometimes taking a few stakeholders through the actual work you need to do can be extremely effective.

[-]

PoopsCodeAllTheTime@reddit

Reality is that you cannot. You can try to use an ELI5 perspective for anyone curious to know, but it’s like telling them a fictional story and expecting them to care. For all they know, it is completely fabricated

[-]

thatdudelarry@reddit

Lose the audience. Be overly technical. They'll stop asking for updates.

[-]

jl2352@reddit

You need to find ways to align the technical goals with actual user outputs. This is where user driven ACs come from. What is the real benefit this will have for the user? If it doesn’t, then why are you doing it? Either of those answers (showing the benefit or why you did it) is what you convey.

You also need to put timelines across and communicate them clearly. Ideally a roadmap of work, where the items take less than one update each. That way you will get something done between updates. If they don’t fit, cut it up more. If that doesn’t fit, fudge it (within reason).

Ideally you want to show last week’s roadmap, and then this week’s, and point to what has changed. That’s literally showing progress. People love that.

You also want to give reminders on the timelines you’ve given. I have started my updates with words to the effect of … ’last week I said this would take two weeks, and so we would have nothing to show this week. So this week, I have nothing to show.’ Worded better, but you get the point.

Remind people of the updates you’ve given. Then remind them again. It sets expectations and helps to preemptively push back on people asking awkward / annoying questions.

Finally find ways to get good at story telling for demos. This is culture specific. Ideally you do want to demo any progress, including implementing an API to non-technical stakeholders. But that is an art, as it can easily come across as boring technical nonsense with no value. You need to get across it does things, and does what is expected, the business-ey bits are done, and what’s left is visual. The details between that are irrelevant, and that’s where people often go wrong.

[-]

spoonraker@reddit

Going to be a bit blunt here, if you're explaining to your stakeholders what you've done only after you've done it, you're misaligned, definitionally. You're doing work you think they'll value, then trying to make up a story for why they should value it after the fact. This can "work" in terms of you not looking completely incompetent if you're really good at explaining and selling technical work, but it's a huge risk. At some point, your stakeholders are going to look up and realize that you're doing a bunch of stuff and getting paid for it, but you're not doing the things they actually want you to be doing.

You need to truly collaborate with your stakeholders. This means they need to be brought into the process right from the start. If you've identified something purely in the technical realm, and you can't explain to them how it effects them or the business or why it would be important to anyone ever, then guess what, you've just proven to yourself and your stakeholders why that thing isn't important.

Yes, I know this might seem like a surefire way to rack up tech debt and grind engineering to a halt. That's kind of the point though. Engineers need back pressure or every bit of tech debt becomes the boogeyman and a lot of engineering effort gets spent solving problems nobody cares about. Engineers, and I count myself among this cohort so I'm not immune to this, just love finding anything that seems even remotely conceptually wrong and instantly thinking it's the most important problem in the world. You simply need to stop doing this, and the way you do this is by actually bringing your stakeholders in early.

If your stakeholders are ever surprised by what you're working on or what you've already worked on, you're not collaborating enough. It really is that simple. Don't make unilateral decisions with your time and efforts. You have stakeholders. That's kinda the whole point. You still get autonomy, but autonomy doesn't mean you're the CEO, autonomy means you are trusted and influential when collaborating. Your opinions have weight, but you don't have the final say. If you earn this trust through effective collaboration you'll find a natural balance emerge in time where your purely technical debt concerns that might previously be hard to sell become naturally more respected, and you'll start developing a language through which to frame technical debt issues to stakeholders because you'll get reps in actually collaborating with them.

Best of luck!

[-]

rwilcox@reddit

I’m a big fan of making sure you match you message with your audience, but something I’m trying now is dependency graphs.

Technical thing A blocks thing B C and D, which block that customer feature you want. Color in completed nodes in this graph: don’t go into the details unless you’re pressed, but stakeholders can see the progress as the march of green=done goes towards the right in this graph.

If you’re at a very high level, then implementing customer feature A blocks customer feature B, etc etc towards the goal. (Yes, Bob, we need login to work before the dashboard has a user’s documents)

[-]

throwaway0134hdj@reddit (OP)

Yeah those would be helpful. Is there a particular tool you use to create those dependency graph?

[-]

Dry_Row_7523@reddit

Claude / cursor is specifically very good at generating graphs. When I’m writing technical docs or specs I always write the text myself (I hate ai-written text tone and it doesnt even save much time if any) but I get claude to help generate diagrams and charts.

[-]

rwilcox@reddit

Sometimes a regular minding tool (or Graphviz / PlantUML) out of my head, sometimes scripts that use marked dependencies from the bug tracker to generate Graphviz/PlantUML

[-]

throwaway0134hdj@reddit (OP)

Great thanks

[-]

couchjitsu@reddit

How does your doctor, lawyer, CPA, or mechanic explain technical things to you?

[-]

kevinossia@reddit

I just…explain it.

I add and remove details as needed depending on the audience. It’s a skill you learn over time.

[-]

Zulban@reddit

There's not a lot of respect among technical people for "education" and "communication" skills but that's exactly what this is.

I love how one of the top comments here starts with "I don't". You're not going to get enthusiastic communicators and educators in a developer community, generally. Maybe try asking a tech educator subreddit instead. That's what those communities are all about.

[-]

james__jam@reddit

Keep it high level.

Stakeholder: How’s the project?

Dev: we’re about 60% done and on time to finish by <date>

Stakeholder: what’s still left to do?

Dev: Functionalities A, B and C are still missing. D is now being tested. Also, we have tasks X, Y and Z that we still need to do (_i.e. Security review, perf test, etc_).

Also, practice with your lead or manager. Or somebody technical who usually talks to non-technical folks

[-]

TheOwlHypothesis@reddit

This is a core skill. You'll never not have to do this. And being able to do it well will move you forward in your career if you want promotions.

Think in terms of business impact. What do they care about? Why?

Honestly it's sort of a red flag if you can't explain this, because how do you even know what you're doing is relevant to what the company needs?

Take a step back and look at the bigger picture

[-]

CelebrationWitty3035@reddit

Show them a colorful sequence diagram. A picture is literally worth a thousand words. Nothing wins over non-tech management more than pretty diagrams or good-looking UI. None (or very few) of them care about the actual inner workings.

[-]

Recent_Science4709@reddit

Make your decisions with business value in mind and then explain the business value.

[-]

react_dev@reddit

You don’t. You explain how the technical progress gets you closer to the business progress

[-]

Altruistic-Bat-9070@reddit

Everyone is always complaining product owners or project managers are a waste of time but this is literally what they are for. They aren’t always good at their job, don’t get me wrong, but when they are all this admins gets taken off your plate and you can just deliver.

You need to be looking up product ownership tasks and mimicing the ones that will help.

[-]

Sulleyy@reddit

Break it into work items and assign estimates. Progress = completed work item hours / total hours estimated. There is no other way to track progress and whatever ridiculously complicated process they try to force in you will fail and eventually just become that again

[-]

FlowOfAir@reddit

Question for you. What do they care about? Have you outlined clear deliverables?

[-]

Bright_Aside_6827@reddit

They care about when snd what but not how

[-]

throwaway0134hdj@reddit (OP)

Speed, costs, that it does what they want.

[-]

TheTacoInquisition@reddit

They care about things like revenue, which is why they care about delivery and that it does something the customer (internal or external) cares about.

So break the technical roadmap into things you can launch. Don't talk about "we made the migrations to the database" talk about "we've finished data work that supports the doodad feature, which we're on track to deliver the first phase of on Thursday morning so we can test it internally on Thursday afternoon and get feedback".

If you have nothing deliverable, then I'd ask what you're building the things for in the first place TBH.

[-]

potatolicious@reddit

I'd dig one level deeper - what does speed/cost get them?

Also knowing what kind of non-technical stakeholder is helpful in these situations. Are these execs? Project managers? Other non-technical peers?

The key to managing this stuff is knowing how those stakeholders are themselves judged. Someone who is judged on if things land on time wants to know about timeline risk, for example, more than they want to know about revenue numbers. Your CEO or CFO on the other hand, cares a lot about revenue and costs, so worth highlighting major reductions to your hosting bill, for example.

You want to ground presentations in what the audience cares about, and what they themselves will be judged on. You also don't have to take their expressed preferences at face value - you should internalize their needs and give them what they need.

[-]

FlowOfAir@reddit

Then you talk to them in those terms. They don't care of the code optimizations or functions. Is the application faster? If so, by how much? How are you lowering costs? Are there new user facing features they should know about?

[-]

Eridrus@reddit

This is also why the industry has moved to delivering MVPs etc to stary with, so that you can deliver actual value sooner.

[-]

BillyBobJangles@reddit

Tie everything back to the outcome that they care about.

If they have requested a product that can do X, explain in general terms how what you did is needed to accomplish doing X.

Anything security or devops can be related back to money. We did X and that prevents us from this type of cyber attack that could have our data stolen and hit us with insane fines.

Or We did Y so now we can deploy features faster saving on development costs.

[-]

throwaway0134hdj@reddit (OP)

Agreed, wrapping everything around costs is super effective.

[-]

diablo1128@reddit

As people are saying you don't. Non-technical people don't care about the implementation details. You talk in high level generalities and give them the information they want to know.

This is usually if the project is on schedule and so forth. If something unexpected came up you let them know at the high level and how it affects timeline. That is to say you tell them something like "We had an issue with the API, but we have a a path forwards. This should only delay things by a couple days."

Frankly even as a SWE in a status meeting, the SWEs that go in to way too much detail about what they are working on looses me as well. People don't need to hear a play-by-play of everything you did in the last week.

I'm talking about the SWEs that say: I am working on X, but I had Y issue. I did A, B, C and found the issue. Now I will do Z, blah blah blah.

Maybe it's just me, but I literally don't care about all that detail as a SWE and a Team Lead. You had an issue and you found a path forwards, great! How is this going to affect they estimate you gave.

[-]

throwaway0134hdj@reddit (OP)

Yeah the first couple of times I did a demo I was literally brining bf up “for loops” Lol. Learning how to very high level explain and dive into details when needed is such a skill.

[-]

drnullpointer@reddit

I don't.

Here is the issue. If you want to talk to non-technical people, you need to talk about stuff they care about. If these are stakeholders, they do not care about what exactly you are doing, they care in terms of functionality being delivered, and when everything gets completed.

The only reason they might be asking is because you are not clear about the explanation of the progress, so they ask probing questions to judge it by themselves.

And frequently stakeholders do not actually ask it, it is the technical person that tries to volunteer those details. This is even worse, you are just getting these guys bored and/or confused.

[-]

throwaway0134hdj@reddit (OP)

Yeah I agree with this, they don’t care about technical details I tend to offer it, so I should just be showing everything visually? And high level explain it?

[-]

drnullpointer@reddit

That's what I do. We make a demo and show the changes that we made. We invite business people, but they are not required to come.

The demo has two parts, we start with functional changes and then we switch to technical stuff (like internal APIs, refactors, stuff that has no outside visibility) so that business people can vacate the call.

[-]

BanaTibor@reddit

You have to translate to their language, as you translate requirements into specification and jira items. So there is your statement, what you have actually done, ex. "we have upgraded the project to framework version X", and they would as why. So you ask yourself this "why" and formulate the answer. But they still will not understand. So you ask "why" again, formulate the answer again. When you think you have an answer which they would understand, go with that. Like "we have upgraded the project to framework version x, because only this new version provides the functionality which we need to deliver Y feature".
If your work solves performance issues or fix security vulnerabilities your job is far more easier. Usually even the most non-technical stakeholder has enough business knowledge to know why performance and security is important.

[-]

Outside-Storage-1523@reddit

Just explain things metaphorically. So there are two camps of tasks:

Camp 1: mostly just for the stakeholders, so this is a bit easier to explain because you have the context of why they are needed in the first place.
Camp 2: mostly just for yourselves, so this can be explained as "Making us more robust so that we can move faster", or "We have realized that such and such can reduce certain costs". Basically just dump words that they understand, like "fast", "cost", "reliability", etc.

You know, it's a bit like making loves. You have to let them hit some mini orgasms once for a while. Otherwise it is too dull.

[-]

Zeikos@reddit

You don't.
There's no point, they don't care anyways.

You talk about progress in general terms.
Is the work going smoothly and is it within the time estimates?
Was there something unexpected that came up that requires business-level discussion?

What I like to do is open up to questions, then ask a couple questions about their questions and then answer them.
By letting them ask you get an inkling about what they care about, by asking them questions you communicate genuine interest about their concerns, and it becomes easier to give a relevant answer.

Stakeholders couldn't care less about how the objective is achieved.

[-]

necheffa@reddit

It's a two way street and at a certain point the audience needs to understand what they are getting into and meet you halfway.

If they aren't will to do that, then your question is kind of pointless and you can just weaponize the "deer in headlights" as necessary.

Assuming good faith on both ends though, you can try to identify tangible milestones they would recognize and say "we are working towards X which will lead us towards Y". You don't have to give them the play by play but you can indicate if there are technical challenges, whether they were anticipated vs unexpected, and critically you want to be clear about if the team is stuck or just needs time to finish working through the solution.

This is also a great opportunity to point out any trade offs, clarify any questions, highlight any risks or needs that could cause problems for the project. Basically you have all these people in a room, none of them can pretend they didn't read the email you sent out 50 times.

[-]

dacydergoth@reddit

Personally I like the project maturity model from Rational. It defines a series of phases for projects like "Inception", "Elaboration", "Construction", "Delivery" and I like to add "Maintenance" and "Sunset". Each phase has a set of exit criteria which define the phase as being completed. Within each phase you can run agile cycles. Briefly, inception is working out what the project is and who cares, Elaboration is how you're going to architect it, including a golden path implementation, construction then is delivering the concrete implementation and delivery is getting it into production.

[-]

SnooGTI@reddit

I generally phrase that work as what it enables us to do. So, if it's IaC, finished CDK updates to enable us to build the infrastructure. Your technical stuff you're doing is to enable you to build the business their application. What is the technical work and what does it allow you to do later.