Personality – Why Engineers are natural problem solvers
Geetha Vallabhaneni & Andy Belk – Personality – Why Engineers are natural problem solvers.
Geetha Vallabhaneni: Have you heard of the whole QRC personality test? Carl Yung proposed this… you probably have heard of this…
Andy Belk: I think I’ve heard of it…
Geetha: Right, so most engineers tend to be intuition driven. In order to be problem solvers you have to actually have some sort of intuition, right? Because you have a sense of… for example… you’re running an experiment, or you’re trying to think about a problem… how to solve… the problem hasn’t been solved because nobody else solved it… so there’s no data to go by; there’s no real solid numbers to go by… but you sit down and think of different factors and there’s an intuition… “Here is the direction that I want to go”, right? A lot of, actually, engineering work is, and I was surprised, by the way, when I read about this. I took the test and I thought engineers operated a lot on data and we would be, like, sensing the other category but, no… actually a lot of engineers are intuitive. So when you have the intuitiveness about you, you make a decision and you execute it and then… constant learning loop, right? “Oh, I’ve done this. Okay, that didn’t work out.” But, again, going back to, like, measuring it, right? you make a decision and you figure out whether it’s working or not and, if it’s not, then you go make an alternate choice… so having that flexibility of personality… and, again, I think you made this, right?… detaching yourself from the… you own the decision-making but you actually don’t sit down and dwell too much about failure or think that, not working out, and taking that as a lesson as opposed to having a sense of failure about it. That’s the whole point; life is a lesson and you’re constantly learning.
Marzena Kmiecik: How do you deal with that with your team?
Andy: We’ve actually had an example of this very recently and, by the way, with my team, this was with an extended team, so we’re actually talking about 40 people being involved, or more. And it’s related to a feature that’s coming out. And what we did is we made a decision some time back and we went in that direction and we stuck with it. And then, what happened relatively recently is that I just turned around and I said, “This isn’t working for this reason and if we can’t fix this…”, which is what the feedback that we got that we were going to be on to address that problem, I said, “Well, we’ve got to do this.“… And so I went and advocated to my VP and said, “We should do it this way,” and he kind of came back and said, “Well, can we do x?”… “Well, we’ll see.” But we ended up doing what I suggested and… it’s going to work but we could have gone the other way in the first place but it didn’t ultimately matter as long as we end up making a decision is important.
I think the important lesson there is that you have to not get too vested in any one thing. Remember that it’s what you’re trying to do, and this is something that I suppose is very true about Apple, is that, we always have in mind that this is a solution for the end-customer and you always have to have that perspective because that really helps guide your decision-making.
I think a lot of people and a lot of technologists can start to dwell overly-much on the minutiae of the solution and it really helps if you stand back and understand that, the customer who uses their iPhone, or who is trying to make a sale and record it on their digital cell phone, or something, is not concerned about how it works; they’re concerned about how well it works and how efficiently and how easy it is. And if you step back and you think about it in that perspective, a lot of decisions that would focus on: “Well, we wanted to do x because y,” and that are more technical minutiae, it becomes a lot clearer as to which way you should go at any particular point in time. So, for example, this thing that we were talking about – it was a performance issue – and it was clear that there was not going to be any technical solution to that performance thing, so we just had to make this sort of big swing and say, “Well, no, we’ll just do it this other way and that will alleviate the problem from the user’s perspective.”
Geetha: And I think because, if I may add one more thing, this is not just true with technology and start-ups and products, right? It’s true of life, too, and you make a decision and you live it and you learn from it and you let go of whatever the consequences of… So, here’s what I like to say: “Nobody cares about your failure as much as you do”, right? So you feel like, “Oh, everybody thinks that I made this stupid decision and now we wasted 3 weeks doing this.” That’s not even a healthy way – not a productive way – of looking at anything, right?… Life, products and your engineering schedule… it’s just the way life is. Life just is, right?