Why good solutions combine top-down and bottom-up perspectives

It’s the responsibility of leadership to set the vision for an organization, and then to design the pathways and constraints to achieve that vision. That’s the work of formulating strategy. Executing strategy is connected but distinct. It’s in the work itself and, ideally, it’s reflected in the work teams are doing day-to-day. However, it's not always clear how the work that individuals and teams do aligns with business objectives and strategy. Sometimes important elements of a strategy are lost in the cascade. Sometimes work is designed without clear alignment at all, because the strategic objectives and how they are to be delivered aren't clear. I find that misalignment is a surface worth scratching for its underlying reasons, because that's where real problem-solving can happen.

A good technology solution facilitates a throughline from strategy to execution and back. Executive strategy cascades meaningfully as actionable work, teams' output aggregates as legible data that informs better decisions at all levels, as well as future strategic moves. A good consultant knows that solving for the question of "what’s the sprint burndown?" should have a direct connection with "are we headed in the right direction?" and vice-versa.

Poor adoption and change management might have caused issues and friction in the past. So I will explore how we can leverage customizability in the implementation, and enablement in the engagement, to meet employees where they are. Experience tells me that, if we can reinforce good habits while simultaneously coaxing people away from bad ones, we improve the whole system.

One simple example of system fixing is combatting notification sprees. Often, managers who consistently see breaks in the chain, want a tool that can automatically notify relevant parties. However, faster than you'd think, it's open season for notifications, and suddenly there are requirements to notify everyone for everything. But when everything is important, nothing is, and it's my job to get to the root of the need. It may be easy to assume missed actions are a behavioural issue (you're not acting fast enough because the warnings aren't early and often enough) but dig a bit deeper and you find it might actually be structural.

From leadership, I want to know what they'd like to measure, and how those measurements inform decision-making. If there is a lack of quantifiables, leaving many decisions to the gut, I want to know that, too. That understanding is central to how I approach standardisation efforts, especially across units or functions.

At the user level, a consultant should be trying to spot patterns of behavior and embedding them in the solution. By standardising where appropriate and only looking to add steps where we must, we can be efficient but also provide familiarity that supports collaboration.

A leader once said to me during a global project portfolio management implementation: "I want to know that a project manager in Stockholm can successfully deliver a project with the Atlanta team." This is a great top-down requirement that speaks to what the client is looking for in the solution. It tells us what is important, from a top-down perspective, and allows us to explore the bottom-up solution. At the organisational level, if we can standardise, we can unlock the command center that yields insights - i.e. collect data in a way that means we can turn it into information about business outcomes.

There is, of course, a balance to be found between standardising and accommodating flexibility. You don't want something so rigid it breaks in the face of day-to-day reality. There will also be legitimate uniquenesses in Stockholm and Atlanta that the solution should support. That’s where deep attention to the user base during discovery is important. Not just for gathering requirements but for building rapport and trust. It's important to understand where it's possible (or sensible) to apply changes in software that may reverberate in unintentional or unforeseen ways. When big improvements require big changes, you want to guide your stakeholders on that journey as participants with you, not deliver them as pronouncements. Process improvement requires nudge work too: asking questions designed to help them reach the conclusion with you or at least consider the possibility in a positive way. To gain meaningful consensus on those changes, you need access to those different roles and perspectives.

Beyond specific capabilities, I think the ramifications of AI and how it's being employed by platforms like monday.com is what interests me the most as a strategic advisor and consultant. Monday recently announced that its Work Management platform is now an AI platform. It gives customers the ability to vibe-code apps that can fundamentally change how you interact with the software. You can employ embedded agents that take on central, actionable roles in your workflows. I have been in software long enough to know how long we have been bending human processes to the featureset's will, and I think we may start to see that reverse. The more those AI capabilities mature, the more organisations will expect to be able to bend the tech stack to its will. That doesn't mean the end of product design, or UX design as a driving principle; I actually think that expertise will become all the more important. I don’t envisage agentic processes driving out deterministic automation entirely. Both have their uses, and using them together thoughtfully delivers solid, sustainable and scalable results.

Underneath it all, a clearly architected structural framework will help you avoid the "garbage in, garbage out" problem you can get with both generative and agentic AI, especially in enclosed implementations like monday agents, where the agent's actions are wholly informed by what’s in the system and how it's organized. As an information architect, I see this clearly and stress it with all our clients. Without the proper framing, deploying agents at scale is, if not risky, then certainly inefficient.

Without a clear understanding of your processes, your desired inputs and outputs (your structural constraints) you may just end up hoping it works out. If you explore the business requirements (top-down) and understand how work gets done (bottom-up), you can be quantitatively confident about your outcomes.