Article
Pick the Process, Pick the Culture.
February 1, 2023
How to chose the tools that make teams stronger.
Tools and processes (you might call them “the work about work”) are widely considered a drag. Fill out your time sheet. Reassign your tickets. Publish your meeting notes.
But they’re not all created equal. I bet if you think about it, you can name a few tools (even the ones you’re forced to use) that actively abate the tasks you least favor. Why then, are there so often required processes/tools that have no apparent redeeming function? If you’re trying to revise the workflow for your team, what do you look for when cutting the cruft or proposing a new requirement?
Imagine a company has a goal to improve code quality. They want to:
- Have fewer P1 issues overall.
- Make sure that issues (once fixed) don’t recur.
- Catch more defects before release.
These are worthy goals. When considering the many different ways to achieve them — how should the team leaders think about their options?
How to think about a new process or tool
1. Does it increase or decrease autonomy?Pause and ask yourself why autonomy is important for you in your work.
Here’s a thought experiment. Suppose you’re in school and you take a summer job as a janitor. The building manager has a list of daily tasks and asks that you have them done by the time your shift is over.
Now compare that to the same job but a different manager. They demand you wash the stalls from right to left, never left to right. You’re not allowed to listen to podcasts. The trash bags must be thrown into the dumpster alphabetically. He stands watch to make sure you comply. Might you look for another job?
While any required process is technically also a restriction, processes should enhance autonomy in the areas important to people , by reducing the need to deal with pointless minutia. Let your team do more of what they’re already paid to do: think through problems and generate solutions. This tends to hold true regardless of the job.
What would help our example company above with its code quality goals? While automated test coverage reports aren’t a substitute for good tests, they can act as a turnstile before human review. A few simple rules enforced on CI can open up time for discussing the behavior and content of a pull request.
By contrast, any rules that prevent problem-solving people from following their curiosities towards solutions, would decrease both autonomy and quality.
✅ Increase Autonomy/Reduce Minutia:
- Automated tests, coverage
- Static checks, linting
- Auto-Formatting, code style
❌ Decrease Autonomy:
- Keeping teams and developers siloed in their own repositories.
- Not allowing developers to chase problems or open pull requests outside their immediate domain.
A principal — agent conflict is one where the representative of a group (say, a Director of Technology) has imperfect alignment with the goals and priorities of the organization. For example, the one who wrote the check for the tool is not in the feedback loop of using it. Or, it subtly taxes the productivity of the business in ways that are obvious to employees and less obvious to leadership.
Examples of this are depressingly easy to find — go look at the pitch deck or sales presentation of any tool you’re forced to use as an employee, while an alternative you greatly prefer is available off-the-shelf, or even free. What features are emphasized in the sales phase? What aspects of its competition does it conveniently ignore?
When selecting your own tools, attempt to state the benefits in a neutral fashion. Read it back to yourself, out loud:
Does it read like this?
This tool gathers useful metrics on employee attentiveness by tracking their mouse movements, allowing me to better understand their productivity.
Or more like this?
This tool automates the ticket movements on our kanban board, letting my employees stay on task while gathering more reliable data on our capacity.
✅ Principal-Agent Alignment
- State the problem from the perspective of your team, and select a tool that directly addresses it.
- Engage your team in evaluating options.
❌ Principal-Agent Conflict
- The team does not see how the tool or process directly addresses their needs.
- The benefits are more related to metrics than real productivity.
Yes, leaders get to call the shots — that’s part of the job. They are expected to take risks, and not all risks taken will turn out favorably. A team generally won’t count a failure against a hard working leader that accept wins and losses with grace and humility.
Still, it’s not uncommon for a company to declare adoption of a new process, only to have it rejected from the team like a mismatched transplant organ.
Changes start at the top, but they’re not sticky if they’re not found to have credible utility. People have a bullshit detector. If there’s a delta between a leader’s words and actions, it will be noticed. Rules for thee, not for me. The end result of a rejected process is not insubordination, it’s malicious compliance.
Fortunately, good leaders will find this step comes naturally. Keep dialog open, feedback loops short, and allow anyone on your team to contribute constructively.
✅ Credibility:
- After adopting a process, always stay open to ongoing feedback.
- After adopting a tool, go back and evaluate it against your goals. Is it meeting expectations?
❌ Risking Rejection:
- Failing to follow your own mandated processes or rules.
- Ignoring constructive feedback.
As a closing thought, there’s a reinforcing relationship between your tools, process, and team culture. Any change adopted by an honest, open leader, with the goal of increasing autonomy, and that presents a credible chance of improvement, will be reflected in the mindsets of your team members. Likewise, any new requirement that appears dishonest, or decreases autonomy, or impedes productive curious people, will become a gamed metric that drags down otherwise naturally high standards.
Choose wisely.
Collin works at Livefront , where the process serves the problem solvers. He thanks you for reading.
