Productivity, prioritisation and progress
How to move things forward
You want to focus on the value that you are delivering. You need to determine what that should be, deliver that value, optimise, and fine-tune it. Next you want to optimise for systems, ensure it integrates well with others in an efficient way, and optimise to scale.
Focus on value
To focus on value is a team culture shift. Learn to see progress from a business perspective. Just because you are a technology team, does not mean you cannot be talking about things in terms of the business needs, and how the work you are doing is directly related. Learn to see progress, not in: "Oh, I shipped this feature", but instead learn to see progress as in: "We shipped this feature, which meant customer engagement rose by 5% or sign-ups increased by 15%", or whatever the business goal is. Features should have business goals attached to them, and you should be helping your team understand that, and focus on that. That is a team culture shift. As you start to do this, you may need to redirect the teams, as needed.
Deliver on value
Your team's skills will shift over time. People will specialise in certain areas, focus on certain aspects of their work, or of the product, or of that project. You begin to ship on a market cadence, you ship as needed. You begin to ship in a way that fits the customer needs. This allows you to capture business value frequently. It allows you to see the result. And hopefully it allows you to reveal obstructions early, because you begin to get a feel for: "Oh, this is in the way. This is going to prevent us from realising that value. This thing here is an issue." Which leads you to optimisation.
Optimise value
You start to look at how to fine tune things. You're like: "Oh, well we always planned things this way. And what that means is X happens. Can we do stuff differently so that X does not happen any more? And that will improve our momentum." This often becomes an organisational structure shift, where people say: "what if we move this team? Or what if we change who the members of this team are?" That can have its own issues, but that is the kind of thing that tends to happen at this stage of the fine tuning of delivering value, because what you want is to improve your product decision-making.
This is not about whether or not you are building a product as a company, but improving your decisions for your customer, and eliminating the hand-offs. This is where everybody switches to a multi-functional team, and suddenly you've got the designer and the developer and the product manager all in the one room, in all the same meetings, all learning the same things, at the same time. That speeds up the decision making, and it speeds up communication. You do not have to repeat things down the chain to tell the teams what's going on. Everybody is an active member of the decision-making process, and they all get the information at the same time.
Optimise for systems
This is when you start to say: "how do we integrate with others? How do we scale this? How do we grow this elsewhere?" And this is really organisational culture shift. You start to think "how do we share this information across other places? We are doing so well as a technology team, so how do we integrate more information from marketing or sales or support? How do we deliver more directly for the customer? How do we stimulate innovation to really achieve something new, and how do we really optimise that value that we are delivering for the customer across the board as a company?
A question: how do teams create realistic roadmaps and stick to them, in the face of ever changing business requirements?
The answer is that they do not. You cannot stick to your roadmap in those conditions. You have to adapt and you cannot plan for adaptation, but you can strategise for it. So how do you do that?
Strategies for adaptation
You need to focus focus, focus! Reduce, and narrow your goals until anyone on the team can recite them casually and accurately. Estimates, forecast, and projections make liars of us all. Challenge the assumptions underlying the plan. What biases are skewing our understanding of the world? What are the things here that are going to trip us up? Debate those assumptions. Examine them, rather than arguing whether it is going to take one week or two to build.
Establish consistent terminology. You want to ensure that everybody using the same language from the CEO on down. You want everyone talking the same terms, because so much can be lost in translation between jargon layers. If the business has subject matter experts, get them to bring everyone up to speed, everybody across the board, from sales, marketing, support, execs, people people, everybody should be talking the same language. Everybody from your company needs to come to grips with the jargon, and fully understand the domain, because so much gets lost, and slowed down for misunderstanding of concepts.
Target the toughest problems first. The absolute hardest part of the project should not always be the first task started, but it should come as close as is practicable. Target the hard work early, because it will define constraints for the rest of the project. You do not want to have built half of the app and then discover some huge constraint you have because of the really tricky thing that is actually the unique selling proposition. The entire reason the app is here in the first place. The entire reason the company exists, or the entire reason the client came to your consultancy. Do that stuff first or as first as is sensible. Find metrics you can track and do so to gain an understanding of momentum. This is not about individual performance or picking on people. This is about momentum. How are we delivering as a team? Where are we getting to? Don't estimate, but definitely do review how long past work took. Gain an understanding of the problems, and how long they took to solve, and how much you can reasonably expect to get done.
And as with everything we suggest, review and check in on this regularly: Is this working? Are people actually using the shared jargon? Are the measurements still useful? Could we add some more or can we take some out because they are obsolete? Has our focus veered? Do we need to tighten the focus up, and ensure to bring back on track? Set up a regular review process to examine the situation, and gain an understanding of where you are at, and to adapt your roadmap accordingly.
Key points
- Focus on the value you are delivering and optimise for that.
- Accept that the only way forward is adaptation
- Establish strategies for responding to change