Category: transparency

Bringing Clarity to Engineering Decisions

lezka

In any evolving engineering organisation, clarity is the bedrock of a healthy, productive team. Ambiguity around who owns a decision isn’t just a drag on speed; it erodes employee confidence, leading to self-doubt and hesitation. The Engineering Decision Board is a simple yet powerful tool designed to build a culture of clarity and trust by defining and aligning expectations for decision ownership within the engineering group.

By using this board, your team ensures that the right people are always consulted, fostering transparency. More importantly, it empowers individuals to act with confidence and autonomy, knowing they have the backing of the organisation. This isn’t just about making decisions faster; it’s about building an environment where every team member feels trusted, respected, and clear about their role in driving progress.

Understanding the Board’s Structure

The board is structured as a table listing specific Decision Areas and the key organisational functions that must be involved in the final call:

  • C-Level
  • HR
  • VP
  • Director
  • Others as needed. These could be other functions, individuals or entire teams.

The core mechanism is accountability and ownership: if a function has an ‘X’ marked, they need to be involved before a final call is made on that decision area.

Example:

Decision AreasCTOHRPMQADirector
Staff
Salary Adjustments / Promotions $$XX
Change Reporting LinesXX
Firing a memberXXX
Teams
Team StructureXX
Job TitlesXX
Team GoalsXXX
Time Management of Teams
Working TimesXX
Approve Vacation DaysX

Filling the Board

For every item under “Decision Area,” mark a cross (‘X’) in the corresponding columns to indicate which functions must be involved in the decision. It is common for a decision to require input from one or more functions.

  • Example: Approving requests for Hardware Accessories may only require the Director to be involved, while Salary Adjustments and Promotions would usually require C-Levels and HR too.

There are a couple of ways to fill in this table:

  1. Top-Down: The CEO or your direct line manager fills out the board based on their established view of organisational structure and authority. This approach is faster and ensures immediate alignment with executive strategy.
  2. Collaborative (Recommended): This approach is more engaging and will spark valuable conversations, though it requires more effort. The process involves:
    • Real-time Input: Get everyone involved in a dynamic exercise where participants—from C-Level to individual contributors—anonymously or openly place their ‘X’s on the board in a collaborative document, indicating who they believe should be involved in each decision area.
    • Discussion and Alignment: The group then discusses the aggregated results, specifically looking for disagreements or differing understandings across roles.
    • Outcome: The aim is to learn more about the interests and concerns of all parties and conclude on the best, agreed-upon way to make each decision, ensuring buy-in and clarity from the entire team. This co-creation process is key to building trust.

Keep it live

This is a living document. Do not treat it as final; feel free to add or amend decision areas as your team or organisation evolves. For instance, if you establish a new process, you may need to define who owns decisions around that process.

Adapt it to each context

This exercise works very well for decisions within teams too. Once I tailored a Decision board for a QA team who was struggling with this issue, we ended up defining 4 levels of decisions:

  • Level 1 – Solo Decision: These are decisions that anyone in the team can take individually and go ahead with it, it’s only required to communicate it to the rest.
  • Level 2 – QA Team Consented Decision: These decisions can go ahead if a proposal is shared with the entire team and finds no opposition.
  • Level 3 – QA Team Consensus Decision: In this case, consensus of the entire team is required to proceed.
  • Level 4 – QA Team + External Decision: In this level, a member external to the team needs to be consulted before proceeding.

We ended up with a board like this:

QA Decision Board

Level 4 – QA Team + External Decision
Architecture
Infrastructure
Tooling
Development workflow
Level 3 – QA Team Consensus Decision
QA Theory
QA Strategy
Best Practices (QA + Code)
QA Workflow
Level 2 – QA Team Consented Decision
New Tools
QA Solutions
Level 1 – Solo Decision
PR Reviews/Approvals
Story level testing + Unit tests
Investigation and research
Task approval

Conclusion

The Engineering Decision Board is a crucial mechanism for transforming decision ambiguity into organisational clarity. By explicitly defining who needs to be involved in key decision areas, it fosters a culture of transparency, trust, and empowered autonomy across the engineering function. Implementing this board—whether top-down or, preferably, collaboratively—ensures alignment and speeds up progress. This is not a static artefact but a living tool designed to evolve with your organisation’s needs. Use the following template as a starting point to begin bringing this critical clarity to your own team: Decision Board Template.

