Sitemate Blog Post – On How Sitemate Makes Decisions

SITEMATE BLOG POSTS

On How Sitemate Makes Decisions

By Hartley Pike, Co-Founder & CEO of Sitemate

Preface

This blog posts aims to help everyone on the team, but I suspect it will help you in different ways depending on your role, which of course, may and hopefully will change over time - meaning you can look back at this blog post in future as required and during important decision making events.

If your role currently consists of primarily individual contribution work, then this blog post will provide insight and context as to how decisions that affect you are considered, documented, iterated upon, collaborated around, and ultimately - made.

If your role currently consists of primarily leadership and/or management work, then this blog post will be immediately actionable - giving you specific guidance on how to drive your own decision making processes, as well as prime you to be able to collaborate effectively with other senior members of the team if and when you are exposed to a decision making process.

Regardless of your role, you should find at least the first part of the blog amusing, and please restrain yourself from laughing too hard at my personal painful story, unless of course you are on the engineering team for Dashpivot - then it is our shared pain together.

The lead up to, my worst decision to date

The first version of Dashpivot launched on Monday 6th of August, 2018, and prior to that our first product was not called Dashpivot. Our previous product launched in March 2016 as Construction Cloud, and it was designed to be solely a photo storage app - yes, Sam and I do have a copy of a very old pitch deck where we pitched our wizz-bang startup idea as ‘the instagram for construction’ (insert cringe emoji).

When Sam and I were working through the initial design decisions for Construction Cloud, one design challenge that we had to solve was; how do we organize the photos in a way that created an ‘instagram-like’ feed for each area of a project or job?

Specifically our intention was to cater for all kinds of project shapes and sizes, and our goal was to provide users with an experience where they felt like the content they were viewing was broad enough to not just be their own personal photos, but have some sense of collaboration by seeing their immediate team’s photos in real-time, whilst also not being too broad that they would keep seeing information that is not relevant to them from other parts of their project or job.

The solution we came up with, was to allow users to create a folder-like structure, but where photos and videos would only be stored at the absolute child layer of the hierarchy, meaning any intermediate folder layers only acted as a layer of the tree, but didn’t actually provide any functional capability at that layer of the hierarchy.

Please see this example, indicating where photos are stored in each absolute child folder;

  • Tunnel Infrastructure Project

    • Geotechnical investigation works → photos stored here

    • Early works

      • Electrical early works → photos stored here

      • Civil early works → photos stored here

    • Tunnel site A

      • Shaft

        • Lift 1 → photos stored here

        • Lift 2 → photos stored here

        • Lift 3 → photos stored here

        • Lift 4 → photos stored here

        • Lift 5 → photos stored here

      • Tunnel drives

        • Tunnel drive A1N → photos stored here

        • Tunnel drive A2S → photos stored here

    • Tunnel site B

      • Shaft

        • Lift 1 → photos stored here

        • Lift 2 → photos stored here

        • Lift 3 → photos stored here

        • Lift 4 → photos stored here

        • Lift 5 → photos stored here

      • Tunnel drives

        • Tunnel drive A1N → photos stored here

        • Tunnel drive A2S → photos stored here

Overall, this architecture worked reasonably well - it allowed us to adapt the product to a project or job of any size and shape, so - what was the problem?

The problem wasn’t in the architecture, it was in the functionality - by the end of 2016 we’d completed around 75 meetings with various people from within the industry, and only 3 had converted to customers.

Making, my worst decision to date

I remember the morning that Sam and I decided to change the direction of the product - we were sitting in a corner office of the UTS Engineering building, a few levels up, which meant we had a nice view over the start of Parramatta Road at Broadway in Sydney.

It was December 2016, I had quit my job at Lendlease only one or two week’s earlier, and it was still quite early in the morning, maybe 7 or 8AM. We were sitting in front of a blank whiteboard thinking back on the year of 2016 where we went from one customer to approximately four total customers.

We were speaking about all of the learnings we’d had around permits whilst we were out on site talking to users about photos and videos, and we were brainstorming how it could be cool to manage them in a Trello-ish kanban-style view, except where e-signatures move the permits to the next step, instead of dragging and dropping cards like you do in Trello.

