Boosting Business Velocity: Lessons from Cross-Functional Team Success

Cross-functional teams only speed things up when the people closest to the problem sit in the same room as the people building the solution. On our POS build for Buddy’s Fastfood, we pulled in developers, the restaurant’s floor manager, and our support lead from week one instead of handing off a spec after the fact. That surfaced a real problem early: their kitchen loses internet during peak hours, something a pure dev team would have missed until launch. We rebuilt the sync logic around offline-first order queuing before writing a single UI screen. The harder challenge was getting operations staff to actually speak up in sprint reviews instead of quietly approving mockups. We solved that by swapping formal demos for short, informal walkthroughs. That one change cut our revision cycles almost in half.

Certification projects are cross-functional by force. Getting a manufacturer through ISO 9001 touches purchasing, production, maintenance, HR for training records, and whoever owns the customer complaints. No single department can carry it, and the standard default is a big steering committee that meets monthly and decides nothing.

What actually moved faster was a small group with authority instead of a large group with representation. Four people, each of whom could change a process in their own area without going upstairs for approval. Everybody else got consulted individually when their piece came up. That’s less democratic and considerably quicker.

But it was tough because the group kept stalling on decisions that crossed two people’s territory. Neither wanted to overrule the other, so items sat. I fixed it by making myself the tiebreaker, which is uncomfortable for an outside consultant but better than a decision aging for three weeks. Once people knew the item would get decided one way or another that week, they mostly resolved it themselves rather than let me pick.

The other thing I’d say is that cross-functional velocity comes from shrinking the decision, not the timeline. When something is stuck, it’s usually because the question is too big. Break it into the part that’s genuinely contested and the part everybody already agrees on, and the second part ships immediately.

We built a task follow-up escalation system to stop delivery work from stalling when team members went silent. Before that, our ops team of 12 to 15 people worked fast on their own pieces, but handoffs died in Slack threads. A content writer would finish a draft and tag the editor. The editor would miss it. Three days later, the client would ask where their piece was, and we would realize it never moved.

The system we built runs in Google Sheets with Google Chat webhooks. When someone gets assigned a task, the sheet tracks it. If they do not mark it done within the SLA, they get a gentle ping in Chat. If it is still open after the second reminder, the tone gets sharper. After the third, I get a notification. On the fourth strike, I message them directly.

The challenge was not the automation. That part took two days to wire up in n8n. The real problem was that people interpreted reminders as micromanagement. Two team members said it felt like being watched. One said they would rather quit than work under constant pings. That friction nearly killed the whole thing before it shipped.

I made one change that fixed it. I pulled the entire team into a call and showed them the dashboard. Everyone could see everyone else’s open tasks, not just their own. I explained that the system does not care who you are. It cares whether the task moved. If you close it on time, you never hear from it. If you do not, it escalates the same way for everyone, including me.

Once people saw that the system applied to all of us equally, resistance dropped. The person who almost quit became one of the system’s biggest defenders six weeks later. Delivery speed went up, and task aging went down, because nothing sat unnoticed anymore.

The principle is simple. Automation works when people see it as fair process, not surveillance.

During one product commercialization project, we needed to move a new formulation from the laboratory into manufacturing on a very tight schedule. Usually, R&D would finish its work, then pass the product to quality, regulatory, procurement and operations one department at a time. I assembled representatives from all five functions at the beginning and gave the team one shared timeline, one risk list and clear decision owners.

While R&D finalized the formula, procurement qualified ingredients, operations reviewed equipment requirements, quality prepared testing plans and regulatory reviewed claims and documentation. The biggest challenge was that each department had different priorities and a valid reason to wait for more information. We overcame that by separating decisions that truly required final data from those that could be made based on an agreed assumption. Any issue that could delay the project was assigned to one person and given a decision deadline.

That approach allowed several weeks of work to happen in parallel and prevented late surprises during scale-up. The biggest increase in business velocity came from reducing the time decisions sat between departments. The team did not cut technical or quality work. We removed the waiting between each step.

The clearest example was a product launch where we pulled engineering, design, and client success into a single working group rather than running sequential handoffs between them. The conventional process had each function completing its work before passing to the next, which meant feedback from client success arrived after design and engineering had already made decisions that were expensive to reverse. Collapsing that into a shared sprint structure cut the feedback loop from weeks to days.

The challenge was that each function came in with different definitions of done. Engineering considered a feature complete when it worked as specified. Design considered it complete when it matched the intended experience. Client success considered it complete when a real user could navigate it without help. Those definitions weren’t compatible, and the tension surfaced early in a way that would have caused conflict under the old sequential model.

