HN Explorer

How Do You Sell Your Code/Architecture to Internal Dev Groups

5 points by 100011_100001 ↗ HN
This question is geared towards Architects, Tech Leads. DevOps Leads etc.

How do you communicate new recommendations or framework changes effectively to developer groups that need to adopt it? I was having a discussion with upper management recently and I came to the realization that the group I am in, doesn't perform HumanOps very well. We don't sell our code to our customers, the development teams within our company, we want to deal with new tech, bleeding edge changes not with the nitty gritty of framework adoption.

We don't just jump on bandwagons, but we do leverage technology that becomes available. We try to be within 1 stable release of current versions. The problem is not all developers are like that. A lot of times we create a mostly turn key solution to solve problems, but the developer groups are slow to adopt.

We luck the sales pitch, or marketing slogan internally. How do we do that better? How do we communicate what's coming soon? How to adopt the frameworks that make their lives easier?

6 comments

[ 2.6 ms ] story [ 24.8 ms ] thread
markus_zhang
IMHO in-house solutions usually sell because you are in the position to sell. That is you simply force everyone working for you to use whatever code you put up.

And apparently it's a lot easier to sell if you were the sole developer in the group and newbies were brought in under your guidance.

100011_100001
The problem is that development groups get so busy adding features / business value that we almost need to entice them to work on their tech debt.
markus_zhang
However, is it absolutely necessary to keep up with the new tech? Others may not share your perspective of the problem so they are not willing to make changes.
100011_100001
Real example, there are dev groups using Gradle 2.4.1, that came out in 2015, current version is 7.2

Is it absolutely necessary to update? I want to say yes.

softwaredoug
To me the best sales pitches is around the overall health of the framework, suitability to a set of problems, and the level of support you, the seller, will provide to me, the customer. This means:

- dev mindshare: hiring for the skills and getting help. You can quantify these trends via job listings and stackoverflow question volume.

- supply chain risk: with open source, what’s the risk of the project going dormant leaving no maintainers behind. How open are they to contributions? How well maintained is the code? Does a major company (or Google) back if? When was the last commit date?

- problem suitability: what class of problems is the project suitable for. Improve your pitch by saying what it’s NOT for.

Finally, if you want adoption you need to engage these other groups as customers. Up to the level of it being the main measure of your teams success. You need to setup support, training, documentation, and evangelism. You also need to work hand in hand ON the customer projects in a short-term, consummating capacity to increase adoption and understand the gaps in the tech. Otherwise you risk being seen as too “ivory tower” divorced from real problems.

Most of these are not technical problems, they are, like you say about “human ops” etc