To be honest, most of this interest was driven by my personal previous frustration with permits - where when I was working as an engineer, I used to spend an entire day each week just taking the paper permits around to each signatory, and then physically drive them out to site to deliver them to each foreman.

We were then contrasting this against a completely different use case and problem to solve - site diaries, where we’d also learned a lot through the same photo and video research. The site diaries were different though, they didn’t need to go through a workflow (or at least these ones didn’t…), and they had tables nested within, that could either be three rows deep, or thirteen rows deep.

After an hour or two of white-boarding and brainstorming, we had the foundational components of the new product direction clear - the photos functionality was staying, but it wouldn’t be the core focus anymore, instead we’d add in this new ability to create advanced forms, and you could either store them in chronological order, or in a workflow, and then we’d allow you to link in your photos into each of the forms.

Fast forward a couple of months to February 2017 - we were right in the middle of the Startmate accelerator program, and had just returned from San Francisco. The plan to completely rebuild and change the direction of our product was in motion, and once again - I found myself in front of another whiteboard trying to think through some deep foundational product decisions.

My logic to make the decision was quite simple - we were working with NorthConnex, Fulton Hogan and Seymour Whyte at the time, and the way that they operated their business was by organizing their staff around projects, and then teams within those projects, usually looking after certain areas, zones or sections.

So, after a quick few sketches I was done, and had drawn up the data storage and access architecture for our new product, whilst also showing how data would be mapped across from the old folders architecture of the photos product, to the new product containing both the current and the new functionality.

We were on the right track, it felt like things were turning around, and I was super, super confident in this new information architecture.

When it hit me that it was, my worst decision to date

It was 100% the right decision, until it became obvious that, well, actually - it wasn’t.

Although, to be fair on myself here - it did take another year or two for this reality to become obvious. As we launched the new version of our product, migrated over early customer data from the photos app, and went through the re-branding from Construction Cloud to Sitemate and Dashpivot, things were running pretty smooth.

It wasn’t until our inbound marketing engine started to fire in late 2018 / early 2019 and leads started to flow, that I started to notice a problem - Lance was booking in demos as our SDR, I was doing the demos as our AE, and I started seeing companies of all different shapes and sizes, from all over the world coming through at demo stage.

These companies would get confused with the terminology of projects and teams, saying things such as 'we do jobs not projects’, or ‘why do we need the team layer?’.

At first, I brushed it off, downplaying it as simple confusion issues, until I noticed myself talking my way around this architectural issue during demos - starting to say things like ‘they’re just like folders, just pretend they’re folders'.

The observations then built - speaking to people on free trials, who had clearly gotten completely lost without any guidance in Dashpivot’s hierarchy, and for whom it became crystal clear - only needed a single ‘layer’ of folder access, at least to start out with whilst they were learning the core concepts of the product.

Over the coming year or two, I started speaking about folders with Sam more and more - saying things like ‘wouldn’t it be great if people could upload/store photos, create forms, workflows, registers, charts, dashboards and anything - at any level of the hierarchy?!’

If we did that, we’d be able to just call them… folders, as everyone already knows how folders work, so it would reduce the learning curve for Dashpivot drastically, as well as drastically simplify the free trial experience, and our ability to tailor the architecture for different verticals.

So with that - we were back at square one, except now with a growing codebase that did not support the vision information architecture for Dashpivot.

Attempting to quantify, my worst decision to date

What followed was period of sustained growth, which you might intuitively think is a good thing, and it was - ultimately it saved the company from the dark days of 2017 and 2018, and Sitemate has been going great in recent years - so by no means am I materially unhappy with our progress in any way.

However, that has not meant that I’ve been able to stop myself from asking myself the question - I wonder how much smoother things could be if Dashpivot’s architecture had been built with folders from the get go, instead of projects and teams?

As I drew out the various lines of thinking around how this architecture is linked to various levers of growth, it allowed me to quantify how broad the impact was;