The resolution was agreeing on a single definition of done before the sprint started rather than discovering the disagreement at the end. That conversation was uncomfortable, but it was cheap to have at the beginning and would have been expensive to have at launch. The cross-functional structure made the disagreement visible early enough to matter.

This one goes way back. We had a healthcare client. Their old vendor took eight months and delivered nothing. They gave us twelve weeks.

I picked a small team. An iOS coder, a backend engineer, a designer and a QA person. I also brought in our sales guy because he knew the client’s real needs. And our privacy expert because HIPAA is serious.

We skipped the long document. Waste of time. We made a clickable mockup in five days. Showed the client every three days. Coders built the API and mobile screens at the same time. QA wrote tests while the code was being written. We set up a group chat with the client. No more endless email chains. We finished in nine weeks.

Then the problem. Our resource manager kept pulling my backend lead to fix old bugs on another project. That stalled our video calling feature. I lost days.

I asked the resource manager to join our morning meeting. I showed him our timeline. I said if you take this guy again, we fail. He understood.

We swapped. I gave him two junior devs from our internal tool to handle his emergency work. That freed my lead. I also made my lead document the video setup and train a backup person.

We launched on time. Client got their money. Signed a long deal with us.

What I learned. Speed comes from protecting your best people. If someone blocks you, bring them in and make a fair trade. That is how you win.

A good example is what happened at VE just last month. In a single month, we developed and released four different products. Two were built directly for clients — Bench Pool and InterviewFirst. The other two sit earlier in the client journey — AI Proposal Generator and AI Digital Marketing Audit.

On the surface, these look like four separate products. I actually see them as one business problem being attacked from four different points.

“How do we remove time between a client showing interest and getting something useful from VE?”

That became the common goal. And I think that is where cross-functional teams become really powerful. Not when you simply put people from different departments into the same meeting, but when people who normally own different parts of the business start solving for the same outcome.

One product reduces the time to find talent. Another reduces the time spent screening talent. Another makes the proposal stage more intelligent. Another gives the client useful insight during the pre-sales journey.

Different teams. Different products. Same direction. That allowed a lot of the work to happen in parallel instead of one department finishing its part and passing it to the next.

The biggest challenge was actually something cross-functional teams can easily create: too many opinions.

When technology, recruitment, sales, marketing, and business teams look at the same product, everybody sees something different and usually everybody has a valid point. If you are not careful, collaboration starts slowing down the very thing it was supposed to speed up.

So the answer was not to get everyone involved in every decision. It was the opposite.

We kept the business outcome shared, but made ownership very clear. People could challenge, contribute and bring their expertise, but every decision did not need to travel through the entire organization.

That distinction made a huge difference. And releasing those four products in one month changed the way I think about business velocity.

Speed is not getting one team to work twice as fast. Sometimes it is getting several parts of the business to move toward the same outcome at the same time. That is when cross-functional stops being an organizational idea and starts becoming a real competitive advantage.

Our cross-functional team is the whole company. We’re small and fully remote, so there isn’t another kind.

The clearest example is sign-up. Most finance apps push you out to a web page partway through signing up because the rules that screen has to satisfy come from outside the company, and it’s easier to let somebody else’s form handle them. For looch, that wasn’t an option. We build for owners who don’t know accounting and don’t want to learn it, and you can’t drop that person into a form written by lawyers halfway through.

So we designed every one of those screens ourselves and then took them to be approved, instead of accepting screens handed to us. That’s the challenge, and it’s a real one: We don’t own the rules, so we can be told no after the work is done. What made it survivable was running the design, the build, and the approval conversation in the same week instead of one after another. A screen rejected on Monday costs nothing. The same screen rejected after it’s built costs a month.

The payoff is that the answers someone gives while signing up now shape the accounting behind their account.

At ZeroAvia, I worked with Engineering, Manufacturing, Finance, IT and Operations to improve how we designed and implemented digital systems for the hydrogen-electric aviation programme. One example was the MES project: the original plan was to use an external MES solution with significant customisation, costing about £450k per year. I led workshops with the engineering and manufacturing teams to understand the existing processes, mapped the current and future workflows in BPMN, and turned the requirements into an MES functional specification and integration design. I also defined the data flows between NetSuite ERP, PLM, MES and WMS, while using Jira to track requirements and actions.

The main challenge was that each team had different priorities. Engineering wanted flexibility, Manufacturing needed simple and practical workflows, Finance wanted to control costs, and Quality needed reliable traceability. I brought these requirements together in one target process and worked through the differences with the teams before finalising the design.

