Philosophy
Introduction
At DreamTeam we believe there’s a lot of encumbered innovation pent-up in tech organizations. We’re on a mission to unleash it.
Here are our ever-evolving learnings for organizations to move fast – more shots on goal – and stay lean: more shots per person – at any scale. There’s a lot of fluff and snake oil out there on ways teams can be more effective. We’ve found these lessons are repeatedly the most impactful, based on years of studying, partnering with, or working at companies like Shopify, Snap, Amazon, & Gusto.
Agile Is Dead! Long Live Agile? 🤷
In a lot of ways Agile has really jumped the shark. Don’t take our word for it though, ask one of its creators. The Agile Manifesto core value of “Individuals and Interactions over Processes and Tools” ran right into the SaaS-plosion we’re living in today. The rise of task management masquerading as project management really did a number on “Responding to Change over Following a Plan.” And then came the frameworks. If you ask Google, there are more than 50 known Agile Frameworks (SCRUM, KanBan, etc.), not to mention the new scaling frameworks (SAFe, Scrum@Scale etc). We think it's high time to get back to first principles – and that is what we advocate for here in our anti-framework for Getting $#*! Done at Scale.
It’s About the Projects and People
If we put the frameworks, goal methodologies, and task management tools aside – what are we left with? At the core, we do projects. And they’re done by a team of people. We have found that stripping away the jargon and process, and focusing on getting really good at the fundamentals, goes a long way toward improving productivity. In this case, that means helping people get really good at executing projects. In fact, that’s why we named our first product KATA. Japanese for “form,” KATA is commonly used in martial arts to refer to practicing fundamentals to achieve overall mastery. 👌
Moving Fast
Moving fast means not wasting effort, which allows for more shots on goal. Moving fast at scale means ensuring large groups of people are spending their effort on the highest value items – to do work that matters – in concert with one another, in complex systems. You don’t just need raw speed. You need velocity: speed AND direction. Otherwise you run the risk of going really quickly in the wrong direction(s) and ending up in the wrong place. This is where projects come in.
We’re Playing Poker, Not Chess
Chess is a beautiful game of decision making and strategy, but it’s also one of clear rules and complete information. You can see the entire board all of the time. If you are a skilled player, there is little betting in chess. Victory and skill are closely correlated.
As nice as that might sound, real life is never that straightforward. As Annie Duke states in her popular book, Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts, “Chess, for all its strategic complexity, isn’t a great model for decision-making in life, where most of our decisions involve hidden information and a much greater influence of luck.”
Environments shift, information is incomplete, and there is no perfect way to play. Every decision becomes a bet. And projects are the bets organizations make. How we decide to apply our finite resources and people.
When reframed as bets, you suddenly realize that projects can’t be approached as a fixed set of things to do, aka tasks, to achieve a known outcome. This is especially true in the case of software development. Instead, projects should be viewed as establishing a bet on a desired outcome, with recognition that you are in an ever-changing environment with incomplete information. Acknowledging this upfront lets the team see shortcuts and optimizations they’d otherwise miss in blind pursuit of task completion.
Focus on Outcomes, Not Outputs & Dates
The popularity of task management tools makes it easy to mistake speed for velocity. Look at all these tickets we are closing! But are we moving the needle on our business objectives? Are we having an impact for our customers?
Focusing a project on achieving an outcome, rather than getting a bunch of tasks done, eliminates wasted effort. It gives your team the guidance, and the autonomy, they need to decide if a task is actually worth doing.
When you focus on achieving an outcome, rather than meeting a (often poorly estimated) ship date, and pair it with thinking in bets, you are in a better position to assess tradeoffs and potential return on effort, or ROE. You can then match your appetite for investment with the potential outcomes, and place your bets (aka projects) accordingly.
This is powerful. Not only will you save wasted effort and find shortcuts along your way, but it lets you say “no” to more projects upfront, avoiding even more wasted effort!
ROE Not ROI
It's a subtle but important mental shift. ROI is a financial term. But more often than not, we aren’t making financial investments with projects. Instead, we’re allocating people’s time and energy, which means we’re investing effort. So, Return on Effort. Why does this distinction matter? Well, the math is different. Sure, time is money and all that. But people are not resources. When you invest $100 and want to double your investment you invest $100 more. Asking people to work twice as hard yields variable results. You may get more or less than twice the effort depending on how you ask! And doubling the people, well, projects don't work like that. If you remember that we are making investment decisions not with algebra, but multivariable calculus, it will go a long way into better upfront decision making and appetite assessment.
But Still Dates (Milestones)
Parkinson’s Law tells us projects expand to fill the time they’re given. So projects MUST have a target ship date, right? Otherwise they go on forever?
But we all recognize that projects evolve as they go. As we make progress, we gain new information, which alters our course. We rarely know the entire path forward when we start. But, we do know the concrete next step, or milestone, we are working towards. These milestones pull us closer to achieving our overall objectives.
Tracking milestones keeps Parkinson’s Law at bay by tracking smaller, higher confidence, interim goals. This lets you subdivide the entropy for lower overall project risk, and have small victories that build confidence and momentum.
The best way to write and set milestones is in the language of your project’s end users and what is being achieved or delivered. Not in task management terms “Tax Engine V2” but in project ones “Begin checkout completion rate test with new tax engine”. For product development, use product functionality language. For technical projects, use technical deliverables. This makes it simple for everyone to connect the goals of the project to the progress being made. For example, stating when a new feature will be complete or a target country launched, is more helpful than knowing that the “back-end is complete.”
Status updates should then cover progress towards achieving both these milestones, as well as the overall project outcome.
We’re Part of the Broader Team
It’s easy to fall into the myopic “it’ll be done when it’s done” mentality, especially as an Engineer. While that sentiment certainly carries some weight, other folks need to be in the know so they can successfully complete their own projects. Marketing needs to be ready to tell the customer. Customer Ops needs to be prepared to support the customer. And Sales needs to be equipped to sell the thing you're building. Setting milestones with target dates that are visible to the entire organization is a great way to keep dependent teams informed. Perhaps even more importantly, it builds trust, and increases the odds of your overall project success. Consider this – if users are never told about a new feature, or a new capability is never sold, did it ever really happen? And we know you can’t foresee the future before it happens. Adding an expression of confidence to your updates makes a huge difference!
Inputs Matter – Connect Your Strategy
It’s no secret, people want to work on things that matter. The more you can connect your project to why it matters, the more motivated your team will be, and the better decisions they will make. Objectives alone aren’t enough.
Consider this example. Suppose you operate a social platform and you want to add games to it. Your overall Objective, in the OKR sense, might be to “build a world class casual gaming platform” for your audience. So your team goes off to build a world class casual gaming platform. One project they define might be to add a portal for game makers to publish games. Sensical.
But what if your strategy was to create a limited number of blockbuster games, rather than offering a broad catalog? Your team would be doing a lot of needless work crafting a world class publishing portal when you really just needed a basic platform to host a handful of games. They were missing the why, the intent of the Objective, the strategy.
Connecting strategy to execution at the project level ensures alignment on what a successful outcome actually looks like. It exposes implicit assumptions and avoids wasted effort.
We’ve seen that a great way to do this is by writing and sharing a Project Brief. A collaborative document to drive alignment and consensus about a project before any effort is spent. In addition to covering what a project is, a Project Brief should also outline the bet it’s undertaking, why it makes sense, and how it relates to the overall strategy. This document should be shared broadly across the project team, not just consumed by leadership and product management.
Tap Into Your Team
The people on the front line often have the best ideas and can spot opportunities first. Empower a culture where anyone can propose projects and get consensus on them. We find project briefs are a great tool to enable this!
“So What?” Updates
Build a culture of action driven updates that stand on their own. Encourage team members and project owners to ask themselves “so what?” when providing check-ins and status updates. If something is on track – what’s working and is there an opportunity to go faster? If something is off track – what is the issue and what is your plan to address it? The more automatic the behavior, the more automatic the continuous improvement.
Staying Lean
Being lean means getting more done with the team you already have – more shots per person. Said another way – you are seeking to make each individual as effective as possible. The best way to do this? Make the process of doing the work thoughtless, so all of the thought can go into the work itself!
Centralized Project Directory
Create a single source of truth for all of the projects being done across the organization. With limited exceptions, this directory should be accessible to everyone – from the interns, to the CEO – so information can flow freely. This requires more than just a project name listed on a spreadsheet. The project directory should clearly communicate why each project is important, how each project is going, and how much effort (people) is being applied. This level of companywide transparency enables everyone to stay tuned in and leadership to more confidently make trade-off decisions.
Standardize Communication, Not Tools & Processes
Let your teams select the tools and ceremonies that work best for them. Teams are like people – no two are alike and they change over time. Forcing them into unnatural ceremonies or undesired tools just adds friction – it makes them stop and think. Standardizing communication, on the other hand, enables information to flow freely, while teams are free to work how they choose.
Have a standard language for talking about projects and a social protocol to actually use it. Beyond tracking milestones, we have found that regularly sharing demos and check-ins from team members, as well as keeping a written decision log, go an incredibly long way to staying in sync, asynchronously.
Sprint processes are a great example of this. Some teams prefer two-week cycles, others six. Some projects have fixed shipping schedules, such as app store updates, and some are arbitrary dates. Sprints are great at scheduling and coordinating tasks and should be flexible to match the actual work the team is doing. But sprints tell you little about progress. You need to standardize how you talk about progress.
Think of projects like a jazz performance. It may be the same song, but no two performances sound the same. What makes jazz special (and hard!) is its improvisational format, or artistic autonomy. jazz artists riff and jam in real time. This works because in addition to their strong functional skills, each musician knows how to communicate (through active listening) with each other as they play and adapt on the fly to what they are hearing.
Projects are the same way. When we share a common language, and have mechanisms in place to hear each other, we can build on each other's riffs and deliver stellar performances as a group. Usually, it’s just not the performance we originally planned on delivering.
Keep the autonomy, standardize communication to bring alignment.
Focus the Feedback, Create Alignment Moments
While frequent sharing and feedback should be encouraged, it’s important for team members and stakeholders to understand where and how to best support the team. Dissecting copy on early designs is not productive. Neither is questioning the approach to solving a problem right as it’s about to ship.
A great way to focus the feedback is to share which phase the project is in. Teammates should then deliver feedback appropriate to the level of project maturity. If the type of feedback and the project phase are misaligned, the project team should feel empowered to push back!
At the highest levels we find projects follow four phases. And no we aren’t talking about the dreaded waterfall. There will be many OODA-like loops in each phase. We are talking about what types of activity are taking place and creating alignment checkpoints before we decide to move further and spend more effort.
Propose – Building consensus and getting buy-in for a project. Write a brief, explaining the bet and why it's worth taking.
Explore – Plan how to achieve the outcome and identify the fastest way to validate this plan.
Execute – Turn the plan into reality! Build milestones and track progress against them.
Validate – Measure success and ensure the project is working as intended.
Foster Focus, Reduce Churn
The entire project team should be responsible for achieving a successful project outcome. But each project should have a single-threaded owner responsible for its successful execution. Projects develop their own gravity, and someone needs to hold the world in their head to keep it moving along. It’s difficult to do that when you’re spread across multiple worlds!
For the rest of the project team, it’s impractical to only ever work on one project at a time. However, the number of simultaneous projects should be limited to as few as possible. This keeps things from falling through the cracks, and it lets the momentum of a project build on itself.
Leverage project phases to help you think about how team members should be staffed against projects. Team members should never be working on multiple projects in the Execute phase at the same time. For projects of any substance, this is simply too much to tackle at once and puts both projects at risk. However, it’s realistic to work on a project in the Propose phase while you are also actively working on a project in the Execute phase.
Bad News Is Good News
Bad news should never be punished. If a warning flag is raised, this is instead an opportunity to jump in and help (if needed). Wouldn’t you rather know immediately when a project is going sideways so that the broader team can put their heads together to get it back on track? The alternative is so much worse.
Normalize the fact that not every project is green all the time. A centralized project directory helps to drive awareness and acceptance of this.
Project Retros, Not Sprint Retros
Carving out time to look back and reflect is a strong tool for continuous improvement. However, we have found much greater value in reflection at the project level, rather than after each sprint. Sprints simply aren’t long enough to make meaningful observations beyond micro-complaints. And reviewing a sprint is just reviewing our ability to get work done in a specified time period. We miss the bigger picture observations as to whether we were able to problem solve, work cross-functionally, and achieve an outcome in the quickest time possible. There’s much more continuous improvement fruit to pick in the latter.