This was inspired by the “Delegation Board” exercise from the book Management 3.0.

Slack DMs kill transparency

lezka

🔊As a company grows and processes get more complex it becomes much harder to share effectively, include everyone, and access all available information.

However, since most information flows digitally, we can follow a few guidelines to get as close as possible to the spirit of transparency which many companies claim but very few implement policies for it.

If you want to increase your transparency, read on.

📄 Online Documents
These may include Confluence pages, Google Docs, Jira tickets and others. Always default to transparency. Do not restrict access unless there is a solid reason to do it. We must not share:

  • Confidential information such as personal data, employee development or third-party contracts.
  • Secret strategic plans or critical business information that could harm our competitive edge if leaked to the public.


Slack
We must use it in our favour and not try to replace physical or phone interaction with it. Slack offers a complete outreach that isn’t possible otherwise, and it’s a waste if we limit it by our acquired social habits.

  • Create channels as public. This one is probably the easiest, yet we still have too many. Please think twice before making them private. The majority of the time, there isn’t anything that can’t be shared.
    • Add a description/topic to help participants understand the topic and their role within it.

Create a #name-team public channel. Use it as the main communication channel for the team and welcome everyone else to it. Remove and merge channels when possible.

  • Participate in the public channels. Use them to share info and ask questions. Help centralise the conversation about a given topic.
    • Acknowledge the information shared. Simple reactions go a long way:
      received 👍 agree 👎disagree 🔔👀later.
    • When people feel ignored, they will automatically be discouraged from continuing to share and ask questions.
  • Avoid DMs ⛔ DMs, even when including multiple people, are exclusive and unnecessary. Unless you deal with a sensitive or personal matter, you should have that conversation in the public channels.
    • Whenever you have the impulse to send a DM, please reconsider and mention people in the public channel instead.
      • By prioritizing public chats over private ones we will have all the conversations and discussions accessible to everyone.
        Imagine an office desk setup, where if person A talks to C about something, B and D can still overhear and intercede in the conversation if they have any valuable information
        .
        One of the main powers of online communication is that you can reach a big audience with little effort. Our business is complex and knowledge is key to our success, so knowledge-sharing is critical for us. For our projects, knowledge is everything. Share info with as many people as possible using public channels. However, be mindful and intentional with the notifications you are triggering by mentioning the specific people or subgroups that are expected to act upon the information. Remember that only people who are specifically mentioned will be notified about further replies within threads.
      • DMs also overload some people who become the unofficial go-to person for certain topics. This creates bottlenecks and adds stress to these people. By sharing the question in a public channel instead, you may get a richer and faster response, and the knowledge will be shared. You will also be promoting participation.
    • Summarise and share. If you still decide to open a DM, summarise the content/outcome and share it in the related public channel so no one is excluded.

Create and participate in #project and #collaboration channels. Use them for cross-team conversations and mention people when needed.

  • It is not Spam. When you keep on topic in a given channel, you are not spamming; you contribute to providing a more complete picture.
  • Link. Cross-reference, quote and link any external information to provide full context.
  • Don’t be afraid of setting roles. Even if you don’t mind everyone reading, you may not want everyone to participate equally. If that’s the case, state it in the channel’s description and politely refer to it when needed.
  • Politely redirect. Encourage others to be transparent and effective by asking them to:
    • Stay on-topic when not aligned with the topic of the channel.
    • Understand their role in the conversation.
    • Move the conversation to a public channel when using unnecessary DMs.
    • Move the conversation to a public channel when using unnecessary private channels.
  • Take control over your notifications to have time for yourself and to help others.
  • Walk out. Feel free to leave a channel when it isn’t relevant to you. You can always join back or read it without joining. If you are needed, someone will bring you back again.
  • Private Channels. Unless you deal with sensitive, personal or confidential information, there isn’t a real reason to have private channels. Private channels facilitate gossip and silos. Sometimes, teams may benefit from having a “safe” space to talk privately and share internal jokes and other personal stuff. Use your judgement.

An alternative to a team private channel is to create a #name-team-internal public channel to discuss lower-level details of day-to-day tasks that may not be relevant to the wider audience. Welcome others to read.

Zoom
Just like DMs, video calls are exclusive. Please summarise and share any takeaways in the related public channel(s) to keep everyone else in the know.