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?
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.
I'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!).
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".