Let Your Engineers Decide Their Ways of Working
A Comprehensive Guide
The workplace has always evolved, and with the rise of agile methodologies, flexible work arrangements, and the shift toward remote teams, one question inevitably arises: How should teams decide how they work? While management often sets frameworks and expectations, many forward-thinking companies are turning to a more novel idea—letting the engineers decide their ways of working. Here are some more resources on the matter.
But why?
The logic is simple: engineers are the ones in the trenches. They know what works, what doesn't, and how to maximise productivity within their unique environment. Asking them to follow a rigid process defined by people who do not understand the nitty-gritty details of their day-to-day work seems, frankly, inefficient.
The Case for Autonomy
When you leave the process up to the engineers, you're not only empowering them; you're also acknowledging that they have the expertise to make these decisions. Trusting your team to figure out how they work best can lead to increased productivity, better morale, and innovation. In fact, micromanagement of process can often stifle creativity, waste time, and lead to frustration.
So, why not just leave this at the behest of the engineers?
Imagine this scenario: You get the team to congregate for an hour or two—preferably two—so that they can discuss how they should work together and collaborate. Sure, it might actually require a couple of more of these get-togethers, but that's a small price to pay for setting a clear direction that everyone buys into. The key is not to dictate every detail of the process, but to allow the team to tailor their approach based on their specific needs.
Setting Up a Meeting of the Minds
A practical first step is to schedule these "how should we work" meetings. One isn't enough (probably). You’ll want at least a few sessions where ideas can percolate, challenges can be addressed, and compromises can be made.
Don’t overcomplicate it. The purpose of these meetings isn’t to draft a corporate manifesto. You're aiming for something much more agile—an adaptable, flexible way of working that the team owns. Maybe by the end of the second session, you come to an agreement that everyone’s happy with, and that it is malleable.
In these sessions, the team might decide (in a summarised fashion), “Alright, we’ve agreed to using Specification by Example (SBE), Behavior-Driven Development (BDD), Collective Code Ownership, Trunk-Based Development, Feature Flagging, and GitHub Actions for continuous integration. Oh, and we'll use a Google Sheet to track our work.”
At this point, you let the team manage the rest: “Everything else is up to you—manage your own work, yada yada yada.”
Embracing the Experimentation Culture
One of the most powerful advantages of allowing engineers to decide their own processes is the opportunity to cultivate a culture of experimentation. Engineers are naturally curious, problem-solving individuals, and when given the freedom to tweak, test, and refine their workflows, they often discover efficiencies and innovations that would never emerge in a top-down environment.
By fostering an experimentation culture, you encourage your team to continuously improve their practices. Whether it's trying a new tool, adjusting sprint lengths, changing the frequency of retrospectives, or removing these methodological aspects altogether, the goal is to allow engineers the flexibility to experiment without fear of failure. Mistakes should be viewed as opportunities to learn and adapt, rather than reasons for punishment or reverting to the status quo.
Why it works: Engineers have the closest view of the challenges they face. When they’re empowered to run small experiments, they can rapidly find solutions that wouldn’t be obvious to those further removed from the day-to-day coding.
How to manage it: Introduce small, low-risk experiments at first. For example, if the team wants to change the way they track bugs or try a new testing tool, let them run a trial over one or two fortnights. Encourage them to review the outcomes during feedback loops and decide if the new approach is worth adopting long-term.
Allowing Room for Diverse Workflows
Every engineer has their own working style, and part of creating a truly effective team is allowing room for diversity in how people get work done. By giving engineers the freedom to manage their own workflows, you can avoid the rigidity that comes with enforcing a single process on every individual.
For instance, some engineers thrive with highly structured to-do lists, while others might prefer to work more organically, focusing on what’s most critical at any given time. Allowing these variations helps keep morale high and empowers individuals to do their best work.
However, this diversity doesn’t mean teams should operate in silos. It’s important to have alignment on the bigger goals—deadlines, key deliverables, and quality standards—but how engineers manage their day-to-day tasks within that framework should be largely up to them.
Why it works: Flexibility breeds creativity. When engineers can personalise their workflows, they often find ways to optimise their own productivity, which translates to more effective teams.
How to manage it: Establish clear expectations around deliverables and timelines, but leave the specifics of task management up to the engineers. This balance ensures everyone remains aligned while still benefiting from individual flexibility.
Encouraging Transparent Communication
Autonomy can’t function without strong communication. One of the potential risks of giving engineers too much freedom is that teams can lose sight of each other’s work, leading to misalignment or duplicated effort. Transparent communication is essential to prevent these issues while still supporting autonomy.
Regular updates, whether through asynchronous tools or brief stand-ups, help ensure that everyone is on the same page. But it’s crucial that communication remains lightweight and efficient, so it doesn’t bog down the workflow. Tools like Slack, GitHub, or Trello can serve as platforms where updates and information are shared in a way that keeps everyone informed but doesn't interrupt the flow of work.
Why it works: Engineers need to feel empowered to manage their work, but they also need to stay connected to the team’s broader goals. Transparent communication allows for both independence and collaboration, ensuring that everyone knows what’s happening without feeling micromanaged.
How to manage it: Encourage engineers to regularly share progress and roadblocks, but avoid unnecessary meetings. Asynchronous updates are often sufficient, and they allow engineers to communicate without disrupting their flow.
Balancing Innovation and Standardisation
While autonomy fosters innovation, there are areas where standardisation is necessary to ensure consistency and reliability across the team. The challenge is finding the balance between giving engineers the freedom to innovate and ensuring that critical aspects—like security, code quality, and deployment practices—remain consistent.
By establishing a few baseline standards, such as coding guidelines, testing goals or security requirements, you create a safety net without stifling creativity. Everything else, from testing design patterns to workflow management, can be decided by the engineers themselves. This balance ensures that the team can push boundaries while maintaining the quality and stability that the business demands.
Why it works: Engineers appreciate having the freedom to innovate while knowing there are a few solid guardrails in place to keep things from veering off track. It’s about enabling creativity in a way that still aligns with the business’s priorities.
How to manage it: Define the non-negotiables (such as security protocols or code review processes) but leave everything else open to experimentation. Regularly revisit these standards to make sure they’re not too restrictive and that they continue to serve the team’s needs.
Creating a Feedback-Driven Loop
An essential component of allowing engineers to define their own processes is the establishment of a strong feedback loop. Engineers should feel comfortable discussing what’s working, what isn’t, and how they can improve. This feedback culture not only helps refine processes but also builds trust within the team.
Whether through retrospectives, 1:1s, or casual conversations, feedback should be frequent and open. Importantly, feedback shouldn’t be limited to what’s gone wrong—celebrating successes and sharing what’s working well is equally important in maintaining a positive and growth-oriented environment.
Why it works: Continuous feedback keeps processes fluid and dynamic, allowing engineers to make iterative improvements to their workflows. It also reinforces trust between team members and management, creating a culture where everyone feels heard and valued.
How to manage it: Build feedback sessions into the regular team cadence—whether through sprint retrospectives, monthly reviews or pulse surveys. Make feedback a two-way street where engineers are also encouraged to give input on how leadership can better support them, creating a culture that not only invites, but demands dissent is pivotal.
The Role of Leadership: Hands-Off, But Not Absent
Leadership’s role in this type of environment is often misunderstood. It’s not about completely stepping back and letting things become disorganised. Instead, leadership should take a hands-off approach to the minutiae but remain deeply involved in supporting the team’s larger goals and ensuring they have the resources they need to succeed.
Leaders should focus on clearing roadblocks, providing the necessary tools, and fostering a culture of trust and accountability. Autonomy doesn’t mean absence—leaders still need to be present, but their focus should be on enabling success rather than dictating how it’s achieved.
Why it works: Engineers thrive when they have the freedom to manage their work but still feel supported. Leaders who remove obstacles and provide guidance when necessary create an environment where autonomy flourishes without devolving into disorder.
How to manage it: Regular check-ins, mentoring, and providing resources are all ways leadership can stay involved without being intrusive. It’s about offering support rather than micromanagement.
Let Your Engineers Do the Decision Making
At the end of the day, letting your engineers decide their ways of working is about trust. It’s about acknowledging that the people who are closest to the code are the best equipped to decide how to build it. This approach fosters a culture of collaboration, innovation, and accountability, while also reducing bottlenecks and inefficiencies.
Is it perfect? No. Will there be bumps along the way? Absolutely. But by giving your engineers the freedom to define their own processes, you’ll be surprised at the results they deliver. And who knows—maybe your team will stumble upon a way of working that’s even better than what you originally imagined.
The key is to start small, experiment, and iterate. Let your engineers decide, and watch as they build not just better code, but a better way of working together.