I remember chatting with a VP of Engineering at a company in my city; he wore a shirt that read “AGILE” in large letters. He had two posters in his office outlining various SCRUM process and rituals, and he talked for 20 minutes about how Agile Development is the only way that good products get built while sitting in front of a library of books on the same topic.
He nearly had a face tattoo that said “Agile”.
The following week, I spoke with an Engineering team lead, based out of Seattle. This person was leading one of the best engineering teams in the US and also loved Agile, but only the Kanban or Lean flavors of it.
Each had different tattoos, but their books were the same.
There’s a lot of great thought about how digital or technical products get built. These two leaders, and many of us in the community, have read all of them. But this article isn’t about what strategies enable you to build great software products. This article is about what kills the delivery of quality software.
Lack of process.
Often, managing process, operations, and knowledge management are the last things on a developer’s mind. Many engineers not only think without regard to process but came up in an age of Zuckerberg. The “Just ship it” mentality, the idea that “shipped code is better than good code” and that too much process can strangle innovation were ideas all drilled into us. Venture capitalist Ried Hoffman summed it up best:
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
But the skills that served you well in creating that first embarrassing version of your product aren’t the same ones that help you build a successful product or company in the long run. While it is true that too much management of the process itself can hinder your ability to bring a product to market, too little can do just as much damage over time.
This is the first of a three-part series. It covers how a lack of a process and poor knowledge management prevent engineering teams of all sizes from shipping good code and products. We’ll talk about the role that process plays, how to build robust processes, and specifically, what tooling or methods can help you get back on track.
Part One: Success and Failure are Relative
“I don’t care what your internal milestone is. Just tell me when I can use the API.”
This request came from an aggravated team member during a moment of extreme frustration; this person couldn’t understand how we had gotten so far off track.
Back up three months to the start of the quarter; two teams at my company had delivery dates they needed to hit, and there was a tricky dependency at play. Team one needed to build an API. Team two needed to use the data from the API for their own product. Team one was set to be done at the end of the quarter and team two was set to begin their work at the beginning of the next quarter.
Everything went well initially. Weekly meetings assured both teams that everything was on track and moving in a solid direction: “Things are green, we’ll deliver on time!”
The end of the quarter came, and – as promised – team one had delivered their API and team two could finally begin their work. Good news all around!
“The API is done!” Team one said, bottles of champagne popping in the background.
“Wait, what? The API is unusable!” Team two said, beginning to pull out their hair as they thought about their own delivery dates a few short weeks away.
Apparently, team one had delivered an API with no data in it. Team two needed the API and the associated data. Oops.
The Problem of Definition
What’s your mission? What are the success metrics for your team? What’s the company culture? What’s your definition of failure? What’s your definition of “done”? If you ask people on your team to answer these questions, most of them can likely give you an answer or a definition. The real question, though, is how many different definitions will you get?
If you have a team of twenty people and haven’t defined any of the above, you may have more than twenty different ways that things like success, failure, shared vision, or team goals are defined. Said differently, you may be going in twenty different directions. Even when these values are defined, it takes constant reinforcement to keep everyone moving in the right direction. Without definition, you don’t have a chance.
“Ready! Fire! Aim!”
This old adage has a time and a place within an organization, but not when it comes to defining the job to be done and the ways in which you measure whether or not it was done right.
Nothing is more dangerous than starting out on a journey of a thousand miles facing different directions. Even being a half step off from each other can lead to miles of separation months later.
In order to avoid ending the journey in different places, you have to think through the trip ahead of time.
Think through where you want to go as an organization and how you want to get there before you start moving. If you’re in a company that’s starting up, it’s easy to get too focused on what you’re building and ignore how you plan to get there. It is just as important that you focus on the way in which you will carry out your plans. Think through a typical day or week for all of your team members.
How do they know what to work on? How do they know where to spend their time? Who do they interact with and how often? How do they feel when they go home at the end of the day?
If you’re at a company that’s already mid-stream with a project or product delivery cycle, you have to be more thoughtful about these sorts of questions. Aligning on the answers can take time, and you don’t want to jeopardize any delivery dates. But I’d argue that not getting aligned on these sorts of things will rob you of more time in the long run. Take a day or two, shut down the office, lock everyone in a room and get on the same page.
Document what you come up with. Make this documentation easily accessible to all. Make sure everyone can look at the map. You’ll be amazed by how much saner people feel when they’re clear on where they’re heading.
Remember that you don’t have to have everything figured out on day one. But you shouldn’t get a year into the company and then ask questions like, “What are our values?” or “How do I succeed?” Take time to think about what matters to you, what sort of grit and ethos is required within your team to get the job done, and how you might begin to flesh out your mission, vision, culture, as well as your definitions of “done”, “success”, and “failure”.
Write these down and use them when you hire and interview. Use them when you have 1:1s, and constantly remind yourself of what they are. If you miss a delivery, ask the hard questions about whether your definitions of success and failure were articulated well enough to serve you throughout the project.
While you want to be careful about constantly changing these internal definitions, (since you run the risk of signaling that leadership is fickle,) you also shouldn’t be afraid to revisit them when the need arises. Use documentation within Tettra to serve as your Bill of Rights for what matters most to your company, so that you have something to interrogate and amend later.
If you’re going on a trip, you need a map. It’s important that everyone can determine when you’re on track and when you’re lost. If you’re trying to build a product without these sorts of definitions, you’re going to waste time course-correcting later, or worse, risk getting so lost you never find your way to where you need to go.
Want to do something scary? Poll everyone in the company about your mission, your values, the definition of “success”, or the definition of “done”. How much variation is there? Would your team be happier and more productive with better alignment?
Check in soon for the next part in this series for more approaches to keeping your team sane.