Understanding people matters more than understanding tech | Hacker News Reader

Understanding people matters more than understanding tech

letterstoanewdeveloper.com

156 pointsmooreds53 comments

> Or, to be more precise, in a “jobs to be done” sense, we wanted shelter from the rain and snow and protection for our belongings from anything coming from overhead. We wanted it to be durable, easy to repair, and hole-free.

> I did not care one whit about the shingle type.

The way this post is posed is very misleading and counterproductive.

In this example, you very much do care about shingle type, it's what makes all those things you care about an actuality. What you don't care about is learning about it and defer the expertise. In this sense tech certainly matters to developers as that's what's being deferred to them.

Exactly. Good products and companies are abstractions that allow a homeowner to not have to learn about shingles. The roofer should definitely understand what shingles are going to provide rain and show protection in the customer's environment. The roofer doesn't have to know everything about the chemistry and material that is in the shingle though. That abstraction is provided by the shingle manufacturer. They need an expert that knows about adhesives and gravel and how many years of sun exposure they can handle.

I think this article is bad because it empowers a lot of people to dismiss expertise as unimportant rather than knowing where that expert is. I think the important thing for companies is to have clear understanding of what abstraction your product provides your customers, and which portion of creating that product are you the expert in. You should then delegate the portions that you don't want to be the expert in, and make sure you hire and retain the experts that DO know about that. "The most important thing is understanding the customer." is bad advice on its own. "The customer wants a flying car." Well, do you have an expert in making cars fly? If not then understanding the customer isn't that valuable.

Did you read the same article I did? It explicitly said expertise is more important than technology choice. From the article:

"Think about it this way. If you were trying to solve any problem with software, which would you choose?

A unmotivated, unskilled team with the best technology

A motivated, skilled team with the worst technology"

This is saying that skilled people with worse tools will still create a better product then people with the best tools but no skills. In the roofing analogy it would be someone who uses the best shingles and hammers and other tools, but screws up the installation and the roof leaks anyways, vs someone with less good shingles but installs things so well that its still a good roof.

I think this lesson is extremely relevant in technology. For example, there are some developers who are more interested in the technology choice than solving the user problem well, and the result is a long development time with subpar user experience. On the other hand I've used excellent services, stable, fast, good UI, built with tech that I'd never personally choose. I can only imagine that those teams have great developers despite having to work with tech that isn't as good.

But that's not the tradeoff presented in the title "Understanding People Matters More Than Understanding Tech".

"Understanding tech" is not about choosing a tool or choosing a tech stack or picking a vendor (coincidentally, doing the latter right would be correlated with "understanding people"), "understanding tech" is about being able to build and/or configure that tech properly. In the roofing analogy, someone who uses the best shingles and hammers and other tools, but screws up the installation and the roof leaks anyways is someone who clearly doesn't understand the roofing tech (i.e. how to build roofs and 'install and configure' shingles) and we have no information about whether they do or don't understand people.

If you put the choice to that, then it's not about the quoted irrelevant choice but something entirely else - a mangling like "an unmotivated skilled team vs motivated unskilled team" isn't exact but at least somewhat relevant to the point the original post attempt to discuss; perhaps, to be generous, "a well-coordinated team of unskilled roofers with great communication and clear goals" vs "a bunch of skilled roofers each individually doing the thing they think is best without asking the customer" or something like that.

I don't actually care much about the title. You are very welcome to criticize it if you want, but what you are reading into the title is not what the article itself said, and the poster I replied to specifically cited the article not the title.

TLDR: we don't need to guess the authors intent behind the title, you can just read the article.

But others do. There are managers who think exactly this - people are replaceable cogs - meaning you can treat them like that too - as tools that are like store bought

TLDR: See Boeing

I'm a bit late responding, but I'll answer anyway. I did read the article and believe I am disagreeing with the author's core point.

In the roofing example, the roof installer is passionate about roofing shingles, but the home owner doesn't have to care about it because he found a roofer who does care. If the roofer is good with people and passionate, but doesn't know the difference between types of shingles, you aren't going to get a good roof. In this case, understanding people is NOT more important that understanding shingles. The expertise of the roofer is what allows the homeowner to not have to care about shingle. But the expert roofer is the rare item. Every random person on the street wants to not have to care, but the expert roofer is rare. I bet business is booming.

