Why Declarative Management Beats Command-and-Control in Engineering

TL;DR: Declarative management empowers engineers by focusing on outcomes instead of tasks. By giving context instead of commands, you increase engagement, performance, and psychological safety–while making it easier to scale leadership and grow careers.

Getting your team to perform at their best involves giving them enough bounded autonomy to be able to efficiently work towards their goals. Declarative language, a communication method formalised by Linda K. Murphy to support children with autism, can also significantly uplift team morale and output in engineering.

What is bounded autonomy?

Bounded autonomy is allowing members of your team to make their own decisions about how work gets done and, to some extent, what work gets done, within a set of limits. This can look different depending on an individual’s seniority and experience. For an engineering manager the bounded context might be the corporate OKRs, with full autonomy on how to deliver towards them. This might filter down into high level feature requirements that a Senior Engineer has autonomy on how to achieve. At a Junior Engineer level this would start out as a story description that describes a result and it’s up to them to work out how to achieve it.

Learning to work with bounded autonomy is a key step in enabling productivity for engineering leaders. It allows them to focus in on “what do we want to achieve?” and “have we achieved it?”, without having to dedicate as much mental energy on how it’s achieved. It forces the manager to delegate and enable, something that people new to engineering management often struggle with. It also gives room for engineers to develop their skills and bring a more diverse range of opinions to the table.

Declarative language is used to define the bounded context

The traditional model of management relies on a lot of imperative language. If you’ve either asked someone to follow a set of steps to complete a task, that is an example of it. It feels like a safe mode for a new manager - they can be comfortable that they know exactly how a task is going to be done and be confident on owning it. There is absolutely a use for imperative language in certain scenarios, e.g. following a deployment checklist or a support runbook. Imperative process are often good candidates to be scripted away. However, using imperative language as a default can cause a lot of problems.

• Imperative statements often get followed without thinking.
• The instruction may not lead to the desired results. This will often only be picked up once the instruction has been completed.
• There is limited room for the process to develop. Each time a similar process needs to happen the same steps will likely be followed uncritically.
• There is limited room for the team member to develop. They learn to follow a checklist, not understand how things actually work.
• Imperative processes can scale poorly in fast-moving environments. If the underlying system is constantly changing then the processes must follow.

The alternative to this is to frame goals in declarative language. Instead of giving instructions or orders, you give context and information. Instead of telling someone that they need to do something, you explain what the end result is and why we need that end result. This small change has a huge list of benefits:

1. Declarative language is intrinsically a less threatening form of communication. Failing to follow imperative instructions often has immediate consequences. Declarative language gives room for adaptive solutions. This level of psychological safety can increase compliance and performance. This extends to performing code reviews - if I think there was a better way of writing some code I’ll provide the suggestion of the approach and invite a discussion about it, not just tell the engineer to rewrite it.
2. Understanding the result. If you’re unable to articulate what the outcome should be then it’s likely that the task hasn’t been thought through. With imperative language it’s easy to just follow the steps without thinking about the destination.
3. Providing room for challenge. It is a relatively common occurrence that, when a team of engineers is presented with a new requirement, and the context of why that requirement needs to happen, they can find a better way of getting there. A not-insignificant proportion of requests can often be met with minor tweaks to existing solutions and reframing the issue to the stakeholders.
4. Career growth. Declarative language necessitates that an engineer demonstrates understanding of a problem space and can perform strategic thinking. At every level of a software engineering career that is the key skill to successfully navigating up to the next rung. The problems they solve will become bigger but the leap from Junior to Mid and Mid to Senior becomes a lot smaller.
5. Builds trust and respect. By allowing the engineer to define the solution you are putting a lot of trust in them to be able to complete the task. Of course you’re there to support them, but just by switching the language used you get more engagement and ownership of outcome from an engineer. This ultimately should lead to less total time supporting them than an imperative approach.

A practical example: Imperative vs Declarative

Imperative language

Can you refactor our customer details endpoint for performance, it’s running slow?

Declarative language

We’ve had some reports that our customer details endpoint has high latency. We’re still within our SLA but there are eyes on this due to a potential client assessing us. Could someone take a look?

The different outcomes

With the imperative language it is likely that a single engineer will pick this up. They will start to work on it alone, and get stressed when they’re not finding a specific issue in the endpoint, maybe it’s the API gateway that’s slow, or the DB in the production environment is overloaded and the endpoint itself isn’t an issue. You will likely get a PR that delivers some performance improvement but it’s not likely to solve the underlying issue.

By using declarative language, the engineer has the whole context, and implicit permission to look outside of the specific endpoint code to find what the issue is. They’re focused on the outcome, rather than following an instruction, so they pull in members of the edge and database team to help identify where the slowdown is. They discover the way we’re querying the database in general is not great and propose a change that improves performance across all of the service endpoints.

We already use declarative language to talk to our computers

We often show our computers more respect than we show members of our teams

There are plenty of scenarios where engineers use declarative language when talking to their computers. Anyone working in the DevOps space will be used to declaring the state that they want their infrastructure to be in. It’s then up to Terraform or CloudFormation to get it there. Ultimately, we don’t care how it gets there as long as it has the right result.

A more developing example would be writing prompts for generative AI to complete a task. The most efficient way to work with it is to give it a description of what the end state should be, and any additional information it needs to get there, and then let it do the intermediary work. In doing so, we often show our computers more respect than we show members of our teams.

What outcomes can I expect?

In every team I’ve managed using a declarative approach, I’ve consistently received 2 kinds of feedback:

1. From management: Surprise at the increase in velocity, mostly through choosing to do the work that is important and making pragmatic decisions along the way.
2. From the team: Reports of higher engagement and greater enjoyment in their work. As a manager, it also makes it easy for me to put people on a path to promotion as their portfolio is littered with projects that they have clearly demonstrated ownership and initiative**.

Declarative management fosters agency, builds trust, and ultimately creates a healthier, higher-performing team culture.