What it is like being the only engineer in a meeting [video]
laughingsquid.com
laughingsquid.com
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.]
It does remind me though of a guy I once knew (late 90s) who was a senior manager at the national arm of a large, well-known international investment bank. He'd be in a meeting with the CEO and the rest of the senior managers, and the CEO wouldn't let the meeting commence if there were any computer cords visible, sometimes taking up to 15 minutes to personally clear away cords...
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.
The cost analysis of the meeting is however helpful to make people realize that there's way too many people in that meeting. It's just like a sports team where half of the players are not actively training while you're paying them all. And on top of that, the effectiveness of a meeting decreases very quickly with the number of participants.
Of course there might be an easier way to quantify the opportunity cost that I can't think of.
I suspect you'll find that more effective people tend to recognize when they're in a meeting they 1) don't need to be in and 2) which is keeping them from doing something more important.
Socializing, strengthening group cohesion, and other organizational (as opposed to individualistic) objectives may mean that even if you personally perceive greater benefit at being elsewhere, the organizational / collective goal may still trump, which is why that's included in the metric.
The concern isn't to do a thorough evaluation where that's not itself cost-effective, but to use the correct basis for measurement. Deciding on imperfect information is perfectly acceptable. Deciding on the wrong basis should really be avoided where possible.
Sounds complicated. Most likely they hired an expert to make it happen.
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.
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
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.
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.
But it's not the same league. Technology often comes down to "it can be done" or "it can't be done without a lot more effort than you are willing to pay for".
Sure, a business analyst may have similar problems ("this process works" vs. "this process would take 5 people a week, each time - but we only have 1 person for 4 days"). However you, the business analyst, are not usually then expected to go away and actually make X happen - you hand over your requirements to other people for them to "make it happen".
Sure, there's always somebody else, same role or not, who has more expertise, but don't confuse role/title for expertise. I've seen BA's with a decade of experience school junior engineers on what can or can not be done.
It's that when it comes down to actually making it work, it's the engineer that has to provide a working solution to the specification. Not a figurative engineer with years of experience and knowledge. The actual person that has the task. Pretty much everyone else in the chain has to make assumptions about what is possible, in what time frame, with what resources. Yes, the more experience you have, the better you get at doing that.
But trust me when I say that all too often, even product engineers for million dollar figure products, have little idea if X is possibly in time Y until they actually try and do it. (I've worked at multiple companies with multi-million product licenses, and seen it at all of them). Sure, a few of the delivery engineers had a much better idea. But there was no way any of the analysts, project managers, and especially not the sales engineers, had any clue about the time. You'd get answers from 1/10th Y through to 10 x Y - 10000% variance.
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).
The topic of the video isn't that everyone else is an idiot, it's that they are not deferring to the person they themselves acknowledge to be the expert to provide expert insight, perspective, knowledge, and requirements gathering. The expert says "you can't have seven lines that are all perpendicular to each other", those outlining the requirements challenge the expert on that, as if the expert is lying or making the service provider look bad by saying something is impossible. "You're the expert, figure it out". "Are you saying that, as an expert, you can't do this?". "Ignore geometry". Trying to get to the bottom of what the requirements actually are (which is often, in my experience, a misapplication, misunderstanding, or misdefinition of terms) is considered being difficult or not being a team player.
Also in my experience, the problem arises when the engineer is brought in the last and final stages after everyone else has already spent significant time on "the problem", and are married to their unworkable solution. The solution isn't necessarily unworkable because it's actually impossible, but often it's because what's been requested and sold to everyone else (read: upper management) is actually too expensive to implement. This is also where undoable aggressive schedules come from. Make no mistake, just about everyone is bad at estimating time and effort when it comes to software projects (this is well documented, at least in the lore), but if only two weeks of time/money are budgeted for what the engineer thinks is a four week project (even if it's actually an eight week project), no one wants to hear it. And it's easy to blame the person who was last to the party.
There are usually ways of dealing with this situation without confrontation or hostility though, and the distinction between requirements and solutions is an important one - in this case the client tried to present a solution when they should be stating the problem. I find most clients are happy to rewind and state the problem, and it helps a lot in presenting an alternative solution if you can then say - well this other solution solves your problem (and is not impossible given other constraints!).
I'm not defending the clients in this video, who are made to act as idiots parroting obviously absurd lines, what I'm questioning is whether this is even a caricature of reality. I think it's more an accurate representation of the world view that some people retreat to when faced with difficult clients who don't understand solutions and want impossible things (and we've all met them).
Sure there are political considerations and sometimes companies are completely dysfunctional - in that case it's best to fire the client or job and move on, but it's very rare in my experience as a developer or designer to come across that. If you can't do your job in a given setup, and can't push back, the best option is to leave, because you can't fix that and it is an unhealthy situation for all parties.
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.
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.
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?"
Fundamentally you have a seat at the table, and you're the only person in the room who can actually solve the problem. Since you're an engineer and your brain has already weeded out all the things that won't work because of technical reasons you can quickly zero in on and propose a solution, also you're the 'expert' so you have the opportunity to not say anything and actually hear what everyone else is saying.
To paraphrase the video if you can say something like "I propose we put together a triangle with two red lines and a blue line" and then draw that on the board, you're a hero.
"Would you like me to draw a kitten using only 7 red lines that, where they cross, are perpendicular?"
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)
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."
Find out pretty quickly (generally) what they are actually wanting and nobody needs to print things in transparent ink... (usually)
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.
What you can do is recognize and either 1) correct it or 2) realize you're working with incompetents (e.g., everyone in the video sketch, engineer included).
Myself, I generally have to make conscious decisions to do all these things.
"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"
BTW, I'm also guessing @lam's comment was referring to the 11 dimensions in string theory: http://en.wikipedia.org/wiki/String_theory#Extra_dimensions
Also, if you ease the restriction to each line perpendicular to every line it intercepts, you can get as many lines as you want in 3d already.
That works in 2d space, too. Parallel lines don't intercept any more than skew lines.
Why? Because "impossible feature request" can and does happen... frequently.
http://en.wikipedia.org/wiki/Poincar%C3%A9_disk_model
(credit goes to my coworker dmvaldman)
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.
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".
I dont think a small project with a small team even needs a project manager.
Granted, it's a sprint requiring downtime afterwards and everyone was doing what they really wanted to do instead of their day jobs.
and yes I am the "expert"
Or you could, say, not radically alter your behavior based on the genders of the people around you.
For an example that plays off the original poster's idea, imagine a group of 6 couples, 5 of which have children, and a single couple that does not. Conversation may drift into parenthood related topics based on the high percentage of parents present. The childless couple can choose their own level of involvement in this conversation, and the two ends of the spectrum are probably awkwardness and center of attention. The center of attention strategy is fairly easy to achieve in this scenario. Profess your ignorance to child rearing strategies, and you will almost instantly be regaled with countless tales from those present...
What's the commonality between both vids? Just enforcing negative stereotypes & emphasizing the weakness found in the worse case scenarios of each group.
It honestly doesn't matter. I've personally never seen anyone in IT of east asian descent anyway.
Get over yourself.
At least, I hope there aren't real-life Certified Red Line Experts running around, nor designers hoping to draw red lines in green ink…
Taken too literally, this sketch could be offensive to all of women, portrayed as clueless; male executives, portrayed as willfully ignorant and over-demanding; Asians, portrayed as obviously engineers; non-Asians, portrayed as obviously not engineers; engineers, portrayed as incapable of working backwards from impossible requirements to find a solution that actually works; and probably other groups I've forgotten.