Opportunity cost - self service; we’ve had hundreds of sign ups per week, it impacts every user’s first experience and hinders them with excess complexity. Even nudging the conversion rate a few percentage points higher, would be a difference of dozens of customers per week, hundreds per year.

Opportunity cost - sales: we’ve lost some opportunities due to perceived complexity or irrelevance, simply due to the naming convention.

NPS detraction: users get frustrated by not being able to tailor the architecture to their needs.

Cost to fix: we are in the middle of preparing for the switch to folders, and there are a handful of areas that must be refactored as part of this switch - it is a multi-year initiative, touching all areas of the Dashpivot codebase.

To put it plainly, if I had made a better decision - for roughly the exact same amount of product and engineering effort (potentially even less), my estimate is that Sitemate would be between 50% and 100% larger than the size we are right now, measured in any of the top line metrics; revenue, employee count, and active users.

Lessons from, my worst decision to date

This event, and how our decision making processes have evolved since, has taught me a lot - and not just within product and engineering either, some of the context surrounding this decision is applicable in any scenario.

The remainder of this blog will now cover each of the core lessons learned, as well as finish with a practical overview of how Sitemate now makes decisions;

  • One way door vs two way door decisions
  • Decision position relative to time
  • The paradox of confidence with decisions
  • The best ideas always win

One way door vs two way door decisions

Decisions should not be treated equally, as they are not all classified the same - one part of our decision making process at Sitemate is shamelessly stolen from Jeff Bezos' one way door vs two way door framework.

One way doors

One way doors, as the name suggests, are designed for one way traffic - once you pass through, it is very very difficult, or expensive, if not impossible in some cases, to reverse the decision.

Examples of one way door decisions include;

  • Product and company branding decisions.
  • Major team decisions (hiring batches, firing, restructuring).
  • Foundational product architecture decisions (vertical and horizontal relationships, variables, custom options).
  • Foundational technology selection decisions.
  • Foundational technology naming convention decisions (domain naming, codebase naming conventions for frequently used items).
  • Foundational vendor selection decisions (e.g. HR/IT, Billing, CRM, Project/Task Management).
  • As you would then expect, one way door decisions should be made with the greatest level of detailed documentation, scenario/risk analyses, and with contributions from people who have varying perspectives and vantage points.

When faced with a one way door decision, as much as it is practical to do so - one should select the option that gives them the most flexibility to change their mind in future.

Two way doors

Two way doors are the opposite of one way doors - they effectively allow you to pass freely back and forth through the door, it may consume some time and effort to do so.

Examples of two way door decisions;

  • Naming conventions for confluence pages, slack channels, salesforce records, jira processes.
  • Which SaaS tool to subscribe to on a monthly basis to solve a particular problem.
  • When faced with a two way door decision - don’t over-complicate it and don’t make it political. After sourcing one quick round of commentary from a set of relevant people - make a decision and pick a path quickly.

Then, if a problem(s) is observed on the selected path, either adjust your navigation slightly, or use the new knowledge and lessons learned to turnaround, walk out of the door, and walk back into another door to pick another path.

Decision position relative to time

In addition to the one way vs two way door mental model for decision type classification, another classification method is to consider how the decision is positioned relative to time.

Here there are also two classification types; decisions made on past events vs decisions made on future scenarios (decision trees).

Decisions made on past events

It may seem somewhat obvious, but as a first step, it's necessary to step back and determine if your decision is being made on top of past events.

If it is, grounding our choices in actual historical events and robust data, both qualitative and quantitative, ensures that we speak in truths rather than assumptions.

This method aligns with the adage, “In God we trust, all others must bring data,” underscoring the importance of evidence-based reasoning in our planning and operations.

By relying on data that reflects what has already transpired or been thoroughly analyzed, we can make informed decisions that are both defensible and transparent.

This approach not only minimizes the influence of bias and subjectivity but also builds a culture of accountability and precision - aligning with one of our values; quality certified.

Decisions Made on Future Scenarios

When making decisions based on future scenarios, it is crucial to approach them with caution and a broad perspective. Rather than focusing on a single expected outcome, it's more effective to consider a range of possible scenarios, mapping out a decision tree with multiple pathways. This approach helps in anticipating various outcomes and preparing for different eventualities.

