Iyfjky

Question

I work as a full-stack engineer. Often, a manager (non-technical) will ask, "show me what you've been working on", or "Show me a demo of what you are making".

Now, this is a problem. My general flow of work is as follows:

Hypothesize a theoritical solution to the problem

Research possible solutions and find those that fit our use case

Test out the researched solutions and see which one makes the most sense

Implement the functionality of the selected solution

Write unit and integration tests for the functionality

finally, tie it together with the user interface

However, if I am caught off-guard with this request, I could possibly have nothing physical to show because the physical component is the Last step in the process.

I get the feeling that if a manager comes in at that step, they get the impression that I have been slacking because I can not show them it in action. They usually just say "yeah, but when can I see it?"

At this point I feel very frustrated because it would be impossible to explain to him the depth of the solution and what I have been working on.

Is there a better way to handle this?

How long does your process normally take from start to end? Is your manager just showing up on short notice, or is it more like "can you show me a demo on friday"? — Aug 2 '16 at 17:46
usually, he tells me within 3 hours that he needs a demo. For more complex problems, the solutions can take about two or three days — Aug 2 '16 at 17:49
Just explain that to them - it's a 2 or 3 day problem, you've had 1 day on it already, and it won't be ready to demo for another day or two... — Aug 2 '16 at 23:32

Xavier J 26.3k104797 · Answer 1 · 2016-08-02 17:49:29Z

Doing a code walk-through will absolutely be a waste of your time. Trying boiling things down to a two-or-three page document, with a diagram or two, that summarizes your current work. Leave out technical jargon as much as you can. You just want to get the person into the "ball park" without exhausting yourself in the process.

It's perfectly okay to ask for a few hours' time to prepare a WRITTEN summary. Put an emphasis on WRITTEN, as this will help you to not keep repeating yourself (and becoming more frustrated at each turn). Make sure you're writing for (smile) an 8th-grade audience and by this I mean assume that the reader understands only basic concepts.

Best of luck.

score 4 · Answer 2 · 2016-08-02 23:58:59Z

Part of the work in doing something like this is to communicate what the user experience will be like. This often can be as important a part of the specification as the functionality. Moreover, it stimulates the domain expert users to think more deeply about their requirements and can direct you more accurately.

I am surprised that no one has mentioned creating "wireframes" or "mock-up" interfaces. There are tools specifically for this but it can be as simple as putting something together with a photo-editor. Mock-ups are done early in the project life-cycle so that users and developers have something in common to talk about. It keeps users from being blind-sided and encourages trust that you're all "on the same page."

I have found that taking the time to make mock-ups or even sketch drawings of a user-interface forces users (and me) to think about the problem being solved and alternative solutions. It often leads to discovery of edge cases, and even new functionality.

Saving the user interface for dead last is old-fashioned. You'll be more compelling if you can give your stake holders something they can see and reason about EARLY in the life of the project. That doesn't mean you have to implement the user-interface first. Just communicate one way or another what it will be like early in the process.

Wise answer. Communication is part of the job. Joel Spolsky made a well-known blog entry about it, long ago : joelonsoftware.com/articles/fog0000000356.html - he thinks that having an interface up-to-date with the rest is the best way to communicate to bosses. — Aug 3 '16 at 10:40
I don't think that this solves the problem - the manager wants to see an end product. — Aug 3 '16 at 11:50
I disagree, when a client see your end user working, he just will play the card why does it take so long to finish. Mock-up interface in this case can be definitively usefull, outside of testing process, in order to parallellize the work between multiple developers. — Aug 3 '16 at 12:48

score 3 · Answer 3 · 2016-08-03 11:47:37Z

When I am in that situation and a spontaneous presentation is required, I grab a pen and head for the whiteboard, then follow these steps.

I explain the general problem that I am trying to solve from a business perspective and emphasize why this is necessary.

I tell them that I have researched and analyzed different possible solutions, focusing on_ which one has the best ratio of cost to benefit_.

Here's an example: Using a key-value-store would be nice because it's fast, but all the other guys only know mysql and there is no sysadmin to help set up a Redis. You would be stuck maintaining it, and really the benefit is not great. It feels better, but we would have to grow about 500% before the mysql-solution would start being measurably slower.

All of that is the technobabble equivalent of saying that the database-driven solution is cheaper, more pragmatic one that can be implemented faster. Managers understand worlds like cheap, pragmatic and fast.