For the team example, it's a straw-man that I don't want to conceded to the author. Sure, in some imaginary land, there is a motivated and skilled team that is force to use terrible technology but somehow overcomes this. This is not a useful description. In my experience, skilled teams are experts at choosing and understanding their tools to make technology. For skilled craftspeople, working with others is important and required, but so is being a skilled expert. The expert part is usually more rare than the people part.

The problem I have with the author is that they have picked two poor examples to support a misleading title. In my experience, companies are fully of people who say they understand people, but there is a skilled group with their doors closed making thing work. One day those people leave, and the people running around saying people are more important than technology are suddenly confused why things stopped getting done.

Be careful with this line of thinking. This reads like overcorrection. Like when a nerd realizes they need to learn to network and become obsessed with all aspects of socialization. You can damage your technical excellence through neglect! If you overcorrect and let your technical excellence suffer because you prioritize people too much, then people will like you but not care as much about what you do. They will be less likely to want you in their professional network. ie they like you but don’t respect you.

It all matters, your product or service is only as good as the weakest aspect. Making an offering great means constantly putting your attention on anything falling behind to ensure excellence in all categories that matter.

I like this line of thought. Growing up, I was bombarded with "networking is everything!", "99% of jobs come from connections!", and it was really stressful for me because I'm really terrible at networking and I know it. Felt like I'll never get a job. But guess what? It turns out being freakishly obsessed with something makes you good at it, and being good at something is also a really good way to find a job. All of my engineering jobs thus far were cold contacts with a strong portfolio. Didn't need the network after all.

(that said, of course networking is still effective. it's just, as you said, people overcorrect - even in their advice!)

Being good at your job will only get you so far in a career. As you move up the ladder, social skills become more important to your career. Also, as you get older you will see that networking will be the primary way to get a job. Being good is not enough all the time. Companies need a job to be done they don't really care that you can build a computer or whatever from scratch or whatever merit you want to name that's outside their needs. If they have X candidates to pick from they will gravitate towards the one that can do the job and the one they have some kind of personal connection with -also known as networking.

It's not really about networking. Being able to schmooze is a nice add-on, but it's much more about being able to understand users and teammates. Those are the people you need to think about every day.

I get what the author is saying, but it still feels like it devalues tech skills.

There's some weird vibe the past few years where programming is mostly seen as a stepping stone to get to the things that really matter, be that Creating Business Value, funding, more money, career success, VC attention, GitHub stars. (Note how they're all extrinsic measures.) It's like caring about the act of programming is seen as vulgar.

The trope of siloed programmers is real, but the rest of us continue to suffer unduly for the fact that a few devs choose to remain unengaged with the larger context of their work.

I get what you're saying, and I've observed this too. I think there is a divide that few people consciously point out, which is there is a difference between programming as an artform and programming as a career. From a career perspective, all of those things matter, as an artform they're likely not important at all. It's not that caring about programming is vulgar, it's that most people are focused on career so the majority of the conversation is optimized around the metrics that matter for careerist goals.

I agree that there is nothing wrong with programming as an art. I enjoy things like the old demo scene, or writing the shortest code, or other forms of programming feats, even elegant designs or proofs.

But when I'm building a product and hiring people, I absolutely do not care about those things. I'm hiring an engineer not an artist. If you want to do art in your spare time great, but on the job I want people to care only about building an easily maintained, bug free, performant application that satisfies the users needs. It doesn't have to use the best tech, it doesn't even need to have elegant code, just easily understood, fast, and bug free code.

If developers separate code as art from code as a job I think they would be much happier. I know I made that transition many many years ago and am much happier for it. I still appreciate code as art, but in it's place.

Yeah for sure. I like both sides, which means I can either talk to everyone or I care too much/about the wrong things. :)

If you value tech skills and want to get certain standards implemented, you need to be able to navigate the people side of things to get agreement. If you strongly believe a certain tool should be used to solve a particular problem, your success in getting that tool selected is directly proportional to your relationships and ability to navigate in the circle of folk who can get that accomplished. If you want your new architecture implemented, you have to know how to sell it up the chain of command. It's not that the tech doesn't matter. Far from it. But those ideas have to be sold in a context that other stakeholders can understand. If you want to have that level of influence on your career so that you're not suffering unduly, you need to put yourself into a position to influence organizational level decisions. Otherwise the decisions will be made by the people who can navigate those circles regardless of their technical ability.

