Maybe it’s okay to not be super strict?
Maybe it’s okay to not track everything?
Maybe you should just chill.
We’ve all worked on that team.
You might be working there right now.
Did you put an estimate on that ticket before you started working on it?
Why did you start working on that when we still have to finish the AC?
I’m sure we all have war/horror stories about trying to build good software in an environment where leadership requires extensive documentation, planning, post-mortems, retros for everything you and your teammates do.
It’s a bummer, and your team was/is likely swimming upstream to get anything meaningful done.
So you adapt, and spend a ton of time appeasing your Scrum Lord and the powers that be just to build that “simple button”.
Where does it all stem from?
It’s pretty straightforward. Your team has a trust and accountability problem.
Not to say that there are bad people at the helm steering you into some Jira laden facist hellscape (not always, at least). However, generally, you will find someone in the chain of command that doesn’t trust engineers or have a solid understanding of what goes into building software (or maybe it’s just been a long time since they’ve built anything themselves). They think people are “taking too long for things so simple”, or they had a really bad experience spending a bunch of money building something that ultimately failed. So, they send their teams into the Jira mines to dig for metrics that make them feel like they are in control.
If you’re reading this and identifying with that statement, I want to respectfully tell you that you are an asshole.
Don’t take it too hard though. I had a phase where I was obsessed with metrics.
Process for the sake of process is always bad
Full stop.
I think we’ve all been guilty of this (myself included), and it’s a hard lesson to learn. Just because you take the time to write an SOP with every little thing you want done with a detailed description of “best practices” does not guarantee anyone will adhere to it. You can try, but there will probably be fights/disagreements or people just plain ignoring it so they can get their work done. At the end of it, you’re likely trading whatever trust your team had in you for your process.
That’s a terrible trade-off.
What I’m not saying
I’m not saying that all process is inherently bad (structure is good, actually) or that you’re a bad person for creating whatever process your team follows.
I am saying that you need to take a hard look at how you manage engineers and make your process as dead simple as you possibly can.
One universal truth that I’ve found in my career is that there is a direct correlation between the amount that I’ve had someone read/retain and the probability of a task being done well. Engineers already have enough cognitive overhead trying to build whatever they are trying to, and the more simplistic requirements are outside of their core responsibilities the greater the chance of success for the projects they work on.
At the very least, get buyin from the entire team on any process that you all collectively feel is 100% necessary.
Managing knowledge workers is hard, and the people who are excellent at it are true master communicators and facilitators.
Communication is key
Ask yourself:
- Can your team communicate efficiently and with accuracy about what needs to be done?
- Is everyone effortlessly on the same page and “in the know”?
- Do you consistently hit your team’s goals and timelines?
If you nod your head at all of those, think long and hard about whether that’s reality and not just your perception…then pat yourself on the back. Those are exceptionally hard things to cultivate on any team, no matter how seasoned everyone is.
Simplicity always scales
The simplest solution is almost always the best
No one is a stranger to that saying. The simpler something is, the easier it is to communicate and act on.
Sometimes complex problems require complex solutions, but we can’t just yell “skill issue!” and expect communication or accountability issues to just resolve themselves.
So why “vibes over process”?
First off, full credit to Yan Lhert for coining this phrase. I’ve learned tons of awesome things from Yan.
The end goal of any team project is to produce something. You have to enter into an iterative cycle of ideation -> build a thing -> get feedback -> repeat until you can ship something of value to end users. This is hard. I don’t care how many times you’ve done it, it’s never simple.
The highest performing teams I have been on that manage to deliver great features and hit their timelines are relaxed. They crack jokes, they shoot the shit with their other team members and really get to know each other.
They are vibing.
They create tickets for their teammates because it will help them achieve the team’s goals, not to “track velocity”.
They get feedback early and often because there are no barriers or boilerplate they need to fill out to receive it.
They flow like water.
They aren’t a bunch of nerds doing battle with 20 Jira columns.
Things I like that have worked for me
I don’t think there is any one tried and true way to plan and build software. Anyone that tells you otherwise is likely trying to sell you something.
That said, these are a few things that I think work really really well.
Do standups and keep on point
Standups where the team sets aside 15 minutes to communicate where they are at with their work is always a smart move. I’m not going to go into detail about how to run a great standup, but keep them short and to the point. Let people get back to their work as quickly as possible and make sure every team member has a chance to report on what they are doing and raise any potential issues.
Talk openly about when things go wrong, and celebrate when things go right
Open and honest communication is the key to any healthy human relationship and is massively important on any team. Any problem you face is an enemy of the team, and you set out to solve it as a team. One of the engineers you work with had a slow week because of this that or the other? Show your homie some love and do what you can to help them get back on track. Only be negative as an absolute last resort.
And baby, celebrate those wins! I’ll say it again, this is really hard, and you accomplished a big goal! That’s braggable and awesome. Duck out early and grab some beers together or go do something kick ass. You all earned it.
Demo-Driven Development
This is one of the most powerful things you can do to keep a team on track and accountable. At the end of every sprint, get everyone together (stakeholders, engineers, literally everyone) and have every Individual Contributor show off what they did. Here’s why this is so awesome.
- It’s a chance to show that awesome thing you just built and get immediate feedback.
- It informs the team, in real-time, where the project is at. No velocity reports or QA on acceptance criteria needed. Everyone can see what’s being built.
- It keeps people accountable and puts social pressure (the good kind) on a team to deliver.
Seriously, do demos if you don’t already do them. Give everyone a chance at the mic and shine the spotlight on them. There are countless benefits outside what I detailed above.
Do necessary glue work, but only the bare minimum
Sometimes we have to write documentation and tickets for the sake of the project. If something is mission critical and especially if it’s complex, document the hell out of it for the benefit of your team and other future teammates. Having a history outside of git and PRs of why things were done the way they were will always come in handy later.
If your team isn’t vibing, you’ll know
If you have to look at a report with 20+ metrics to tell whether or not your team is healthy, it probably isn’t.
Just relax. And start vibing.