What you've actually done is basically a cost-benefit-analysis, just way more technical. All you tell them is the result.

Draw the process in a diagram, again from a business-perspective. The user is going to come from here. They do stuff. Data goes this way. There is a box here that does the new business logic. It talks this way to the database. There's an interface with our existing product. Don't get very technical. Usually they understand that there is a database somewhere. They've heard that before.

Knowing the process and being able to visualize it tells the manager that you've invested time to think it through. Making it user- or business-focuses helps the manager to follow the visualization.

Explain in which order you are going to build the parts in that diagram. Which ones are existing infrastructure. Which ones are new. Who is going to build which ones.

Explain what else needs to be done. Are there dependencies in other departments? Customer service will have to be told about that new button that customers might ask about, and you have already created tasks to do that once the new product is usable in testing.

Ask if they think you have forgotten anything. Give the manager the pen, let them draw into the diagram if they want to.

Tick off things that are already done in the diagram. Tell them which pieces are big and which are small. You don't need to give real numbers or estimates. Seeing the diagram and knowing that this box that is done was a lot of work, and there are three more squiggles left that each are small tasks gives a good overview without feeding into micromanagement.

This usually works for me. It doesn't have to be super-technical. The key is to appear knowledgeable. You need to give the impression that you know exactly what you are talking about. That way they understand that you are involved with the project and that you are making progress. The visualization helps to understand how far you have gotten.

Dan 4,752412 · Answer 4 · 2016-08-02 19:42:46Z

I find your scenario difficult to imagine. You're working on a very technical problem yet your boss is not technical or understanding of what it is you're working on?

It sounds like you might be working on nanotechnologies and your boss doesn't understand one thing about it. Why couldn't you say something to the effect of, "I am currently at stage X and I have Y to show. If you wait until Z I can show you A, B, and C?" Why does this explanation has to be so complex and difficult that it cannot be explained in any shape or form even at the hypothesis stage?

I also suggest putting in a issue tracker. That way your boss can see your progress and might know when something can be presented. You can say, "I have it in Jira and estimate it'll be ready in 3 weeks." He might not understand code but maybe he can understand a issue tracker.

Many corporate jobs have non-technical managers leading technical teams, or sometimes even primarly sales-type managers or service delivery managers whose primary job is not related to the actual technical implementations but more on being the contact point for the client and doing add-on sales. — Aug 2 '16 at 20:35
At some point there must be a technical type managed by a non-technical type unless the CEO is a technical type. The guy at the top of the technical hierarchy will be in this boat to a greater or lesser degree. — Aug 3 '16 at 22:56

keshlam 41.5k1267144 · Answer 5 · 2016-08-02 17:50:42Z

Show the prototypes, explaining why you feel a need to prototype/experiment rather than taking the first expedient solution as good enough while consulting literature/experience to screen out the inferior ones.

Remember that not everything needs to be optimized to death. Sometimes the thing to optimize is how quickly you can deliver a working solution.

And with experience, the ability to predict the algorithm's behavior for a data set should improve and the need to test should decrease, unless you are addressing a novel problem.

