Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One would wish. Personally, I don't think I've ever worked under a manager who understood software development. It tends to be all about what they can see (GUI) or about nearly meaningless metrics on a dashboard (LOC, tickets closed, etc.). Again, just in my personal, limited experience.


The problem is not "manager/client doesn't understand software development". That's fine.

The problem is lack of trust in you as the expert and possibly a lack of self-awareness (they think they understand).

A manager/client should make mostly strategical decisions like: We should solve this problem, here are the resources. And almost never tactical.

They also shouldn't even care or look at LoC. They shouldn't be worried about metrics of 'effort' at all.


Ah, agreed. I guess that, in my experience, not understanding SW development tends to go hand-in-hand with not trusting the developer.

I found your phrase "lack of trust in you as the expert" a little jarring because (again, in my personal experience) considering the developer to be a domain expert is somewhat of a foreign concept. I suspect/hope the situation is better elsewhere in the industry. :-)


I meant 'expert' as in the person responsible for the technical side. Not in the sense of 'they know everything they need to know all the time' or anything like that.

> I suspect/hope the situation is better elsewhere in the industry. :-)

I do freelance, client work. Alone and in (very?) small teams. Typically my/our clients only have a superficial understanding of everything technical (if at all). Trust often needs to be earned.

One way to gain trust is being creative/optimistic and explaining feasible possibilities and strategies. Another one is being pragmatic and not selling them something they don't need, or might not need.

And then the most important one is to have conversations about their problems and wishes. Showing that you understand them by asking questions and writing a specification. And explaining your (iterative) workflow: "Let's figure this part out after we've done this other part." I guess this is the "domain" part of the process.

My experience is that if trust is in danger then the work is less valuable, less fun and less sustainable. Indications of this are things like we discussed before and similar:

- Trying to measure effort instead of rewarding value.

- Nitpicking, bikeshedding and other distractions.

- Overstepping their expertise (typical for UI design, a bit less for programming)

Now most of my interactions are good but sometimes I get the above. We're actually discussing of doing more upfront communication work in the offers and initial discussions to prevent these things (even by filtering out clients/collaborators) and to set a tone. Because again, this is unsustainable on multiple levels and it never ends well...


Thanks for sharing your experiences! This is good advice. I also agree that, at times, some "filtering" must occur with regard to who we work with/for.


Bingo.

My leader isn't a technical person by a long shot. Instead they focus on getting people that they can TRUST on their team. Yes, sometimes it means we have to go back and 'fish' for metrics to throw the business. But we do notice that the less we chase metrics (and, yes, the arbitrary goals set out by the company as a whole) the more productive we really are.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: