
Ask HN: How to build developer empathy in non-tech folk? - CosmicShadow
What do you wish you could teach non-developers in management roles, or those you have to work with, about how to communicate with, understand and treat developers?<p>What kinds of lessons would be great to teach that would force them to understand what developers have to go through? e.g. give them some sort of memory intensive challenge and then constantly interrupt them for pointless messages so they lose everything they were holding in their head and have to start over.<p>I&#x27;m thinking it could be fun to setup a training course for folk that will help these folks better understand how to work with and understand us Devs, but also give them a taste of their own medicine (for their own benefit of course!).
======
ethiclub
>also give them a taste of their own medicine (for their own benefit of
course!)

The biggest win is removing the 'us vs them' mentality. "taste of their own
medicine" is probably not conducive to bridging gaps.

It's also probably valuable to think of this as a two-way street, rather than
simply thinking 'managers lack empathy'. What Manager woes do Devs not know
about?

The idea of a training course doesn't appear viable on first glance (little
value gained, difficulty in getting buy-in, potentially patronizing, etc.) but
workshops or 'lunch and learns' are sometimes used for general cross-dept
knowledge.

Here are specific initiatives to improve communications and interfaces between
depts:

\- Shared documentation - While different views might exist for different
roles, many businesses (especially big business that uses archaic TOGAF /
other EAFs) split out views - And even language - too far for each
stakeholder, resulting in siloed areas and a lack of common language.

\- Company team cultures and cliques - There isn't any action to be taken here
(it goes without saying that you don't want to try to force friendships and
behavior), but it is worth observing the mini-cultures within the
organization. The standard comparison would be between stereotypical Sales and
Dev teams.

\- Compensation alignment - When Sales teams are being gamified with big $
commissions, it changes the culture of the team. When you do this for one team
and not another, you are forcing difference within the org. It also causes
resentment. Therefore it is critical that a business creates a standard
salary&benefit backbone that aligns all staff. While they differ in specifics
(sales = $ commissions on sales, service = $ commissions on performance, etc.)
the point is to ensure that you are looking after everyone to the same
standard.

\- Company Language - Go to your Sales department and ask what a 'Process' is.
Now go to your Dev team and ask the same. Chances are that scope varies wildly
in each provided definition. There is often no core language/definitions that
bind a company together, causing communication issues.

\- Discussion - Many issues are never raised with management in the first
place. E.g. "Have managers actually had the '20 minute shoulder tap cost'
explained to them? Or are staff complaining about it without actually voicing
it directly?"

\- Anonymous feedback mechanism - All businesses need this. Don't try to
attach names to it unless you want to spoil company trust, undermine all
collected data and reduce the amount of incoming feedback. Anything other than
a true anonymous feedback system = unethical business / blind business.

\- Internal promotions (long-term) - Where appropriate, personnel functions
are improved to facilitate more internal progression. Includes improvement of
recruitment and l&d procedures. _In general_ there is tangible benefit in
Managerial roles being taken by internal technical staff.

\- Inter-department newsletters, workshops etc.

\- Team and org structure changes. Often a 'cross-department pod' structure is
incredibly effective (see Spotify for a good case study). Bring product
managers, exec roles, dev teams etc. into pods that deal with end to end
business scenarios.

And in terms of stereotypical dev-manager issues (shoulder taps, disruptive
meetings, lack of empathy), the following are standard goals:

\- Clear discussion: Explicitly state to managers the intangible costs of
shoulder taps and valueless meetings.

\- Meeting templates & improvements: Tighten meetings to be more valuable and
follow consistent best practice for efficiency reasons. Implement expectations
regarding meeting attendance, on-time kick-offs etc.

\- Set up 'No meeting days'. Many businesses are able to (within ~6 months)
reduce down to 'Non-urgent meetings only on Tuesdays and Thursdays'.

\- Tighten up and automate reporting. Give managers a clear window into the
operations of teams. Automate, so that devs don't have to manually update
their line managers.

\- Templating and time budgeting - Set up clear boundaries that show managers
technical estimates of time. Empathy rises when managers realize the true time
investments needed for outcomes. This isn't about setting up complicated
forecasting - It is simply a case of Devs stating "We don't know exactly how
long this is going to take, but we do know that you should leave us alone
until 03/02/19 - Don't bug us on this deliverable until then".

