A Quick Raspberry Pi Project

Since about 2015 or so, it seems like there are always Raspberry Pi’s lying around the place, at work and home, just waiting for some project to come along to put them to use.

One of the Pi’s looking for a job as part of my home lab has found just itself retasked as a Plex Media Server following a very simple process.

  • A new Operating System was written onto the SDCard, this time out the OS chosen was the Raspberry Pi variant of Ubuntu Server order to have a more consistent experience across systems being used lately.
  • Once up and running and fully patched, the Plex repo was added and the Media Server installed via apt.
  • Directories were added to host the media library and the Plex configuration ran. Once complete it was a simple matter of connecting the TV to the new media server via the Plex app and enjoying the content I had that was driving this little endeavour in the first place.

I heard it said recently that a Raspberry Pi with decent enough storage can be purchased for less then the price of running an EC2 instance for a year, so when it fits the use case a Pi can be a great solution and even in the age of cloud there are still times when it’s better to run locally (streaming dodgy media being a classic).



Old Books, Russian Hip-Hop, and Database Imports

The value of learning about lots of different topics really comes to the fore when you spot a connection, however tenuous, between things that on the surface have no bearing on each other at all.

I recently picked up a copy of the first Joel on Software book having read the second book in the series and once been a fan of the blog, it seemed only right to revisit the insights into software development that Joel Spolsky shared with the world in the early 2000’s. In the fast paced world of technology the interest in this material, dating as it does from a pre-Agile and pre-Cloud age, is in considering what foundational and unchanging lessons are worth a refresher on as well as considering how things have changed since that time. The biggest surprise so far has been somewhat foundational as the chapter on character sets (The Absolute Minimum Every Software Developer Absolutely, Positively, Must Know About Unicode and Character Sets (No Excuses!)) has really made me reconsider a topic I felt I was pretty familiar with already.

So, this is the “old” book, but what’s that got to do with Russian hip-hop?

I’ve discussed my love of German industrial metal music in the past (in this post), safe in the knowledge that like many fans of the genre around the world, my inability to speak German has little to do with my enjoyment of the music and can in many ways heighten it through the air of mystery that surrounds the unknown. This mindset has proven useful in building an appreciation for other international music (Swedish Melodic Death Metal, obviously, but also French rock/metal, but that’s another story), and into this open-mind dropped some Russian hip-hop.

