Sitemate Blog Post – On How Sitemate Communicates
On How Sitemate Communicates
Preface
Depending on what kind of environment you've operated in prior to joining the Sitemate team - I've found that most new starters typically have one of two types of initial experiences.
First - for some, joining Sitemate can feel like you've been walking along the side of a motorway, with cars driving past you at one hundred miles an hour, until suddenly you are yanked inside one of them, leaving you with whiplash once you're sitting inside.
And for others - you may feel as though the work environment is fast, but also less 'noisy' in the day to day, particularly on Slack.
Even if the speed and frequency of communication isn't new to you, nuances around norms, expectations and habits can lead to a similar feeling of whiplash.
As our current team is now acclimatised to the pace and these nuances, most of the time they don't even realise the unique aspects, and it can be jarring for them to need to temporarily adjust their communication patterns as new starters phase into our team.
Prior to the AI era, which is when this blog was first written, the person doing the communicating was always the person also doing the writing.
That's no longer a safe assumption - generative AI has transformed business operations, and whilst we are already seeing immense benefit in our own operation, and there continues to be a long runway of upside - there is also a spectrum from good to poor AI usage in your communication and thought process.
In-line with the above, this blog post is designed to help provide context for, and the history of, Sitemate's communication system, hence lowering the likelihood of new starters experiencing that whiplash feeling I mentioned above.
It also aims to guide both current and new team members on how to effectively execute their communications with the correct type and amount of support from AI, which can vary drastically depending on the scenario - from tasks to summarize research, to critical project communication, to feedback to another team member, announcements, customer facing communication and more.
As you will read below, there's a lot more to creating and maintaining effective, modern and global communication infrastructure, systems and habits, than just "oh yeah we use Slack."
This is now amplified in the AI era - the communications quality bar isn't your message is long and has lots of complex words in it, it's that it's easy to read, no matter how complex the subject.
Human Reading Now Has A Cost
Reading verbose dumps of text now comes with a price tag attached to it, and the currency is our energy as human beings, or our el nat'ural intelligence.
Ted Chiang (a sci-fi writer) wrote this in 2024, before most of us were using Claude daily:
We are entering an era where someone might use a large language model to generate a document out of a bulleted list, and send it to a person who will use a large language model to condense that document into a bulleted list. Can anyone seriously argue that this is an improvement?
We're now there, we got here sooner than anyone anticipated, and I'm certain you've been on the reading end of the stick already.
It can be hard to describe - you hit a word that you have to work out from context, you read the same sentence three times before it registers in the brain tissue, a term gets introduced that you're fairly sure the author of the text that you're reading didn't know last week.
The best term I've heard for this is AI being a jargon bully; Complex words, big acronyms, heavy technical terms, invented shorthand and hyphenated coinages.
All of it moves work from the writer to the reader.
Which is a bad trade, because author effort is paid once, and reader effort is paid once per reader.
Save yourself an hour by sending something unedited, and it costs ten readers fifteen minutes each - you saved an hour, and spent two and a half hours of everyone else's.
Nobody sees that cost, because it's split ten ways, but it's very real, and this is exactly what GOP.11 (don't offload the thinking to the next person) has always been about.
The problem is, it's just far easier to do now.
There's also a trust cost on top - when something reads as generated, the reader's question stops being "is this right?"
And it becomes "did this person actually think about this, or am I reading the default answer?".
Default answers are average answers - no nuance, nothing local, none of what you know about our customers, our product or our codebase that a model simply doesn't.
So even when the content is fine, you've spent some credibility to save yourself a bit of time.
Email, And Front
Let's start off with the big one out of all of the traditional communication channels - email is banned internally. Zero. Nada.
Except for calendar usage, email is exclusively used for external communication.
However, that's not to say email is not important - for our Operations and GTM teams, our inboxes are supercharged with Front.
You can think of Front of like having Slack overlain on top of your inbox, it allows you to have internal conversations, about external conversations - discussing challenges, sharing information, reviewing drafts for critical communications and coaching on best practices during new starter onboarding.
We've been using Front for a long time - back in 2019, we were sitting in one of the very early Sydney offices one day, there was only 5 of us; Khanh, Sam, Lance, Terry and myself.
These were the days when Sam was acting as our Customer Success Manager, and over the course of about an hour, he asked Khanh to forward him multiple emails with questions from customers about billing.
It seemed inefficient, but I didn't really have any better ideas, until a few days later I saw an ad for Front online, and I started a trial right away.
Front were themselves relatively early on in their journey at that time, I think they were around 50 employees, and now at the time of writing this blog, I believe around 500.
A week or so later, I called Sam, Lance and Khanh into a room, and was super excited to pitch them on Front - their response was simply… blank faces, skepticism and even some confusion.
Luckily, as CEO, I didn't have to ask for their permission to trial the product, and the rest is history!
Front is probably the tool that surprises people the most after they join Sitemate, with many wondering how they ever lived without it.
Asynchronous
Asynchronous, or 'async' communication and written communication go hand in hand, although it's important to talk about the dynamics of async communication patterns specifically and why adjustment can be required.
In more traditional workplaces, communication often revolves around meetings, and email. Email is a form of asynchronous communication, but it's fundamentally different to messaging based systems, as well as 'on object' communication patterns within workflow and database systems.
Unless you've been living under a rock and have never used Messenger or Whatsapp, you will almost certainly have some level of experience with async comms.
The general theory is that you can send a message, or leave a note for someone, and they can reply back when it's convenient for them. This way, everyone can take their time to think about their answers and respond when they're ready, making it easier to manage conversations without disrupting what you're currently doing.
Leveraging async comms patterns allows you to progress projects, ideas, decisions and discussions across timezone boundaries, unlocking the potential of talented individuals across the world within globally distributed teams.
Async communication allows thoughts to simmer, evolve and mature, and you often end up with higher quality outcomes because of this.
However, there are a couple of triggers to look out for, which may indicate that you need to deviate away from async comms.
The first being when emotions like frustration and anger come into play, as writing under these conditions can be damaging and it's best to write out your feelings on a personal note, and then discuss during a meeting.
The second being when there's too much back and forth - usually indicating that the topic being discussed needs to instead be ported into a document summarizing multiple options and perspectives.
Writing Is Not Admin, It Has Inherent Value
About two weeks after Rob joined our Sydney office, he was starting to go live in his role as Sitemate's first ever Enterprise AE, and like every other new starter - was through watching most of the 'Sam from Sitemate' product videos.
He was reporting to me at the time, things were looking good, we had heaps of larger leads coming through the inbound flow, but there was just one problem - he kept pinging me via Slack Direct Messages (DMs) asking for a call to talk about things.
This might seem like an obvious use of slack, but switching from primarily written communication, to primarily verbal communication, can quite disruptive - and when your manager is also the CEO, any disruptions don't usually last long…
Speaking over the phone, video call, or of course face to face, requires real-time engagement from everyone involved, which means calendars need to be aligned and available.
In addition, unless well prepared for, typically internal phone calls, video calls and face to face meetings contain approximately 80% wastage for attendees, due to large amounts of 'filler' time.
I have a strong personal belief that whatever someone writes, whether it be an internal message, or an external email, is a direct representation of what is happening inside of their mind at that point in time - meaning if it's messy and confusing, their thoughts are messy and confused, and vice versa - if it's clear and concise, their thoughts are clear and concise.
Writing helps you move from the former to the latter, as most of the time you can look at what you've written, realize your thoughts are in fact a mess, and iterate on it yourself a couple of times to improve it.
Now to clarify - this is not to say that verbal communication is not important, it's just as important as ever, particularly given how much written communication happens in modern workplaces, which are becoming increasingly digital.
There are certain scenarios where verbal communication should be the default - examples being; 1:1s covering personal updates/development discussions, feedback, as well as pulse check team meetings and rituals where it's important for leaders to provide not just operational updates, but convey the general feeling, energy and mood at any given point in time - for example; weekly team meetings and the allhands.
In addition, and to contrast - there are also many scenarios where real-time collaboration is extremely valuable - primarily in creative contexts where the objective is not clear leading into the meeting or session. This could be exploratory research calls/meetings with customers and prospects, retrospectives, project objective and kick off meetings.
Needless to say, with the above being said - my response to Rob was a polite; "Can you write to me with what you want to ask?"
After another week or so of frustration due to me saying different versions of the above response, Rob finally reached the other side of the hill, where his written comms were flowing naturally and efficiently in written form.
The irony was that when our next new starter joined, Rob started getting frustrated because they were disrupting his daily workflow, doing the same thing that he did when he started, at which point he messaged me to say;
"Once you feel the efficiency of written comms, you can never go back."
Put simply - in order to thrive at Sitemate, particularly as you start to move into management leadership roles, your written communication skills will need to be very strong.
It's ok if you're not there right off the bat, there are plenty of examples day to day to learn from, as well as people on the team and resources (such as this blog post) that can help you start to build the muscles required.
Also, for the avoidance of doubt - if you ever have something personal or sensitive that you need to raise, please do not hesitate in using DMs to reach out to your manager or a leader on your team. The scenarios referred to above relate to project, task and account related communications only.
Messaging, And Slack
I remember the first time that I used Slack - it was during university, one of the classes that I was taking had a workspace setup to allow teachers and the cohort of students to communicate easily and openly.
I've been a part of a few Slack communities since then - Productboard power users, Startmate Accelerator, and some other miscellaneous workspaces. Some of them were very active, some of them had a few bright spots, and then fizzled out quickly.
The main learning for me has been that while the underlying system is important, ultimately it's the people that make all of the difference.
As at the time of writing this blog, each week approximately 70% of messages read in slack are in public channels.
In-line with our value high vis, the guidance is that for anything project, task, account, case, opportunity related - never use DMs. But the question is why?
With our hybrid operating model, as detailed in our working arrangements, even for our office based team, who only see each other once per month, we are deprived of the value of spontaneous 'water cooler' conversations.
Conducting most communication in public internal areas such as channels, as well as onto the records of work, has many benefits. It builds visibility, trust, allows new members of the team to absorb what is happening, and increase the likelihood of spontaneous water cooler chats, albeit in a digital context.
However, this level of transparency can often be intimidating for new starters, due to concern of potentially saying something wrong, or asking a silly question.
I wanted to emphasise here - speed and visibility, is much more important than a perfect response.
Private strategy and tactics channels are used to allow senior members of the team to discuss raw ideas before they are ready for broader sharing, as in some cases, it can be confusing, distracting and broadly detrimental to share some things prematurely.
Direct Messages, or DMs, on Slack, should be used strictly for things such as personal/private discussions, general check in, banter with colleagues, etc. Meaning that DMs should never be used for discussion around tasks, projects, accounts, opportunities etc.
We originally started using country flags as our remote team started getting bigger and bigger, as a fun way of celebrating all of the different cultures that exist within Sitemate, and that is still the intention. Using your status in slack to indicate which office or country you're based in, or where you're traveling at the moment, or if you're on leave - is an extremely efficient and effective way of communicating with people who may need to reach you.
It's important that we continue to utilise this feature even more as our global team grows larger, particularly given how flexible our working arrangements are at Sitemate.
One final note for this section - please, please, pleeeeaaaase… "use threads".
Daily Reports, Or Standups
Unnecessary meetings are like rust that slows down the turning of gears inside of a company's decision making engine.
I've heard horror stories of some companies running daily one hour zoom meetings to do a standup - every, single, morning, and it gives me shivers.
Broadly speaking, the guidance at Sitemate is to hold the absolute least number of meetings as possible - typically we aim for one single meeting per week per team, and managers should be aiming for 1:1s with their direct reports either weekly, fortnightly or monthly, depending on the stage of each person's journey at Sitemate.
One of the tools that helps to minimise the need for meetings is our async daily reports, or daily standups - done by a tool such as geekbot or standuply, and posted in a #reports Slack channel.
We started doing daily reports each morning when we were less than 10 people, it was right around the time we started growing our remote team.
Coming from a construction and engineering background, where I was used to in-person briefings like pre-starts and toolbox talks, I not only had no idea what they were, but it felt a little odd writing down my daily update in private, and then pressing the send button into the abyss.
As it seemed to be a good practice for software and product teams, I thought I'd give it a go and that we should all be doing it, instead of just the software engineers on our team. I wanted it to be a tool for anyone in the company to feel like they have visibility into what is going on, instead of a tool for just software developers to report on their progress.
As we've grown, we've had to break up the various #reports Slack channels into smaller groups, to ensure that it's relevant for each team.
When Khanh and I broke up the #reports channels the first time, at around 15 people, we saw that it was possible with the functionality available to send one person's reports into multiple slack channels, and we decided to send my report into every channel.
Why did we do it? To be honest, we just looked at each other and said 'Maybe one day Sitemate will be like 100 people, and wouldn't it be cool if anyone could see what the CEO is working on every day?'
The expectations around the reports is pretty clear - of course every now and then there is a day where things get a little crazy, and you might forget, or miss it, and that's fine. But, generally speaking - the goal is to do them daily.
Is anyone going to check on you day to day if you miss one? No - probably not, everyone else is too busy.
But, they are one of the key pillars that support the flexibility in our working arrangements, and as they're one of our standard operating principles, it probably wouldn't block progress on an individual contributor pathway, but it will likely block progress on a leadership path.
As a leader, either current or future - it's a great way to easily and quickly keep your team up to date, as well as 'manage up' if you've had any wins, good progress, or are experiencing any challenges.
Which is also why auto-generating your report from your calendar and Jira activity defeats the purpose - the few minutes of thinking about what actually moved, and what's actually in the way, is the point. Skip that, and nobody wrote it, so likely - nobody reads it.
'On Object'
Probably the most difficult part of Sitemate's communication system to grasp, and adjust to, and the part of which I believe Sitemate skews further towards uniqueness compared to most companies, is how communication happens 'on objects'.
But wait, what in the world is an object? And how do I communicate on it?!
In this context, the definition of an object is a record within a system - it could be a Jira Ticket, a Confluence Page, a Salesforce Account, or a Salesforce Opportunity.
These systems, and the records within them, are designed with embedded communication capabilities, however, even within technology companies, they are often not used to their full extent.
Our intention is to use the embedded communication capabilities as much as possible, for example - discussing Confluence pages on the page itself, discussing Jira tickets on the ticket itself, discussing Salesforce accounts on the account itself.
You communicate on them by using the native chatter, comments and @ mentioning capabilities.
Emoji Culture
Lance and I have discussed the theory of emojis being the modern day digital hieroglyphics a few times - hieroglyphics were used to communicate across different regions and cultures in the ancient world.
Emojis can now do the same - communicate deeper meaning, or a broader message, with just one symbol.
Let's cover the base level of expected usage first - in order for our communication systems to function, there are a couple of base level requirements; acknowledging that you've seen things with a simple ':eyes:' or ':thumbs-up:'.
On top of that, there are a couple of practical use cases, such as having emojis for each of Sitemate's values, for example, :value-high-vis:, which allows us to indicate when someone is doing something in-line with one of the values.
Outside of those two things, pretty much everything else is just for fun - a bit of a laugh can really help take the edge off of what can be the grueling day to day of scaling up a company, with endless challenges and never ending to do lists.
Keep in mind though, Slack is intentionally designed to have some similar features to addictive social/consumer products, which is part of the reason why it's such a powerful tool - but, it's also important to set boundaries for yourself to ensure sustainability, and this will be covered below.
PS, a tip for anyone new to Slack, you can type a colon, or ":", on your keyboard when inside of a text box, and it's a shortcut to accessing any emoji by name.
Headshots
You might have noticed that Sitemate has a somewhat regular cadence for getting new photos and headshots for new starters on the team - for office based team members we've grown to start doing this once per quarter, and for remote team members we aim to do it at each annual offsite.
This section will answer two questions relating to this; (1) why do we do it? and (2) what does it have to do with communication?
On the why - this stems from a somewhat quirky theory that I have, which I've spoken to a couple of people about, but not many.
The theory is that people remember their careers in blocks of time, and their professional photo is like a shortcut to summarising each of the individual blocks of time.
Noting that a block of time doesn't need to mean changing company, you can have multiple blocks of time within the same company, and in fact, this should arguably be a goal - it means you're progressing.
If you are interested in testing the theory, pull up all of your previous professional head shots on a screen, and glance over them - you will likely have clusters of professional memories attached to each one as you do. Kind of like when you hear an old song that you used to love, and it takes you back to the major things that were happening in your life at the time when you first fell in love with it.
By getting a fresh new headshot, the goal is to start a new professional memory block - a clean start and signaling that you're progressing, or have progressed, into a new stage.
If you hang around long enough, you might end up with multiple memory blocks from Sitemate alone - I know I've got four myself, and each time I see an old photo, I remember exactly what was happening at the company at that point in time.
So, how is this relevant to communication?
Due to the prevalence of digital systems, as well how significant your photo and image is, your headshot is your 'digital hello' or 'digital handshake', like a first impression, which as we know - always lasts.
It may seem like a small thing, and it's a little hard to describe from my perspective, but for some reason - as our team has grown, and recruitment volume has picked up, it's been surprisingly noticeable how important the way someone presents themself has been, both internally and externally.
The engineer in me doesn't like that this is a thing, but optics are important - my recommendation would be two things; (1) always take a minute to present yourself in the best light (2) keep your presentation consistent across all digital platforms.
These are two very easy things to do - and it generally helps to make a good first impression, whether it be people internally, or external candidates.
It's just like presenting yourself well in the real world and making a good first impression, and with so much now digital - why would you not do it there as well?
A Machine For Machines, A Human For Humans
It's clear from the section above that the power of written communication is in the act of needing to write down your thoughts. When you are forced to write something out, it helps you construct a much clearer message, and sometimes, you can even answer your own question just through the process of trying to clarify what it is you are in fact looking to ask.
Write 10,000 words yourself and you make almost 10,000 small decisions.
You sweat over which word, which order, what to leave out, where the reader needs an example and where they'd be insulted by one. Most of those are invisible and you make them fast, but you make them.
Generate those 10,000 words and you made maybe 10, 20 decisions (the prompt, a few nudges, hitting send). The other 9,900+ got made for you by the LLM, and they got made averagely, because that's its job; pick the most likely next word given everything ever written.
Fine for plenty of things, not fine when those decisions were the thing you were being paid to think about, to plan, to apply your craft through.
What most people haven't conceptualized is that they are now a manager, and that they are responsible for their agent's outputs, especially when it comes to communication.
In any company, each organizational layer makes the calls at it's own level of detail and hands the rest down. Nobody expects a CEO to pick the words in every doc: they set direction, the layer below turns that into a plan, that gets broken down again, and by the time you reach the last layer someone is choosing the wording of a customer email, or what to name a variable, without running it past anyone.
Delegating decisions isn't the problem, that's just management. It works, and the value is in making the right calls at your layer and trusting the layers below.
LLMs made everyone a manager overnight - nobody told you where your layer stops, so the default in many cases has been to delegate all of it, down to the last word.
For writing aimed at other humans, your layer is the ideas, the order they go in, and the words that carry them. You can't hand any of that off, since it's the actual work.
For writing aimed at a machine (codebase documentation, agent instructions, context files), delegate the lot. Nothing is lost and nobody cares.
It's Hard And Takes Time, To Make It Simple And Short
None of this is an argument for dumbing things down. It's the opposite.
As Blaise Pascal put it (not Mark Twain 🤓):
I would have written a shorter letter, but I did not have the time
The trap is that complicated writing reads as authoritative, so people reach for it, feel comfort in it.
Academia is an extreme version, where the incentive, through perceived status, is to sound rigorous and the result is papers that are hard to read for no reason.
Research on legal writing found the same: what makes contracts hard isn't the legal concepts, it's the writing, and it's proven lawyers comprehend plain versions much better.
Claude does this by default because hedged, formal, maximally complete prose is what got rewarded.
Taking something genuinely complex and making it land in a simple way, is one of the harder things you can do, and it's a signal for true understanding. If you can't explain it simply, you probably don't get it yet.
The bar I'd aim for: a new starter can read it easily, and the most senior person in the room finds it crystal clear. Plain language does both at once.
Human Communication Expectations
There are three key expectations for communicating at Sitemate in the AI era, which I'll detail below, followed by a brief note for ESL folks.
1. Edit It Before You Send It
AI assistance is expected. Sending its output to a colleague unchanged is not - this is now Global OP.15 (human reading requires human writing).
Before you send, read it, think it through, and edit it until it says what you mean, in the simplest way possible.
Judge what you send by what it costs the reader - how it was made doesn't matter.
If it's bloated, jargon-heavy, or takes two passes to parse, it hasn't met the bar, whether you wrote every word or Claude did.
Yes - this makes writing slower for you in the moment, but the time savings on a net reduction in total communication, both for you and the business, due to clarity, will far outweigh that incremental cost at the time of drafting.
2. Make It Clear Which Part Is AI
When a message contains AI-written content, make it obvious which part is which.
Your words at the top: the ask, the priority, and what you want back. The AI-written detail below, or in the thread, in a quote block, marked accordingly.
Example here;
The reason is how people actually read - when the seam is visible, people engage with the human part and only dig into the generated detail if and when they need it.
When it's blended, they have to read all of it to work out which bits matter.
One caveat - labelling makes the reading cost visible, it doesn't reduce it. It's not a licence to paste unedited output under a label and call it done. If the AI part isn't genuinely worth reading, delete it rather than mark it.
PS, no, not all of the quotation blocks in this blog were written by AI! This is a different use case for the quotation blocks, lol.
3. If It Lands On A Person, You Write It
Feedback, reviews, and any decision affecting someone's work, employment, benefits etc, is always written by you, personally.
If a message is going to land on a person, especially a hard one, it deserves a human author. People can tell when it wasn't, and nothing spends trust faster.
When You Are ESL (English Second Language)
The general principle for internal communications is;
I would much rather see and/or read a comms that contains some translation nuances, but that was written by you, a human, vs a copy pasted output from Claude.
Here's a tip that may help you, if you still feel as though it's not good enough to send.
Step by step for ESL editing;
- Write your message in your native language, conveying what you're trying to communicate.
- Then, write the same message from scratch in English, right below it, conveying what you're trying to communicate.
- Give Claude both versions, as well as any additional context, and ask it to re-draft the English version in your style and tone, but whilst fixing any grammatical and/or sentence structure issues.
Monitoring Expectations
As a general rule, it's important to monitor critical comms channels at least every few hours, potentially more frequently depending on your role - Slack, Front, Jira, Confluence, Salesforce and Github.
There is only a very, very small number of scenarios where the expectations around monitoring communication channels change from the default described above, to a heightened level.
For product and engineering teams, this is when there are critical issues in your direct responsibility area - at which point, you are expected to be owning the work to drive this through to resolution, which could be either doing the work, or coordinating and project managing.
For GTM teams, this is when there are critical prospect/customer communications actively in progress - for example; closing a large and complex opportunity, or managing large customers in the case of any potential product outage.
However, even if the above occurs and you do need to go completely offline, for example, due to illness, or a special event such as birthday, wedding, travel, etc, the solution is simple - alert your team and/or line manager that there is something urgent that needs monitoring, and ask for their help to monitor during this period.
The only mistake you can make in these scenarios, is to not communicate.
Closing – Notifications And Sustainability
I've been asked probably a dozen times now by various people on the team, something along the lines of "How do you keep track of all the communications channels, across 5-6 product teams, 3-4 GTM teams, and everything else? How do you never miss anything, and respond so quickly?".
Personally, I receive close to zero notifications on my phone and computer - no desktop notifications for slack or email, no push notifications on my phone, for both personal and work apps.
With Slack, I take it a step further, not only do I get zero notifications, but within the tool itself, I have 95%+ of my channels muted - public, private and DMs.
Literally the only way someone can reach/interrupt me is via a phone call or text message to my Australian mobile phone number, or through whatsapp.
If something is truly, truly urgent, which 99% of the time it is not - someone will call you.
The above allows me to drive the systems, not to have them driving me - the full mechanics of how now live in the Personal Task Management Framework.
Back in 2024, Australia passed a law giving people the right to disconnect from work communication systems - it made me laugh at the time, and it still does.
I will lean on a couple of analogies from On Operating Like A Pro Sports Team to help explain my thoughts on this topic.
Not having the right to disconnect, would be like expecting athletes to be playing on the field 24 hours a day, 7 days a week - insanity.
My perspective is probably still somewhat extreme, but on the other end of the spectrum - I would advise you, and I've done this multiple times to people on the Sitemate team, to uninstall Slack and Front/Email from your phone, or at a minimum - disable push notifications.
You do not need to be checking these systems 24/7, and it is typically easier to achieve this if you are processing them on your computer.
The ironic part here, is that people often keep notifications on because they're worried about missing something, and I've found, now in dozens of cases, that it has the opposite effect.
The people who miss things, which causes friction, frustration and performance issues, are always the ones who get interrupted and distracted, and then forget to come back to things, instead of processing their notifications in a calm and systematic way.
All of the above is about protecting your attention on the reading side. AI has made it trivially easy to spend everyone else's on the reading side - so the last word goes in here; if a human is going to read it, a human needs to have written it - or properly rewritten it.
About The Author
Hartley Pike
CEO & Co-founder · 
LinkedIn
Education
University of Technology Sydney - Master of Business Administration in Entrepreneurship (Dropped Out)
University of Technology Sydney - Bachelor of Engineering (BE), Diploma in Engineering Practice, Civil Structures
Bio
Hartley is the Founder and CEO of Sitemate, where he turns real-world construction and infrastructure experience into software products that site teams want to use. With a background in civil engineering across major transport infrastructure projects, manufacturing, and large-scale site operations, he brings experience to product strategy and development.
He applies lean principles to improve productivity and efficiency across complex, high-risk operational workflows. Today, he leads Sitemate's product strategy and growth, building platforms such as Dashpivot, Flowsite, Gearbelt and more that transform standard operating procedures into structured, data-driven workflows, helping teams deliver work more reliably, safely, and on time.
Past Projects
Major tunnel motorway infrastructure project (NorthConnex – $2.6B)Civil Engineer contributing to the delivery of a nationally significant nine-kilometre tunnel motorway, supporting construction of the Trelawney Street vertical shaft and the main tunnel alignment, which will form part of the National Highway route.
Highway upgrade and concrete pavement improvement project (Nambucca Heads to Urunga – $780M)Civil Engineer undertaking analysis and assessment of concrete paving processes for a large-scale highway upgrade, supporting the delivery of two new interchanges and performance outcomes across 22 kilometres of upgraded highway.
Large-scale precast concrete manufacturing operations (Australian Precast Solutions – APS)Engineering contributor supporting the manufacture of high-quality precast concrete elements, including Super-T girders and bridge planks, supplying major transport infrastructure projects across New South Wales.
Motorway widening and intelligent transport systems delivery (M5 West Widening – $350M)Civil Engineer involved in motorway widening works, including installation of IT systems within civil works, construction and commissioning of the M5 Control Centre, asphalt resurfacing, finishing works, and project handover.
Lean construction research and process improvement projectLead researcher investigating the application of lean principles to civil engineering processes, demonstrating up to 40% reductions in process durations through waste removal and improved workflow design across live construction and precast manufacturing environments.
Construction technology startup and product development initiativesCo-founder and product lead developing early-stage construction technology solutions through programs such as the 3P Business Plan Competition and the University Startup World Cup, including business plan development, international startup exposure, and investor-facing product positioning.
Construction cloud and digital workflow innovation programsEntrepreneur and technology advocate recognized through multiple international and academic awards for advancing cloud-based information systems aimed at improving productivity, safety, and quality in construction and infrastructure delivery.
OMRON (Industrial Automation)Led the upgrade of a legacy asset management system into a single digital platform (Gearbelt), bringing together work order management, QR-based access to asset information, and safety procedures. This resulted in a reduction of work order administration time by more than 30%.
Compass Energy Systems (Oil & Gas)Managed a multi-year transformation focused on consolidating quality assurance, field ticketing, and safety systems across Canadian and US operations. The outcome was a unified user experience with smooth integration into the Microsoft environment via Flowsite, including Power Platform, Power BI, Excel, and SharePoint.
Thrasher Engineering (Civil & Environmental Engineering)Oversaw the rollout of tailored daily reporting workflows supporting both DOT and private projects. Field teams working in demanding, online and offline conditions now generate large volumes of reports and photos each month across multiple US states, supporting timely, high-quality reporting to project stakeholders.
Want to learn more about Sitemate?
English (United States) 
English (Australia) 
English (UK) 
English (New Zealand) 
English (South Africa) 
German