We decided to move away from the original heavily customised vendor approach and develop an internally governed MES solution. This reduced the planned annual cost from £450k to £250k, a saving of around 44%, while also reducing vendor dependency. More importantly, the teams had a common process and clearer ownership, which made subsequent implementation decisions much faster.

The most successful example I can think of right now is MH-1 (our human + AI marketing services), where we managed to unify specialists from different areas (strategy, creative, analytics, and automation) into one fast-performing team instead of making them work in isolation. We were able to do it because we started working in two-week sprints, with us launching the first campaigns within the first 14 days. This way, by having all specialists work toward the same deadline instead of different ones (as it would be the case if they worked separately), we managed to remove the delays between handoffs, which previously slowed down the whole process unnecessarily.

While it might seem impossible to get everyone on board with the same pace, there is an obvious logic in what we did. For example, strategists usually think in terms of quarters, while creative professionals think in projects, engineers—in releases, and analytics—in cycles. All of these time frames are completely different, which makes it hard for team members to synchronize their work. In reality, there is always someone who takes longer than expected to deliver their part of the work, which causes others to wait for them, essentially slowing everyone down. That is why the agreement of working in two-week sprints was so important because it acted as a constant reminder of the shared commitment to velocity. Essentially, we got everyone to agree on one deadline instead of them coordinating with each other after each deliverable was completed. If something took more than 14 days, it had to be re-prioritized for the next quarter. This is how the seemingly simple change in culture removed all unnecessary delays between our team members.

One of the strongest examples of cross-functional work increasing business velocity was an insurance app project, where the key was not just bringing more people into the process, but bringing the right perspectives early enough.

On the client side, different teams had very different definitions of success. For sales, the product needed to be easy to explain and strong enough to support acquisition. For analytics, it needed to capture the right signals: sources, statuses, funnel movement, lead quality, and user behavior. For managers, it had to support daily work after the sale – claims, renewals, documents, statuses, and communication history. For legal, the focus was consent, data handling, wording, and safe process design.

On our side, the product, design, development, and delivery teams helped turn those expectations into one product logic instead of a set of separate departmental requests.

The challenge was that all of these needs were valid, but they could easily pull the product in different directions. Sales usually wants fewer steps. Analytics needs enough data. Operations needs more detail. Legal needs careful boundaries. If these conversations happen too late, the product gets rebuilt layer by layer.

What helped was mapping the full journey together: first interest, application, processing, policy documents, claim, renewal, and reporting. At each stage, we looked at what the user needed, what the business needed, what data had to be collected now, what could wait, and where legal limits had to be respected. That made the product easier to sell, operate, measure, and trust. It also gave the app stronger positioning, because it wasn’t built around isolated features. It addressed real industry pain points: fragmented processes, lost context between teams, manual follow-ups, and limited visibility into what happens after the first lead.

For me, this is where cross-functional work creates real velocity. It does not simply make people work faster. It helps teams make better decisions earlier, reduce late-stage rework, and build a product that matches both internal expectations and market needs.

A few years ago, I noticed that our technicians were wasting a lot of time trying to find the right instructions before they could start building a machine. They were spending around 30 to 40 minutes just searching for the information they needed. The problem was that the information was all over the place in old files, different versions and different formats. Nobody could find what they needed quickly, so people were just guessing, asking around or building from memory.

So I decided to create a system that would put everything our technicians needed in one place. I used Jira and Confluence to make it happen. It sounds easy. It was not. I had to work with our engineers, the people who write and manage our documentation and our technicians who actually build the machines. We have teams in the US, Singapore, Taiwan and Korea and everyone had their way of doing things. They all had their version of “how we’ve always done it,” so getting them to agree on one system was not easy. It took a lot of conversations, not just sending out an email announcement.

Once we got the system working, the time our technicians spent searching for information dropped from 30-40 minutes to under 5 minutes. That is a big deal because it means we get that time back on every single build at every site.

The challenge we faced was not building the system. It was getting people to actually use it. Our technicians had been doing things a certain way for years and even though the old way was slower, it was familiar to them. A new tool can be scary when you are being judged on how you get builds done.

So how did I get past this problem? I found someone on the floor who people already trusted and respected. I built the version of the system around what actually frustrated them, not what I thought they needed. Instead of forcing everyone to switch to the new system overnight, I let people use the old system and the new one at the same time for a little while. This gave them space to trust the system before they had to rely on it. Giving people a say and giving them time is what made the change last instead of just disappearing after a few weeks. Our technicians were able to use the system and were able to make the switch.

