On software projects, we often have clearly defined deliverables. That’s very useful for staying focused, but it can make us a little narrow in our perspective. This post defines the concept of secondary deliverables as a tool for broadening our thinking, sharing knowledge, and raising the profile of an organization within their specific discipline.
What are secondary deliverables?
Secondary deliverables are artifacts produced in the course of your "main work" that can be made to be of value in a broader context – lessons learned from a specific task distilled into a generic, publishable form, or a workflow tool extracted from its original project. To formalise the term, a secondary deliverable is any content (documentation, code, workflow, etc.) that can be derived in a generic form from a specific task.
Secondary deliverables may include:
Blog posts
Podcasts
Video tutorials
Tweets
A talk given at a meetup or conference (which should be video recorded to maximise ROI)
Open source contributions
Let’s take a look at some examples.
Three tales of secondary deliverables
Tale 1: Developer Alex is working on a ticket for a client and writes an end-to-end (E2E) test to verify that the client’s acceptance criteria have been met. In doing so, Alex has to make several decisions about how often to reset the test database from fixtures, and when to roll on to the next test with the same data. In doing so, Alex is making a tradeoff between test execution time and isolation. Alex decides that this is worth doing a blog post about. Alex’s marketing department promote the post and, if the organisation is fortunate, it ends up being featured prominently on an aggregator such as Reddit or Hacker News.
Tale 2: Project manager Charlie trials running sprints from Wednesday to Tuesday rather than Monday to Friday. Charlie keeps a close eye on burndown and velocity and sees if any measurable gains are made. Charlie presents his finding at a local meetup and gets into a conversation with another project manager afterwards, comparing the strengths and weaknesses of various approaches. Charlie capitalises even further on this by recording and releasing a podcast with these PMs discussing the idea.
Tale 3: Operations engineer George has automated deployment of a system’s infrastructure on EC2 using Ansible. George thinks "hey, that wasn’t so hard as I thought" and produces a video tutorial for upload to Youtube. The organization feature the Youtube video on the company’s blog. The video gets spotted by a conference organiser, who invites George to give a talk.
These are just some examples of how adopting this mindset can work. Be creative!
Benefits of secondary deliverables
Enhanced knowledge base. It’s very tempting to solve a problem and simply move on, only to have the issue recur and not to be able to remember how you solved it. If you blogged about it, there’s a much stronger chance that you’ll be able to solve it quickly, and that if you’re not around, your colleagues at least know where to start! Blogging can help an organisation maintain a sense of progression.
Knowledge sharing. A private knowledgebase is one thing, but a public one is even better, as there is more impetus for it to be correct! The entire open source world is built on this ethos. More importantly, software development is a very young industry in the scheme of history, and best practices, such as they are, are in their infancy. Sharing discoveries allows us to coalesce on common patterns and ideas, and your contribution may trigger further insights in others who may be working on similar or parallel tracks.
Organisational perception. If you’ve solved a problem, or done something clever, why not shout about it? Let the world know that you’re smart people! Things like podcasts and tutorial videos can give an organisation an authoritative voice. Conversely, without blog content, technical articles and so forth, an organisation will struggle to position itself as thought leaders. If I’m looking at a tech company website, and there is no tech content on there, I am likely to dismiss that company pretty quickly!
Recruitment. A tech company with strong open source and blogging output, for example, is very attractive to many in the industry. Thought leaders like ThoughtWorks are considered desirable employers partly for this reason.
Greater variety. Frank Herbert may have called fear the mindkiller, but surely boredom is just as dangerous! Spending an afternoon or a week working on writing, blogging and video content derived from one’s primary tasks can be a fantastic way of recovering energy.
Reduction of siloization. Bearing secondary deliverables in mind as a team works on a project can encourage broader thinking. No disrespect intended, but if you leave your company’s profile solely to your marketing team, you can end up looking generic. Without technical blogging and technical content, how are you going to position your organisation in your industry? With secondary deliverables, you are actively supporting your marketing department’s efforts to show your organisation in a positive light. It’s taking your eyes off small, tight "KPIs" (which, in my opinion, are utterly poisonous) and giving an organisation-wide perspective.
Increased ROI. All of the benefits we’ve seen in this list can be summarised as Return On Investment - the secondary deliverables mindset is about getting the most you possibly can out of the hard work that you put in.
Risk mitigation
Secondary deliverables certainly aren’t "free" and do have some risks which should be considered. We’ll take a look at the top three.
Firstly, producing secondary deliverables inevitably exerts a drag on productivity. After all, if you’re producing a video, you’re likely not getting paid directly for it. I would contest, however, that you could consider this time to be coming out of the marketing and R&D budgets.
Secondly, secondary deliverables are the first things to go by the wayside when pressure is on as it’s difficult to justify their value in direct terms. When this happens, it can be frustrating to have a whole list of ideas and no time to implement them. This can be mitigated by planning in some slack time into everyone’s schedule. It won’t always work out, but if you start with some slack, then you stand a fighting chance!
Finally, there is the risk of accidentally leaking sensitive information. Much like code, all secondary deliverables should go through some form of peer review before being released into the wild!
Introducing secondary deliverables to your organisation
Although I’ve not really codified secondary deliverables before, on reflection, it’s long been part of my mindset, and that’s where it has to start. It is not about adding pressure to people to produce things outside of their remit: sometimes, an organisation can get hold of the concept of secondary deliverables and pressure its staff to produce more; that’s a total misrepresentation of what we’re advocating. A secondary deliverable should happen as a byproduct of somebody’s work, notas an additional pressure. Rather, it’s about taking time to maximise the benefits of the work that’s already being done rather than letting that value simply evaporate.
So, with that caution in place, what I recommend is to simply get people thinking about their roles more broadly. Lead by example, whether you are in a position of authority or not. In my experience, that is the most reliable way of effecting change. Start small, and be consistent. An internal podcast or team training lunch is a great place to start!
Wrapping up
The perception of your organisation is everyone’s responsibility, and adopting a mindset of considering "what can I take from this experience and how can I present it?" is a really good way of improving that. The examples I’ve talked about in this post certainly aren’t the only secondary deliverables; it’s much more about thinking “hey, this is a really interesting problem I’ve just solved, is there some way I can share that information with people in my organisation and in the wider community?”
I hope this post has given you some ideas. Why not get in touch and let us know what you think, or share some of your own ideas and post a link below?
