Eating your own dog food
A delicious can of dog food. Apple Image Playground
I have worked in a number of small to medium size teams, some scrappy startups and others embedded in monolithic corporate entities. In latter years have focused on driving the use of ‘e’ technologies in clinical research.
For a small team of engineers, testers and product specialists to be successful, to punch above its weight, I strongly believe they need to eat their own dog food (it’s a reference).
Ideally you’d use your own ‘e’ technology platform in your daily business.
That can be tricky for technologists working outside of clinical research.
So what do I mean? How can you apply the philosophy of eating your own dog food to a team making ‘e’ products?
We use portals, wikis, public facing websites.
We store information in shared places so that it is discoverable, searchable and available.
We build, collect, collate and store knowledge systematically to stop us re-inventing the wheel.
If we are running our business off email, we are doing it wrong. Use service desk software, use CRMs, use project management tools.
If I see documents that need ‘wet ink’ signatures, we are doing it wrong. Use DocuSign.
If I see an Excel project tracker, we are doing it wrong. I’ll concede it’s hard to escape Excel for budgets, forecasting and financial analysis.
I am going to turn up the crazy now…
If I see us using Word, we are doing it wrong. Outside of lawyers and contracts, we don’t need it.
If I see SharePoint, we are doing it wrong. Although it’s marginally better than storing documents in files and folders on servers.
The final heresy…
If I see PowerPoint, we are doing it wrong.
Demo your product, create video recordings of your product, document your product in public facing websites.
Don’t PowerPoint your product.
I know I have presented some sweeping statements that will have exceptions, but a person has to have principles right? 😄
Remember, I am presenting these principles in the context of a small technology team and not arguing them from the perspective of a large corporation (although maybe…).
I am conscious of, and not advocating shadow IT (although might have been a little guilty of this in the past 🙈). I realise there are concerns about going rogue because of security issues, data retention issues etc.
But sometimes a skunkworks project (it’s another reference) or a scrappy startup can just move so much faster and still work within the bounds of the law and best practices.
So, junk the Microsoftian file / folder and store & forward paradigms and jump on ‘e’ tools to support your ‘e’ product.
Thanks to the many colleagues who have helped me develop my thinking in this area over the past 20+ years. It’s your fault 😉
Links in this article…
This article was first published on Linkedin.