Predicting the future inherently involves uncertainties, and speaking in absolutes about outcomes that have yet to occur can be misleading and potentially hazardous.

In these scenarios, our focus should shift from merely gaining acceptance of our proposals to critically evaluating the potential consequences of their implementation. The key question to consider is not just, "What if no one agrees with my proposal?" but rather, "What if my proposal is accepted and turns out to be wrong, sub-optimal, or, in the worst cases, damaging?" Such considerations are essential, especially when decisions are irreversible and based on scenarios with no historical data to rely on.

Unknown Unknowns

The concept of "unknown unknowns" refers to the factors and variables that we are completely unaware of and cannot predict or measure in advance. Unlike "known unknowns," which are uncertainties we recognize and can plan for, unknown unknowns represent the blind spots in our understanding and planning.

Conceptually, unknown unknowns are the surprises that can derail even the most well-thought-out plans. They are the events or factors that we don't know we don't know, making them particularly challenging to anticipate and manage. This concept was popularized by former U.S. Secretary of Defense Donald Rumsfeld, who highlighted the distinction between what we know, what we know we don’t know, and what we don’t know we don’t know.

Speaking in absolutes

When discussing decisions, it's important to avoid absolutist language, which can create a false sense of certainty and shut down constructive dialogue. Examples of absolutist statements include:

  • "This is 100% the right decision."
  • "This will not work."
  • "Users will not like this."
  • "Users will not understand this."

Such statements can be problematic for several reasons. First, they imply that no further discussion or consideration is needed, which can stifle creativity and critical thinking. Second, they often ignore the complexities and nuances of real-world situations, leading to oversimplified and potentially flawed conclusions. Lastly, absolutist language can alienate team members who may have valuable insights or alternative perspectives, reducing the overall effectiveness of the decision-making process.

Instead of speaking in absolutes, it's more productive to use language that acknowledges uncertainty and invites collaboration. This approach encourages a more thorough examination of the issue and helps build consensus.

Consider the following alternatives;

  • "These are the possible scenarios."
  • "This is what may eventuate, for the positive and the negative, in each scenario."
  • "Here are some potential outcomes based on the data we have."
  • People might have different reactions; let's map out what those could be."

Benefits of Avoiding Absolutist Language;

  1. Encourages Open Dialogue: Using flexible language invites others to contribute their thoughts and insights, leading to more comprehensive and well-rounded discussions.
  2. Recognizes Complexity: Acknowledging the uncertainty and complexity of decisions helps ensure that all potential factors are considered, reducing the risk of oversight.
  3. Fosters Collaboration: When team members feel their perspectives are valued, they are more likely to engage actively in the decision-making process, fostering a collaborative environment.
  4. Improves Decision Quality: By exploring multiple scenarios and potential outcomes, the team can develop more robust and adaptable strategies that are better equipped to handle future uncertainties.

Practical Tips for Avoiding Absolutist Language;

  • Use Probabilistic Thinking: Frame your statements in terms of likelihoods and probabilities rather than certainties. For example, say, "There's a high probability that this will succeed," instead of, "This will definitely succeed."
  • Present Multiple Scenarios: Outline different possible outcomes and their associated risks and benefits. This approach helps others see the range of possibilities and prepares the team for various contingencies.
  • Be Transparent About Assumptions: Clearly state the assumptions underlying your decisions and be open to questioning and revising them as new information emerges.

The paradox of confidence with decisions

Navigating the balance between confidence and caution in our decision-making is a delicate art. While confidence can drive decisive action and inspire trust within our team, it can also lead to overconfidence and flawed choices if we don't temper it with critical evaluation. Understanding this paradox is crucial for us to make sound decisions that account for both the strengths and limitations of our knowledge and perspectives.

Confidence and Decision-Making Risks

Excessive confidence can lead to overestimating our abilities and knowledge, increasing the likelihood of making poor decisions due to a lack of thorough analysis or disregard for alternative viewpoints and new information. Confidence can often precede a full understanding of a situation, leading to overconfidence in untested assumptions.