While watching a very dodgy Russian action movie late one night, I was rather taken with the track that played over the end credits, in that “I don’t understand the lyrics, but I love the tune” way familiar to Rammstein fans. However, not wanting to get caught out humming along to something grossly inappropriate, I decided to check out the lyrics on iTunes and found myself a most wonderful surprise in how they were presented in Russian Cyrillic, something I thought particularly cool as I still had thoughts of character sets dancing through my head along with a new found appreciation of how hard this type of thing can be to deliver. (I don’t know if there’s an official video anywhere, but check out this link to the tune that caught my attention: https://youtu.be/7yW0T04DCQ0)

So, here’s the Russian hip-hop, but where’s the (inevitable) database connection?

My recent interest in building an Oracle environment is related to restoring a dump file of a very old database of mine for educational purposes. A very, very old database of mine that was originally hosted on a Windows server many, many years ago. The dump file is intact however and the import was going fine right up until it until it wasn’t and a review of the log file was needed. In there lurked this error (more than once):

ORA-12899 value too large for column

This odd contradiction (how could a column be created too small when the import was creating the column as well as importing the data into the column so is fully “aware” of every aspect) is one of those misleading errors – the problem is character set related, caused by a mismatch between the source database and the target being too great to be resolved by the import process.

The solution to the import problem was to create another throw-away database configured with the character set of the import and from there to either clone the PDB or more interestingly to take a look at the Database Migration Assistant for Unicode (DMU) as a more permanent fix, but for me the funny thing is how you notice how the dots can be joined between radically disconnected things when you know or are at least aware of what to look for.

Why Install Oracle 21c on OL8 via RPM?

Far too often in home lab situations, where there’s some interesting idea to be explored, efforts get derailed as a result of sinking too much time into the environment setup particularly when something like Oracle Database is involved. Maybe the the initial idea is to play with data migration or to investigate some new feature or just to brush up on skills, but whatever the scenario there’s a need for an environment and then, just like that, a week has passed and you’re just about ready having hunted down all the obscure errors and issues thrown up as the setup has progressed, when you get distracted by something else as the idea you wanted to work on has been crushed by the weight of getting things ready.

For reasons that I suspect are more related to Cloud automation than home labs, Oracle has managed to package up the install of the database on Linux (up to Enterprise Edition!) into an RPM that actually works. They’ve been trying to do this for a while and previous efforts were a mixed bag of results that were better regarded as interesting curiosities as opposed to real and useful things, but now the 21c release RPM seems to be both very real and actually useful, in certain circumstances anyway.

Oracle has used an RPM to prepare hosts for database installation for some time now but the main install via RPM was just not right or simply didn’t work first time and as it wasn’t something worth putting time into as you’d never want to install this way for real the RPM install just wasn’t a thing, but times have changed and whatever the reason behind the development the RPM database install now works to the point where it’s useful for home labs, demos, and other throwaway scenarios, making it far easier to setup an environment with a handful of commands; one for the pre-install RPM, one for the Database install RPM, and one for a basic database configuration the sets up a container database and a pluggable database.

The RPM based install is incredibly handy for setting up non-production, “throw away to the point of being ephemeral” style environments or for testing out automation but the lack of control over the installation rules this approach out for production or other long-living systems where you’d need to know what was going on under the hood or if there were any configuration elements you want to change at install time; in many ways the RPM install is a lot like using a managed database from a cloud provider where the internal workings have been abstracted away and some functionality lost or restricted, which can be ideal depending on the use case.

From the perspective of the home lab the RPM based install is perfect for rapidly setting up a system for testing and learning, as long as the topic under consideration isn’t “How to setup Oracle in Production”.

Oracle RPM installer can be found here: https://www.oracle.com/database/technologies/oracle21c-linux-downloads.html

Considering The Scrum Guide

It is perhaps unsurprising when you consider the widespread adoption of the framework by development teams around the world that there seems to be almost as many variations of practices as there are teams working under the auspices of Scrum. Over the years since Scrum burst onto the development scene as a new way of organising to deliver complex work, a host of techniques, customs, and habits have found their way into how teams implement Scrum in the real world. Anyone who has worked with different teams in different organisations can tell you how these customs can vary and of the delight that can come with introducing to a team a practice that you saw work somewhere else.

However, amidst the myriad of associated practices something about Scrum has gotten lost. The core truths of Scrum, the underpinning theory that gives rise to core values that are to be exemplified by the team as they engage in the limited set of well-defined events that mark the cadence for delivering increments of value, don’t play as big a part in the day-to-day as the habits that have formed on top of the framework. It appears that a lot of teams have forgotten, or perhaps didn’t know in the first place, that Scrum is a defined framework and not a collection of habits that are supported by tools like Jira.

The Scrum Guide is the foundational document that outlines what exactly Scrum is, the values behind the framework, the people involved, and the events that need to take place in order for Scrum to be effective. Even as the primary source of definition for Scrum, the Guide is a lightweight document at only fourteen pages long, which is reflective of the philosophy that informs the approach; but the brevity of the document isn’t the only surprise.

The Guide is firm on what is and what isn’t Scrum, stating that the framework outlined in the guide is immutable and that any practice that does not completely implement everything described in the guide isn’t really Scrum at all. What’s interesting here is that a lot of the practices that you may see implemented as “Scrum” in the real world aren’t mentioned in the guide, though there is an acknowledgement of how these things come to be, facilitated by something of a loophole that allows for various techniques to extend Scrum without needing to be vetted or described anywhere in the core framework.

Where this takes a bit of a turn is when you look at how certain practices, for example having the Scrum Master or Product Owner never work on backlog items, contradict how the framework should operate as stipulated in the Guide, suggesting that teams that don’t ground their practices in the framework and refer back to the Guide to verify the techniques they are utilising may in fact be introducing problems rather than solving them.

The Scrum Guide is a surprising read and worth reviewing on a routine basis to help ensure that the practices being followed by a development team aren’t straying too far from the whole point of the framework: the central aim of generating value through adaptive solutions to complex problems.


Psychological Safety Webinar

Earlier today I was fortunate to be able to participate in a webinar for Laois and Offaly Education and Training Board on the subject of psychological safety in teams, which is a topic I care deeply about as it’s so essential for cross-functional agile teams to be able to operate well, but beyond that, ensuring psychological safety at work is in my mind simply the right thing to do!

Check out the video and slides below.

Lessons Learned in 2020

A lot has already been written about the year 2020 and I’m confident that an awful lot more will be written about the impact on society this particular year has had. As the events of the year unfolded and various aspects of life were forced to adapt to the different challenges that were thrown up, it seemed like more and more material for academic papers, theses, policy documents, training materials, and even half decent fiction was being presented on an almost daily basis. From the technology leadership perspective I think 2020 showed that there’s work to be done around how to adapt Agile processes to remote work, but while interesting this isn’t the only area where there’s something to be learned, so in the best traditions of the internet here’s a list of things I consider among the lessons 2020 taught.


Easily the single biggest take away from 2020 is in the field of communications. Over time many of us have developed a strong preference for written communication methods like email and texts to get our messages across to the point where phones are no longer deployed on desks by default and tools like Teams or Slack have become established as the comms tool of choice. However, a bias for a particular type of media doesn’t make it the best way to communicate and during difficult times like those experienced this past year when tensions ran a little higher than usual and nerves were a little more frayed the miscommunication issues known to be associated with written messages became more frequent.

Written communications just don’t work for everyone as some people don’t write clearly and some don’t comprehend willingly, which triggered a need to adapt how to communicate in order to accommodate these differences in style. While this became more obvious this year as all those hallway conversations that normally happen in the office just didn’t take place and were instead replaced by emails, the fact is that there is a broader lesson to be learned about the tools we use to collaborate with others as well as how we respond when faced with an email that seems unfair or overly critical. Taking a beat before responding or doing away with the CYA email in favour of a clarifying phone call is something that should be taken from 2020 and re-established as normal practice.

Risk Management

Wired published a great article in June 2020 about pandemic insurance and how no one wanted to buy any in 2019 (https://www.wired.com/story/nathan-wolfe-global-economic-fallout-pandemic-insurance/) and it speaks to the obvious about how risk is really managed in businesses around the world. Organisations need to get better at risk management. Right now “risk” is too often considered like a gamble that doesn’t pay off and therefore isn’t worthy of attention. Conversations about bus factor issues in teams all the way up to business continuity in the face of global pandemics or more localised and very real risks like fire never seem to resonate the way they should until it’s too late.

2020 made a distant risk into a crushing reality which cost people their jobs as businesses were forced to close and markets became inaccessible. In IT, a lot of firms discovered the consequences of under investment when they tried to get their workforces to operate remotely and in the panic of trying to get teams working the conversations about laptops and cloud as risk mitigators were forgotten. Suddenly, the only issue with getting a laptop was finding somebody to sell you one, whereas at the start of the year the justification arguments still raged as did budget fights around moving on-prem applications to the cloud. In hindsight these fights seem silly but it’s a pity that they ever happened at all.


The value of culture in an organisation is well documented but what interests me about culture when considering 2020 is how culture manifests in the real world in terms of traditions and cultural norms expressed by a team or firm as a whole. Established traditions are a valuable way to build and reinforce culture but where tradition is helpful at a practical level is as an aid in times of crisis.

Traditions remind us of who we are and help to ground us when times get tough. Teams that are encouraged to connect to their culture (like the very strong culture around software development) and create traditions of their own are able to guide themselves through new, high pressure situations with greater ease as they can base their actions on the standards of behaviour and insights of the community of which they are a part, and of which they are reminded whenever they do something “traditional” like a daily stand-up or distribution of a new set of stickers for laptops.


The concept of agility, as in adaptability in the face of uncertainty, was strongly tested in 2020. Companies struggle with agility, not just adopting the Agile values and principles used to guide development, but in being responsive to the opportunities and challenges that come along regardless of the scale of those events. Companies strategise and lay plans and place value in adhering to those plans without enough concern for the value to be delivered as a result of those plans. This results in long backlogs that teams are tied to delivering without regard for the potential need to pivot away from the backlog at short notice.

A stronger sense of agility suggests that teams should shorten the timelines of their deliverables in accordance with Agile practices, ensuring that stories are atomic and that it is possible to drop everything and pivot to something completely different by the end of the current sprint. Beyond that specific Agile action, there is a need to build capacity into teams to allow for a disruptive event to be capitalised on.

Away from development, 2020 showed that there is a benefit for organisations to think on shorter time frames, to iterate on most activities, to report frequently so that issues can be identified early and actioned quickly.


In times of disruption, whatever the cause, reassurance can be found in the regular routines of life. Real disruption triggers ad hoc responses and these responses too quickly become normal – how many times this past year did you hear the phrase “the new normal” to describe pretty much anything that was happening? Accepting ad hoc structures as normal isn’t the most productive approach nor does it make for happy teams, as trying to work in uncertain times using uncertain methods only creates stress.

It may seem contradictory but agility thrives when there are structures in place that promote responsiveness, as long as those structures build capacity and recognise the activities that are really going on in the organisation. Regularly scheduled cadences of work that facilitate as much BAU as possible are absolutely essential as are techniques to identify what constitutes “Business As Usual” in a world where change is a constant. A good example of this that was validated by the events of 2020 is that meetings specific to a narrowly defined topic should be minimised where possible and more flexible structures be implemented in their place that can handle when things change.


It’s a truism that we learn more from hard times than from good, but it’s also too often true that we never learn. Anyone who’s worked a project in the real world knows that the “lessons learned” part of the process is frequently skipped due to time constraints, which is such a shame. 2020 was a year where a lot of people had too much time on their hands, stuck at home with nowhere to go, but even after having all that time we should still take a little more for a retrospective on what happened, how we handled the situations presented, and what we can do better as a result of having learned a little from the experience.

My Role

As someone who has spent their career working with systems I have come to love a good framework. Taking a systematic approach to how things should operate enables me to conceptualize the tasks at hand and to identify gaps and weak spots so that they can be managed successfully. Identifying the component parts of my new role as Director of Software Innovation with ACETECH and weaving them together into a framework of sorts has helped me in these early stages to approach some difficult topics with confidence as well as quickly establishing where I can add value.

Having spent some time deep diving on where things are going well and where there are definite needs for improvements with my new employer, I have worked out that there are four major focus areas of the role:

  • Product Management
  • Team Leadership
  • IT Management
  • General Management

As I worked out how to group my work into focus areas and these four headings emerged, I realised that only the people focused area was about leadership in the truest sense whereas the other three seem more accurately defined as management areas. This is reflective of how I have assessed the job ahead of me and how I feel that so much of my focus needs to be on delivery and addressing certain key challenges with processes and approaches, as opposed to needing to “manage” the team I am working with. To put it more succinctly, the processes need management capability whereas the people deserve leadership.

Product Management

The main thrust of the role is about delivering software products. ACETECH produces IoT devices that are installed into vehicles to aid in the management of the vehicle, the operation of the vehicle and more, on into areas like real-time tracking of high-value assets. In order to unlock the value of these devices, customers are given access to a suite of software tools delivered in a SaaS model, that enables them to view, manipulate, and derive even more value from the data that is captured from the devices on their vehicles.

All software benefits from strong product management, and there is a definite opportunity here to implement some new approaches to product management that I am sure will help to improve the pace of delivery while also better addressing the needs of our customers.

Team Leadership

While there is significant focus on the Product Management aspects of the job, for me the most important aspect of the job is managing the development teams, meaning directly managing the team based in Tullamore but also working with remote teams around the world, both in-house and outsourced.

Managing a team is an absolute joy, either regardless of the challenges or maybe because of them. Walking into a situation where a team has been without direct technical management for a little while was especially interesting as it had highlighted the value a manager can bring to a team in terms of offering guidance on activities for a given period, providing structure in terms of how things need to be done, delivering feedback and developmental advice, but most essentially acting as a buffer between often conflicting needs of the business who had gotten used to approaching engineers directly and demanding action on a variety of things.

The nature of managing the outsourced teams is different in that their performance management is more clear cut from my perspective but I still want them to operate in a certain way, to utilize the same tools as everyone else, and to align their processes as closely as possible when it comes to areas like Agile. The distance and time zone differences are challenges but not insurmountable especially when taken properly into consideration – simple tricks like including the timezones of the outsourced teams on my Outlook calendar are gentle reminders that other people are experiencing their day at a different point to us when scheduling meetings or calls.

IT Management

Every company is in someway a technology company due to the reliance on Information Technology that all businesses have. In order to be able to unlock the value of that technology there is an ever present need for someone to be thinking about how the internal network is managed, how the hardware and software we need is purchased and supported in the long run, and how the whole operation can be kept secure.

In a practical sense, for smaller organisations there’s little chance of having a dedicated Systems Administrator, despite the need for that type of focus, and ours is no different with Sys Admin falling to members of the Software Engineering team. I’m not opposed to this in principle as that team are the ones best placed to look after the running of a network but also because it’s good practice for those who are tasked with looking after a cloud estate to understand the fundamentals of networks and the types of issues you will encounter when users are unleashed and where better to learn that in a realistic but also relatively safe manner than a company LAN?

General Management

As a member of the leadership team, I have a duty to contribute to the broader running and direction of the company as a whole, beyond my areas of direct responsibility as part of a holistic management structure. That being said, there is a significant opportunity for me to address the impact of software and data products on the strategic development of the company, by looking at how software can drive sales and help push the company into new markets.

More broadly though, this part of my role is for me all about delivering at a higher level, about making a mark on how the company will grow into the future, about setting the tone in terms of culture particularly around diversity and inclusion, and about guiding us to greater success through initiatives like strategic partnerships with other technology organisations but especially with local educational institutions, and not just for recruitment purposes but also to contribute to, and of course benefit from, original research.


There is always more to a role than can ever be accurately captured in a job spec and it is this element of possibility that often brings the most rewards from work; in the spaces between the lines of a job description lies the chance to do something wonderful, though it is something of a skill to be able to spot those opportunities. To that end I have found that, in the early days of starting in my new position at least, it has been beneficial to classify the major areas where I can make an impact and thus put some level of structure around where I need to focus my attentions and where I can develop the technology offerings of ACETECH.

Go Big and Go Home


A new opportunity has presented itself to me that is so aligned with my desired next move that it’s hard to believe. Next week, I start a new role heading up the software engineering department of a technology company located in the Irish Midlands; in fact, located about 3 minutes from my home. And this isn’t a small opportunity, this is the chance to head up the software delivery aspects of a global player that makes a real impact on people’s lives.

The Commuter’s Tale

For about twelve years or so, with only one or two very brief exceptions, I have commuted from my hometown of Tullamore, Co. Offaly, to work in Dublin. For most technologists in Ireland, Dublin is where the action is. There you will find all the major technology companies as well as the Irish head offices of so many financial institutions and other organisations that depend on hired geeks that if you’re a technology professional of pretty much any type, most of the opportunities for you will be located there. Not all, of course, but most of them, and certainly the better paying ones.

Commuting to work is an accepted part of modern life and something that nearly everyone must do in some way. What marks out “Commuting” (with a capital C) as something different is the scale involved. Getting to and from work is commuting, getting up at an early hour and taking the train halfway across the country every working day is Commuting!

Humble bragging about how far you’re prepared to travel for work aside, commuting long distances has a lot of downside; it obviously takes a lot of time, time that is spent away from family, friends, and being a part of the local community in any meaningful way. There are financial costs to commuting a long way, with train tickets for my type of journey reaching several thousand Euro every year and travelling by train every day brings its own set of challenges. And of course, there are the early starts and late finishes that combine to make every day a “very long day”.

Making a Down into an Up

During my time commuting on the train from Tullamore to Dublin I have tried to make the best of that challenging situation. At first, I did all the things commuters do; I watched movies on laptops, TV shows on iPads, listened to podcasts on my phone, and read many, many books. After a while though these techniques for killing time lost their appeal and I came to the realisation that I had to do something a little more productive with the roughly ten hours every week I spent on the train. I started studying.

As part of a work initiative around project management, I found myself attending a week-long PRINCE2 course where the plan was to sit the first, foundation-level exam at the end of the third day before trying at the practitioner exam on the fifth day. In order to be in with a fighting chance of passing it was necessary to do some study in your own time. Considering what was at stake as well as how best to pass these exams I made use of the time I had on the train to study, and I found that it worked amazingly well. Not only did I pass the exams but I found myself in the strange situation of being almost disappointed when the train arrived at my stop, I found that I could always use a just a little more time with the books and always expected that I had more time than I really did, a marked difference from times where the journey seemed to drag on for ever!

That course set me on the path of studying on the train as a way of passing the time constructively. After PRINCE2 I studied for and passed the ITIL foundation exam, followed by the AWS Solution Architect Associate exam, and then five of the CIMA accountancy exams to earn the Certificate in Business Accounting. With that hanging on the wall, I turned my attention to degree level study, pursuing the University of London BSc in Management and Digital Innovation.

A Base of Operations

Even though I was making something of the time I spent travelling every day, there is no escaping that I want to be able to spend more time nearer to home, to effectively be based out of the Midlands region as opposed to only living here. The heartlands of the country is my idea of a good base of operations for logical reasons like proximity to several major towns and cities, and for the simple, more human fact that this is my home. Our environment can energise us, it can motivate us to excel, it can help to remind us of who we are and where we come from which is an essential part of figuring out where we are going; and it’s vitally important that it’s “we”, as being a part of a community is important for social animals like us.

The region is not overly populated, so participating in life in the Midlands requires to be part of communities that are pulled together from different towns, villages, and parishes across the four counties, which brings surprisingly different insights and points of view. This is where I want to spend the majority of my time, not all my time to be sure, there’s a wide world out there to explore and experience, and working in technology has provided me so many great opportunities to see the world that I could never fully retreat away from what’s out there.


The ability to compromise is important in order to successfully navigate relationships and maintain a healthy balance in life, but there are also times when something is important enough that it’s worth pursuing to the fullest extent, to not settle for something nearly as good, which makes the ability of recognising when a goal is important enough not to compromise on a perhaps more valuable skill than understanding where ‘good enough’ lies.

Regardless of their form, career ambitions can be such significant drivers that they can easily lead to frustration when the pace of progress is slower than desired, which it nearly always will be as there will be so many variables beyond anyone’s control. You will need patience as you gain experience, learn the right skills, build a network, and wait for the right opportunity to present itself, so it is vital that you are happy doing what you’re doing during the wait, especially as you will need to excel in the role you are in so that you have a better chance of achieving the role you want.

My experience taught me all this and more. I had my own ideas around what compromise looked like that I took comfort from them as they were nearly as good and felt more achievable. When asked what the future held for me I always pointed to those ideas, over time almost discounting the possibility that my primary goal could ever be achieved, however when the right opportunity arose I was ready, moved faster than the competition, and achieved that goal. I now eagerly face into a new challenge, one that will give me the chance to make the type of positive impacts I know I can deliver.

One odd thought does occur to me though as I gear up to “work from home(town)”. Maybe there is, in some part of me, an actual desire to Commute. Yes, that arrangement was certainly born out of necessity and was a huge pain, but it does have upsides, with an important aspect for me being the realisation that in many ways our commitments make us better people, like how having to catch a train early in the morning makes you regulate your bedtimes and clothing preparation. Working to the train schedule made me disciplined in ways that I never would have imagined before needing to make that daily journey. Perhaps the far future will lead me back to some sort of hybrid or split-time arrangement between home and a city, but for now I am grateful for the chance to make an impact in the town and region that I call home.

Prepare to Fail

There’s always a lot going on in work and it can be easy to sacrifice essential, foundational activities in order to progress the “real work”, but doing so eventually takes a heavy toll. Just like spending enough time contemplating what’s being done and why and if that’s the right thing to be doing, there is a need to be prepared and thus avoid going into every situation trying desperately to figure out what’s going on and determine your position on the fly, a position that you may regret taking and finding you later need to defend out of not wanting to loose face.

Some activities demand preparation, it only takes one attempt at winging a presentation to convince most people of the value of being prepared, whereas it is too often the norm, for example, for people to arrive in meetings late and utterly unprepared, which is just a waste of everyone’s time. Again, this type of problem is all about time management. How many back to back meetings or events fill the calendar? How much time is set aside for preparation, if any? And how would you feel if a colleague blew-off a meeting you considered important in order to prepare for some other meeting or event?

Personally, I’ve seen too many organizations where terrible meeting etiquette prevails, from an over reliance on using meetings to actually do work, to the lack of defined purpose or an agenda, and so on, with a particularly nasty vice being the continuous overloading of calendars with recurring events and double, triple, and more bookings, and in those organizations a common underlying issue (no doubt one of many) is the lack of consideration for colleagues. Being busy can wrap us in a sense of urgency that can manifest as a feeling of self importance that in turn erodes the consideration we would normally have for those around us.

One way to help restore that consideration might be to build enough sacred time into our schedules to ensure we are prepared for the events that keep the wheels turning in our respective organizations, and in that small way show some professional consideration to those around us and start to limit the urgency that’s pressing us to be so unprepared in the first place.


I flip-flop on the subject of whether to use a paper notebook or to use a laptop for everything including note taking in meetings and capturing stray thoughts. My indecision comes from appreciating both sides of the argument for either tool with laptops claiming the higher ground in terms of efficiency but loosing out to things like noise levels, having the opened screen imposing a barrier between you and other people, the issues around battery life, and the distractions that come with the installed apps all clamoring for your attention, usually when you need to be more focused.

Recently I’ve noticed a previously hidden benefit of using a paper notebook as a tool to monitor commitment levels, particularly when you’re prone to over-commitment in a busy organisation.

Once upon a time it was normal for students to take notes in lectures to later write-up into proper materials that could be used for study. This concept is where my paper notebook come back into play as it is certainly beneficial to spend some time digesting notes, transcribing them even, as an exercise in thoughtfulness around work.

However, when time is limited, do you have enough for this type of seemingly unnecessary activity? Arguably, if not, can you be sure you’re spending enough time thinking about what you’re doing at all, or are you simply running from meeting to meeting, lurching from issue to issue, and hoping that you’re doing the right thing in the heat of the moment?

Taking time out to be mindful of your work is a proactive thing to do, as counter intuitive as that may seem, and thinking about something is getting ahead of the issue. If there aren’t enough hours in the day to dedicate some time to this, then perhaps it’s time to assess if you’re over committed, need to delegate more, or in some other way need to address your workload; this is the action I’m taking away from the current use of a notebook and pen!