In the age of AI (Artificial Intelligence) and machine learning, there is a temptation to assume that all we need to do is to ‘train’ our software, load in the data, and wait for the answer.

“42” instantly comes to mind - for those of you old enough to remember the prescient imagination of Douglas Adams and “The Hitchhikers Guide to the Universe”.
There is no question that both AI and machine learning have a huge potential in helping us better understand the world. Computers provide us with the capability to interrogate the vastness of our data libraries and to draw out patterns and conclusions that we would otherwise not have the time to do. The developments in these techniques are impressive. If you are not convinced check out the Google AI site (https://ai.google/).

But we need to be careful.

Not because AI is not useful, it is. But because there are fundamental issues around data and analytics that we must answer first:

1. Are we clear about the question(s) we are asking of our data and software? (Douglas Adams’ premise in Hitch-hikers).
2. Will we be able to understand the answers when we get them?
3. Do we trust our data?

Each merits an essay in its own right.
​
Here, I am going to focus on the third – do we trust our data?

I have spent much of my career designing, building, populating, managing, and analyzing ‘big data’. From using paleobiological observations to investigate global extinction and biodiversity, to testing climate model experiments, to paleogeography, and petroleum and minerals exploration.

Having worked at each stage from data collection to data analytics I have gained a unique insight into data, especially big data.

Most databases are built to address specific problems, and no surprise, these rarely give us insights beyond the questions originally asked.

But when we think of Big Data and AI we are usually thinking of large, diverse datasets with which to explore, to look for patterns and relationships we did not anticipate.

My interest has always been in building these sorts of large, diverse ‘exploratory’ databases following in the footsteps of some great mentors I was privileged to have at The University of Chicago, the late Jack Sepkoski, and my Ph.D. advisor Fred Ziegler.

‘Exploratory’ databases have their own inherent challenges, not least the need to ensure that they include information that can address questions that the author has not yet thought of… That is a major problem.

This requires specific design considerations, especially, as I argue you here, the fundamental importance of ensuring that we know the source and quality of the data we are using. Because it is upon these data that we base our interpretations, and from those interpretations the understanding and insights we derive.

If the data are flawed then everything we do with that data is similarly flawed and we have wasted our time.

This is even more important when we are analyzing 3rd party databases that we have not built ourselves. How far can we, should we trust them?
​
In short, we can have the best AI system in the world and the most powerful computers, but if the data we feed the system is rubbish, then all we will get out is rubbish.

In discussing data and databases it has become de rigueur to quote Conan Doyle: “Data, data, data! I cannot make bricks without clay!” Good old Sherlock, a quote for every occasion… ("The Adventure of the Copper Beeches" Sir Arthur Conan Doyle, 1892)

But what do we mean by “data”? 

When I started to write this article, I thought I knew.

But in looking through the literature I soon realized that such terms as “data”, “Big data” and “information” were vaguely defined and used interchangeably.

So, to help anyone else in the same position here is a quick look at the terminology, including some that you may or may not be familiar with. This is summarised in figure 1. A more comprehensive set of definitions is provided as supplementary data in the pdf version of this blog article.

The fundamental progression here is from data to verified data to knowledge, understanding, and insight (see the recent Linkedin article by the branding company LittleBigFish). 

Admittedly, in many ways trying to define the relationships between observations, facts, data and information is semantics.

For databasing we can reduce this to data and verified data, and this takes us back to the need to audit and qualify our data: the data to verified data transition.

When designing and building a database we need to ensure that we include information about the data.

For spatial geological data, we need to answer a range of questions about the data, including the following:

• What is the provenance of the data?
• What is the resolution of the data?
• What is the type of data?
• What is the data grain?
• What is the spatial and temporal accuracy?
• What is the spatial and temporal precision?
• What is the analytical technique used?
• What is the analytic error?
• If an interpretation what is it based on and why?

(For further information on this see Markwick & Lupia (2002)

Providing the answers to these questions will enable anyone using the database to replicate what was done and to make decisions on how they use the data.

Where this applies to the database as a whole it will be recorded within the metadata. The metadata also provides information on the intrinsic characteristics of the data in a database, such as data type, field size, date created, etc.

This is different from extrinsic information, such as the input data used for a specific database record. This extrinsic, record specific information is stored within the data tables themselves. For example, in our Structural Elements Database (see figure 3 attribute table), features may be based on an interpretation of one of several primary datasets, including Landsat imagery, radar data, gravity, magnetics, and seismic. This needs to be recorded because each primary dataset will have its inherent resolution and errors.

I have always believed that more explanation is required. So, within my own commercial and research databases, I have added text fields for each major inputs to describe the basis of each interpretation. For example, an “Explanation” field provides a place for describing exactly how a spatial feature was defined.
​
All records are then linked to a reference library through unique identifiers (Markwick, 1996; Markwick and Lupia, 2002). This is a relatively standard design. (Nb. In my research, I use the Endnote software, which I have used since my Ph.D. days in Chicago in the 1990s and which I can highly recommend https://endnote.com/)

The problem for database design is knowing what level of auditing is needed to adequately qualify an individual record. This will depend on whether the record is of a primary observation – analytical, field measurement, etc – or an interpretation.

Interpretations can change with time. For example, a biostratigraphic zonation used 30 years ago may not be valid today, but the primary observations of which organisms are present may still be true (accepting that taxonomic assignments may also change). So in a database of this information, you would need to record not just the zonation (interpretation), but also what it was based on – this might either be a complete list of the organisms present (the approach I took with my Ph.D. databases) or simply a link to the reference which contains that information.

Another example that has driven me to frustration over the years is the use of biomarkers in organic geochemistry. Interpretations of these have changed frequently over the last 40 years. For example, the significance of gammacerane (the gammacerane index) which I remember in the 1980s as an indicator of salinity (Philp and Lewis, 1987), but which may (also) indicate water stratification (Damsté et al., 1995), or water stratification resulting from hypersalinity (Peters, Walters and Moldowan, 2007), or none of the above.

In both of these examples, we have an analytic error – misidentification of a species down a microscope or errors associated with gas chromography (GC), or GC-mass spectrometry (MS), etc – and an error or uncertainty in the interpretation.

In any database, we, therefore, need first to ensure that we differentiate between the two: observation and interpretation. We then need to record auditing information that covers both: what the biomarker is (observation); the analytic error in the observation; the interpretation; a reference to who made the interpretation, when, and why.  To which we can add a comments field and a semi-quantitative confidence assignment by the person entering the data into the database (see below).

By recording the reference of the interpretation and analysis we can then either parse the data to include or reject it for specific tasks or update the interpretation with the latest ideas. Again, this would be attributed as an update or edit in the database and audited accordingly (in my databases I have a “Compiler” field that lists the initials of the editor and month and year when they made any changes – in corporate databases you may need to have more detail than this).

We need to keep track of all these things in a database if the database is to have longevity and application.

This is not easy.
​
The consequence is that within a database we end up with most of the fields being about auditing our data, rather than values or interpretation (Figure 3). 

In spatial databases we also need to understand scale and resolution.

We all ‘know’ what we mean by “map scale”. It is something that is always explicitly stated on a printed, paper map and provides an indication of the level of accuracy and precision we can expect (not always true but our working assumption).

But digital maps are a problem.

Why?

To answer that, ask yourself a simple question “what is the map scale of a digital map?”

To understand this question, open up a map image on your laptop or phone and then zoom in. Is the scale the same before and after you zoom? – measure the distance on the screen!
The answer is of course “No”. The map image may have a scale written on it, but on the screen, you can zoom in and out as far as you want (Figure 4).

This immediately creates a problem of precision and accuracy (see below). How far can we zoom into a digital map before we go beyond the precision and accuracy that the cartographer intended?
In building digital spatial databases we can address this in one of several ways

1. Specify the mapping/compilation ‘scale’ – this is the stated map scale at which the feature was captured on the screen or digitized.
2. Record the size of each feature (this is automatically calculated in most GIS databases)
3. Add an attribute for resolution or size-related – in the Structural Elements Database, we have included a semi-quantitive attribute (Class) that records the impact of the feature on the crust or stratigraphy

As with all data issues, the importance is being aware there is a potential problem here.
​
Two further terms you may find of use when thinking of spatial data are “grain” and “extent”. These are both adopted from landscape ecology. Grain refers to the minimum resolution of observation, for example, its spatial or temporal resolution (Markwick and Lupia, 2002). Extent is the total amount of space or time observed, usually defined as the maximum size of the study area (O'Neill and King, 1998). So, a large scale map may be fine-grained but of limited extent. The key is specifying this for each study. 

Differentiating between precision and accuracy is something of a cliché (see Figure 5). But no less important. A geological observation has a definite location, although it is not always possible to know this with precision, either because the details are/were not reported, or the location was not well constrained originally. Today, with GPS (Global Positioning Systems), problems with location have been mitigated, but not eliminated.

For point data, this can be constrained in a database by an attribute that provides an indication of spatial precision. In my databases, this is a field called “Geographic Precision” (Table 1). The precision of lines and polygons can be attributed in a similar way, although in our databases we have used a qualitative mapping confidence attribute which implicitly includes feature precision and accuracy (see below).

Temporal precision and accuracy are more difficult to constrain in geological datasets. Ages can be made incorrectly, be based on poorly constrained fossil data, or radiometric data with large error bars. In some cases, there may be no direct age information at all, and the temporal position is based on geological inference. Ziegler et al (1985) qualified age assignments based on their provenance, which we have also adopted.

Whilst analytical error is numeric, and sometimes we can assign quantitative values to position or time (± kilometers, meters, millions of years) this is not always possible. So another way to approach the challenge of recording confidence or uncertainty is to have the compiler assign a qualitative or semi-quantitative assessment.
​
In our databases, we again follow some of the ideas outlined in Ziegler et al., (1985), Markwick and Lupia (2001), Markwick (1996). These schemes are distinct from quoted analytical errors and are designed to give the user an easy-to-use ‘indication’ of uncertainty (Table 2). 

The advantage of this approach is that it is simple, which encourages adoption. The disadvantage is that even with explanations of what each code represents (Table 2), there will be some user variation. Nonetheless, it provides an immediate indication of what the compiler believes, which can then be further explained in associated comments fields.
​
In map view, colors can be applied to give the users an immediate visualization of mapping or dating or other confidence depending on what the user needs to know. An example of the mapping confidence applied to structural elements is shown in figure 6. Confidence is further expressed visually using shading, dashed symbology, and line weighting (this is discussed in our database documentation and will be the focus of an article I am writing on drawing maps).

By including fields for record confidence means that the database can be sorted (parsed) for good and bad ‘quality’ data.

Why is this important?

Why not do this on data entry?

You could, for example (and I know researchers who do this) make an a priori decision and remove all data that you believe is poor and not include this in the database.

But what if this ‘poor’ datum is the only datum for that area or of that type of data that you have? For example, in a spatial database, we may have a poorly constrained data point for a basin (we know its location to within 100 km, but no better), but no other data.

That data point is then important or could be, but is spatially poorly constrained – in this case, a low spatial precision.

We need to include this record in our database, because it is all we have. But we need to ensure that the record is audited to reflect the uncertainty in its location.

A priori decisions on which data to include in our database based on an initial assessment of data confidence are therefore to be avoided:

1. This may be all we have
2. This may point us to where we need to actively find more data
3. You can improve/update/replace that datum as better information becomes available – as long as you have attributed correctly

​

Given how much information we need to record to qualify our data, it will come as no surprise that data entry compliance is a major difficulty.

Database population is very tedious. This can result in errors, or short-cuts being taken, or worse.

As an example of what can happen, I had one senior geologist, who will remain nameless, point-blank refuse to attribute his interpretations, stating that GIS and attribution “were beneath him”. After pressure, he acquiesced. But during my QC stage, I found that in a fit of pique he had copied and pasted the same attribution for all records – assigning “Landsat imagery” as the source for submarine features was a bit of a giveaway! All of his work had to be redone, by me as it happened…

This case highlights a serious challenge, to get staff to realize the importance of the audit trail and to fill in these fields.

From my experience let me suggest four ways you can do this (other than threats):

1. Make data entry as clear and as simple as possible. This goes back to something that my friend Richard Lupia and I wrote back in Chicago, that a “database needs to be simple enough to be used, but comprehensive enough to be useful”.
2. Have the data entry teamwork with and update an existing dataset. When faced with a previous entry that does not have enough information to make a decision the new compiler will, hopefully, realize how important including that sort of information is. A common problem is that the data entry team does not use the data. They, therefore, do not have a vested interest in it. Ideally, you need everyone involved in all steps.
3. A rigorous QC workflow – this was something we had at BP when I was an intern spending seven weeks entering data into a wells database. In the late 1980s, this was entered by line code… After completion, the well log was printed and checked by hand by a more senior biostratigrapher. Given this was a bed-by-bed database you can imagine the time and work needed to check every entry. But it was critical
4. Automated QC – design the database so the fields have to be filled in. Dropdown menus, limited options.
5. Automated data entry. For some types of data, this makes sense - capturing data tables -, but care must still be taken. Other automated techniques, such as lineament analysis in structural element mapping are useful to help systematically identify patterns but also can lead to a mess. Such methods still need human interrogation.

 
The solution here is to recognize that technology is there to help you reach answers by removing the most tedious repetitive tasks, and analyzing and managing large datasets. But we must never forget that we still need to know our data. It is a truism that the more remote we get from our data the least likely we are to understand any answers our AI system gives us.
​
We also need to remember that databases are ‘living’ in the sense that you cannot, should not simply populate a database and walk away, but recognize that you need to update and add to your database as more information becomes available.

There is no question that AI and machine learning have much to offer us in data science. But where I worry a little, or perhaps more than a little, about AI is how it is being perceived in many companies as a black-box solution to the problem of big data.

We as users need to have enough knowledge to understand the answers such systems give us, but more importantly, as I hope I have demonstrated here in this brief introduction, we need to ensure that we know where our data has come from and that we trust it. This is not just in the sense of computer verification, but in constraining the nature of the original data itself, how it is recorded, how confident we can be with this recording.
​
This process of qualifying and auditing data is admittedly laborious as my examples of solutions show, but I hope you will have seen how powerful even the simplest schemes can be when used systematically.

​A pdf version of this blog is available here for download.

As some of the more observant readers will have noticed the sediment in the picture at the beginning of this article is not clay, but sand.

​As I have emphasized throughout, you need to know your data – be careful what you build from

Callegaro, M. & Yang, Y. 2018. 23. The role of surveys in the era of "Big Data". In The Palgrave Handbook of Survey Research eds D. L. Vannette and J. A. Krosnick). pp. 175-91.

Damsté, J. S. S., Kenig, F., Koopmans, M. P., Köster, J., Schouten, S., Hayes, J. M. & Leeuw, J. W. d. 1995. Evidence for gammacerane as an indicator of water column stratification. Geochemica et Cosmochimica Acta 59, 1895-900.

Markwick, P. J. 1996. Late Cretaceous to Pleistocene climates: nature of the transition from a 'hot-house' to an 'ice-house' world. In Geophysical Sciences p. 1197. Chicago: The University of Chicago.

Markwick, P. J. & Lupia, R. 2002. Palaeontological databases for palaeobiogeography, palaeoecology and biodiversity: a question of scale. In Palaeobiogeography and biodiversity change: a comparison of the Ordovician and Mesozoic-Cenozoic radiations eds J. A. Crame and A. W. Owen). pp. 169-74. London: Geological Society, London.

O'Neill, R. V. & King, A. W. 1998. Homage to St. Michael or why are there so many books on scale? In Ecological Scale, Theory and Applications eds D. L. Peterson and V. T. Parker). pp. 3-15. New York: Columbia University Press.

Peters, K. E., Walters, C. C. & Moldowan, J. M. 2007. The biomarker guide. Volume 2. Biomarkers and isotopes in petroleum systems and Earth history, 2nd ed.: Cambridge University Press, 704 pp.

Philp, R. P. & Lewis, C. A. 1987. Organic geochemistry of biomarkers. Annual Review of Earth and Planetary Sciences 15, 363-95.

Samuel, A. 1959. Some Studies in Machine Learning Using the Game of Checkers. IBM Journal of Research and Development 3, 211-29.​

Ziegler, A. M., Rowley, D. B., Lottes, A. L., Sahagian, D. L., Hulver, M. L. & Gierlowski, T. C. 1985. Paleogeographic interpretation: with an example from the Mid-Cretaceous. Annual Review of Earth and Planetary Sciences 13, 385-425.

Alexander's restaurant (http://jalexanders.com) at the corner of Westheimer and Wilcrest had long been my refuge. It had been there for as long as I had been visiting Houston. First as Houstons then as Alexanders. A place to relax and think, to meet with friends, enjoy a steak after a long flight or a days’ meetings.
 
My usual dilemma was whether to go for their ‘famous’ baby back ribs or the filet mignon with a béarnaise sauce. Then there was their “vegetable of the day” of which the sautéed spinach, creamed spinach, grilled zucchini, and beefsteak tomatoes are, or rather were, worthy of note.
The baked potato fully loaded was usually a step too far as I saved myself for their wonderful carrot cake. So moist. So bad...
 
And now it was gone…
 
Whilst for many of you the closure of Alexanders is completely inconsequential, especially now, and indeed most of you have probably never heard of Alexanders, for me, it was yet more evidence of changing times and the loss of reassuring certainties. Little did I know…

The oil and gas industry has always been cyclic and many of us have seen many - far too many - downturns and recoveries. Indeed, many old-timers seem to keep track of their careers by the number of downturns they have seen and survived.
 
Each recovery in the past has seen an increase in budgets and a major hiring drive, as business returned to 'normal'.
 
But the last downturn has been different, starting in 2014, and now exacerbated by the consequences of COVID-19.
​
Yes, we as an industry are faced by many challenges, not least the transition from fossil fuels to a more diversified energy portfolio, the vagaries of unconventionals or the political game playing between the worlds leading oil producing countries. Each deserves a blog in its own right.

But the change that concerns me the most, and which I think will have the biggest ramifications not only for our industry but for Earth education in general, is the loss of experience.

As I walked around last year’s AAPG convention in San Antonio I was struck by the greater number of young geologists and the broader diversity of attendees than in previous years.

This was great to see. Change is happening and it is no bad thing.
 
But with all the new faces there was also the demonstrable absence of old faces and with that experience and expertise.
 
it is true that each past downturn has resulted in a gap or pause in the staff demographics as potential graduates looked at what was happening and opted for different careers. The resulting demographic imbalance has been long recognized, and many, if not most companies were actively addressing this through mentoring, knowledge transfer, and digital knowledge and database systems.
 
But the depth and extent of this last downturn have left this process of knowledge transfer incomplete.
​
More significantly, it has seen a generation of experience opt for early retirement and a younger generation who are increasingly deciding against the Earth sciences. This has been compounded by a general reticence to hire significantly this time given uncertainty over the future.
 
The question is, have we lost so much of our experience in this last downturn that this will affect our recovery as an industry and especially our ability to brainstorm and solve the challenges that now face us?

Our industry can boast some of the brightest scientists and engineers of the 20th and 21st centuries.
We have been at the forefront of increasing the understanding of our planet from tectonics, to depositional processes to paleontology and beyond.
Our industry has developed and build technologies and tools that can send sound waves into the Earth to resolve the structure of the subsurface even down to the Moho (the base of the crust) and can now drill through kilometers of rock from rigs sited in two kilometers of water and still know where the drill head is within meters. That is quite incredible. Well, I am still impressed
 
This is something that we should be extremely proud of. Achievements that we should shout about far more than we do.
 
The new generation is equally gifted, if not more so. I have been lucky to hire and work with many excellent young geologists. But they would be even better with mentoring from and access to experienced staff. But those experienced staff have either left or are about to leave the Industry. (As I was about to post this article, I received an e-mail from a friend in Houston who had just announced that she was leaving the Industry. Carmen is one of the most impressive scientists I have worked with and a great role model for the next generation and especially the growing number of young women joining the industry. Her departure is a devastating loss and one the Industry can ill-afford).
 
Experience is key!

This is all the more important as we apply our industry’s skill-base to energy transition and building new business models.
 
Experience is about having seen numerous real-world examples and being able to draw on these when making decisions, warts, and all.  Knowing what worked, what failed, and why.
 
As my Ph.D. advisor repeatedly told me "the best geologists are those who have seen the most rocks". (I am convinced that this is something said by every Ph.D. advisor to every geology Ph.D. student, but that makes it no less true).
 
And that places us in something of a cleft stick.
 
On the one hand, the Industry is addressing past diversity issues and hiring a new generation of enthusiastic, talented, Earth scientists, albeit in limited numbers. Whilst simultaneously cutting costs. Great…
 
But, on the other hand, we have lost the experience and expertise we need to both mentor the next generation and also to make informed decisions as we start to explore once more.
 
So, what to do?
 
Let me respectfully offer a few suggestions:

Today companies have libraries filled with 3rd party reports, internal studies, presentations, and databases. That is an incredibly powerful resource, but only if used.

The challenge is to understand what you have and how to integrate this within your current workflows. What data and knowledge are good? What is bad?  What can you accept and what should you ignore? It is certainly advantageous to know where the skeletons are before you repeat past mistakes! Mistakes cost time and monies.
 
Why spend more monies if you already have the answers, or resources to get to the answers, in-house? 

An easy win is to get your libraries curated and databased. In some companies, this has already been done. It is something I spent 2019 doing with my libraries​ (see my blog on scanning)

Another solution is to bring in the original product builders and get them to explain what they did and where useful, updating their products to fit new corporate workflows. This is certainly where much of my time would have been focussed this year (until some errant RNA intervened), having spent the last 25 years designing, building, and selling products and solutions to exploration companies.

One problem with seeking out the builders is that whilst their companies may still exist (possibly) the authors themselves may have moved on.
​
The same is true when looking for your own staff who made the original purchases with a specific plan in mind and/or who used the products. You may need to visit the golf courses of Houston or drive out to the Hill Country (though obviously not Alexanders) – ‘social distancing’ notwithstanding.

University research groups have always been a great source of cutting-edge ideas, knowledge, understanding, and data. Not to mention future staff.
 
With down-sizing and the disappearance of company-based research groups, universities are becoming all the more important.
 
This is not just about bringing in a professor to give a one-off seminar, but from my experience is best achieved through more active participation through workshops, having academics work directly with teams, and through MSc and Ph.D. projects and internships. 

As an example, last year I participated in a week-long workshop for a company that convened leading academics from different research groups and with varying opinions. In a few days, staff were exposed to all the views and background from the leaders in the field, something that would have taken them months to get a handle on by only reading their papers, and which even then, would not have provided the insights into the mindsets of the protagonists.
 
(There is also a need to maintain a presence in Academia at a time when our industry is increasingly perceived negatively).

Get out the pencil crayons.
​
Get your young staff to look at paper copies of seismic and use colored pencils to identify horizons. The key is to encourage your teams to understand the data, know their data, and to ask questions. They should not be afraid to disagree with their elders, but wise enough to know that experience can be an advantage. We are not infallible, but we have seen more rocks and solved more problems.

​With fewer staff and the disappearance of the armies of specialists we used to have, it is key that the next generation knows how the Earth system fits together.

This does not mean going all "fruit salad" (my thanks again to Catherine for that wonderful imagery), in which our staff have a little bit of knowledge of everything but no real depth.
​
This is about ensuring that our teams know the vocabulary and key headlines of diverse scientific fields and most importantly that they know enough to be able to ask the right questions and know whom to ask or where to search for the answers.

Over the last three years, advances in machine learning and AI have been impressive.

Pattern recognition has indeed been around for many decades: auto-trace in seismic interpretation, or computerized fossil recognition in biostratigraphy. The limitation in the past was largely computer processing power, which is no longer such an issue. 

With data storage now relatively cheap, and especially the development of cloud storage, accessing data and knowledge from anywhere in the world should be child’s play.
​
The problem is that whilst a child can operate an iPad with ease from kindergarten on, if not before, and they are incredibly computer savvy, they do not necessarily know the questions to ask. That comes with experience and does not seem to be always taught. As evidence ask them to do a Google search and see what they find; I am always amazed at what people do not find.

Technology is wonderful, and I am a self-confessed addict having designed, built, managed and analysed computer-based databases for over 30 years. But don't forget the basics - ask questions, know your data, question everything.

Operationally what should we do?

Well that is your call, but let me suggest the following:

1. databasing and data management – curating your data and knowledge so it can be assessed, accessed and analyzed;
2. work with data scientists, who can help design systems that make that data more accessible and program the systems to help us find patterns and get the most from it;
3. have the data scientists work in the same teams as the geoscientists, who know the questions to ask and the significance of the results. 

The future is about preparing our new generations of Earth scientists with all that we have learned over the last century or more, what worked, what failed, and why. To know the questions to ask and where and how to find the answers.

The next generation of Earth scientists needs to be well-grounded in the fundamentals of geology and the scientific method.

At the same time, they need to be conversant with a broad range of scientific fields, or at least enough to know the vocabulary of diverse fields and how each discipline might impact the problem they are trying to solve.

This also gives them transferrable skills that will aid the energy industry as we transition to alternative sources of energy, but also enable them to look at applying their expertise and experience to a range of other challenges, from the management of water resources to carbon capture, and storage (CCS), to geothermal energy, mineral exploration and waste management.
 
They need to be familiar with the tools available, but not to assume they these will solve all the problems they find.

At the end of the day, we need to harness all that we have learned in our industry to accelerate the next generation in understanding even more than we do for the betterment of mankind.

Understanding the Earth is what we do!

A search on the internet revealed that Alexanders Westchase closed at the end of January 2017 on the very same day that I had left my role as Technical Director of an Aim-listed consultancy after 12 years of successfully building the business. Coincidence I am sure…Rule #39 notwithstanding..
 
Today, what was once Alexanders in Westchase, Houston, is the site of a 24-hour emergency center. Useful and admirable, especially right now. Though I won't be going there for steak
 
"Alexanders is closed". All change. 

A pdf version of this blog is available here for download

​2. Make sure you have the right team

A year later, and I found myself self-employed. As an executive director for 10 years, my focus had been on management, strategy, and marketing. But, now here was an opportunity to regain my academic ‘mojo’, to catch up on research, teaching and several decades of scientific papers. An almost impossible task. Thank goodness for Kimbo espresso coffee, good wine and a range of great cookbooks… 

Now, after 24 months I have a major paper published, with several more on the way. New datasets in progress, a completely new data management system and suite of workflows, and an array of new ideas to promote. And most importantly, I have a reinvigorated curiosity about the Earth - my scientific ‘mojo’ is back.

In so doing I also found an answer to my question.

Are we limited to achieving only one big thing?

No. Of course not. We can always do more. It is about time and priorities. And therein lies the issue.

Once we get into our careers, where ever that takes us, time goes quickly. No sooner have we started then we are looking back. For me, it was when I was around 35. Next thing I knew I was close on 55.

There is also the problem that at the very point that we can contribute most to science given our experience, that experience takes us into management where we can no longer do the science. Something is wrong with that surely!
 
So, are there any lessons to learn that might help you if you are in the same position?

Let me suggest a few thoughts: ​