Some of the successful processes that have developed on my team over the years.
I have some new mentees! While I always mentor within my immediate team, I haven't had much time to mentor people embedded in other teams who are mid-career at the company. I'm more likely to be spinning up or training new folks and then they're off. Or if I'm mentoring someone outside the team it is usually about the tactical problem like a piece of code or design, not really prying into their team business.
With my new mentees I do get to talk about team processes and as it turns out my team's a little bit of an odd duckling. So I wanted to break down some of how the team runs, what we've tried, and what's been working for us.
I can't even ease into a conversation before someone cuts me off with a, "sprints are stupid, process for the sake of process" remark. And of course, they are correct.
Now there's broad sentiment that sprints are oriented around being meat grinders, meant to suck the most out of people at the cost of burnout. This is captured eloquently in a joke from the creator of Clojure Rich Hickey.
However, as most engineers can't wait to tell me: engineers themselves do not like sprints. So why do we do them?
Inertia. Once a process is in place without also putting into place a means to change it, it is seemingly hard to change.
The sprint isn't for the engineers. And this is the truth of it in almost every case.
One of the big lies we tell ourselves is that there can be a single representation of work that fits all purposes. If true, that would be incredibly limiting and the world would be rather boring. And yet that is the central pitch of so many apps: "everything in one place."
Workplaces are infected with this reductive thinking, and it leads to tools like Jira: a rather poor choice for anything in particular but so many features you can force it into most processes. Everything is a ticket and tickets can have links, sub-tasks, epics, tags, and probably other things.
Software development in medium and large businesses is not just engineers. There are usually managers and product/project managers (PMs) who are steering engineers to goals and reporting progress to their management chains.
With only Jira at their disposal because of this incessant reductionist thinking about work, these work orchestrator types flock like moths to a flame. The flame is using Jira to assign new work and summarize work to their management chain. To achieve this, epics and tasks are shaped for those purposes, not for the work being done.
Engineers tend to be more agreeable than managers/PMs simply because the manager/PM relationship often puts engineers underneath them. Disagreement and push back is more difficult than amongst peers. So process changes oriented towards the manager/PM aren't met with much friction. Slowly but surely, the manager/PM goals are met at the expense of engineers having to shoehorn their work into this process.
This is the trap most engineering teams fall into and why they fall into it.
These are bad arrangements for everyone:
So how do we manage our work on my team? However we want. We have projects of 1-2 people on the team and between themselves they choose how to manage their tasks. Some folks create a bunch of tickets, some create hardly any. There's no format for these tickets, they contain whatever the people working on them find useful. The board is strictly for the engineering team, it doesn't serve ancillary purposes.
We don't deny that managers and PMs have important roles in the process, but they don't need to infect the process. We're happy to give them tailored information they can most easily regurgitate up the management/reporting chains. The honest truth is that day to day and week to week there isn't much that needs to be reported so this doesn't take much time. For the team these things take about 30 minutes a week and is great because we:
Help represent an accurate narrative about the work being done. A manager or PM trying to accurately summarize the status of multiple projects by scouring dozens of tickets leads to too many miscommunications and erodes trust in the team.
Free up the manager/PM to do the more important work. They were gonna need to dig in and summarize if we didn't. Now they can focus on the longer term priorities and how our work does fit into the broad goals of the company.
This style does take some managers some getting used to. As a team lead I often have to "box out" people from muddling in our board or talk with my manager about prying too deeply into individual tickets as opposed to focusing on overall project status, impact, and priority. Micro-management can be viciously self-enforcing if not called out early.
The members of the team organize however they want and our board fulfills that purpose exclusively.
This anti-work-reductionism has other positive pressures. For example, a common crutch teams use tickets for, when goaded to use them for everything, is documentation. With all the time we save not marking up our tickets with details that will drift out of date over the course of a project, we write proper, curated documentation of design decisions, implementation details, and guides/tutorials in the appropriate places. We don't scour tickets trying to understand our code.
I got really tired of the time lost on carpet-pulling of various projects surrounding and involving my team. Those types of 'high impact' projects that appear out of nowhere and suddenly need done.
So I made a simple change: every quarter we chose the projects which had the highest impact for the company. If a submitted project didn't make the cut line, it would try again next quarter. It wasn't important enough. I wrote up this process change, circulated it, and got management chain approval. The team proceeded to be pushed but we stuck to our quarterly projects.
Some people will argue quarterly planning is too rigid. A team needs to be more fluid and able to pivot with less than a whole 90 days notice. Surely this allows for optimal utilization of resources.
What actually happened is different:
By all measures adopting quarterly projects was a success. Not only did we become more effective, we became reliably and predictably effective. A happy cycle that awards us more trust and more opportunity to experiment to become even more optimal.
People tend to embrace shifting priorities eagerly. We all seek to avoid the sunken cost fallacy so much that we ignore that we're giving ourselves whiplash and under delivering.
The stream of random projects that had been coming our way died out because:
We held a firm line. "You missed the boat, sorry." Shifting priorities are the result of poor decision making. It's kinda like electricity, it follows the path of least resistance. After a couple successful push backs, we broke our reputation as even entertaining random priorities.
We had a transparent prioritization process that was aligned
with company priorities. We optimize for the best thing for
the whole company. Not our team, not our immediate reporting
chain, the whole company. Our priorities were documented
with evidence that they ranked the way they did. If someone
could come to us and legitimately convince us that things
had higher impacts based on evidence we could
change course. This has not happened.
Most priorities shift because they are allowed to shift
without much justification, so requiring justification
spares us. Transparency also takes pressure off of our team.
Someone asking for us needs to be taking away a project from
someone else, and folks are less inclined to confront
another team. We are not a hat that more can be drawn out
of.
Teams could get us to help, but they needed to reveal their incompetence to do so. Their 'emergency' was a process failure and would need to be corrected going forward. If they wanted our help for an 'emergency' we required them to file an incident which would be tracked and reviewed by leadership. Suddenly they didn't need us.
I wasn't sure where quarterly projects would take us as a team. I've learned from seeing it play out that all of the churn in projects and priorities are a result of being too easily swayed by whims and poor justifications. I was prepared to burn a lot of earned social capital on this experiment, assuming it would take a year to really get the team out of the mix. However, it didn't take long at all for this process to become the norm.
Now after running so long, the results of quarterly projects have spoken for themselves and continue to solidify our position as a high performing, predictable team.
A small note on why quarters as opposed to halves: quarters being 90 days feel appropriate to run a small/medium size project end to end and deliver completely. This isn't to say we don't do the longer projects, but we aren't locked into them. We aim to hit our goals for a quarter so we choose projects that will 1) meaningfully contribute to a larger project's direction, and 2) if it turns out to either be the wrong approach or is solved well enough in that quarter we don't overcommit to something we don't believe needs done.
There's a joke I heard somewhere that's like: talking about what your team will be doing in two years is kind of like talking about what happens after you die. You can only plan tactically and know you're not wasting time in halves. Anything longer than that has got to be very light abstract/vision work.
I mentioned this above but wanted to break down this decision a bit more.
Software engineering is a team effort, but the reality is individuals are measured/evaluated by the business independently.
On my team everyone gets a project they get to completely run end-to-end, however they want to. They get the credit for that work in performance results. No one is ever without something to show for their efforts in a way leadership can't appreciate. (Leadership can only appreciate the high-level, overall project impact, never any handful of tasks completed along the way.)
So that's frankly the main reason. Individuals are incentivized and rewarded for successfully running larger and larger projects basically on their own and so we throw ourselves into the deep end and give everyone those projects. Yes, we help each other and work through problems together but the work, the meat, is only done by 1-2 people per project.
There are other great benefits to this approach such as much lower coordination overhead, the fact that the best work in software engineering is almost consistently done by 1-2 engineers, the incredible capacity for people to learn much more quickly when working on problems in full, and the sense of trust imparted to engineers to do their best work empowering them to do just that in a healthy way.
Mistakes will always be made, no one can solve that away at scale. The only thing you can do is empower the individual to do their best work and that means giving them the rope to climb. A team lead can always come in and save the day for the business if needed, but that's a last resort. We need a killer team and they need the initial trust and mentorship to work towards that.
A grab bag of others things we do:
"Office hours" (like college professors do). A dedicated time slot that anyone can book to meet directly with the engineering team. It's an hour every week and no friction: folks just add their topic to a table for the office hour date. We pre-read their documents and discuss their problems in person. There's no commitment from us to do anything (cuz quarterly planning), it is strictly advisory.
"Brown bag" (cuz it's supposed to happen at the end of the lunch hour) Since folks are on their own projects most of the time, we do a meeting to go over designs or new things we learn as we're working on projects. This is totally voluntary to present at. We trust each other to raise concerns about our projects when we have them.
"Campfire." We have tons of things we do review as a team, mostly for knowledge sharing purposes. Those individual things aren't themselves meeting worthy so we jam them all into one mega two hour meeting once a week to get it all done. This is where all our overflow discussions from the week get talked about at length. We optimize this meeting to be high value and usually finish early.
No meeting Wednesday. A fully dedicated day there can be no meetings. Anyone outside the team booking time we can explain we are busy and cancel. It's a predictable heads-down time to work.
This process I am documenting now will change. It took a lot of incremental evolutions to get to this process and it works for now.
How do you facilitate change?
The road has been long, but at least for the past few years I have enjoyed the team processes we've arrived at. Hopefully some of this reasoning and context motivates you to make those process changes you've wanted to make!