Trust and verify.

You've probably heard those words before. They're part of the standard management vernacular. I've certainly written them several times in this guide. But what does it mean, and how can you apply it?

Simply put, trust is empowering. People operate best from a position of trust. They make better decisions, and they make them more quickly. Teams with high trust have high morale, and more autonomous, and will deliver more, better software. Added to which there is a virtuous cycle: productivity breeds trust, which breeds productivity which breeds more trust.

Sounds great - I'll let them get on with it then!

It's not quite that simple. Engineers work best when single-threaded - they can focus better and get more done. The clearer and more explicit a product spec is, the more resilient and faster built the software will be.

As a result, engineers tend to micro-focus. They need to have all questions answered in order to build the right thing. They lose track of relative feature value, and which are the really important flows. This is where the need to verify comes in. You must stay on top not just of what is getting done, but also why. You earn your crust not by telling your team how to build things, but prioritizing for them. Allowing them to cut corners, but for the right reasons.

Name this movie: “A million dollars isn’t cool, you know what’s cool? A billion dollars.” Now just replace ‘a million dollars’ with ‘project status updates’, and ‘a billion dollars’ with ‘project demo’s’. That is an accurate ratio of their relative value.

Project status updates are curated, crafted pieces of information, written by professional storytellers. They have a role, but it’s a supporting one when way too often they’re put center stage on communicating progress. Build a culture of creating demo’s for everything your team does, they are what really should be center stage. And find a way to make sure they’re seen. Live demos can put people off, but recording one async and posting to a common place is great! They come with many benefits:

• Way more interesting to consume (and if you argue they take longer try to read a project status update, and Loom et. all do auto-transcripts now)
• You communicate way more, pictures and 1000’s of words and all that
• There’s no crafting or curating, it is what it is.
• Way better at building alignment, you see all of the details so you can catch if something is off that might not have made it into an update.
• Gives your team more visibility and credit to individuals doing the work
• By default forces you to think in incremental functionality which we think is the best default
• Not mutually exclusive with other flavors of *DD
• Not only for feature teams. We love demo’s that are just a picture of a graph showing an X to Y change. Ditto for partially working features, or prototypes, or mockups!
  

We think demo’s are infinitely (well at least 1000x) better than status updates so we made sure you in KATA you could post them from anywhere, to both your team and your projects, and we’d notify everyone for you! Whether you’re in KATA, Slack, GitHub or any other tool with our native integration or simple tagging language you can post your demo in context, and we’ll make sure it gets to the right place and is memorialized for later.

I joined the Prime Video team shortly after college, back when it was still called Amazon Instant Video and no one had ever heard of it. We were moving fast, setting out to be a top streaming service (something I’m proud to have played my small role in!). As a young, ambitious, overzealous engineer I was always looking for ways to do more. We didn’t have any way to plan our sprints, or optimize our velocity I soon realized, and with that, an opportunity! Jira, surely this is the answer. After-all, how else could we be agile?

So I got it up and running, got all of our tasks in there, and even managed to snag a TV to display our board on, like an ever watching beacon of speed, above our pod. Surely I’ve done it now, I figured, look at me go! Well it took exactly 1 week of standups around that board before I had to resort to showing up at everyone’s desk 10 minutes prior to our standup asking them ever-less politely to update their Jira. And after a while of that I ditched the display saying you know what, I need more of a forcing function, I’ll make physical stickies and we’ll stand around a whiteboard and actually move them. Then we’ll never be out of date.

I’m sure this scene has played out in countless tech offices around the world: well-but-misplaced energy gushing from a young aspiring engineer-would-be manager, standing over the desk of someone decades their senior, saying would you please update your Jira or move your sticky note so we can work better as a team?

As that young future manager, having tried many versions of planning and measuring innovation on many team combinations at various companies thereafter, here’s what I’ve learned: none of it works. The reason? Software projects unfold, they’re never known fully in advance. There’s some surprise here, technical debt there, operations issue, staffing issue… always something and usually many things! So while it makes you feel warm and fuzzy when you spend all of this time and energy upfront building a meticulous and perfectly crafted plan, tasks estimated down to the day, knowing exactly what will be done and when and by whom. Only to start, and watch it all change and you have to start again. And again. And again.

In the words of Mike Tyson, everyone has a plan until they’re punched in the face.

I’m not saying there’s no value in breaking out high level tasks. Those are great, but view them as an organizing and remembering system, not a scheduling system. And this is why you won’t find tasks in KATA, we think there’s a lot of great task tools already and everyone has their favorite. We built KATA to help you get those tasks done efficiently, not spend your day managing tasks and updating tickets.

We all know the best way to get nothing done is to try to do everything, the power of prioritization and focus. There’s many prioritization methods out there to debate with your favorite Product Manager, this isn’t about that. This is about how focus slowly erodes through your execution cycle, kind of like build times. A second here, a few more over there, all of a sudden it takes you 10 minutes to build your code, and that feels normal! Focus is the same way while you’re executing, a little change over here, a “quick win” over there. Have someone start early on a project even though they’re still finishing their last one. Before you know it you’re doing too much again, despite your intention not to.

My favorite example of this, while doing research for KATA early on, was speaking with an old colleague and friend who’s an Engineering Manager. I asked him how big his team was, 10 people. I then asked him how many projects he was working on right now, and he pulled out the project tracker spreadsheet. I politely chuckled as he started counting… 1, 2, 3…. 11, 12, 13…. 18, 19, 20!  2 active projects to 1 engineer on the team. He was shocked, he’d never actually thought to count it despite staring at the spreadsheet almost daily. He immediately knew he had a focus problem. This is how this gets you, not in the beginning of your planning when best intentions are all you have. But when you actually start executing and reality sets in. So stay vigilant my friends, you’re probably doing too much!

This is why you’ll find the board view in KATA so you can quickly see how many projects are in flight, and shortly KATA will tell you when it’s too many. We’re all guilty of it, it’s one of the silent killers of progress, so stay on guard!

Similar to projects, teams tend to exist because, well, they exist. And they keep existing because they are always forward looking. But, not often, but sometimes, you should realize when you need to kill your team. Nuts right? It’s like saying please fire me.

In a former life I led a decently sized engineering team for one of the oldest products at our company. As a result of its age it had taken on a lot of product forms over the years, so had a lot of tendrils technically as well as organizationally. The company was also a fast-growing startup, so you know, technical debt. I truly loved that product line, it was incredibly fun to work on, and we really tried to make a go of it. But after a while I realized, it shouldn’t really exist, it had become a cobbled together frankenstein of systems and product lines. Heck we simultaneously had an ad product, a B2B product, B2C product, and an organic one. It was one of the scariest things to do but I advocated with my also brand new boss to break it up and find the right homes in the technical architecture for the product as well as right teams for the people. And as for me? I wasn’t fired, I actually moved into a larger role with a bigger team, on a much more critical company initiative. In all definitions I was rewarded.

As humans we’re hardwired for self-preservation but just remember why you joined the company. Not to make the best team, but to help make the best company. You’re part in that is building effective, durable teams. And sometimes it takes an incredible amount of maturity and courage to say the team isn’t and can’t truly be effective in it’s current form. The trick to self preservation here is to make sure to realize this before someone else does.

Don’t take our word for it though, here’s one of the original Agile Manifesto authors.