management
[AFD] has the objective of identifying and mitigating failures. Rather than asking developers to look for a cause of a failure mode, it reverses the problem by asking developers to view the failure of interest as the intended consequence and try to devise ways to assure that the failure always happens reliably
Interesting way to discover unknowns and side step things like denial.
https://www.npd-solutions.com/afd.html
Thanks Connor for the share...
These are some questions I've had written down as we looked for a manager a while ago. Not an exhaustive list or the top 10. Just some questions worth thinking about. Hope this helps.
As successful products increase in revenue, companies grow. Growth allows a company to improve their products, support more customers and create additional value-add services.
Growing up isn't easy. As a handful of engineers become hundreds, or even thousands, the added weight introduces many issues. These can often lead to the opposite outcomes of what growth should have brought: products falling short of providing value and unhappy customers.
-
Why is that?
As companies grow in size, chaos takes over. There is a need for structure to allow humans to successfully exist with one another. Typically, employees are grouped into "teams" and each team is assigned ownership over part of the product. This allows teams to work alongside others to achieve a larger outcome. Often, metrics are put around these areas to understand if progress is being made.
For example, an e-commerce product would usually be split up based on customer flow (or funnel). There will be teams tackling home and landing pages, search, product pages, payment, receipts and so on. Landing and homepage teams only work to increase SEO rankings and "click through rate" to product listings. Product page teams care about converting customers by sliding them to payment.
To ensure all these groups work well, we add management. Managers keep track of progress and tackle a constant stream of people problems. Sometimes, they are also to blame for these problems.
That's not enough. There has to be a way groups can communicate effectively and coordinate tasks. This layer of protocols is "process". Process mandates its participants work to a standard. When mistakes happen, process tightens up to prevent future occurrences. When efforts are successful, process digs deeper. In all instances, process wins.
These pieces that form the structure -- team layouts, metrics, management layers, process -- overtime leads to an organisation becoming more rigid. Rigidity, unfortunately, takes the innovative drive away from organisations.
-
Safi Bahcall, author of Loonshots, managed to capture this in an equation.
From "Innovation Equation" (HBR): In organisations, the competing forces can be described as “stake in outcome” versus “perks of rank.” When employees feel they have more to gain from the group’s collective output, that’s where they invest their energy. When they feel their greatest rewards come from moving up the corporate ladder, they stop taking chances on risky new ideas whose failure could harm their careers.
M = E x S² x F / G
M = certain size at which human groups shift from embracing radical ideas to quashing them
He points out that organisations can alter the point in which they become too rigid by employing certain strategies to move the "freezing point".
-
Rigidity has its purpose.
Rigidity brings order to the chaos of having a huge community of people. Society needs laws, companies need rules too. Drawing lines between disciplines, roles and product teams help keep things under control. But, of course, you won't find innovation in excel spreadsheets.
Rigidity helps an organisation be more disciplined and operationally excellent. It protects revenue. That is a key thing to think about: at some point, the organisation will squash attempts to innovate because it could hurt current revenue. Only proven, incremental changes are allowed. Changes have to be discussed, reviewed, checked, approved by many layers of management (that's why most employees just sit in meetings all day without building stuff). It won't even matter if the products are slowly degrading, as long as revenue stays on green.
If an organisation is full of professionals and makers, can't they override these tendencies? It is not quite that simple. In 1960s, Stanley Milgram ran an experiment to understand authority and obedience. He had an authoritative figure order a teacher (participant) to give increasing amount of electric shocks to a learner as they incorrectly answered questions. Two-thirds delivered fatal shocks to learner and no one checked on the suffering humans in the next room or stopped the experiment. Milgram concluded that people can exist in two states: autonomous, where they direct their own actions and, agentic, where they pass off responsibility of consequences to someone else.
Yep, it is hard to break out of a hierarchy of authority. Autonomy doesn't come for free. We have to create the right environment for it to flourish.
It is tough to steer culture back. It can be done.
-
Some companies try to break out by hiring high profile individuals from already successful companies. In the book Inspired, Marty Cargan talks about how many of these new hires have acclimatised to an organisation that's slowed its growth. So they aren't always best equipped to push the organisation towards innovation.
I've only had the opportunity experience the reversal of rigidity in one team thus far. In my previous team, the leadership team actively worked to bring part of the organisation to a more fluid state. While it will take this entire series of posts to explain pieces of it, there are some basic observations I made.
Vithun with some words of wisdom: vithun.com/posts/playing-the-long-game
...the longer the game one is in, the more they have got to be able to let something go. And not just let it go, but take it off their mind and start from blank for the next thing coming their way. Reacting to everything is something one does when having a shorter-term mindset.
Leave some balls. Thanks @vithungajendra.
I had the privilege to take part a panel discussion on “scaling technology” for
go1’s offsite. It got me thinking…
Software products are (usually) written to meet product outcomes. Initially, these outcomes tend not to include deliverables like “used by millions” or “developed by 1000s”. As a product grows and matures, these concerns start to bubble to the top. Sustaining growth requires businesses to take on “scaling” activities. They help build a lasting product.
Scaling tends to be forced upon a team on 2 directions:
As market adoption increases, there’s more inbound traffic and opportunities. Product team will start to pile on new features to improve conversion and stickiness. Organisation may acquire horizontal pieces of technology to integrate and grow the business. With such rapid growth, software applications starts to breakdown under its own weight.
With more customers, comes more funding and interest from the wider organisation. That means more developers start to push code into the mix. Operations start to slow down as overheads, dependencies and complexity of collaboration increases.
Scaling systems will both help continued growth and reduce some of these issues. Often, that’s not enough to be successful. We also have to evolve people’s mindset to support the growth in business (i.e. scaling people).
This is a large topic. There are lots of books about achieving scalable systems. Here, I’ll focus on some ideas I’ve seen teams miss out on.
Scaling systems is a lot about having a strong architectural direction, aligned to business strategy. Where do pieces of your system go and how do they fit in? “Highly cohesive, loosely coupled” pieces that support where the business is taking the product.
The architecture cannot be “too clever” and should be easy to reason with. Sometimes, we forget that we will have more people with diverse skill levels working in the system. With more people comes more misunderstandings and confusion. Simplicity does well here… as long as simplicity doesn’t adversely affect the competitive advantage a business has.
One mistake I’ve seen made over and over is that we tend to design for the problems we face today. Scaling requires imagination and creativity to identify and agree on a future vision. This has to be done with stakeholders from other disciplines. Tradeoffs and constraints applied for future has to be made together deliberately.
Think about a road vs a F1 car design. What changes and tradeoffs are made to achieve the outcome of going around a circuit significantly faster? F1 car only carries 1 person. It has to have extreme turn around time when swapping out modules like tires and pieces of the body. It’ll support lots of configurations and costs a fortune to maintain and improve one. Scaling is a lot about trying to figure out how you can turn your road car to a race car.
Architecture should be thought as an organic/fluid element of the product. There is little chance that a living product reflect any idealised architecture design. Some parts will lag behind while others will evolve rapidly. That’s the nature of large software applications. Systems are always in motion, much like the business itself.
Think about where “rubbish is collected”. Every system produces waste as more development occurs. Waste usually floats to the top of the stack because these parts tend to be more volatile. Can you isolate areas of high waste production so they can be renewed with low friction?
Example of this is edge services (or backend-for-frontend APIs). Most changes goes into the edge to drive changes in clients. Overtime, they are natural places for bloat. They need to be regularly refactored.
Lastly, any new architecture should have an incremental migration plan. Businesses continue to operate and make money. This means that rewrites are expensive and downright dangerous. Go incremental. If you are not convinced, read the big redesign in the sky.
Scaling people is much harder. Even when the technology is thoughtfully designed, it may not yield good results if people didn’t learn to think from a point of scale.
All teams and companies have an equilibrium: a “default” mode of operation. New systems and processes tend to devolve back to the state of legacy systems when nothing’s done to move existing equilibrium state. Many disregard this as an issue because it is the current playbook to company’s success. Problem is, to make more money, to have scale, you have to move your equilibrium.
Example... You may build a new CI/CD system that takes an application from monthly releases to 15min. It is hailed as a victory for how quickly issues can be resolved in production. However, team’s scrum process may dictate that sprints can’t change after they are set every 2 week. This leads to bugs sit in queue for 2 weeks before picked up anyway. Team may decide it is not valuable to release all the time since the testers are over worked with hourly releases. Couple of mishaps have led to some bad performance reviews. Slowly, things move back to monthly releases. Pipelines degrade because speed is no longer a priority. PR sizes go back up since no one’s trying to push atomic changes to production.
The “way of work” has a direction, even if no ones designed it to have one. The way people work is what yields the system we are trying to replace. So we have to pair the system change with a people direction change as well. These changes have to compliment each other so we get the most out these changes.
Continuing our CI/CD example... Team may move to a Kanban model (or swim lanes for issues). Testers have to be integrated to the process in a different way. A new support process with daily triaging and SLAs will push the team towards monitoring quality. Reporting on revenue from customer value delivered may motivate the team.
On the thinking front, individuals can end up in 2 places.
Neither of these help to achieve scale and get shit done. Most leaders lean on continuing to maintain hard boundaries and tinkering with process. These tend to have low yield.
Changing mindsets and how people think is the ultimate challenge for an organisation. Everyone has to be given a path to mentally transition from where they are to where they need to be.
…I am a frontend developer who had full autonomy to prototype and release a new UI patterns to production. Now that we are larger, customers need to have a consistent set of patterns to work with. This will help them navigate the product better. It is still important to innovate so I should discuss the new pattern with a designer to understand wider concerns. I should pitch my prototype as an opportunity to gather data on customer behavior. It will help us decide if we should deploy this pattern across the product to have wider impact than my single concern…
Elevating people who reflect the mindset required to achieve scale can help. Allowing them to take up leadership positions and making decisions can guide the rest of the organisation to see new thinking in action. It shift the organisational equilibrium quickly.
There is a lot more to changing processes and mindsets at a company. I’ve spent the last 5 years pushing for a new identity of “Maker” within Expedia to aid its transition. I hope to be writing about it more in the future.
For now, I hope these thoughts will help you scale your company better.