Autism spectrum disorders are characterized by challenges in social interaction, verbal and nonverbal communication, and often the presence of repetitive behaviors and restricted interests, according to Wikipedia.

Remarkably, understanding people does matter to a degree dependent on the social context.

Explaining how to more easily understand people might have a greater benefit than berating them about their shortcomings. And would show social competence.

> Explaining how to more easily understand people might have a greater benefit than berating them about their shortcomings. And would show social competence.

Author here. That's a great idea. Maybe I'll tackle it in the future. I do have a post about how to engage with people when you don't know them that uses a technique I've found helpful: https://letterstoanewdeveloper.com/2019/02/25/use-a-conversa...

Sorry if this came off as berating people. I have been the person overly focused on tech in the past and wanted to make it clear to readers that, at the end of the day, the people the tech is helping really matter. Appreciate the feedback.

It's just a provocative statement. If you're a software engineer, your job is primarily to engineer software. I'm working remotely, I spend 75% of my time alone in front of the computer trying to solve problems, using years of accumulated technical knowledge. Comparatively, dealing with my teammates and manager is pretty easy. It's not like we are salesmen, our craft is tech.

The author sees technology as something mutable but doesn't consider humans/relationships to be that. He can either work with inflexibly, unalterably "good" or "bad" people (as measured by skill or motivation).

I would hope that understanding people would mean seeing them with a bit more depth.

