At one marketing-overrun startup, the suits were calling two hour meetings every afternoon and then wondering why I wasn't getting any work done.
So I installed a cuckoo clock in that meeting room. The CEO loved it; he even helped wind it. I knew I'd succeeded when one of the marketing types looked at the clock and said, "I hate that thing." I don't remember if the meetings got any shorter or less frequent, but they were a little more enjoyable.
[I invested some money in that place. They pulled some shenanigans, and my piece of a billion dollar company got zeroed out. But I still have the clock.]
Love it. A few years ago at a place I was helping out in, one of the devs had built a clock for the conference room that, at the start of a meeting, you punched the number of people in the meeting into. It knew the average company salary (this was a ~15 person software house) and would count up the "money spent" given the number of people in the room and the time on the clock. Very motivating.
The problem with the meeting (hourly rate | billable rate) × members × time cost approach is this: a well-performed meeting is what provides your worth. In this sense, considering a meeting to be a cost based on what you can charge for your time is as ridiculous as a professional sports team considering workouts and training to be costed at the average revenue rate of a game.
The training is what provides the ability to charge for admission and airtime royalties for games. The meeting is what gives you a product or service offering.
The question shouldn't be "how much is this costing us in salaries" but "is this meeting productive, and more productive than the alternative activity which could be performed at this time" -- the opportunity cost basis, in other words. Salary/billable is simply the wrong metric.
To the sports metaphor, the question concerning training would be "is this training improving our skills / ability / capability / teamwork", as compared with alternatives (rest/recovery, marketing, travel, game time).
Where meetings often get derailed is that participants:
• Don't understand one another.
• Have different agendas.
• Are simply incompetent.
Identifying these challenges and addressing them, without bogging all participants down in the process is far more productive than simply showing the cumulative pseudo-cost of the meeting.
Some of the comments here claim this is just showing how engineers think they are the only smart ones, or how there's equal frustration pointed back at engineers.
However, this is illustrating a particular problem that only[2] affects engineers -- engineers are the ones at the end of the day who have to make a solution reality. This particular weight doesn't fall on any other role. It's easy for anyone, including engineers, to misjudge a problem when simply talking about it. This makes non-technical meetings about technical problems particularly difficult.
But yes, it's true, every role has stereotypical flaws, and it's healthy to be able to laugh at them[1].
I wouldn't be surprised if accountants are also affected. There's something so excruciating about acting as a hypothesis checker for hours while the people in the room gradually develop the knowledge they need to solve their own problems because they don't trust you enough to delegate.
However, this is illustrating a particular problem that only[2] affects engineers -- engineers are the ones at the end of the day who have to make a solution reality.
That's not true. Almost every role is a specialty, and almost every role requires translating requirements from others who do not understand the solution space into solutions which meet that requirement, and explaining just what is possible and what is not. Just as one example, designers translate things like 'I need this text to read better' to adjusting the leading, measure, weight, size and font to something appropriate while meeting the other existing constraints. You could think of examples like that for almost every specialty, including designers, business people and accountants, who do things the developers don't understand (but might think must be trivial, because they don't understand them) which are just as vital for the company. There are also plenty of examples outside the fields developers interact with (engineers, architects, doctors, lawyers etc).
The meeting in the video wasn't funny as a caricature because it portrays everyone around the developer as idiots, though I suppose it is a brilliant unintentional caricature of the way an ignorant specialist might see the world. In real life, the clients are not idiots, they just have conflicting requirements, and don't understand the solution space, but they usually understand the problem space better than the developer and should be seen as a mine of information and gently guided away from making decisions they don't understand. A developer (or any other specialty) seeing the world this way is a bad developer IMO, and someone facing something approaching this situation in real life should just get another job, as clearly working for idiots is a losing proposition.
Back in real life, both design and development require very similar skills - refining requirements, proposing solutions which will work, persuading clients as to the best solutions, taking on board their ideas and adjustments gracefully without compromising the technical constraints. The issue of dealing with clients who don't know exactly what they want or what is possible is probably similar in a lot of other domains, and the laziest solution is to call them idiots and dismiss their concerns.
What I'd do in this situation is ask the client to rewind and state the problem (our lines clash and we can't change the colour or make them see-through), not a proposed solution (7 perpendicular red lines, one of which is green and transparent).
In a very meta twist, your comment reads with a slight undertone of "engineers are the only smart ones."
Engineers might end up with the keys to the servers, but many problems (and solutions to them) are not very technical. Things like the copy on landing pages, or customer support workflow, and many other problems businesses can face are only technical in that at one point an engineer will do something.
But it's not just engineers that have this problem. Designers can get them, marketers can get them , etc. Any opportunity for there to be cognitive dissonance will be exploited by Murphy's Law to make people's lives like this
> However, this is illustrating a particular problem that only affects engineers -- engineers are the ones at the end of the day who have to make a solution reality.
This is simply not true. In the past I was a Business Analyst. I would meet with clients to gather requirements and that illustration would often unfold in the same manner.
It has nothing to do with a persons role, it has everything to do with having large knowledge or expertise gaps.
I thought this was a very funny video, not because of the reasons you are articulating but because it underscores a very real problem, namely that people come in with unrealistic expectations and can't understand why they are unrealistic.
This being said, I don't think this is a problem specifically related to engineers. I think it affects nearly every specialist who is tasked with a vital role outside of the general knowledge. Accountants, particularly cost accountants, would be my second thought for a profession that must be in a similar position.
Doctors and lawyers also come to mind.
In the end, I think it is funny because the problems are framed in a way we specifically can relate to, not because the problems uniquely affect engineers.
I'm sorry, but it actually effects anyone who is in individual contributor. Even with the caveat for "a work pipeline involving engineering". Linguists doing translation run in to it, designers run in to it, document writers run in to it, even individual sales folks run in to it.
engineers are the ones at the end of the day who have to make a solution reality
That's rarely true. More often than not engineers hand off their plans to lowly underling programmers/technicians/builders/craftsmen who are the ones who actually have to make thing a reality.
Moving beyond the exaggeration of the sketch, the irony here is that being the only engineer in a business meeting puts you in an incredibly powerful position - if you see the opportunity and know how to take advantage of it.
Learning to interact with non-technical stakeholders and finding ways to deliver solutions perceived as adding value to a business is one of the best ways to make real money in this industry. For the average person, it is quite literally the difference between making $150,000/year as an employee "engineer" and practically as much as you'd like on your own terms/as your own boss.
Absolutely. And it's not just a powerful position, it's an extremely important one.
Some engineering teams so effectively resist meetings that they worm their way right out of any decision making beyond "how do we deal with the mess we've been handed THIS time?"
That's a very inspiring way to put it. For balance, I'll put out here that being the only janitor in a building also puts you in a position of power, and learning to interact with the stakeholders should be invaluable.
If you truely believe everything is an opportunity, being an engineer or janitor should be on a similar footing (there's actually janitors that build companies and set their prices)
Glad to see this finally making it on the front page. I'm particularly impressed with the actors' ability to capture the subtle facial expressions and other mannerisms that the various characters tend to make in real life under various situations.
PHB: "That's it. Now you've confused everyone. So what exactly is stopping us from doing this?"
Anderson the Engineer: "Geometry."
Client: "Just ignore it."
PHB: "We have a task. Seven red lines. It's not 20. It's just seven! Anderson I understand you're a specialist of a narrow field; you don't see the overall picture. But surely it's not a difficult task to draw some seven lines."
Walter the PM: "Exactly! Suggest a solution. Now, any fool can criticize --no offense-- but, you're an expert. You should know better."
I agree that this bit is fantastic. Can't count the number of times I've encountered each one of these tropes. The power of positive thinking will allow us to do the impossible and so on.
"Why", or "what do you want to do" are two of the most useful questions in my arsenal. Often a client (or user you're trying to assist) is 2-3 steps past their initial requirement when they ask for some technical solution. Backtracking to the base problem often suggests a far more useful and viable approach.
The video sketch shown here isn't so much an illustration of what it's like to be the only technical person in a meeting as it is one of what happens when you put technical and nontechnical types together with no way of establishing a common language and understanding. The project leads and/or engineer are incompetent.
Agreed. Many times when you are approached with nonsensical requirements it is wise to try to figure out what problem the asker is trying to solve. This is doubly true when you receive technical requirements from non-technical people.
Stupid engineer...just draw the thing in an 11-dimensional space, and he would have gotten transparency and perpendicularity. No wonder he got talked down by management.
My comment when someone posted this on Facebook earlier today-
"Although... A true engineer would know how to solve the problem of 7 perpendicular lines. And a master corporate engineer would get the budget for developing 7 perpendicular lines. Actually, that more or less explains defense contractors"
There is no mention of engineering in the original short story. I think it's more general, it's about being the guy who will do the actual job versus all people who manage this guy.
This video highlights two separate problems: unacceptable behavior, and ignorance. One should never sneer at one's coworkers, or openly mock them or undermine them. Doesn't matter if it's an engineer or a janitor, in my view. No-one should put up with being treated like that, ever, and I think you'd be better off just quitting, on the spot.
The matter of the project ignorance is itself is another matter. When faced with well-meaning but confused stake-holders, the correct solution is not to throw errors like a compiler (which is what the eng in the video does), but rather to probe for more information to understand the context of the request, and work toward a workable solution. Ignoring line ink and geometry, step back and ask: where will these lines be drawn? Who will see them? What information are they trying to convey? Of course, these are the same questions that would ruin the conceit of the sketch, but that's the solution to this riddle.
I've been the only engineer in meetings often. At one company I regularly attended senior staff meetings (President, CFO, VPs, etc.). I observed all the traits and foibles one might expect in a Dilbert cartoon strip. During one heated discussion they were arguing over the implications of some data that one of them had drawn on a graph; I had to walk over to the whiteboard and explain that the reason they couldn't interpret the data was that they had reversed the X and Y axes on the chart!
1) In Hollywood they draw red ("blood") lines with transparent inc all the time.
2) There is no problem to draw 7 mutually perpendicular lines as long as lines are not straight. Moreover, clients never asked for mutually perpendicular lines.
There are other solutions too, such as 7-dimensional space and imaginary lines.
The "expert" looked quite inexperienced when he started his answer with "No".
True, but to take the silly video, and mix in a real issue with meetings like this, we've got a problem of terminology. In standard geometry, a line, by definition, is straight. Of course we can't assume the way other people are using words agrees with our own technical definitions, so I think you solutions are reasonable.
Awesome.. I have a similar situation regarding the project manager in the video :) we have a small team of 5 members and i don't think we need a "project manager" considering only 5 members working on a not-so-big project and the team members are efficient enough to self manage.
I dont think a small project with a small team even needs a project manager.
I was shocked when no one drew that lesson from our international corporate hackathon. We were cranking out impressive new products in less than twenty-four hours without a single PM.
Granted, it's a sprint requiring downtime afterwards and everyone was doing what they really wanted to do instead of their day jobs.
I've been in this meeting myself. The situation is nicely rendered in a scene[0] from Cryptonomicon in which a main character feels like a dwarf among hobbits.
This shouldn't be too hard. Just draw lines in 7 dimensions and accellerate them away from the viewer such that the color shifts so it is red. in fact, you only need to do three, because the other four can be discussed as being drawn in transparent ink and aligned in higher dimensions.
[+] [-] kabdib|12 years ago|reply
So I installed a cuckoo clock in that meeting room. The CEO loved it; he even helped wind it. I knew I'd succeeded when one of the marketing types looked at the clock and said, "I hate that thing." I don't remember if the meetings got any shorter or less frequent, but they were a little more enjoyable.
[I invested some money in that place. They pulled some shenanigans, and my piece of a billion dollar company got zeroed out. But I still have the clock.]
[+] [-] zorpner|12 years ago|reply
[+] [-] dredmorbius|12 years ago|reply
The training is what provides the ability to charge for admission and airtime royalties for games. The meeting is what gives you a product or service offering.
The question shouldn't be "how much is this costing us in salaries" but "is this meeting productive, and more productive than the alternative activity which could be performed at this time" -- the opportunity cost basis, in other words. Salary/billable is simply the wrong metric.
To the sports metaphor, the question concerning training would be "is this training improving our skills / ability / capability / teamwork", as compared with alternatives (rest/recovery, marketing, travel, game time).
Where meetings often get derailed is that participants:
• Don't understand one another.
• Have different agendas.
• Are simply incompetent.
Identifying these challenges and addressing them, without bogging all participants down in the process is far more productive than simply showing the cumulative pseudo-cost of the meeting.
[+] [-] badusername|12 years ago|reply
[+] [-] chavesn|12 years ago|reply
However, this is illustrating a particular problem that only[2] affects engineers -- engineers are the ones at the end of the day who have to make a solution reality. This particular weight doesn't fall on any other role. It's easy for anyone, including engineers, to misjudge a problem when simply talking about it. This makes non-technical meetings about technical problems particularly difficult.
But yes, it's true, every role has stereotypical flaws, and it's healthy to be able to laugh at them[1].
[1]: http://i.imgur.com/YiuSeRE.png
[2, edit to address comments]: Only affects engineers, of all the roles in a work pipeline involving engineering.
[+] [-] gatehouse|12 years ago|reply
[+] [-] grey-area|12 years ago|reply
That's not true. Almost every role is a specialty, and almost every role requires translating requirements from others who do not understand the solution space into solutions which meet that requirement, and explaining just what is possible and what is not. Just as one example, designers translate things like 'I need this text to read better' to adjusting the leading, measure, weight, size and font to something appropriate while meeting the other existing constraints. You could think of examples like that for almost every specialty, including designers, business people and accountants, who do things the developers don't understand (but might think must be trivial, because they don't understand them) which are just as vital for the company. There are also plenty of examples outside the fields developers interact with (engineers, architects, doctors, lawyers etc).
The meeting in the video wasn't funny as a caricature because it portrays everyone around the developer as idiots, though I suppose it is a brilliant unintentional caricature of the way an ignorant specialist might see the world. In real life, the clients are not idiots, they just have conflicting requirements, and don't understand the solution space, but they usually understand the problem space better than the developer and should be seen as a mine of information and gently guided away from making decisions they don't understand. A developer (or any other specialty) seeing the world this way is a bad developer IMO, and someone facing something approaching this situation in real life should just get another job, as clearly working for idiots is a losing proposition.
Back in real life, both design and development require very similar skills - refining requirements, proposing solutions which will work, persuading clients as to the best solutions, taking on board their ideas and adjustments gracefully without compromising the technical constraints. The issue of dealing with clients who don't know exactly what they want or what is possible is probably similar in a lot of other domains, and the laziest solution is to call them idiots and dismiss their concerns.
What I'd do in this situation is ask the client to rewind and state the problem (our lines clash and we can't change the colour or make them see-through), not a proposed solution (7 perpendicular red lines, one of which is green and transparent).
[+] [-] rtpg|12 years ago|reply
Engineers might end up with the keys to the servers, but many problems (and solutions to them) are not very technical. Things like the copy on landing pages, or customer support workflow, and many other problems businesses can face are only technical in that at one point an engineer will do something.
But it's not just engineers that have this problem. Designers can get them, marketers can get them , etc. Any opportunity for there to be cognitive dissonance will be exploited by Murphy's Law to make people's lives like this
[+] [-] whyme|12 years ago|reply
This is simply not true. In the past I was a Business Analyst. I would meet with clients to gather requirements and that illustration would often unfold in the same manner.
It has nothing to do with a persons role, it has everything to do with having large knowledge or expertise gaps.
[+] [-] einhverfr|12 years ago|reply
This being said, I don't think this is a problem specifically related to engineers. I think it affects nearly every specialist who is tasked with a vital role outside of the general knowledge. Accountants, particularly cost accountants, would be my second thought for a profession that must be in a similar position.
Doctors and lawyers also come to mind.
In the end, I think it is funny because the problems are framed in a way we specifically can relate to, not because the problems uniquely affect engineers.
[+] [-] cbsmith|12 years ago|reply
[+] [-] dagw|12 years ago|reply
That's rarely true. More often than not engineers hand off their plans to lowly underling programmers/technicians/builders/craftsmen who are the ones who actually have to make thing a reality.
[+] [-] 7Figures2Commas|12 years ago|reply
Learning to interact with non-technical stakeholders and finding ways to deliver solutions perceived as adding value to a business is one of the best ways to make real money in this industry. For the average person, it is quite literally the difference between making $150,000/year as an employee "engineer" and practically as much as you'd like on your own terms/as your own boss.
[+] [-] harlanlewis|12 years ago|reply
Some engineering teams so effectively resist meetings that they worm their way right out of any decision making beyond "how do we deal with the mess we've been handed THIS time?"
[+] [-] canadev|12 years ago|reply
[+] [-] hrktb|12 years ago|reply
If you truely believe everything is an opportunity, being an engineer or janitor should be on a similar footing (there's actually janitors that build companies and set their prices)
[+] [-] aspensmonster|12 years ago|reply
Direct YT link: https://www.youtube.com/watch?v=BKorP55Aqvg
============================================================
My favorite bit...
PHB: "That's it. Now you've confused everyone. So what exactly is stopping us from doing this?"
Anderson the Engineer: "Geometry."
Client: "Just ignore it."
PHB: "We have a task. Seven red lines. It's not 20. It's just seven! Anderson I understand you're a specialist of a narrow field; you don't see the overall picture. But surely it's not a difficult task to draw some seven lines."
Walter the PM: "Exactly! Suggest a solution. Now, any fool can criticize --no offense-- but, you're an expert. You should know better."
[+] [-] zenlikethat|12 years ago|reply
[+] [-] jacalata|12 years ago|reply
[+] [-] sikhnerd|12 years ago|reply
Find out pretty quickly (generally) what they are actually wanting and nobody needs to print things in transparent ink... (usually)
[+] [-] dredmorbius|12 years ago|reply
The video sketch shown here isn't so much an illustration of what it's like to be the only technical person in a meeting as it is one of what happens when you put technical and nontechnical types together with no way of establishing a common language and understanding. The project leads and/or engineer are incompetent.
[+] [-] mbillie1|12 years ago|reply
[+] [-] McGlockenshire|12 years ago|reply
http://en.wikipedia.org/wiki/5_Whys
[+] [-] cpeterso|12 years ago|reply
[+] [-] Karunamon|12 years ago|reply
http://www.morna.nl/post/4185018780/a-business-meeting
[+] [-] lam|12 years ago|reply
[+] [-] waterlesscloud|12 years ago|reply
"Although... A true engineer would know how to solve the problem of 7 perpendicular lines. And a master corporate engineer would get the budget for developing 7 perpendicular lines. Actually, that more or less explains defense contractors"
[+] [-] GeneralMayhem|12 years ago|reply
[+] [-] kazagistar|12 years ago|reply
[+] [-] peter_l_downs|12 years ago|reply
[+] [-] vayarajesh|12 years ago|reply
[+] [-] jdubs|12 years ago|reply
[+] [-] dstroot|12 years ago|reply
Why? Because "impossible feature request" can and does happen... frequently.
[+] [-] morkfromork|12 years ago|reply
[+] [-] malandrew|12 years ago|reply
http://en.wikipedia.org/wiki/Poincar%C3%A9_disk_model
(credit goes to my coworker dmvaldman)
[+] [-] nolite|12 years ago|reply
[+] [-] MonsieurHoho|12 years ago|reply
[+] [-] javajosh|12 years ago|reply
The matter of the project ignorance is itself is another matter. When faced with well-meaning but confused stake-holders, the correct solution is not to throw errors like a compiler (which is what the eng in the video does), but rather to probe for more information to understand the context of the request, and work toward a workable solution. Ignoring line ink and geometry, step back and ask: where will these lines be drawn? Who will see them? What information are they trying to convey? Of course, these are the same questions that would ruin the conceit of the sketch, but that's the solution to this riddle.
[+] [-] todd8|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dennisgorelik|12 years ago|reply
1) In Hollywood they draw red ("blood") lines with transparent inc all the time.
2) There is no problem to draw 7 mutually perpendicular lines as long as lines are not straight. Moreover, clients never asked for mutually perpendicular lines.
There are other solutions too, such as 7-dimensional space and imaginary lines.
The "expert" looked quite inexperienced when he started his answer with "No".
[+] [-] sopooneo|12 years ago|reply
[+] [-] vayarajesh|12 years ago|reply
I dont think a small project with a small team even needs a project manager.
[+] [-] mncolinlee|12 years ago|reply
Granted, it's a sprint requiring downtime afterwards and everyone was doing what they really wanted to do instead of their day jobs.
[+] [-] carrotleads|12 years ago|reply
[+] [-] Moru|12 years ago|reply
[+] [-] return13|12 years ago|reply
[+] [-] dewarrn1|12 years ago|reply
[0] http://www.euskalnet.net/larraorma/crypto/slide8.html
[+] [-] einhverfr|12 years ago|reply
[+] [-] einhverfr|12 years ago|reply