I was reminded of this after our panel talk @ hashtag#dtxmcr23 yesterday, when someone spoke to me afterwards who’s accountable for the digital workplace strategy at his org.
The great thing about paper, pens, spreadsheets and WhatsApp groups is they’re ultra flexible and the technology works for /you/.
If you have a broken process, invariably, adding more technology makes the situation /worse/. Why? Because you’ve now sealed the process in concrete and making changes is 10x harder (and more expensive). Your users are now beholden to the technology. You’ve probably not made their lives better, or their work more efficient.
Where do you start? I fell in love with Service Design (see comments for Wikipedia link), after seeing folks like Katherine Wastell, Kathryn Grace and Elisse Jones use it at the Co-op. Start by mapping your end to end process – people, systems, tools, workspace – and identify the pain points.
When you do this, more often than not, you find technology is /not/ the answer to the biggest problems.
And if you do choose to add new tech into the mix, you’re doing so with a much better understand of why and what problem it’s going to solve.
To me, that’s the heart of Digital Transformation.
n Agile circles we talk a lot about autonomy, and good teams being autonomous. However, there’s a common misconception. No team is ever fully autonomous. No team lives in a vacuum.
Autonomy needs boundaries to be effective.
Look at a top-flight football team, where high performance is essential. They need to be empowered to self-organise, so they can adapt to what the opposition is doing.
But their autonomy has clear boundaries – how many players you can have on the pitch, the playing area and many other rules. Without them it would be more like the Royal Shrovetide Football game, an early form of football dating back to the 12th century which is basically just a massive fight (the main rule is, somewhat bluntly, no killing).
A team is an example of a complex adaptive system. Every successful complex adaptive system is bound by rules, even in nature. A flock of birds works on 3 simple rules, allowing them to self-organise, avoid crashing into each other and leading to mesmerising patterns like murmurations of starlings.
To enable autonomy, it’s important for teams to have clarity about what they’re responsible for and the boundaries around what they can make decisions on.
Defining boundaries is a delicate act. Overly rigid and you can inadvertently limit the very autonomy you aim to foster. Too much leeway can lead to misalignment and inefficiencies. The goal is to offer enough structure, while preserving the space for creativity.
Like a conductor with an orchestra 🎻: set the tempo 🎵, but let the musicians shine ✨
Your proposition might be bleeding edge, your tech doesn’t need to be. Go with well-known, battle-tested technology.
Both start-ups and established orgs frequently fall into the trap of chasing the latest trends and opting for cutting-edge technology. More often than not, they later find themselves burdened with complex stacks that are not fit for purpose and hard to maintain.
Here’s the thing: unless you’re operating at a mega scale or working in a very specific niche, you can accomplish nearly everything you need with tech that’s been popular for decades. The benefit? They’re well-known, well-supported, and it’s easier to find engineers who are familiar with them.
🚨 The Trade-off Trap 🪤 When assessing new tech, many developers overlook the trade-offs. They get caught up in the allure of the problems the new tech will solve, without understanding the new ones it might introduce.
🚨 The Re-write Trap 🕸️ When the opportunity to re-write something arises, the temptation to choose shiny new tech is strong. However, more often than not, the tech stack wasn’t the core issue. The main reasons are typically out of support frameworks and languages, and an architecture and codebase that have become too complex to maintain. By opting for unfamiliar tech, you risk complicating your re-write even further. 🚧
Common examples 🔍 – Choosing NoSQL databases over traditional relational databases – Overcommitting to a microservices architecture – Going all-in with a serverless architecture like AWS Lambda – Opting for GraphQL over more traditional REST-like APIs – Dare I even begin when it comes to front end web frameworks 🥺
While all these choices have their merits, they are best suited for specific use cases and you need to know what they are.
Innovation 💡 in your product or service is where your focus should be, not in the technology that supports it. By choosing reliable, common technology, orgs can avoid unnecessary complexity, freeing up more time and resources for what really matters: solving real-world problems and growing their business.
It may seem paradoxical, but you often get more done by doing less, better.
Delivery slow 🐢? Expectations and deadlines regularly being missed 📅? All too often it’s because teams are just trying to do too much at the same time.
Think of a congested motorway, frequently caused by nothing more than too many vehicles trying to go too fast. Smart motorways solve this by reducing the speed limit, meaning everyone gets where they’re going more quickly.
Larger organisations trying to do too much can be very inefficient, further exacerbated by dependencies between teams and complex org structures creating competing initiatives, akin to a city gridlocked at rush hour.
Why better as well as less? You didn’t plan for misunderstanding requirements, didn’t plan for code becoming more complex and harder to change, didn’t plan to fail QA, didn’t plan for it to break something in production.
These are all things more likely to happen when you’re juggling too much work at the same time (and they all slow you down), but won’t necessarily improve by just doing less. If you’ve been working this way, bad practices are probably baked in culturally.
📉 Doing less 📉
⚠️ Reduce and limit the amount of work in progress at any one time (see WIP limits) 🔪 Break work down into the smallest possible deliverables ✅ Focus on getting things done before picking up new work
🌟 Doing less, better 🌟
🎯 Ruthless prioritisation to ensure you’re always focusing on the work that will have the most impact 🤝 Make sure outcomes and requirements are clear and agreed before you start new work 👩👩👦👦 Take collective ownership and work as a team rather than passing tasks between silo’s 🔧 For engineers, focus on writing maintainable and well unit tested code, so it’s easy to change and reduces the likelihood of introducing bugs.
What practices have you found help create better focus, streamline delivery and get more done as a consequence?
There is no existential threat from Artificial Intelligence any time soon, despite what the headlines might have you believe, so I’m going to try and explain why.
Why are we hearing so much about it then? Fear, uncertainty, and doubt (FUD) make for great headlines, sell papers, and generate advertising revenue on podcasts. However, if you dig a little deeper, the substance beneath is considerably less sensational.
Understanding the current state of AI
AI as we know it today predominantly falls under what’s known as Machine Learning (ML). There are other concepts in use, but the vast majority – including those using Large Language Models (LLMs) like ChatGPT and MidJourney – are based on ML principles.
ML is learning in the very loosest sense. It’s intelligence in the very loosest sense.
Machine Training would, be a more accurate description. Algorithms are fed data, evaluated on their outputs, adjusted, and then fed more data until their results improve. This iterative process eventually creates models capable of some very impressive tasks. But they’re not ‘learning’ in the way we think of a child or a baby chimp discovering the world. They’re not generating new, novel insights or demonstrating any form of consciousness or understanding.
Artificial General Intelligence (AGI) is no more than theory
ML isn’t remotely close to the kind of intelligence that could theoretically pose an existential threat to humanity. The fundamentals of ML have been around for at least 40 years and it’s taken us that long to get to a point where it has genuine, widespread practical applications.
As for AGI, there are currently no accepted theories for how it could even be achieved. There are plenty of ideas, but they remain hypothetical. Could machines become genuinely intelligent? Possibly. But no one knows for sure.
Predictions of when the “Singularity” (the point at which artificial intelligence surpasses human intelligence) will arrive, are thus pure conjecture.
Ignore the FUD and focus on the real issues of AI
While ML-based AI is undeniably changing our lives, it is doing so in the same way computers have been since the invention of the pocket calculator. There are tasks at which computers already outperform us, like processing large amounts of data and performing complex calculations, but for the vast majority of what we consider to be human intelligence, they’re still light years away.
We’re no closer to a Terminator-style “Judgement Day” than when Alan Turing first started kicking around the idea of AI in the mid 20th Century.
That’s not to say AI doesn’t present us with challenges. Job displacement, privacy concerns, potential misuse, and inherent biases are real and pressing issues we need to address. We’d be better off focusing on these tangible problems rather than worrying about hypothetical existential threats posed by AGI. Let’s redirect our energy to making sure that our use of AI is responsible, ethical, and beneficial for all.
I grow more convinced each day that one of our biggest battles, in our organisations and even society as a whole, is with Confirmation Bias.
Confirmation Bias is when we unconsciously look for, interpret, and remember information that backs up our own beliefs or values, and downplay information that doesn’t.
It’s all around us and has likely grown worse with the rise of social media. We create “filter bubbles” by following only what we like, and recommendation algorithms make this even easier to do.
Recent events like Covid, Brexit, and even Twitter’s rate limiting over the last few days, show how people selectively use information to back our view.
This also happens at work, especially in “them and us” cultures between teams. A common example I see is between commercial and development teams:
Development says, “Commercial sell new features without asking, make unreasonable demands, and don’t care about tech.”
Commercial says, “Development take too long, only care about the tech stuff and don’t care about the business being successful.”
In both cases, we tend to amplify the information that backs our view and ignore what doesn’t. This makes our biases stronger and the “them and us” gap bigger, which hurts open communication and cooperation (let alone being an unpleasant working environment).
So, what can we do?
First, have some humility. Realise that YOU are just as likely to be vulnerable to Confirmation Bias as anyone else. We like to think we’re more self-deterministic than others. We’re not. Get over it!
Second, show some empathy. Put yourself in the other person’s shoes. Engage positively and with an open mind. It’s amazing how many times I’ve had an “Ah ha” moment, and even apologised for how I acted when I better understood their view point. Crucially, this also builds trust, which is vital in being able to work together to solve problems.
Lastly, burst your filter bubbles. Follow and read viewpoints you disagree with as well as ones you do. Be careful about opinions that don’t have evidence to back them up. And check that the evidence is reliable.
Challenging our biases can be tough, but it’s worth it. By doing so, we build stronger connections, foster better communication, and create more collaborative environments. And who knows, we might even change our minds along the way!
I think it was Jamie Arnold who first introduced me to this phrase.
In engineering teams it’s – sadly – still all too common that Quality Assurance (QA) is the last step in the delivery process. Developers code, then throw it over the wall to QAs to test. Teams working this way typically have a high rate of failure and large release bottlenecks – features and releases pile up, waiting on the QAs. Developers pick up more new work whilst they’re waiting. Bugs come back and developers are now juggling bug fixes and new work.
It’s slow, inefficient and costly!
What I dislike the most is the cultural aspect – the implication that quality is the responsibility of QAs, not the developers who wrote the code.
Quality is a team sport. The most valuable role for QAs* is to ensure quality is baked into the entire end-to-end delivery process. This has become known as “shift-left” – QAs moving away from spending all their time at the end of the delivery lifecycle and focusing more on how we can “build quality in” throughout.
What does this look like in practice?
– QAs involved in requirements gathering and definition, making sure requirements are clear, well understood and we’ve considered how we’re going to test it (inc. automated tests).
– QAs ensure we’re following our agreed Software Delivery Lifecycle (SDLC) and the steps and control we have in place to ensure quality is front of mind.
– QAs collaborate with developers to write automated tests, developers collaborate with QAs on mutation testing, compatability testing, performance testing.
– If there’s any manual testing required, /everyone gets involved/. QAs make sure everyone in the team is capable of doing it.
It’s a much richer role for QAs, and far better for everyone!
This is something I said in a talk on high performing teams recently that resonated with a few folks.
In my experience the most effective teams are small, between 3-5 members, and the most effective organisations are the ones that manage to stay small overall.
Why might this be? Fewer people streamlines communication: a 3-member team has 3 channels, a 5-member one has 10. It rises exponentially with every person you add.
In small teams, alignment is more organic. Greater shared understanding fosters greater autonomy and more informed decision making.
“Better” is not just about technical expertise. Behaviours are just as important, if not more so (teamwork, communication, adaptability and so on).
In a high performing team, the whole is greater than the sum of its parts.
With an underperforming team adding more people will most likely slow things down (it may not look like at first because everyone is “busy”, but it will).
In the fast-paced world of start-ups, it’s common to overlook the importance of writing unit tests*. With limited resources and short timescales, many consider it a luxury rather than a necessity (if they even consider them at all).
The long-term impact is far from marginal – if you’re lucky enough to start getting to scale, you’ll regret not investing in them early on.
However, even in the short term, writing unit tests can speed up your delivery. Here’s how 👇
🐛 Bug Reduction
Unit tests enable teams to catch bugs early, before they reach production. This not only improves user experience, but also saves time and resources in testing, debugging and hotfixes.
⚡ Quicker Changes
Good unit tests encourage modular, less complex code. This makes it easier to implement changes and add new features. Furthermore, unit-tested code acts as its own documentation, reducing the time needed to understand how the code works.
🔄 Frequent Releases
With a solid suite of tests in place, the risk associated with each release decreases. Developers and stakeholders gain confidence that the new changes haven’t broken existing functionality, enabling more frequent releases and quicker feature rollout.
👥 Fewer People (& Cost)
Unit tests reduce the number of people required overall. Less resource needed for manual testing and debugging, and a lower overall cost of change & maintenance as a result of the tests encouraging less complex code.
🌱 Why Early-Stage Start-ups Should Care
Many early-stage start-ups don’t invest in unit tests, especially when the development team is small. However, as the team grows, their absence becomes increasingly detrimental. Adding unit tests retroactively can be a herculean task, particularly if your codebase has already turned into spaghetti.
In summary, unit testing is not just a “nice-to-have”; it’s a strategic advantage. Even if you’re working with a lean team, the benefits far outweigh the initial time investment. The sooner you start, the faster you’ll go.
Either have regular set office team days or choose fully remote, but avoid the messy middle of “come in when you need to”
Firstly a few disclaimers: This article doesn’t intend to compare or argue the merits of either fully remote working or co-location/hybrid. Secondly, these are my views and not those of my employer or any other organisation.
As things are gradually getting back to normal, many organisations are formalising their hybrid working policies. Some are choosing to have set office days – including my current organisation where our Product & Tech leadership (which I’m part of) made the decision to take this approach early 2021. You can read about our rational here. It’s not long and saves me repeating it in this article.
Others are taking the “come in when you need to” approach. This generally means if a team needs some face time for activities that benefit from in person interaction, they arrange to come into the office together. Otherwise do what suits you (the individual) best.
Why “come in when you need to” is the messy middle
When I try and arrange to meet up with friends who are now spread across the country (or even old work colleagues locally for that matter) it’s a military effort finding a time when everyone is free. Usually we have to schedule months out in advance. Even then things fall through as often as not.
I’m hearing similar stories from organisations currently taking the “come in when you need to” approach – teams finding it a struggle to get everyone together in person at the same time, especially when they’ve now hired people geographically further out from their offices. I’d imagine this gets exponentially harder when you want to get a few teams together who are, for example, collaborating on a shared outcome.
For working parents I see it as a particular issue. Most parents I know don’t have five full (i.e. 8am-6pm) working days of childcare (due to the expense). It’s usually a mix of paid childcare, grandparents and then parents splitting shifts on drop-offs and pick-ups (thankfully at my current employer we have flexible working hours which allows you to do this). In my experience at least, it’s a highly disciplined and drilled exercise, needs a routine and is difficult to change on a whim.
“Hey, why don’t we all go into the office tomorrow and workshop it in person?”
What if you’re the only parent on your team and now feel like the “difficult” one because you can’t just always change your routine that quickly? Now they’re all going in anyway and you’re missing out?
From an HR perspective, it’s ambiguous and difficult territory. What if someone says they won’t come in? Is that a conduct issue? When you have set days for everyone it’s pretty simple, they’re the same polices you had pre-hybrid working for those days. In the “come in when you need to” world you’re going to require a very clear definition of “need” and most likely, new and complicated colleague policies.
I’ve a strong suspicion (I know it’s the case in some places) quite a few organisations taking the “come in when you need to” approach aren’t doing so because they see it’s working, but because they’re still in wait and see mode. Why? Primarily I’d guess, fear of attrition in a highly competitive labour market. I predict that as more organisations come out formally with set office day working patterns, others will follow.
Choose set days or go fully remote?
Like I said in my disclaimer, I’m not out to argue the case for either remote or co-location here, just highlighting the situation I see as the worst of both worlds. If you can’t see set days working for your organisation, then perhaps it’s worth looking into whether fully remote is a better option.
