Martin Haynes

How do plugin companies grow? Some find they need to constantly bring out new software, going from release to release, steadily getting new customers but ending up with a catalogue that’s harder to manage too. Others can have radical success from one plugin and live off it for years, without feeling the need to make more. As usual, most are somewhere in between. I recently wrote two articles for Moonbase. One on how to grow a small plugin developer, and another on how medium-sized plugin brands can turn into big ones. As a company in our industry grows, the marketing strategy usually changes with it. But how? In the two articles, I get specific about the patterns I’ve witnessed across multiple plugin companies, trying to extract out some rules of how growth looks, and therefore how to make it happen, assuming other conditions are right. As ever, I make some bold claims about how I think things work, because I think that’s better than not proposing anything at all. Links here, but more thoughts below… https://lnkd.in/ebcZZyc9 https://lnkd.in/ePGfXszN I’ve always thought there were different stages of development in plugin companies that might be possible to pin down, like different categorisation of stars. – “The FabFilter Class that has roughly ten plugins and slowly upgrades them all” – “The Waves Class that keeps releasing and releasing”  – “The Modartt Class that’s doing fine with one or two plugins, thank you very much” … When I first talked with Moonbase, we discussed this idea and they suggested I write something like these articles. Here, I was trying to make the abstract ideas more concrete, and it was hard to tease out with just three categories (small, medium, large), let alone more. What did I leave out? – A product strategy is (usually) essential to growth, too. In most cases, a larger catalogue of plugins is the obvious plan, and every new launch is an opportunity to write a new line and build your audience.  – What’s the definition of a small, medium and large developer anyway? Revenue alone may not cut it, as revenue doesn’t necessarily correlate with team size. If you don’t know Moonbase, they’re helping companies to sell, license and deliver software, and just like me, they’re specialised in working only with plugin developers.

28

It’s worth having a closer look at who’s actually involved in your hiring process. I’ve seen interviews where the candidate never speaks to another tester. Or where all the questions come from a developer’s perspective - focused on speed, coverage, tooling - but missing the bigger picture around risk, quality strategy, or communication. And for the candidate? That’s telling. If the team doesn’t involve test engineers in hiring, what message does that send about how they’re valued internally? The best processes I’ve seen bring testers into the room early - not just to assess, but to represent what the team actually cares about when it comes to quality. Because culture isn’t just how you work. It’s also who gets a voice. Hiring someone into a test role without showing them what that role really looks like on your team? That’s a missed opportunity - for them and for you.

5

When "Being Right" Isn't Enough. Marcus, a capable mid‑level engineer, asked his engineering manager, Sofia, for an urgent 1:1. "I can't work like this. I now fear every commit I make because I know it will start another fight." Marcus had joined the team relatively recently and was still building confidence in cross-team conversations. He had been pulled once again into a never‑ending PR battle with Jules, a long‑tenured senior engineer from another team whose opinion carried a lot of weight. Jules was technically sharp and often made valid points on the code, but at times his reviews crossed a line and had become a source of stress rather than growth. This wasn't the first time. Other developers had experienced similar behaviour from Jules in the past. Sofia recognised the impact this was having. She knew psychological safety mattered just as much as technical quality. So she acted. First, she made sure Marcus felt heard and supported. She extended the 1:1, moved her calendar, and went through the PR threads with him line by line. Together, they labelled what was technically valid and what crossed the line. "Your reviewer is often right about the code, but sometimes wrong about how he's saying it, and both of those things matter." She ended the meeting by reassuring Marcus: "We will fix this." Next, she involved Jules’ manager. Together, they reviewed the situation and agreed on some simple principles: • Design preferences, patterns, and styles are negotiable. • Respect and psychological safety are not. They used this as a chance to raise the bar for collaboration across teams by agreeing new review norms: • No sarcasm. Focus on behaviour, impact, and the code. • Limit async back‑and‑forth: once a thread gets more than a few comments, move to a short call. • Establish code owners across teams as accountable decision‑makers. • Use PR review rotations so cross‑team reviews become structured collaboration. They shared resources on constructive review practices: how to give more effective feedback and which behaviours to avoid. Sofia also paired Marcus with another senior engineer as a mentor to help him strengthen his architectural thinking and communicate his design decisions more clearly. Psychological safety is part of engineering excellence, and it starts with leaders who stand beside their engineers. #PsychologicalSafety #PeopleFirst #EngineeringManagement #CodeReview #HealthyTeams

1

The early 2010's were the golden BDD days, I really enjoyed the projects I worked on back then. An astute article on the rise and fall of BDD tools, and BDD in general. Thought I do wish people would stop talking about things "dying" in tech or being "dead", it's just evolution. " ... we as an industry failed to successfully productize tools for collaboration. The world jumped on BDD because Cucumber-esque frameworks were easy to adopt. The world was less willing to adopt BDD’s collaborative techniques because they were merely processes, not products. Products are sticky; processes are not. Cucumber tests will still be running after we all retire." https://lnkd.in/ezXXbvUE

1

Thoughts on Go after using it recently: - not being object orientated is a big plus. One of my least favourite parts of C#/Java - feels right at home coming from a typescript background - concurrency built into the language feels very nice - wish the type system had some more advanced features like discriminated unions - auto garbage collection makes the language very easy to use  - the fact that it compiles to a binary so no runtime is needed is a great advantage - seems like it's a language in between rust and C# which makes it a great tool for a lot of projects - love that go has errors as values and you can see which functions can return an error ahead of time, maybe one day we'll get something like this into typescript ( kinda is with effect.ts ) - interfaces being implicit instead of explicit is interesting and I'm not sure how I feel about it yet

6

I always find it cringey being told by non-technical people how my business should tackle software development. I find genuinely technical people (I'm not one) are actually way less quick to tell you what to do, because they know there's huge amounts of context they're missing. A case in point this week was someone imploring us to do all our coding in AI. He runs a software development agency, and they use it for everything he said. When I asked why we should, he said it's faster. Sure, but as with everything: speed, cost and quality are in trade-off relationships. I asked if he was a developer; he said no, he's non-technical. I'm non-technical too, so no judgement, but to me it's big red flag when someone non-technical has very firm blanket opinions on technical matters. I've asked my team about this before and they're really sceptical of the quality that AI produces. Have you ever had an experience of ChatGPT just making something up in an answer it gave you? Well it does that in writing software too. Although I'm not technical, I experimented using ChatGPT to write a script for me to run in Google Sheets, and it just went around in circles creating a new bug each time it tried to fix the last one. I know my devs would have had it done in under 30 min. So I do think there is a real false economy at play for most AI uses right now. I remember when I was interviewing for our AI engineer role in February, one of the applicants said his philosophy was if the code seemed to be working, just move on and don't worry about it. Not sure I'd want a builder to build my house with that attitude. (And yes, that comment was a dealbreaker for me hiring that guy.) I'm open to being wrong on this, and I know other very credible developers have found incredible ways to leverage AI for coding. One told me that it's like having a full team of junior developers supporting the development. My bias is a view that quality is an investment – you put the time and skill into something, it pays you back in the long run. What am I missing? Adam Sawtell Benjamin S.

24

15 Comments