You could start looking at some agile strategies - schedule a demo every Friday afternoon, for example. That way, managers will know progress is being made, and hopefully you'll have less requests for demos interrupting your workflow. And like Keshlam said - it doesn't matter if the demo is a bit rough one week (as long as it's not broken), so long as it's more refined the next. — Aug 2 '16 at 23:36

score 1 · Answer 6 · 2016-08-02 18:21:29Z

it would be impossible to explain to him the depth of the solution and what I have been working on.

But that's precisely what you need to do. The problem you're having is that your managers think that they not only should be able to understand what you're working, but that they actually can and it's up to you to disabuse them of that notion.

You need to talk to them as you would another engineer and don't pause to explain anything. Let them interrupt you and ask you questions and then answer them in slightly less jargon until you get to a point where they understand or (more likely) give up.

The problem they're having is a lack of trust driven by a lack of knowledge. Most people don't like not knowing something, especially when that lack of knowledge forces trust. And therein they lose the feeling of control and in many cases, authority. In my opinion, you can't build trust directly, but you can build respect of your knowledge and abilities. I realize it might seem harsh, but they easiest way to do that is to remind them that you have the abilities they lack which are necessary to do your job.

I'm not suggesting to be anything but helpful and polite but I do believe you've probably been coddling them by dumbing it down. And when they ask you to back up your assessment, stand by it.

I find the first paragraph a bit condescending - not having a shared background doesn't mean that a manager cannot understand complex/technical issues. I agree with the rest of the answer, though. — Aug 2 '16 at 23:39
I strongly disagree with this answer. I have been able to explain really difficult, subtle bugs in prototype computer hardware to managers. Avoid unnecessary jargon from the start. Define and explain terms that will help with communication. Check that you are being understood as you go along, without waiting for questions. Good communication is much harder than blinding someone with jargon, but is likely to result in better management decision making. — Aug 3 '16 at 1:47

Mike Robinson 1,9021410 · Answer 7 · 2016-08-02 19:39:06Z

It is also a good idea to share your progress and your expected schedule.

For instance, in your OP you described your six-step workflow. Can you briefly describe (to him/her) everything that's in any one of those stages of completion? Can you predict when progress will next be made? And so on.

I don't think that you per se need to justify either your process or your progress: Â if they didn't already know that you are a great engineer, you wouldn't be there. But, you can provide an effective status report.

Be sure to keep in mind what the manager wants and needs; and, doesn't. An exhaustive technical explanation would be useless to him/her ... that's what you're there for. The manager is there to manage the project, to report status to superiors, and to be sure that you have what you need to do your job effectively.

HLGEM 133k25226489 · Answer 8 · 2016-08-03 14:17:21Z

While I agree with many of the answers, occasionally you run into someone who just refuses to believe that you have done any work unless they see a finished product. You have to remember that many non-technical people have no idea how much code it takes to produce a product. They think the final page in the application is the whole thing. So if there is no page, then no work has been done.

In that case, I inundate them with the code I have done and the documentation of the research I have done. After you have shown them that you have thousands of lines of code, hundreds of database tables you have set up, and hundreds of pages of research, they will leave you alone. The key to this is not to try explain the code or research step by step but just to show them how much of it there is and offer to go through it with them (they will generally decide they don;t really need to do this once faced with actual code which is completely mysterious to them).

Note this is a special case, you do not want to do this for the average non-technical manager, but only for the ones who refuse to believe you have done anything after multiple times of trying to explain at a non-technical level.

I have had to do this a couple of times when trying to fix a complex bug as well and the non-technical person doesn't get why you can't do it in five minutes.

Generally after they have seen the complexity of the code (which they do not understand so it is very intimidating to them), they start to learn to trust your judgement.

Xavier J 26.3k104797 · Answer 9 · 2016-08-02 17:49:29Z

Doing a code walk-through will absolutely be a waste of your time. Trying boiling things down to a two-or-three page document, with a diagram or two, that summarizes your current work. Leave out technical jargon as much as you can. You just want to get the person into the "ball park" without exhausting yourself in the process.

It's perfectly okay to ask for a few hours' time to prepare a WRITTEN summary. Put an emphasis on WRITTEN, as this will help you to not keep repeating yourself (and becoming more frustrated at each turn). Make sure you're writing for (smile) an 8th-grade audience and by this I mean assume that the reader understands only basic concepts.

Best of luck.

score 4 · Answer 10 · 2016-08-02 23:58:59Z

Part of the work in doing something like this is to communicate what the user experience will be like. This often can be as important a part of the specification as the functionality. Moreover, it stimulates the domain expert users to think more deeply about their requirements and can direct you more accurately.

I am surprised that no one has mentioned creating "wireframes" or "mock-up" interfaces. There are tools specifically for this but it can be as simple as putting something together with a photo-editor. Mock-ups are done early in the project life-cycle so that users and developers have something in common to talk about. It keeps users from being blind-sided and encourages trust that you're all "on the same page."

I have found that taking the time to make mock-ups or even sketch drawings of a user-interface forces users (and me) to think about the problem being solved and alternative solutions. It often leads to discovery of edge cases, and even new functionality.

Saving the user interface for dead last is old-fashioned. You'll be more compelling if you can give your stake holders something they can see and reason about EARLY in the life of the project. That doesn't mean you have to implement the user-interface first. Just communicate one way or another what it will be like early in the process.

Wise answer. Communication is part of the job. Joel Spolsky made a well-known blog entry about it, long ago : joelonsoftware.com/articles/fog0000000356.html - he thinks that having an interface up-to-date with the rest is the best way to communicate to bosses. — Aug 3 '16 at 10:40
I don't think that this solves the problem - the manager wants to see an end product. — Aug 3 '16 at 11:50
I disagree, when a client see your end user working, he just will play the card why does it take so long to finish. Mock-up interface in this case can be definitively usefull, outside of testing process, in order to parallellize the work between multiple developers. — Aug 3 '16 at 12:48

score 3 · Answer 11 · 2016-08-03 11:47:37Z

When I am in that situation and a spontaneous presentation is required, I grab a pen and head for the whiteboard, then follow these steps.

I explain the general problem that I am trying to solve from a business perspective and emphasize why this is necessary.

I tell them that I have researched and analyzed different possible solutions, focusing on_ which one has the best ratio of cost to benefit_.

Here's an example: Using a key-value-store would be nice because it's fast, but all the other guys only know mysql and there is no sysadmin to help set up a Redis. You would be stuck maintaining it, and really the benefit is not great. It feels better, but we would have to grow about 500% before the mysql-solution would start being measurably slower.

All of that is the technobabble equivalent of saying that the database-driven solution is cheaper, more pragmatic one that can be implemented faster. Managers understand worlds like cheap, pragmatic and fast.

What you've actually done is basically a cost-benefit-analysis, just way more technical. All you tell them is the result.

Draw the process in a diagram, again from a business-perspective. The user is going to come from here. They do stuff. Data goes this way. There is a box here that does the new business logic. It talks this way to the database. There's an interface with our existing product. Don't get very technical. Usually they understand that there is a database somewhere. They've heard that before.

Knowing the process and being able to visualize it tells the manager that you've invested time to think it through. Making it user- or business-focuses helps the manager to follow the visualization.

Explain in which order you are going to build the parts in that diagram. Which ones are existing infrastructure. Which ones are new. Who is going to build which ones.

Explain what else needs to be done. Are there dependencies in other departments? Customer service will have to be told about that new button that customers might ask about, and you have already created tasks to do that once the new product is usable in testing.

Ask if they think you have forgotten anything. Give the manager the pen, let them draw into the diagram if they want to.

Tick off things that are already done in the diagram. Tell them which pieces are big and which are small. You don't need to give real numbers or estimates. Seeing the diagram and knowing that this box that is done was a lot of work, and there are three more squiggles left that each are small tasks gives a good overview without feeding into micromanagement.

This usually works for me. It doesn't have to be super-technical. The key is to appear knowledgeable. You need to give the impression that you know exactly what you are talking about. That way they understand that you are involved with the project and that you are making progress. The visualization helps to understand how far you have gotten.

Dan 4,752412 · Answer 12 · 2016-08-02 19:42:46Z

I find your scenario difficult to imagine. You're working on a very technical problem yet your boss is not technical or understanding of what it is you're working on?

It sounds like you might be working on nanotechnologies and your boss doesn't understand one thing about it. Why couldn't you say something to the effect of, "I am currently at stage X and I have Y to show. If you wait until Z I can show you A, B, and C?" Why does this explanation has to be so complex and difficult that it cannot be explained in any shape or form even at the hypothesis stage?

I also suggest putting in a issue tracker. That way your boss can see your progress and might know when something can be presented. You can say, "I have it in Jira and estimate it'll be ready in 3 weeks." He might not understand code but maybe he can understand a issue tracker.

Many corporate jobs have non-technical managers leading technical teams, or sometimes even primarly sales-type managers or service delivery managers whose primary job is not related to the actual technical implementations but more on being the contact point for the client and doing add-on sales. — Aug 2 '16 at 20:35
At some point there must be a technical type managed by a non-technical type unless the CEO is a technical type. The guy at the top of the technical hierarchy will be in this boat to a greater or lesser degree. — Aug 3 '16 at 22:56

keshlam 41.5k1267144 · Answer 13 · 2016-08-02 17:50:42Z

Show the prototypes, explaining why you feel a need to prototype/experiment rather than taking the first expedient solution as good enough while consulting literature/experience to screen out the inferior ones.

Remember that not everything needs to be optimized to death. Sometimes the thing to optimize is how quickly you can deliver a working solution.

And with experience, the ability to predict the algorithm's behavior for a data set should improve and the need to test should decrease, unless you are addressing a novel problem.

You could start looking at some agile strategies - schedule a demo every Friday afternoon, for example. That way, managers will know progress is being made, and hopefully you'll have less requests for demos interrupting your workflow. And like Keshlam said - it doesn't matter if the demo is a bit rough one week (as long as it's not broken), so long as it's more refined the next. — Aug 2 '16 at 23:36

score 1 · Answer 14 · 2016-08-02 18:21:29Z

it would be impossible to explain to him the depth of the solution and what I have been working on.

But that's precisely what you need to do. The problem you're having is that your managers think that they not only should be able to understand what you're working, but that they actually can and it's up to you to disabuse them of that notion.

You need to talk to them as you would another engineer and don't pause to explain anything. Let them interrupt you and ask you questions and then answer them in slightly less jargon until you get to a point where they understand or (more likely) give up.

The problem they're having is a lack of trust driven by a lack of knowledge. Most people don't like not knowing something, especially when that lack of knowledge forces trust. And therein they lose the feeling of control and in many cases, authority. In my opinion, you can't build trust directly, but you can build respect of your knowledge and abilities. I realize it might seem harsh, but they easiest way to do that is to remind them that you have the abilities they lack which are necessary to do your job.

I'm not suggesting to be anything but helpful and polite but I do believe you've probably been coddling them by dumbing it down. And when they ask you to back up your assessment, stand by it.

I find the first paragraph a bit condescending - not having a shared background doesn't mean that a manager cannot understand complex/technical issues. I agree with the rest of the answer, though. — Aug 2 '16 at 23:39
I strongly disagree with this answer. I have been able to explain really difficult, subtle bugs in prototype computer hardware to managers. Avoid unnecessary jargon from the start. Define and explain terms that will help with communication. Check that you are being understood as you go along, without waiting for questions. Good communication is much harder than blinding someone with jargon, but is likely to result in better management decision making. — Aug 3 '16 at 1:47

Mike Robinson 1,9021410 · Answer 15 · 2016-08-02 19:39:06Z

It is also a good idea to share your progress and your expected schedule.

For instance, in your OP you described your six-step workflow. Can you briefly describe (to him/her) everything that's in any one of those stages of completion? Can you predict when progress will next be made? And so on.

I don't think that you per se need to justify either your process or your progress: Â if they didn't already know that you are a great engineer, you wouldn't be there. But, you can provide an effective status report.

Be sure to keep in mind what the manager wants and needs; and, doesn't. An exhaustive technical explanation would be useless to him/her ... that's what you're there for. The manager is there to manage the project, to report status to superiors, and to be sure that you have what you need to do your job effectively.

HLGEM 133k25226489 · Answer 16 · 2016-08-03 14:17:21Z

While I agree with many of the answers, occasionally you run into someone who just refuses to believe that you have done any work unless they see a finished product. You have to remember that many non-technical people have no idea how much code it takes to produce a product. They think the final page in the application is the whole thing. So if there is no page, then no work has been done.

In that case, I inundate them with the code I have done and the documentation of the research I have done. After you have shown them that you have thousands of lines of code, hundreds of database tables you have set up, and hundreds of pages of research, they will leave you alone. The key to this is not to try explain the code or research step by step but just to show them how much of it there is and offer to go through it with them (they will generally decide they don;t really need to do this once faced with actual code which is completely mysterious to them).

Note this is a special case, you do not want to do this for the average non-technical manager, but only for the ones who refuse to believe you have done anything after multiple times of trying to explain at a non-technical level.

I have had to do this a couple of times when trying to fix a complex bug as well and the non-technical person doesn't get why you can't do it in five minutes.

Generally after they have seen the complexity of the code (which they do not understand so it is very intimidating to them), they start to learn to trust your judgement.

Search This Blog

Iyfjky

Explaining abstract problems to non-technical managers

8 Answers
8

Your Answer

Post as a guest

8 Answers
8

8 Answers
8

Post as a guest

Comments

Post a Comment

Popular posts from this blog

White Anglo-Saxon Protestant

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

One-line joke

Category

Random preview

Explaining abstract problems to non-technical managers

8 Answers 8

Your Answer

Sign up or log in

Post as a guest

Post as a guest

8 Answers 8

8 Answers 8

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

White Anglo-Saxon Protestant

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

One-line joke

8 Answers
8

8 Answers
8

8 Answers
8