Why Engineers Work on the Wrong Things and How Transparency Fixes It

[applause] Um, welcome to my talk about engineers and transparency. My name is Victor Lebaski. I've been in tech for over 25 years. I'm currently a principal software engineer at Fleet Device Management. At Fleet, we make endpoint telemetry for corporate security teams and device management for corporate IT teams. So, over those 25 years, I've written a lot of code. Once I've written code for 16 hours straight to hit a deadline, I've shipped features. I've fixed outages. I've had great managers. I've had terrible managers. And for a long time, I thought the hardest problems in engineering were technical. Scaling systems, performance bottlenecks, security flaws. Well, I was wrong. The hard pro the hardest problems were not technical. They were invisible. They were organizational. They were about why we were building something, who it was for, and whether anyone actually agreed on what mattered most. And I didn't realize how damaging that invisibility was until I found myself living in what felt like a time loop. This is a picture from the 93 movie Groundhog Day. A few years ago, I felt like I was living in one. Same day over and over again. I was a tech lead at a large company. We were working on a project that depended on another upstream engineering team. Every week we had a joint meeting with both teams. Same room, same faces, same Excel spreadsheet. And every week I would ask the same question. I tried to keep my tone professional, calm, neutral. Hey, Alex, any update on that component we need from your side? And every week, Alex would say something like, "Oh, I meant to get to it, but I got pulled into something else. I'll try to get to it this week." At first, I gave it the benefit of the doubt. Stuff happens. Priorities shift, emergencies come up. We're all adults. But then it kept happening. Two weeks, three weeks, four weeks, same answer, no progress, no accountability, no one stepping in, just polite nods, and then the meeting moving on to the next agenda item. I was boiling inside. I kept thinking, why is no one telling Alex to work on this? Where's our project manager? Who's making the call on what really matters? Deadline slipped. Commitments evaporated. Meanwhile, I had to face my boss again with another non-update. And the worst part was that no one was fighting this. No one was arguing. No one was escalating. Everyone everything was polite. Everything was reasonable. And seemingly no progress was being made. That politeness felt mature, professional, civilized, but it was expensive. Sounds good wasn't commitment. Silence wasn't agreement. A nod wasn't alignment. It felt like we were confusing politeness with alignment. And the cost of that confusion was weeks of delay and months of frustration. In those meetings, no one said this is not a priority. No one said we don't have capacity. No one said another initiative is more important. Instead, we said things like, "Yeah, we'll try." And everyone accepted that as progress. But we'll try is not a plan. It's a social lubricant. The frustration started eating at me. I'd sit in those meetings and think dark thoughts about Alex, about myself, about the company. Did Alex just not care? Was I failing as a tech lead? Was this just how companies worked? And this wasn't just a few bad weeks. It was years of my life. The same pattern in different teams, vague priorities, soft commitments, status meetings that produce no decisions. I would go home exhausted, not from hard work, but from the sheer weight of organizational dysfunction. And here's what was awkward. I participated in it. I was polite, too. I didn't push harder. I didn't demand clarity. I accepted ambiguity because it felt socially safer than conflict. The room rewarded smoothness, not truth. And so, this loop continued. Looking back, I can name it now. the cost of politeness in engineering cultures. When we avoid discomfort, we avoid clarity. When we avoid clarity, we avoid decisions. And when we avoid decisions, work drifts. Not because people are incompetent, but because no one is explicitly explicitly saying what matters most. For a long time, I thought the problem was Alex. Maybe he lacked urgency. Maybe he lacked discipline. Maybe he just didn't care enough. That was the easy explanation. Blame the individual. But eventually, I had to admit I was wrong. This wasn't about motivation. Alex was probably overwhelmed, just like I was, just like everyone else in that room. He wasn't choosing to ignore our request. He was responding to signals I couldn't see. He was optimizing based on information I didn't have. And I was doing the same. This was not a motivation problem. It was an information problem. We were operating inside what I now call priority fog. A system where everyone is busy. Everyone's sincere and no one can clearly see how their work connects to what actually matters most. In priority fog, engineers guess, managers filter, road maps drift, meetings multiply, and polite alignment theater replaces real decisions. Everyone believes they're doing the right thing, and yet nothing significant moves forward. That was the fog I was living in, and it took me years to realize it wasn't inevitable. Let's step back from Alex for a moment because this wasn't just about one meeting. At many organizations, engineers don't know why their work matters. They know what ticket they're working on. They know what sprint they're in, but they don't know how that work connects to revenue, retention, or strategy. They're executing tasks without visibility into impact. At these organizations, people say things like, "Customers want this." But which customers? Paying customers or prospects? Often no one knows. Other directors I've heard sound strategic but remain vague. Make it reliable. Make it faster. We need dashboards. Add AI. These phrases feel decisive. They feel ambitious, but they don't define tradeoffs. They don't clarify what should be deprioritized. They don't define what success looks like. They create activity without clarity. Many companies believe they are aligned because they hold meetings about alignment. They believe alignment exists because no one objected. But alignment meetings don't create alignment. Shared context creates alignment. When engineers lack context, they still behave rationally. They improve test coverage. They refactor messy modules. They instrument better telemetry. They harden edge cases. None of that is wrong. It is responsible engineering, but it may not be the thing that unlocks revenue, prevents customer churn, or supports a strategic customer at a critical moment. When context is unclear, engineers optimize what they can see. That's logical. But companies don't win through local optimization alone. Companies win through global optimization. That means um sometimes shipping something imperfect because it unlocks a large customer or prioritizing a recurring customer issue over a beautiful refactor or delaying elegance in favor of momentum. Those trade-offs require business context, not just technical judgment. Managers cannot sit over every engineer's shoulder and dictate those trade-offs. Engineering work is knowledge work and it is notoriously difficult to measure. Lines of code, commit counts, velocity points, all of these metrics are imperfect proxies. Managers must rely on engineers to make sound decision decisions themselves in the moment. But trust without context is fragile. I'll explain. If engineers are expected to own outcomes, they need visibility into what outcomes matter. Otherwise, they're held accountable for goals they cannot see. That's not empowerment. It's structural ambiguity. Looking back at that meeting with Alex, the problem becomes clearer. It wasn't laziness. It wasn't incompetence. It was rational people responding to incomplete information. Everyone was optimizing locally. Everyone was sincere. And no one had a shared, explicit understanding of what mattered most. Another pattern appears in siloed organizations. Teams cannot see each other's priorities. Each team has its own board, its own backlog, its own emergency. Inside that boundary, everything feels urgent. Everything feels justified. From the inside, the work always makes sense. But urgency is relative. What feels critical inside one team may be marginal at the company level. Without cross team visibility, teams operate as if their slice of work is the center of gravity. Silos don't just separate code bases, they separate context. Over time, this creates artificial importance. Teams begin to defend their road maps. They protect their commitments. They escalate their blockers not out of malice, but out of incomplete visibility. When no one can see the full picture, everyone assumes their corner manners matters the most. This is where people start playing a zero- sum game. In non-transparent organizations, priority feels like a limited resource. If one team gains attention, another team must be losing it. So, urgency gets hoarded, language intensifies, everything becomes critical. What would the opposite look like? What would it look like if urgency weren't hoarded, but visible? At my company, Fleet, one of our values is having short toes. That means not being territorial about work. So each product team has a visible board as shown in the example here. You don't need to read all the details, but it's easy to see if another team is overloaded with critical customer commitments. Uh we can fil filter by customer tags or priority labels. Uh and when visibility exists, work can shift. Capacity can rebalance. Urgency becomes shared instead of competitive. When teams can see each other's constraints, artificial importance dissolves. The conversation changes from um this is our priority to what is the company priority. That shift is subtle but it is structural. Without shared visibility, cooperation depends on persuasion. With visibility, cooperation becomes rational. Uh some of you may be wondering what about the managers? It's tempting to assume managers solve this problem. After all, managers attend more meetings. They see more of the cross team picture. They hear executive priorities. In theory, they can translate all of that context down to the teams. I used to be a manager years ago. A large part of the job was gathering information and relaying it to direct reports. But that relay process is fragile. What if I misunderstood something in the meeting? What if I didn't get the nuance? What if I missed the full context because I was looking at my email? Managers are human routers. When details must pass through layers of management, it gets compressed and compression removes context. Managers are also saturated with inputs. Even the best communicator cannot transmit everything. Somewhere in that chain, clarity degrades. So if meetings don't scale trust, what does? Next, we move into transparency as infrastructure. So realizing the importance of transparency changed how I think about leadership. For years I believed alignment came from better communication, more meetings, clear updates, better slide decks. But communication is episodic. Infrastructure is persistent. If clarity depends on who was in the room, then clarity is fragile. Transparency is not culture. It is infrastructure. I call this structural transparency. It means transparency built into the operating system of the company. Not just information being shared, but documented processes, visible escalation paths, inspectable decision frameworks. Culture is how people behave. Infrastructure is how the system is built. Culture depends on intention. Infrastructure defines defaults. When transparency is treated as a value, we value openness. It remains and feels optional when it is designed into the system. It becomes structural. If context must pass through layers of management, it becomes a bottleneck. If strategy must be relayed verbally, it becomes distorted. If priorities live in private conversations, alignment is easy to lose. Transparency when designed well functions as infrastructure. That is the difference between conversational transparency and systemic structural transparency. Conversational transparency says I'll explain this to you. Structural transparency says it's already visible. One depends on memory and interpretation. The other depends on design. You cannot scale trust with more meetings alone. Meetings help. They clarify nuance. They allow debate. But if clarity depends on who attended, the organization resets to priority fog. What scales is not the meeting. What scales is what survives the meeting. If how we operate is written down and accessible, alignment does not depend on attendance. It depends on structure. Defaults are very important. If documentation is optional, it decays. If transparency requires too much effort, it'll fade. If visibility requires, it becomes scarce. Infrastructure is about defaults. Public by default, visible by default, accessible by default. When transparent becomes infrastructure, behavior changes naturally. Teams stop hoarding urgency because urgency is visible. Engineers make better trade-offs because business impact is inspectable. Managers stop being sole routers of information because context no longer depends entirely on them. The system carries the clarity. This is the conceptual shift. Transparency is not a personality trait of leaders. It's not a vibe. It's not about being nice. It is about designing systems where context flows without distortion and priorities are inspectable without permission. Infrastructure scales, culture follows. And once transparency is designed into the system, something interesting happens. Meetings don't disappear, they improve. Conversations become sharper. trade-offs become explicit, disagreements become easier to resolve because the shared state is already visible. So that was the upgrade I had been missing for years. I kept trying to improve communication. What we needed was to improve organizational architecture and that that's when the fog began to lift. So transparency isn't the same thing as information. Many organizations confuse the two. They assume that if data exists somewhere, transparency exists. But information alone doesn't create clarity. It creates volume. Information answers what happened. Context answers why does it matter. A dashboard full of metrics is information. Knowing which metrics affect revenue or strategy, that's context. When companies dump raw data into shared drives and call it transparency, they create noise. No does. Noise doesn't create alignment. It creates create increases cognitive load. Curated context creates clarity. That takes effort. But it's architectural effort, not clerical. It means deciding which question should never be asked twice and preserving that reasoning behind key decisions. Not just what we choose, but why. That why is what lets others act without waiting. In the past, that kind of curation was expensive. Today, it isn't. With better tooling and increasingly with AI, we can summarize long threads, extract recurring questions, and draft documentation quickly. The barrier isn't cost anymore. It's intent. Mature transparency isn't about dumping everything into a shared drive. It's about operational relevance. Not every detail needs to be written down, but the frameworks, escalation paths, and priority roles that shape decisions should be visible to the people affected by them. When information is shared without context, people fill in the gaps. Different teams for form different interpretations of the same facts. Volume increases. Alignment doesn't. The reason I bring this up is because organizations often overcorrect. They swing from secrecy to overload. But volume isn't openness. Relevance is. The goal isn't maximum exposure. It's shared understanding. There's another effect of structural transparency that's often overlooked. It compresses decision latency. In non-transparent systems, decision travel upwards to management for approval and downward for interpretation and sometimes up and down a few more times. Each layer adds delay not because people are slow uh but because context is scarce. In transparent organizations, more context lives at the edge. Engineers can see which customers are affected. Teams can see which contracts are at risk. Managers can see cross teamam dependencies without constantly requesting status summaries. When visibility increases, fewer questions need to travel upward. That shortens the time between program recognition and action. Transparency does not eliminate hierarchy. It reduces dependency on hierarchy for routine trade-offs and that reduction lowers latency. In competitive markets, especially now as developers are increasing their velocity with AI agents, latency is more important than ever. The difference between responding in days versus weeks can determine whether a customer renews or churns. There's a final dimension that makes this uh more than a cultural preference. Transparency reduces risk. When priorities are hidden, revenue risk increases. Teams can spend months building something that doesn't actually move an important deal forward. And by the time anyone notices, a key customer may already be walking away. There's single point of failure risk. When context lives primarily primarily in conversations, it lives primarily in people's heads. If those people live leave, the reasoning leaves with them. Documentation reduces dependency on individuals. There then there's execution risk without shared visibility. Cross team dependencies are discovered late. Surprises multiply. Firefighting increases. Delivery becomes unpredictable. And there's strategy drift. When trade-offs are implicit instead of explicit, the organization gradually moves in directions no one consciously chose. So looking back at that meeting with Alex, the real risk was not one delayed component. It was systemic drift. Multiple teams optimizing locally, priorities shifting quietly. There was no shared understanding anchoring decisions. Nothing dramatic was happening. There was no outage. But momentum was dispersing. That kind of drift compounds over time. Transparency is not about comfort. It is about reducing the probability of silent failure. When visibility is structural, risk becomes visible earlier and visible risk is easier to manage. Think about an API. It defines a contract so components don't renegotiate meaning every time they interact. Organizations need the same thing. Organizations need stable, inspectable contracts for how work moves. At my company, Fleet, that leverage does not come from logging every decision. It comes from documenting how the organization operates. Processes should be documented like APIs. We do use ADRs, architectural decision records, and they're useful. This is a sample beginner one, and you don't need to read all the text. Um, they capture meaningful technical trade-offs. They reduce litigation, and they help new engineers understand why the system looks the way it does, but they're not the structural center of gravity. At Fleet, the core transparency infrastructure is our handbook. You can see the starting page here. You don't need to read it. It is public so you can view it later. Um, we do not run on ask your manager. We don't rely on orient tradition or Slack archaeology. We we run on written version processes. Think about what an API actually provides. It defines inputs and outputs, constraints and guarantees. It creates a contract that allows independent teams to move without renegotiate meaning every time they interact. Our handbook plays the same role but at the operational level. It defines how hiring works, how releases are shipped, how customer issues are escalated, how product design reviews are conducted, and how recurring tasks are handled. It defines the contract of how we operate. So when someone asks, "What do we usually do in this situation?" The answer is not in a slack thread, not in a memory of a past meeting, and not in a quick clarification from a manager. The answer is to open the handbook and follow the documented process. That shift ma matters more than it sounds. Clarity no longer depends on proximity to leaders or tenure inside the company. It depends on inspectable structure. That is what operational autonomy looks like in practice. Now consider remote work across time zones. Sorry for the busy slide. If you're in another country and asleep when leadership is online, you still have access to the prioritization philosophy, the escalation paths, the release process, and the frameworks that guide decision-making. You're not waiting for interpretation or context to trickle down to you. Instead, you're following a documented contract that dramatically reduces dependency on real-time clarification and eliminates much of the fog traditionally created by asynchronous work. So earlier I described priority fog as the condition where context lives in people, processes live in habits and trade-offs lives in human memory. That fragility creates bottlenecks and misunderstandings. When someone leaves the company, context leaves. When someone is overloaded, clarity stalls. Handbook first design removes that fragility by shifting knowledge into the system itself. The organization carries the reasoning. It's not stored in the IC, the manager or the person who happened to be in the meeting. So at Fleet, our handbook is public. Customers can read it, contributors can read it, candidates can read it, partners can read it before signing an NDA that reinforces a structural truth. Transparency is infrastructure, not a vibe. When your operating system is public, it has to be coherent and defensible. Public visibility imposes discipline. Weak processes cannot hide behind ambiguity. If structure is unclear, the world can see it, which pushes us to continuously improve. This model is not free. It requires writing before acting. In some cases, it requires updating documentation when reality changes. It exposes weak thinking and outdated assumptions. It creates friction when something is unclear. But that friction is productive. Instead of vagueness, you get inspectable structure. Instead of dependency, you get autonomy. If you want practical transparency, begin by making how you operate inspectable because processes outlive meetings. But who maintains it? The honest answer is everyone who depends on it. Leaders help define what must be explicit. They shape the operating principles and escalation path, but individual contributors improve processes, propose edits, and document recurring patterns. The handbook only works if people doing the work keep it accurate. At Fleet, we reinforce that explicitly. We have a public thanks channel where people are regularly acknowledged for improving the handbook or clarifying a process. That might sound small, but it signals something important. Maintaining the operating system is valued work not invisible labor. Curation is not clerical clerical work. It is system maintenance. The operating system of a company like any system stays healthy only when everyone treats it as shared infrastructure. What gets curated is not every decision and not every slack debate. You documented decision frameworks, escalation paths, release processes, customer handling standards and the philosophy behind prioritization. In other words, you document how to decide, not every instance of deciding. That distinction prevents bureaucracy and keeps the system lightweight. Transparency should scale with consequence. High impact patterns deserve structure. What does not get curated are minor tasks, temporary experiments, and low impact implementation details that do not meaningfully alter how the system behaves. A simple filter works well. If the same question is asked twice, document it. If it's a one-off, move on. Filter by impact, risk, and repetition. The goal is not comprehensive exposure. The goal is preserving reasoning that will predictably recur to avoid burnout. Use templates, adopt a handbook first norm for operational changes, reward computer contributors who improve clarity, and invest in good search tools. AI can assist by summarizing long Slack threads, proposing draft handbook edits, and identifying recurring questions that deserve formal documentation. But AI should not define priorities or strategy. It reduces clerical friction. It does not replace judgment or leadership. The guiding principle is simple. Write for the future teammate, not the present meeting. If an artifact only satisfies today's status update, it will decay quickly. If it enables someone next year to act confidently without asking for permission, it compounds in value. That is structural transparency, not volume, not performance theater, infrastructure that enables independent progress at scale. So we talk a lot in engineering about technical debt. We understand that when you cut corners, complexity accumulates and eventually you pay interest in the form of slower velocity and fragile systems. Transparency works kind of the same way. Secrecy accumulates confusion. I call this transparency debt. It builds quietly, often invisibly until suddenly everything feels harder than it should be. Transparency debt occurs when processes are known but undocumented. When decisions are made but not inspectable. When priorities shift but no one explains why. When escalations happen repeatedly but no one captures the pattern in a durable way. Nothing seems catastrophic in the moment. Work continues. Meetings continue. But reasoning slowly decays into memory instead of structure. That interest shows up as repetition. The same questions asked again. The same escalations replayed. The same meeting happening for the fourth time. When I think back to Alex, I see another angle to our issues and that is accumulated transparency debt. Prioritization logic was not inspectable. Escalation paths were informal. Trade-offs were implicit. The meeting kept replaying because the system had never externalized its reasoning. We were paying interest on invisibility. So to make this practical, here's a simple maturity model for transparency. Not a scorecard, a a diagnostic. Most organizations fall into one of three levels. The difference here between them isn't intention, it's structure. Level one is the conversational organization. Context lives in meetings and people's heads. Managers act as routers of information. If you miss the meeting, you miss the reasoning. This is where priority fog thrives. Level two is the artifact organization. Context starts living in visible artifacts. handbooks, boards, escalation paths, documented priorities. Alignment depends less on meetings and more on what people can inspect. Level three is the autonomous organization. The operating system of the company is visible. Engineers can act and reason about trade-offs without waiting for interpretation. Leaders spend less time clarifying processes and more time setting direction. Here's a simple test. Imagine a senior engineer in another time zone asleep during executive discussions. Can they still ship safely, escalate correctly, and explain company priorities without asking their manager? If yes, you're close to level three. If not, there's still some fog. Some of you may be thinking, "This sounds great, but I'm not the CEO. I don't control the operating system of the company. What can I actually do?" Well, if you want more transparency, the first alignment is upward. You need to understand your manager's priorities. You should aim to know about 90% of what your manager knows about strategy constraints and trade-offs. Not because you're political, because context drives better decisions. Here are a few examples to uh of things to ask. These are just ideas. If we could only get one thing right this quarter, what would it be? Where do you want us to move faster even if quality dips slightly? What kinds of issues they want to hear about immediately? And what does your manager care about most right now? Now, if these questions feel unwelcome, well, that tells you something about the system you're operating in. How do you get to 90%. Here's a few more ideas. Watch meeting or recordings if they exist. If not, suggest that key meetings be recorded. Read meeting notes carefully. If none exist, suggest AI notetakers. Use your one-on-one with your manager to clarify strategy, not just status. Make it a context transfer session, not a task update. Then repeat this pattern. Try to have a skip level meeting with your manager's manager. Trace the signal upward. You don't need to know everything, but if you can see one layer beyond your team, you reduce local opt optimization. Transparency starts with curiosity. Also, you don't need permission to document recurring decisions, write down escalation paths, move discussions into shared channels, suggest artifacts over threads. You can externalize reasoning inside your scope. That is grassroots grassroots structural transparency. If you understand something others don't, don't hoard it. Share it, write it, link it, surface it. Every time you move context from memory to artifact, you reduce transparency debt. That is how systems change from the inside. So up to this point, I've been talking about systems, infrastructure, documentation, operating rules. But systems don't just change process. Transparency also changes the human identities of people involved in a good way. So, I need to admit something. I love being the hero. I love being the person who gets called in late when something critical is broken. I love stepping into a messy situation, untangling the complexity, and saving the day. There's a particular satisfaction in being the one who understands what others do not, especially when the system is on fire and everyone's looking for answers. I remember diving into production issues and fixing something no one else understood and the next the next day people would say thank you for stepping in. That praise feels good. It reinforces a basic human desire. It tells me that I matter. It tells me that my knowledge is rare and valuable. It tells me maybe that I am indispensable. But there's a problem. That feeling may have been built on asymmetry. Perhaps I knew things others didn't. Perhaps I had context that wasn't written down. Perhaps I had access to decisions that lived in conversations. Hero culture thrives when operating systems are undocumented and context is trapped inside people. When process lives in memory and trade-offs live in the private threads, the person closest to the information becomes the hero. Over time, after thinking about it, it became clear what was happening. Many emergency rescues reinforce dependence. They rewarded the person with the most context instead of fixing the structure that created the problem. Heroics aren't excellence. They're usually evidence that something structural is missing. When a system needs a rescuer to function, it isn't strong. It's fragile. These days, I try to work differently. I look for context I need instead of waiting for manager updates. I check the handbook before escalating something that feels urgent. If the same question appears twice, I document it. And I move conversations out of direct messages and into shared channels. I'm not trying to be the fastest fixer anymore. I'm trying to make sure the next problem doesn't require a hero at all. When operating rules are written, when escalation paths are inspectable, and when prioritization philosophy is documented, emergencies actually become less frequent. Not because people suddenly become more disciplined. Not because everyone tries harder, but because fewer things depend on hidden context, on something that only certain people know. When reasoning is visible, confusion drops. And confusion is what fuels most chaos. In blackbox systems, information hoarding becomes power. In transparent systems, visibility becomes power. That shift changes behavior. Instead of heroic rescues, you get reliable execution. Instead of dramatic saves, you get predictable delivery. Instead of late night Slack messages, you get fewer surprises. The energy that once went into reacting can now go into designing systems that pre prevent recurrence. When how work gets done is visible. No single person has to interpret reality for everyone else. Engineers can see escalation paths. They can see prioritization logic. They can see cross teamam constraints. They can also see the actual engineering artifacts. the stories, the architectural documents, the ADRs, the QA test plans that describe how something was tested, as well as the issues that show up when um that show what trade-offs were made. That reduces the need for a human router to mediate every decision. Instead of asking someone what happened, you can inspect what happened. Fewer bottlenecks means fewer crises. And without constant emergencies, no one needs to play the hero. This does not eliminate complexity. It does not eliminate risk. But it reduces dependence on personality. Reliability replaces heroics. Prevention replaces rescue. Shared visibility replaces information hoarding. And trust grows not because someone saved the day, but because the day did not need saving in the first place. That is what structural transparency does. It stabilizes the system. Now there is an ego cost to this shift. Transparency removes mystique. It reduces the power that comes from proximity to hidden details. It exposes weak reasoning and makes dep prioritization visible. Not every engineer enjoys that. When decisions are inspectable and processes are documented, you don't get to feel special just because you know something others don't. Influence become less about access and more about contribution. Transparency forces an identity shift from indispensable to replaceable by design. That can feel threatening at first, but in healthy systems replaceable by design is not an insult. It is resilience. When no single person is required to hold the system together, everyone is freer to contribute at a higher level. It's uncomfortable, but it is necessary. Um, there's a danger here that I need to name clearly. Transparency by itself is not automatically good. If you expose problems, risks and constraints without giving people the authority to act, you don't create empowerment, you create anxiety. Visibility without agency is incomplete. It is pressure without control. There are organizations that share dashboards, metrics, and strategic concerns widely. Engineers could see churn risk. They could see missed deadlines. They could see customer escalations, but they have no documented decision framework, no clear escalation path, and no permission to move. They're informed, but structurally constrained. That combination easily learns to burnout. When you can see the fire, but you're not allowed to touch the hose, that experience is frustrating and exhausting. Visibility must pair with operating rights. Visibility must pair with documented decision frameworks that clarify who can decide what. It must pair with clear escalation paths so that acting does not feel like overstepping. So at Fleet, one of our values is having short toes. As I mentioned before, that means we're not territorial about work. When priorities are visible and escalation rules are written down, work can move across boundaries without waiting for permission rituals. Visibility increases mobility. It is easy for our people to work on the most important thing. But if visibility increases and authority does not, we have an issue. When people see the problems but they hesitate, they wait, they second guess whether stepping in will be seen as overstepping. That's a problem. That doesn't feel empowering. It feels like being watched without being trusted. So I say this carefully, visibility without operating rights starts to feel like surveillance. Agency requires structure. Transparency should make it easier to act responsibly, not just easier to observe what go what goes wrong. So this is where conversation stops about being about tooling and starts being about fairness. We often talk about accountability as a virtue. We expect engineers to own outcomes. We expect managers to take responsibility. But ownership without visibility is structurally unfair. If someone is accountable for a result, they must be able to see the forces that shape that result. If someone is expected to make sound tradeoffs, they might they must have access to the reasoning that defines those trade-offs. Otherwise, we're asking them to guess. Expecting accountability without visibility is unfair. Expecting autonomy without documenting operating rules is unfair. If leadership keeps strategy private, keeps prioritization logic informal and keeps processes implicit, they cannot reasonably demand independent execution. You cannot require responsibility from people you keep structurally dependent. Um, dependency is not always obvious. It can be subtle. Engineers wait for clarification. Managers become approval bottlenecks. Decisions escalate vertically because the framework for horizontal movement doesn't exist. The organization then misinterprets this behavior as a lack of initiative when in reality it is a lack of inspectable structure. Accountability without visibility and without agency is unfair. When people are expected to own outcomes, they need access to the reasoning behind those outcomes and the authority to act on it. All right. So what does all of this look like in practice? Let me ground this in something concrete. At Fleet, transparency is not an abstract principle. It is embedded in how we operate day-to-day. It shows up in documentation, in meeting norms, in how we ship releases, in how we escalate issues. It's not perfect, but it is structural. So, one of our strongest norms we have is handbook first. I mentioned the handbook earlier. If we change how something works operationally, the handbook gets updated before the change is considered live. That forces clarity. It prevents decisions from living only in meetings or Slack threads. If it matters operationally, it must be written down in a way that someone else can follow without interpretation. Also, as I alluded to before, we operate with open GitHub issues and public boards. Customers can see what we're working on. They can follow the progress of features that affect them. Contributors can see where help is needed. That reduces friction. It also forces prioritization decisions to be visible. When something is not being worked on, that absence of work is inspectable. I can go and figure out myself why something is not being done. Many of our meetings are public by default, including sprint demos. Those recordings allow customers and community members to see not just what was shipped, but how we reasoned about it. That reduces misinterpretation. It also builds trust. people can see the actual engineers discussing trade-offs, not just the polished release notes. And that goes further internally. Most of our regularly scheduled meetings, including our CEO staff meeting, is recorded and made available to the entire company. That includes strategic discussions, trade-offs, and areas of uncertainty. When I tell that to uh our interview candidates, they often can't believe it. that changes the informationational gradient inside the company. It means context is not filtered exclusively through management layers. It means I can hear strategy discussions directly instead of relying on compressed summaries. Sometimes I know more than my manager about a particular situation simply because I watched a different meeting than they did. And here's how I personally consume this content. I'll get on the elliptical machine at the gym, open up a recording, and watch it at 2x speed. If I want to watch another meeting, well, that means I need to continue working out. This also means I don't I don't need to attend every meeting live. In fact, if I'm not planning to contribute it, it can be more efficient to watch it later at a time that fits my schedule. That flexibility matters in a remote environment. It decouples context from attendance. It allows depth depth without blocking real-time work. It also reduces the pressure to be present everywhere just to stay informed. This is structural transparency in practice. Context does not depend on proximity to leadership. It depends on whether you choose to access it. Internally, we lean toward shared Slack channels instead of direct messages. The norm is to have discussions in public channels whenever possible. That means context is searchable. It means questions answered once can help multiple people. It also reduces information asymmetry over time. We reinforce that structurally. As I mentioned before, we have a public thanks channel where people are acknowledged for improving the handbook or clarifying a process. That's intentional. It signals that maintaining the operating system is real work. It's not invisible labor. It is contribution. We also defined clear data classification boundaries. Not everything is public. Customer data, security details, financial specifics, those have controlled access. Transparency is not recklessness. It is structured visibility with defined limits. Clarity about what is public and what is restricted is part of the system. And all of this creates agency. Engineers do not need to wait for a manager to explain how to escalate a customer issue. The path is documented. They don't need to guess how releases are cut. The process is written down. They don't need to rely on hallway updates to understand strategy. They can read the prioritization philosophy. But this model has real friction. There is burnout risk. When information is widely available, people could feel pressure to consume everything. 80 hours of recorded meetings per week can overwhelm someone new. Search helps, but discipline is required. Transparency does not remove the need for focus. There's also camera discomfort. Some people don't want to be recorded for various reasons. Some people worry about how they come across. That is real. Public visibility can change behavior. Social desiraability bias shows up. People may speak more cautiously when discussions are recorded. Also, maintaining the handbook requires discipline. Documentation drifts if no one updates it. Processes change. Reality moves faster than writing. Someone has to notice when the documented path and the real path diverge. That tension is something we deal with every day. And not everyone prefers this environment. Some people are more comfortable operating with informal influence with context living conversations with flexibility that's not written down. Structural transparency removes some of that ambiguity that can feel constraining to those who benefited from it. So this is not utopia. It is a system with trade-offs. But it is a system designed intentionally and that intentionality changes behavior in durable ways. There's another pattern that appears when you make systems visible. At first, things actually look worse. When processes are written down, you see inconsistencies. When prioritization logic is documented, you see conflicts. When boards are public, you see stalled issues. When escalations paths are explicit, you see how often they're used. Visibility reveals what was already there. It just removes the comfort of not seeing it. Hidden context hides dysfunction. It allows teams to believe alignment exists because disagreement was never surfaced. It allows drift to continue quietly. When transparency increases, that quiet drift becomes visible misalignment. That can feel destabilizing. It can feel like transparency caused the chaos. In reality, it exposed it. You cannot improve what you cannot see. But seeing clearly is uncomfortable. It forces conversations that were previously avoided. It forces prioritization decisions that were previously deferred. It forces leaders to explain reasoning that was that previously lived in private. Structural transparency increases discomfort before it increases performance. That's not a failure. That is maturity. It is the system acknowledging reality instead of pretending stability exists over time. Fixing weak processes and documented repeated problems reduces the chaos, not because you hit it again, but because you addressed it structurally. That's the paradox. Transparency can initially make the organization feel less stable. In the long run, it is what makes stability possible. So when I think back to those meetings with Alex, I don't feel frustration anymore. I feel clarity. Alex wasn't undermining the project. Alex was rational inside a system that hid its logic. Alex was responding to signals I couldn't see. I was responding to signals Alex couldn't see. We were both optimizing locally because the global picture wasn't visible. Our meeting kept replaying like groundhog day because the organizational architecture allowed it to. If the prioritization philosophy had been documented, that meeting would have gone differently. If escalation rules had been visible, we would have known when to push and when to wait. If cross team capacity had been visible, we would have seen whether delay was overload or indifference. Instead, none of that was written down. So, alignment dependent on politeness, and people carried the pressure themselves. That's the shift. The system failed first. I blamed Alex because I couldn't see the I couldn't see the system. When operating rules are invisible, friction becomes personal. We start questioning motivation, competence, character. We turn structural ambiguity into interpersonal judgment. But once the system becomes visible, you stop diagnosing people and start diagnosing architecture. The same behavior looks different under inspection. For a long time, I thought leadership meant better communication, more meetings, clearer updates, stronger persuasion. Now, I think leadership is something else. Leadership is designing clarity into the system. It is building operating rules that are visible, making prioritization logic inspectable, making escalation paths explicit, reducing dependency on personality. Leadership is not the loudest voice in the room. Leadership is architecture. When clarity is structural, behavior shifts. Engineers don't wait for interpretation. Managers stop acting as information bottlenecks. Trade-offs are inspectable instead of political. Escalation feels procedural instead of personal. You get fewer repeated meetings, fewer heroic interventions, less silent drift. You get adults operating with real agency because the system gives them the context required to act responsibly. That is not cultural magic. That is design. This is how organizations scale. Not by adding oversight, not by centralizing authority, but by externalizing reasoning. When context lives in artifacts instead of conversations, it survives turnovers. It reduces single points of failure. It lowers decision latency. It limits ego because influence shift from access to contribution. Clarity redistributes informationational power. And when responsibility and visibility align, accountability becomes fair. That is not softness. That is structural integrity. Priority fog is not a personality flaw. It's not laziness. It's not lack of ownership. It's not a generational issue. It's not a motivation problem. It is architectural. If meetings replay the same ambiguity, that is architectural. If engineers guess at priorities, that is architectural. If escalation feels political, that is architectural. Priority fog is not fate. It is design. And design can be changed. So if you leave this talk with one thing, let it be this. When your organization feels confused, is it because your people are not trying hard enough or is it because the system was never designed to make clarity possible? Because if it is the system, that is not a character problem. That is a design problem. And design problems can be solved. So before we wrap up, let me pause on this for a moment. These are some of the teams using fleet in scale at scale today. They operate in pretty complex environments and when things get pretty complex uh you need visibility. So many of them prefer tools that make system state visible instead of hiding it. So that mindset is similar to the transparency we've been talking about today. Um that's it for this talk. So if these ideas match how you think about your organization, I'd love to hear about your story. Uh here's a few links about Fleet. This this takes you to our homepage. Uh and yes, we are hiring. And here's some information about me and where you can find me and some of my work. Thank you for listening. [applause] >> Thank you, Victor, for that talk. I think we have time for one or two questions. I'll take one from this side and then one from the other side of the room. >> Gentlemen over here. Uh my question was about your handbook and >> you know it sounds like it's a very it's very much a living document that's getting constantly updated, >> right? >> Uh how do you deal with the issue of somebody reading the document maybe a week ago and not catching a new change? How do we constantly keep the organization updated about all the changes? because I also think that it it seems impractical to notify everyone about every single one of the changes. So I'm just curious how that works. >> You're you're right. Uh uh you know when handbook is updated if it's like if it's engineering related it'll be posted in the engineering channel but of course you can miss it and later you are doing something maybe you're on call and you're doing your tasks and then some task is not getting done. Yeah. So there could be disconnect right you're doing something because you remember the procedure from a month ago but actually there was something else added. So eventually someone will let you know like someone will be like hey why is no one looking at this failure you know tag on call you're supposed to be looking this per handbook. So you know yeah people find out eventually so it's not you know it's not immediate. Good good question. Thank you. >> Thank you. Anyone from this side? >> Uh yeah, thank you for the presentation. It's feels very relevant to the sort of struggles that we have at our organization as well. Um my um I'm curious if there's any friction h having the system operate across technical and nontechnical teams and I'm also curious um what your process is for having consensus on when new things are added to the handbook. um non-technical and technical um I think everyone's basically required to be able to use uh GitHub in our company um [snorts] so like everyone everyone has to know how to submit submit [music] things to GitHub so that's like a requirement to work for fleet um uh what was the second part of your question so I'm sorry >> yes uh how do you achieve um make sure there's consensus when new things are added to the handbook like one person just add stuff or what's the >> Yeah, we have yeah we have PR reviews um and we do have owners for some parts of it. So it's kind of a mixed bag. Um you know some some things some areas of the handbook that don't have like an assigned owner then anyone can approve that PR and it goes in. Uh of course normally you'd want like you'd let people know at least your manager that you're updating this part. uh other parts of the handbook do have an owner. So that owner has to approve that PR before it goes in. Um all right, so I'll be outside if you guys want to chat. Uh thanks everyone for coming.