How to sell ideas as a software engineer

Every developer comes up with a brilliant idea every now and then.

Ring a bell? Well, these ideas are often quite ambitious, and neither our teammates nor we are optimistic about them after a little thought. But sometimes we brush off something really interesting.

In this article, I’ll reflect on my own experiences to find out what it takes to come up with a good idea and sell it to your team or boss. Fasten your seat belt!

Business context

Firstly, we’re all in business and bound by context. Every business has its own goals, all of which lead to making money and staying profitable. Any idea can take any form, from the silliest to the most brilliant, depending on this context. If your app is written in not-so-recent React and you want to upgrade it - that’s a hard sell. But if your company is planning to grow rapidly and hire a bunch of engineers, but your app was written in some abomination of your fevered delirium 15 years ago - it’s a good case for rewriting it from scratch so it can scale with the needs of the business.

That’s a key point to take away from this article. Your ideas should benefit the company you work for. Technical improvements for their own sake are not good enough. Always think about how it will affect users, metrics and even your colleagues - you can boost their productivity which in turn will affect various metrics here and there. Even you’re working for yourself and can do pretty much anything you want, prioritise your ideas according to the impact they will have on your app.

Don’t just take my word for it. Addy Osmani, for example, feels the same way.

Ideas

I (like all of us, right? Right?) have a lot of good and bad cases on the subject. Now, months or years later, I can look back and evaluate them and myself in those situations. Was the decision to do or not to do something right? How could I push my ideas better if I believed in them and they came out positive in the end?

Here are three illustrative examples of when my ideas weren’t implemented and what the end result was, as well as my thoughts about it some time ago. I think they cover three of the most common (at least in my experience) mistakes in arguments about technical solutions: focusing on what you want instead of the objective benefit, inability to find the right scenario aka thinking inside the box, and superficial understanding of the problem.

Autonomous design system

There was a time when we at Practicum decided to create our own design system. Not that we didn’t already have one, but at the time the project had just celebrated its 4th birthday and everything was scattered here and there. We had Button and Button2 components for god’s sake!

The main point of discussion was where to put the new system. Some of us thought it should be in the platform codebase, some of us wanted it to be an independent package. I strongly wanted it to be an independent package so we could play with CI, beautiful newer storybook, etc.

In the end, we put the design system on the platform repo because of these points:

• Another package to support;
• Different CI;
• Small number of services using this design system (1 at that moment).

Well, it didn’t age well. At that time it was not very difficult to create an independent package and I had a lot of time to do it myself. Since then we switched to monorepo, following the idea of small reusable packages and CI out-of-the-box, and, guess what, started using this design system in different projects. We had to decouple the design system from the original service via a proxy package and only then create the dedicated one for it. Should I say that this process was a pain in the ass, as there were many more components to work with at that time, and their various implementations can be found here and there?

I really had to do a better job of protecting the idea and taking responsibility for it. It wasn’t a complex or very time-consuming task that could really benefit us in the not too distant and fairly predictable future. That is what I should have focused on in my argument, rather than the technical attractiveness of the task.

Feature widget

Once upon a time we talked about UX studies. I came up with an idea to use the power of our feature flags system and enhance it to the point when we to control it just for the current session with some tool.

If you’re familiar with the concept of feature flags, you can skip to the next paragraph. For those who aren’t, feature flags are, well, flags that control the behaviour of the app. It’s also the core concept of TBD (trunk-based development), where you break features down into really small atomic pieces, and very often merge them into the main branch, which is called trunk. Each small piece of code should be protected by a feature flag, which means that the code will not run unless the flag is turned on. When the whole feature is ready, you switch on the associated feature flag, and it becomes active.

So, feature flags and the UX studies. With this approach, we need to develop something that we want to test in the study, which in turn should be the reason for developing it in the first place! After some thought, I kicked the idea into the long grass. A year or so later, I remembered the core concept - changing the behaviour of the app in a controlled way - but in the context of the honest day-to-day work of software and QA engineers. I found that some colleagues were thinking about it in the same way. So, a year later, we’d created exactly what we needed - a widget to control the features of our app by any user with certain privileges, completely independently. If I’d gone with the original idea, it would have been a lot harder, because there would definitely have been conflicts in the logic behind the scenes.

It leads us to conclude that an idea should not only be evaluated in the first scenario that comes to mind. It’s better not to do something if you’re sure it won’t help anyone, sure, but it’s even better to look at all the angles to really understand the potential of the idea. Always try to see the bigger picture so you can make the best decisions.

Static service

The I18n of our application uses two internal services: Actual I18n service where content managers write texts; JSON storage, from which clients retrieve texts and some other static content.

JSON storage doesn’t handle large amounts of data well, and the main concern was that it wasn’t fast enough. I suggested that we build our own JSON service so that it could do exactly what we needed it to do, in the way we needed it to do it, with no additional overhead.

It would have been an upgrade, of course, but it wasn’t easy to sell in our current business context. The idea was put off until this storage started occasionally failing to deliver the static files.

This time it was urgent. We put together an initiative group of developers and came up with a more complex solution than the one I’d had before: it wasn’t just about the speed and usability of the JSON service client web page anymore, it was about stability and single ownership of all static data in our project, not just texts. It wasn’t even just a JSON service anymore: we’ve thoroughly refined our processes and reduced the amount of data we use.

There was a hidden problem but I couldn’t see it. The slowness of the service we used was not just a problem itself but an indicator of the problems in the way we’re working with texts and other data in our apps. It was neccessary to look deeper to truly understand what’s going on and what exactly should be done about it. It’s important to find the root causes of the problems we encounter (and we’re not just talking about programming, are we?), rather than just fixing them here and there.

I hope my experience and these examples will help you evaluate your (and not only yours) ideas and make the best informed decisions. To do this, ask yourself three simple questions:

• Why should I do it? What impact do I expect? Don’t focus too much on your personal preferences, evaluate the current business context and put your users and colleagues first;
• What user scenarios do I want to improve? Will it really improve them? Even the greatest idea can fall flat in the wrong scenario. Try to find one where it will make a difference;
• Am I solving the problem or just patching it? Sometimes we need quick decisions, sometimes we need smart decisions. If you have time and resources, spend more time finding the root cause of the problem you want to fix. A deeper understanding of the problem is the key to better solutions.

Have a good day!