Pragmatic Skepticism and Effective Decision-Making

Adopting a stance of pragmatic skepticism—questioning assumptions and critically evaluating information—enhances our decision-making by ensuring a more comprehensive assessment of risks and options. This approach not only mitigates the risks associated with overconfidence but also increases the likelihood of us making well-informed choices. By continually practising pragmatic skepticism, we can navigate the complexities of our decisions with greater clarity and success.

The best ideas win

Our belief that "the best ideas win" embodies a meritocratic approach to decision-making and innovation. We strive to create an environment where the most effective, efficient, and innovative ideas naturally rise to the top due to their inherent superiority.

This philosophy underscores the importance of objective criteria and rational evaluation in choosing between competing ideas.

In an ideal environment free from bias, politics, or external influences, the ideas that offer the most benefits or solve problems most effectively are the ones that will be adopted and succeed.

This belief encourages open competition of ideas, fostering a culture where creativity and critical thinking are valued. We aim to ensure that all contributions are considered on their merits rather than the status or power of the person proposing them.

However, we recognize that this ideal can be challenging to realize in practice due to subjective interpretations of what makes one idea "better" than another and various external factors influencing our decision-making processes. By continually striving toward this ideal, we can create a more inclusive, innovative, and effective organization.

Decision classification matrix

Summarizing the above sections produces the matrix below - a tool that can be used to orient discussions at any time during the decision making process.

c25a5b07-50f6-471d-8705-f4a6f9d2736a

Decision logs

The Evolution and Benefits of Decision Log Documents in Confluence

The use of decision log documents in Confluence started within our engineering department, thanks to Tim's initiative. Recognizing the inefficiencies of frequent meetings and verbal communications, Tim proposed a structured approach to decision-making through written logs. These documents have since become a cornerstone of our processes, offering high visibility and fostering a culture of transparency and accountability.

Key Benefits and Practices

  • Clarity Through Writing; Writing forces clarity in thought, requiring us to articulate our reasoning and options clearly. This practice not only refines our ideas but also enhances communication skills, making it easier for all stakeholders to understand the decisions being made.
  • Reduced Dependency on Meetings; By documenting decisions in Confluence, we significantly reduce the need for synchronous meetings. This shift allows us to focus on productive tasks without the interruption of frequent meetings, improving overall efficiency.
  • Visibility and Accessibility; High visibility of decision logs ensures that all relevant stakeholders can view and contribute to the decision-making process asynchronously. This openness improves the quality of decisions and helps maintain alignment across teams.
  • Historical Reference and Learning; Decision logs serve as a valuable historical record, enabling us to review and analyze past decisions, especially when outcomes differ from expectations. This retrospective analysis is crucial for continuous improvement and learning.
  • Onboarding and Continuity; For new team members, decision logs provide an essential resource for understanding past decisions and the rationale behind current practices, easing the onboarding process and ensuring continuity.
  • Integration with AI Tools; Over time, the integration of AI technologies into Confluence has further enhanced the utility of decision logs. AI tools can analyze decision patterns, suggest improvements, and automate parts of the decision-making process, increasing efficiency and effectiveness.

Overall, adopting decision log documents in Confluence has transformed our approach to decision-making, making it more structured, traceable, and efficient. This method not only supports better decision outcomes but also contributes to a more informed, engaged, and accountable team culture.

Hard decisions

If a decision is on your mind frequently, or it makes you feel anxious, uncomfortable, nervous or stressed - it is likely a signal that it may be a hard decision.

Hard decisions don’t need much more of an introduction than that, so the question is - what do you do about them?

Personally, when I feel a hard decision coming on, I try to detach from any pre-conceived ideas or pathways, and instead route the nervous/anxious energy into decision tree mapping and documentation. Besides having some practical psychological benefits such as reduced stress and anxiety, it also creates a practical overview the potential paths forward - and picking a path is much more digestible than feeling blocked.

Some of Sitemate’s largest decisions to date have started as a Slack thread, either to myself in DMs, or to one other person, where each time I think of that topic - I go back to the thread, and drop another thought in.

