Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion about middle management and product management
- Be specific about context; companies can differ in different ways
- e.g., style, governance (traditional vs. modern)
The middle management problem
- Middle management is given their own set of KPIs and objectives; their employees who are participating in inner source are, in a sense, diverting precious resources to activities that do not contribute to the middle management's KPIs. This pressure/disapproval can cause (some) employees to not engage in inner source contributions to other projects.
- Explain to middle management how it benefits their BU (some inner source projects may do so directly; but this advice may not otherwise hold).
- Good developers can move to where they do have permission and support to engage in inner sourcing.
- Give the middle management company wide KPIs and goals that inner sourcing contribute to so that the MM will support inner sourcing.
- Let MM take initiatives to make this work.
- Use their evil for good.
- Make MM a mentor or coach.
- Have upper management plan for 80% capacity rather than 100%.
How to communicate with middle management
- "It is the future of SW: inner sourcing will make your company more attractive to talent, it will be involved in something like open source, it will help retain people."
- Use concise, factual communication but include buzzwords
- Address MM fears
- Need to find the right language to talk with non-developers
- Think like a services company--invest in your people (through their inner source participation)
- "Can you afford to train them? Can you afford to train them and have them leave? Can you afford not to train them and have them stay?"
- Like with a sail boat, don't tack into the wind. Sometimes it is better to loosen your control for a while to avoid capsizing.
- Comment: Agile has self-organizing teams (like inner source)
- Completely self-organizing holocracy is possible (but has a lot of downsides)
Thoughts for later down the road
- Eventually, what is the middle management role in inner sourcing? Inner source developers are self-organizing; do they really need much guidance from middle management?
- MM realign staff to new objectives
- What makes the company profitable? Would developers and MM know? (an argument that self-organizing may not be enough)
- Daniel Pink motivation; tell developers WHY should they do something. Extend the trust.
How much time do developers spend in inner source?
- 10% is only effective as a teaching exercise
- Let MM take a tour to see how it works first hand (essential if you want to make them a mentor or coach)
- 20% minimum participation
- 50% ore member
What you use inner sourcing for
- tools and APIs, live demonstrators: inner sourcing is easier to do for innovation purposes; it is a perfect match for managing chaos.
- It is harder to ensure that SW is ready for real production release on a schedule.
- PdM enter a contract with penalties for non-delivery
- Delivery of content on time is key
- Do you control the # of engineers? Needed to promise content on time.
- Does project management work with inner sourcing?
- PjM ensure that the product is delivered on time.
- Can inner source work for product development? With visibility and the open collaboration model? Yes, there is a proof point from a large company.
Clone this wiki locally
Press h to open a hovercard with more details.