The machine building process is now much faster. Our technicians are able to build machines correctly. The system using Jira and Confluence is working well. Everyone is using it. I am happy that I was able to make this change and help our technicians build machines efficiently.

Yes. One example was moving ownership of the Gold layer closer to the domain teams.

Instead of sending every new metric or reporting requirement to a central Data Team, we enabled domain developers and analysts to build their own data products. The central team focused on ingestion, governance, CI/CD, monitoring, and providing a safe path to production.

The biggest challenge was avoiding a situation where every team started doing things differently. We addressed that with shared templates, access patterns, CI/CD standards, monitoring, and regular enablement.

That balance between domain autonomy and central governance is probably the most important part of Data Mesh for me.

What worked well for us and helped move projects faster was to create cross-functional teams of people from different parts of the business who were working on the same problem instead of letting the work flow from department to department.

So in a client project, for example, we’d have a team where one person’s handling SEO, one’s working on content, one’s thinking about digital PR, etc. simultaneously so no one’s waiting for the other person to finish their work so they can start theirs.

The biggest challenge we faced here was that everyone was understandably looking at the project from their own angle. The solution to this was to sit together and agree on the main goal first and then let each person explain what they needed from the other team members.

Doing it this way ensured that we were all on the same page. Each person could also make their own decisions independently instead of waiting for the other, which made decision making faster.

An example that comes to mind is for certain client engagements, we might be their first introduction to how a properly functioning development and marketing partner should be. They may have had some less than satisfactory results previously. Once they experience what we believe is the right way to do things, and what many other companies do properly, the situation quickly becomes you being their go-to for more than might be your original mandate.

With that said, some of those situations might warrant having more of an embedded relationship than a traditional outside vendor relationship. Rather than treating ourselves as an outside vendor waiting for requirements, we effectively create one team consisting of our developers and PMs, usually alongside the client’s operations, marketing, and leadership, allowing us to move at a faster velocity.

With that said, a natural challenge that occurs is that there needs to be a very thoroughly defined scope, and we need not be afraid to call out when the scope is starting to creep. As I found, the more competent someone sees you as, the more comfortable and the more of a desire there is to have you do more than might be your initial role and responsibility. I believe this is because once you build up that trust, they know you’re going to do it the right way, because they know you do everything else the right way. The most recent example of this exact approach was with a healthcare client that we were the sole technical resource for, going from sub-$50k/year to multiple eight figures a year.

One of the effective methods of enhancing the pace of business is that the team of product strategy, user experience (UX), engineering and Quality Assurance (QA) should act together in decision-making process from the very early stages onwards and not pass along the projects from team to team. For instance, bringing together these groups in the phase of discovery saves a lot of time for the team throughout the process of development by discovering the technical limitations, vague user paths, and testing threats ahead of time.

The most common problem encountered is the inconsistency in priorities. For example, the product team may aim at speed, the design team may prioritize the user experience, while the engineering team may take technical risks into account. The solution to that would be to establish a common goal and prioritize various features regarding their value, efforts to deliver them and possible risks they carry with them.

One example involved improving secure software delivery across multiple development teams where late security reviews were slowing releases. Instead of treating security as a final checkpoint, we brought developers, security engineers, operations, and product stakeholders together from the start of each project. We integrated automated security testing into the CI/CD pipeline, established regular collaboration sessions, and created clear guidance so teams could address issues earlier.

The biggest challenge was changing the perception that security would delay delivery. We addressed this by showing how early collaboration and automation reduced manual effort and prevented last-minute surprises. Over time, development teams became more engaged, remediation cycles became faster, and releases moved more smoothly without compromising security. The experience reinforced that business velocity improves when security is treated as a shared responsibility rather than a separate gate.

One project that reinforced the value of cross-functional collaboration was our work with several public libraries to deliver free community education seminars on AI and cybersecurity. Success required much more than subject matter expertise. Marketing coordinated event promotion, website content, and press outreach; leadership built relationships with library partners; technical specialists developed educational presentations; and our client-facing team ensured every interaction reflected the level of service we strive to provide. Bringing those perspectives together allowed us to create educational programs that served the community while strengthening trusted partnerships.

The biggest challenge was balancing long-term outreach with the immediate demands of supporting clients. In a small business, your technical experts are often the same people responding to urgent issues and leading client projects. What helped us move faster was making sure everyone understood the larger purpose behind the initiative. When team members could see how community education strengthened relationships, generated new opportunities, and reinforced our role as a trusted IT consulting and managed IT services partner, collaboration became much more intentional. I’ve learned that cross-functional teams don’t gain momentum simply because people work together; they gain momentum when everyone understands how their contribution supports a shared mission.