Most threads die out and don’t continue to get used, but if I find myself continuously going back to a thread, it’s a signal that I now need to collate all notes into a decision log in confluence.

To give you an example - heading into 2024 I needed to make a decision about the GTM leadership team, which unfortunately resulted in a senior member of the GTM team being let go from their role at Sitemate.

Taking approximately two months in total, this decision evolved from;

  • A slack thread with myself, to
  • A slack thread 1:1 with Annabel, to
  • A one page decision log draft consisting of bullet points only, to
  • A 6-7 page decision log draft with charts, diagrams and screenshots, to
  • A closed decision log shared with other members of the GTM leadership team in-line with high vis, for their understanding on the situation and region-specific context
  • A final decision log PDF’d for board review

This process facilitated a fair and balanced review, allowing us to arrive at a consensus: it was necessary for the team member to part ways with the company. This decision, while tough, was supported by documented evidence and collective agreement, ensuring that the conclusion was not only clear but also justifiable to all parties involved.

Hard decisions should not be rushed, but that does not mean things need to move slowly when documenting pathways and evidence for and against each pathway - this should start as soon as possible.

For when there is a difference of opinion

When differences of opinion emerge within our team, it's crucial to determine whether they stem from a divergence in vision or simply in the methods of achieving our goals. Understanding this distinction is vital for effective resolution.

If the disagreement is about vision or ‘end-state’, it reflects deeper, more foundational differences in our long-term aspirations or our philosophical approach to work. Aligning on vision is challenging but critical, as it shapes the direction and spirit of our initiatives. This type of disagreement requires thoughtful dialogue to explore each party's perspectives and find common ground or a redefined purpose that resonates with all involved.

Conversely, if the difference of opinion concerns the path to achieve our shared vision, the resolution is generally more straightforward. These disagreements are typically about tactics or strategies - essentially, different ideas on how to execute our shared vision.

Resolving these issues involves a process of experimentation, feedback, and refinement, leveraging diverse viewpoints to strengthen our approach and enhance our collective learning.

In both cases, fostering an environment where open communication and a commitment to mutual understanding are prioritized is essential. By focusing on both the alignment of our vision and the flexibility of our paths, we can navigate disagreements constructively, ensuring that our team remains unified and effective in its pursuits.

The role of storytelling

When we encounter resistance to a proposed path, it's important to consider the role of storytelling and personal ownership in persuading others.

If someone or a group isn't on board with an idea, it often reflects not just on the decision itself but also on how the idea was communicated.

A deep understanding of the problem, clear presentation of the options, and robust data supporting each choice are fundamental. However, wrapping these elements in a compelling story that connects emotionally and logically with the audience is equally critical.

Storytelling in this context does more than just relay facts; it builds a narrative that helps others see the potential impact and value of the idea. This narrative approach helps bridge gaps in understanding and can convert skepticism into support by aligning the vision with the personal or collective aspirations of our team.

Moreover, taking ownership of your ideas involves more than defending them; it means being open to feedback and willing to refine our approach based on input from others. This aspect of ownership discourages counterproductive behaviours like frustration or defensiveness when faced with initial resistance. Instead, it encourages a proactive and responsive attitude that seeks to understand and address concerns.

By effectively combining storytelling with responsible ownership, you can enhance the persuasiveness of our ideas, foster better understanding and collaboration, and ultimately drive stronger alignment and commitment within the team. This approach not only resolves differences more effectively but also strengthens the overall decision-making culture within our team.

Conclusion

I started this blog post with a personal story that tries to highlight how I believe good (or bad) decision making is less about raw intelligence, experience and confidence, but moreso about strong mental models that aim to improve the quality of decision making by primarily providing orientation context.

Because, well - when you know where you are on the map, it’s easier to know which direction to step next, and how quickly you should move!

Keen to learn more or join the Sitemate team?

About Hartley Pike

Hartley is the Co-Founder and CEO of Sitemate. An Engineer by trade, Hartley founded Sitemate to enable built world engineers to operate more like software engineers, using a suite of best-in-class and seamlessly integrated tools.

Leave a Comment