How to Demo Software
Selling your skills to stakeholders
Why Public Speaking?
Most people who become a software engineer skew towards the introvert scale while also not being great at public speaking. This is a common stereotype amongst our profession and I find it to also be true. If this matches your persona, breaking out of those stereotypes are how you can get promoted more often than your peers. Being a talented developer who is also good communicator gets you recognized more than the peers who sit in the back, hoping recognition gets bestowed upon them. Great technical work does get recognized amongst peers and immediate management, however building your reputation amongst key stake holders give you a supplemental X factor at your W2. While your work is overtly technical, the people promoting you are often less so. Your manager may not have coded in a decade after moving up the ladder. Their boss even more so. That also doesn’t include HR, which often makes the final call to approve a promotion. You need at least all three on board to give you that pay raise.
Relaying your skillset is effectively a giant game of telephone. If the initial signal is weak, it will die out before it can reach the powers that be. Therefore, it’s on you to start off with the strong signal in this process. The easiest hack towards this is any sort of public speaking amongst your organization. If you’re an Agile practicing team, then you already have a built in Demo session where your team and others gather to see what you have built.
You need to remove the preconceived bitter taste of giving demos that I, amongst many other software devs, have had for years. Instead of seeing it as a waste of time or a fruitless effort, you need to flip the problem on its head and turn a problem into an opportunity. By giving a strong demo of your work, you will share with managers, senior managers, peers, projects managers, and more how good you are at your job. This is often the most productive facetime you will get with extended team members and people on the business side too.
You will use the software demo to convey the business needs to the audience, share your technical implementation along with all novel code, offer a live demo, demonstrate the value of the feature, and then take questions from stakeholders. We will go in depth on each step of giving a public presentation.
Software Demo Guide
Confirm the meeting
Before you start any public presentation you need to ensure your work environment supports the Demo loop. Agile shops will include this usually but if there is not a culture of Demos you probably have to fight up hill for this. If you wish to make this happen then lobby your boss and their boss and mention how this is a direct way to see the impact the team is making on the business unit. If your boss doesn’t agree, then you may need to side step to your product manager and schedule something your self. In this case I would demo larger features - multiple features on a longer time frame, as the 2 week sprint will often include smaller work such as simple bug fixes, API changes. I would leave the basic CRUD endpoints as just a smaller bullet point, but if there is new or interesting code involved, try to share that. Often new development techniques spur the rest of the team to copy or transform your work, especially at the smaller level corp, which is how you start building a good reputation.
The frequency of the demo will determine the amount of content to show. If this is a special project with a demo for your Director or VP put in much more work in every phase, as key business decisions will flow from what you show them. Often more senior level devs will need to build proofs of concepts and demo them to inform higher management of the potential future work.
Additionally, ensure that the meeting owner - either you, your boss, or PMs have a clear agenda of the demo material, and send over what you wish to demo in advance. Lack of agenda is a main reason stakeholders do not attend, so send it out early and determine the speaking order.
Once you have the demo setup it’s time to prepare to give the presentation.
Prepare the System
Demos are usually given the week after a sprint is done while a new sprint is in flight. This means there will be a few days between code complete and the actual display of the software. It’s important in these interim days to save all relevant testing data, API requests, data base setups, DB queries, Config values, Stubs, etc… so that once demo day comes, you do not have waste time and setup your environment again. Personally I always have to remember to seed the database with the correct data again come demo day, you do not want to make this a habit, especially if your feature is complex. You’ll waste up to half a day just setting the demo up, and you do not want to be stressed going into a presentation. I have certainly scrambled minutes before a demo to setup the database correctly and it is not fun. To get around this, in your Pull Request always add in relevant test data and configuration options to be used as a historical record of documentation. This will make your recall easier as you will have already context switched into a new task due to the new sprint.
By this point you will now understand if your software is in the correct state to demo. If this isn’t the case, please inform the meeting owner ASAP to reschedule if needed. Also if you find any bugs, do your best to avoid them in the demo. Again if your demos are frequent, you can afford some level of “off-ness” - known bugs can be fixed in next sprint, or incomplete features can be shown. Just make sure to note that and say, ”it’s prioritized”, which are magic words in the Agile world. This will comes down to your work culture here but my team is flexible and understanding that we have lots of work in flight and not everything is going to be perfect all the time.
Now that you have a working environment you need ensure that the environment remains stable leading up to the demo. Often the day before I try to set everything up, and then retest a few hours before demo time to ensure everything is working. Inform your team also of any important data that must not be changed. Often sprints have you working together on a feature, so it’s highly likely the state you put the system in may clash with another teammate, so confer and sort the details out. If you have shared testing environments then also ensure that no one deploys news code as a safety measure. Ideally your testing suite would catch any new bugs, but it’s easy to miss a case that results in a bug cropping up.
Build your Presentation Script
Now that everything is ready, you need to build your presentation. Before you start working on this, you need to follow the golden rule of any public speaking, “Know your Audience”. If this demo is mostly business side of the house, then limit technical details and focus on presentable features and mention business problems and solutions. If the demo is more technical folks, don’t be afraid to dive a bit, show relevant code, and more. However, even the most technical of folks need a business problem to understand the context and what needs to be solved. Often you’ll get a mixed audience so balance the business needs and technical presentation. Remember demos are supposed to show your skillset off, so optimize for the forum.