5 Capabilities Tech Businesses Need To Survive 2019
Ambiguity is not the compass developing technology products.
Agile became “mainstream” around 2010. For the last 8 years, we have been applying and exercising Agile in all sorts of ways in attempt to improve the way we deliver software and technology products. To name a few, SAFe, Scrum and Kanban are other frameworks that were developed off the Agile methodology.
But developing software in 2018 is different to how we developed software in 2010. And the way we develop technology products and software in over next 5 years will also be different than today. In order for us to keep up with the fast-pace of technology, innovation and competition, I believe that we need to push our limits further in how we approach the way we develop and deliver those products.
From working with 50+ organisations, I’d like to share 5 capabilities that every business developing technology products will need in their organisation tomorrow.
1. Budget a project in minutes, not days or months
I did a quick survey with a random handful of business stakeholders about how often they do some number crunching before deciding on a project’s budget. They admitted to only crunching the necessary numbers 30% of the time before making a decision about a project’s budget. I’ll admit that number is a lot lower than I expected but in some ways I was not surprised. From every organisation that I’ve worked within, there’s often not enough time in a day to get through one’s to do list. So there are bound to be shortcuts made which means not every step that we should be taking is taken.
Upon conducting research studies with over 100 organisations, I’ve collaborated with a few others to develop a quick and convenient way to enable decision makers to quickly determine a project’s budget. We also took it a step further and came up with a way for stakeholders and investors to get real-time tracking of the project. At the end of the day, the big question we all want to know is if we have delivered the expected value and if not, how far away are we and how much more will it cost. Did I spark your interest? Request early access
2. Estimate projects in seconds, not days or weeks
Today, estimations appear to be conducted like Aladdin rubbing the oil lamp for the genie to grant him a wish. Aladdin only got 3 wishes. But in the tech world, the genie is not so generous. The reality is that poor estimates result in projects getting shut down, companies closing and/or people losing jobs. And the even more unfortunate reality is that because estimates are not well understood or performed incorrectly, they are perceived as a rituals that are a waste of time. The impact of poor abilities to estimate doesn’t stop here. It goes further — businesses that fail to generate money also cannot invest into new jobs and open up new opportunities. Hence, it’s a sad ending for everyone.
There are ways to improve the way we estimate projects, features, tasks and outcomes of business initiatives.
3. Know when data is useful, not when its vanity
When data looks good, it looks good. There is no debate about it. But what does the data tell us? How does that data help reduce uncertainty in our decisions? This often opens up a debate that circles around forever or is shut down so quickly the conversation didn’t exist. When it comes to useful data, the plain hard truth is that it requires real skill, a deep understanding and experience in defining what it is that we want to find out. Having an unclear direction or thirty seconds between meetings to think about “useful data” only makes matters worse. Imagine that you were a Project Manager for a project which needed to produce new airplane. How would you feel if you received a specification that said “plane needs a lot of thrust”, or “the plane has to land softly”? Good luck. Besides the mere existence of data, data needs to be unambiguous in a context so that it can be useful.
“Numbers can be used to confuse people, especially the gullible ones lacking basic skills with numbers” — Hubbard
Currently, there is a lot of hype and conversation about “data scientists” and “big data”. But don’t just take it for face value. I’d recommend to proceed with caution around anything data related and ask lots of questions to stress test that the data you are collecting, referencing and producing to validate that it is correct and reliable. It’s important that the data expertise on your team understands the fundamental concepts behind probabilities, risk and measurement in general. There’s nothing worst than making high-value decisions based on data that was simply incorrect. Also ensure that you’ve got the right expertise on your team or engaged the right experts. Happy to chat if you’d like to learn more.
4. Pinpoint team performance improvements in seconds rather than guessing indefinitely
“If you can’t define it, you can’t fix it.”
From speaking with various team leads and managers from engineering to product, it has become apparent to me that many find it difficult to articulate what defines performance. Hence, the articulation of “good” and “bad” team performance seems impossible to define from the conversations I’ve had. As a result, many organisations resort to running large surveys, doing periodic reviews such as 360s throughout the year or nothing at all. But often the challenge here is that the process to measure the performance is still very manual, time-consuming, ambiguous and usually difficult to determine the appropriate action to drive the improvement. Since this is not a core focus of many businesses, it then falls to the waste side and left as an after thought. So how does a team efficiently improve their performance?
Firstly, if you can’t define it, how can you fix it? (Note that this also applies to product development itself but I’ll resist from getting off topic.) The point here is one first needs to define what “good” and “bad” performance looks like. Secondly, you need to have a reliable and analogous reference to which the team performance “measure” is compared to, otherwise its just a number of piece of qualitative information alone which isn’t too useful. Think this sounds interesting? We’d love to speak with you.
5. Establish a unified way to communicate project progress at every level
Whether its stand-ups, meetings, emails or digital and/or physical project boards, it appears as though we have exhausted every tool option under the sun. This makes me begin to wonder…
- “Have we not found the right method to go about communicating project progress?”
- “Are we using the right combination of methods?”
- “Is the information that we’re communicating lacking substance?”
I would argue that it’s the latter. Whilst there are many tools on the market today that enable us to show information in some way, the biggest problem is that there is no structure or standard around that information we communicate from the investor and stakeholder level to the product designers and engineers.
Currently, we have a disconnect between stakeholders and product managers. The tools today fail us because they don’t allow us to establish an effortless and unified link between the teams developing the technology products and the people who are taking the monetary risk (eg. investors). For example, being able to show feature cards moving across the board is “getting old” because people are starting to wonder what does that really tell them other than giving the feeling of progress being made? Cards moving across the board doesn’t adequately answer the questions of an investor or stakeholder. They’re interested in knowing how much value the cards delivered equated to and how much revenue those feature will generate for them. They’re looking for their return on investment.
Another typical example is an investment into a security appliance (eg. firewall) without having an understanding of the business value with and without the appliance. Telling an investor that the improvements are significant is like telling them that their house is worth a lot. But how much exactly does “a lot” equate to?
In summary, no tool is a silver bullet. A tool is by it’s own definition a device used to carry out a particular function. Through tens of thousands of hours spent in other organisations, we’ve been able to design a model that enables traceability of information from start to finish of a project in a unified language that answers the questions of each actor, specifically from investors and stakeholders to product designers and engineers.
Challenge Your Limits
“Sometimes the hardest thing and the right thing are the same.”
Before coming to Australia, I would have not been so direct (since Canadians generally are not) with this. But I’ve learnt that being direct sometimes is what people need to hear. Thus, I was compelled to share an honest and more direct opinion about this topic because every organisation that I’ve walked into has been a victim of spending a lot more money than was necessary. Along the way, my colleagues and I have experimented with ways of how to improve them and wanted to share it back.
By not accepting to challenge your current approach towards developing technology products, you are allowing your organisation to fall behind. This is neither a favour to the business nor the employees of it. Yes the challenge will feel uncomfortable, perhaps even a bit intimidating but only in the beginning. I can assure you that with time and momentum, it will get easier. After all, “practice makes perfect”.
Keep in mind that performance, purpose and perception of your business plays a key role in the types of talent you recruit and retain. Where would you like to be for 2019?
If you’d like some guidance, feel free to get in touch at email@example.com.
Learn more at Criticide.
Learned something? Click the 👏 to say “thanks!” and help others find this article.
Hold down the clap button if you liked the content!
Clap 25 times!