(Also, he doesn't really make a case for his thesis.)

Author here. Thanks for the feedback! I think that different people can be good or bad in different roles, organizations and times in their lives. Sorry if that didn't come through.

This is a blog devoted to new devs, and one thing I've seen new devs focus on (myself included) is technology as a solution to all the problems. I was hoping to illustrate through this post that the technology matters less than people (their problems, their strengths).

New developers have the most to learn about technology. Teaching them that technology is less important than “people” is counterproductive and harmful unless you anticipate them moving to a PM, managerial, or technical sales track.

Furthermore, as someone who just replaced a roof, “I did not care one whit about the shingle type” is frankly insane. As a homeowner, you are your only advocate. If you don’t care, you will be taken for a ride — either by someone actively malicious, or purely incompetent.

Applying the point more broadly, somebody trusted in a position of authority must understand the technology, or you’ll get poor technology. Developers are supposed to be that somebody trusted in a position of authority.

I looked up your title — “Head of Developer Relations”. Of course people matter more than technology for you — you’re not a developer! People are literally your job!

> Teaching them that technology is less important than “people” is counterproductive and harmful unless you anticipate them moving to a purely PM or managerial track.

I intensely disagree with this statement. Of course technology is important, but so is (for the vast majority of tech jobs) working with people. I'm not talking about managing people, I'm talking about understanding customers and/or team members.

Teaching new developers that they need to not only be concerned with the tech they are using, but how they are using it and to what (human focused) goals, is critical to people's careers.

> Furthermore, as someone who just replaced a roof, “I did not care one whit about the shingle type” is frankly insane.

Different strokes for different folks. I found someone who'd done work for others that I could ask about, checked his references, and trusted his advice. I don't want to have to become an expert on everything, I want to delegate that (as other comments mentioned).

> Applying the point more broadly, somebody trusted in a position of authority must understand the technology, or you’ll get poor technology.

Absolutely agree. But you can also say:

"Applying the point more broadly, somebody trusted in a position of authority must understand how to apply the technology in such a way as to benefit people, or you’ll get poor results and unused technology."

That's my core point. As technologists we have a deep rooted understanding of the importance of technology. But we (myself included) often lose sight of the actual purpose of the technology and its use.

Maybe I missed it, but what does the author even mean when they say "understanding people", and what is it that devs don't "understand"?

What I tend to see is junior devs having inappropriate levels of confidence (either too high or too low) and their superiors taking advantage of it for their own gain. Is that what we're talking about? Because otherwise I don't see social awkwardness, but fear being mistaken for "passion".

The majority of the time a dev wants to talk technical details is because they want validation or expect a certain level of input from the rest of the team, especially leadership. It's perfectly reasonable for such a person to become frustrated when that doesn't happen. This isn't a lack of understanding from the dev, but maybe a lack of communication and a few naive assumptions on their part.

It is understanding that leadership doesn't care about the technical details. Devs are expected to figure out these details on their own.

Instead try to understand what others really care about and frame the discussions around that.

Technical details are not always irrelevant nor mere implementation. They are often critical to the success of a product. It's like refusing to order from a menu at a restaurant and instead shouting "I WANT FOOD!" in a vain attempt to hide illiteracy.

"Oh what kind of food, sir?"

"GOOD FOOD! HOW DARE YOU ASK ME THAT!"

"Would you prefer a picture menu, sir?"

"...yes"

So, better off talking to the product manager who just orders hamburgers for them. Of course that just drives a wedge between devs and leadership even further and erodes trust. No wonder devs job hop. No wonder every product is so mediocre.

There's no escaping the fact that the days of non-technical leadership are numbered. Conversation should never be one way regardless of the hierarchy within a business. Such is the dysfunction of today's leadership.

This sounds like telling devs to 'manage up' which is shorter/searchable. I think that's good advice for more sr devs but juniors are still working out how to solve problems as stated and understood with their tech at-hand. Having this extra layer would probably be too much to deal with all together.

There's a common complaint among developers that they wished their PMs were more technical. When I started as a PM I incorrectly took this feedback to heart and leaned into my technical strengths. This was a mistake, as much less technical PMs who focused on people had much more success than me. I was exhausting myself understanding the technical details of the projects and aligning execution, when in some cases I was missing out on what the customer really wanted. It's great to be good at everything, but I'm not going to let myself get distracted from listening to what customers/partners have to say. And if you're a developer who thinks your PM isn't technical enough, you may not be correctly appreciating what they're bringing to the table.

The best PMs involve devs early and trust them to make technical decisions - including saying “no”.

A PM who cannot do this _has_ to be on a higher technical level. That’s why we sometimes think we want that. But what we really want is trust and agency.

I think one problem is that it is a vicious circle: it is not always that the PM cannot involve devs early and trust them to make technical decisions, it's that sometimes, devs are not trustworthy because they are not understanding people.

Why would a PM involves devs early if the dev team has demonstrated that they are not interested in understanding the rest of the business?

I'm not saying it's always the case, but I have the feeling that in these conversations, the discussion is often a one-way street: a lot of devs are talking a lot about how they wish their PM is more technical or gives them more trust or freedom of decision, but a lot of them seems at the same time totally uninterested or oblivious in the possibility of changing themselves to satisfy the PM's wish. Why should the PM change to please the dev when the idea of changing to please the PM is so remote from all dev's considerations?

It's really a two way street and both sides need to grow into earning each other's respect and trust.

> Why would a PM involves devs early if the dev team has demonstrated that they are not interested in understanding the rest of the business?

They wouldn't. Because in order to really trust someone to take more responsibility this interest is a prerequisite.

In the ideal case the developer _wants_ to hear about the problems that need solving, not be assigned specific tasks. And a PM _wants_ to leave technical responsibility and agency in the hands of the developer, shield them from politics and trust their decisions.

Mistakes happen and there are ups and downs to these relationships. But it has to start with building mutual trust.

I agree and I think it's the point of this article: the ideal case is when the developer want to hear about the problems that need solving, aka need to understand people rather than focusing on understanding technology.

I still feel that there is a lot of developers expecting that everything should revolve around them without caring about the other members of the company. At least more than PM not caring about the developers needs. I feel that I can see this behavior in the comments here, for example in some comments criticizing the article that show that their author really don't care about reaching a two way street situation.

> But what we really want is trust and agency.

Yup. One of the best PMs I've had the pleasure of working with secretly thought we were doomed, but she still gave us what we asked for and supported us all the way to success. When people trust you like that, you do all you can to not let them down.

IDK, quite often the PM has to manage external people/teams who need to do stuff in a project but clearly have their own interests (either their employer or personal) in mind than the organization who wants to use their services. Purchasing and outsourcing (which are key parts of most non-tiny projects) does require being able to make technical decisions that are best for the project, not the most profitable or easiest for some of the vendors implementing their parts.

The hardest programming language to grok is human language.

English is not a programming language, but it is the language of most programming language’s documentation and syntax.

How is human language not a programming language? Go to the store and get me a carton of milk and a box of cereal.

woosh

It's like choosing between a pro photographer who only has a phone vs a beginner who has the latest full frame DSLR.

The technology is important, but it's impotent without foundational understanding.

In film school people would often say "wow thats great, you must have a really awesome camera" and I eventually took to saying "thanks! btw your hair looks great, your hairdresser must have a really amazing pair of scissors"

This is so true. My company uses an Excel-Macro like tech in the product that empowers our customer-care and presales people to actually create features themselves for the user - it is awesome. Not because of the tech itself, but because they understand and can make it so much simpler, faster and iterate 5 times with the customer through the first week of the pilot. For the cost of _asking_ a developer how long it would take to do. What do you think, who gets the contracts even with better margins?

I get the writing but it's too vague to represent using "than understanding tech". Under the context of the overall brand of the website--letters to a new developer- then it would be better to change the title/wording to better silo under the brand.

Good article nonetheless. It is true and just like every job, people matter more than the niche action.

> (s/man is/human beings are/)

I like that

I guess somebody's gotta drag Protogoras kicking and screaming into the 21st century levels of understanding eh?

Makes me kinda wonder what people 2000+ years from now are going to think of us, or me for that matter

I'd probably leave a legacy as a chump that mighta cracked a half decent joke on the net once in a while

> If you were trying to solve any problem with software, which would you choose?

> A unmotivated, unskilled team with the best technology...

How do you get an unmotivated and unskilled team with the best technology? Who has picked up the technology? Who has set it up and got it working?

What you frequently see instead is a:

    - motivated unskilled team with a mediocre technology (e.g. a bunch of recent bootcamp grads armed with react), or:
    - unmotivated skilled team with a mediocre technology (mature developers who have found themselves in a trough of disillusionment, a journey accelerated by business requirements that made them torture their initially beautiful code into an unrecognizable mess, and produced ever-growing resentment)

> How do you get an unmotivated and unskilled team with the best technology?

Last year I had a project where I designed the architecture for an IT system for some IT department in a non-IT company. At the end they asked me for help to build a small team to implement and support the system. Unexpectedly their director hired a bunch of zero skill people for that team. One year later, they struggle to build the system that I have designed, with almost no progress. They are an unmotivated and unskilled team with the best technology.

Hmm...the title contradicts the content.

"A motivated, skilled team with the worst technology"

A skilled team is one that understands tech.

It could be that the skilled team was given crappy tools due to company culture

This is trivially untrue:

- median hr salary: $61k

- median software developer salary: $111k

Maybe what you’re trying to say is that the average junior dev doesn’t spend enough effort on people. But that’s a very different statement than saying that understanding people is more valuable.

This comparison is exceedingly bad. In one, you deal with people in a specific context, in the other you ALSO deal with people, just in a different context.

He doesn't say valuable, he says it matters more.

Didn't the pandemic show that those jobs that matter aren't well paid?

BTW The median salary in the NBA in 2021/22 is $4,347,600, so NBA > Tech

> He doesn't say valuable, he says it matters more.

What does that mean? How are these words different in this context?

> Didn't the pandemic show that those jobs that matter aren't well paid?

What the… how in the world did you derive this from the pandemic? Seems like the phrase “essential worker” confused you. The people who were allowed to keep working in person were those that were essential in the short term to provide everyday services, that’s it. This says nothing about whether software developers matter more or less, since 99% of software developers kept working anyway.

But anyway, this argument is moving the goal posts — the original article was saying that you’ll get paid more for them.

> BTW The median salary in the NBA in 2021/22 is $4,347,600, so NBA > Tech

I think this is basically true when comparing individuals. Any one of the 450 players in the nba bring more enjoyment and meaning to the average persons life than the median software developer does. (Though obviously if you compare the entire tech industry to the nba, then tech will win out.)

Like I said, in the pandemic the work of hospital and grocery staff mattered but these jobs aren't valuable because they are heavily underpaid. If they would have stopped working matters would have got way worse. This isn't true for 99% of software developers and 100% of athletes.

Some athletes on the other are overpaid and their sport doesn't really matter.

And by matter I mean are necessary for survival.

If it were true, software would be replete with "people people" and not us introverted nerds who understand the technology but shy away from people. Understanding people is a useful nice-to-have, understanding technology is an essential requirement. That doesn't fit the definition of "matters more".

Reply on news.ycombinator.com