I think we have silo busting all wrong. Well… partially wrong. I recall a story about a university campus. When buildings were put up on campus, there was a deliberate choice to not build any sidewalks or walk paths. Students, staff and faculty moved freely from building to building and over time, paths were worn into the ground where people had walked. The worn paths were the natural walking routes between buildings. Sidewalks were built on the beaten paths.
The usual approach to sidewalks and walk paths is to make straight lines, usually perpendicular or parallel to buildings. They look nice, neat and organized. But they are often not the way people choose to walk from point A to point B. Traditional organization design creates a neat, easy to understand model of how things should work. When it doesn’t work, we re-organize in the hope we are busting a silo. What happens instead is that we create a new silo. Silos are impossible to avoid. We trade one for another.
If instead, we could focus on the paths, we might have a chance of finding something better. In large knowledge-worker enterprises, the flow of information is the real organization. The rules and policies and containers we build are often not respected when something just has to get done. We use our network of trusted colleagues who have access to the right levers and information. When designing an organization, think about the flow of information. Go out into the organization and look for the beaten information paths. Find the “natural networks”, the ones that actually get things done and reinforce them. The challenge is to reinforce them without inhibiting natural change, or without constraining them.
A great TED talk on how we are losing our listening…
Particularly interesting for me was the part on filters that we apply when we listen. In a world where we we are increasingly broadcasting, Julian Treasure reminds us of the importance of listening, and shares five tools for improving our listening. Enjoy.
AgileTour is fast approaching. The tour is made up of one-day events in cities around the world. There is likely an AgileTour near you. You can find out about the different events here. This year I will be speaking at AgileTour in RTP, near Raleigh, NC. My topic is the Trajectory of Change. This year’s speaker’s line-up is awesome and I am privileged to be among this group of professionals. The RTP AgileTour can be found at: www.takebackthepark.com. Check out the Tour and take part!
Creating great software is a lot like creating great music. Both require skill, practice, and technical knowledge. Both require creative thinking, collaboration and involve good judgment. Both have an end-customer. Both have a user-experience.
As software professionals we have deadlines. So do musicians. I think about being in a studio, engineer behind the console, producer on the clock, and you gotta create. Pressure… You often hear about the emotional war that takes place between band members, in many respects similar to what software teams go through. You want to add that great new riff you invented, and you search for a place to insert it but sometimes, you just have to save it for another day because it adds weight without value. Similarly, code bloat also occurs because a team member wants to make something cool happen in the code that does not add value. We often hear the words that musicians should “check their egos at the door”. This was made famous by Bob Geldof during Band Aid, the huge Ethiopian famine relief benefit. Bob insisted that the event was not about the musicians, but about helping those in need. As software professionals we can all take a page from that book. Set our egos aside. Create something of value for our customers. Celebrate the success together. Learn from our experience and make the next one even better.
Some of the takeaways and questions I found relevant are:
Organizations often build short-lived project teams that disband at the end of a project. Is there a way to minimize team churn in this environment? Is it is possible to build cross-functional feature teams that can persist over multiple feature deliveries?
Sometimes the need for a specific skill is not required for the life of a project. Some expertise is required to deliver IPSec for example, but the individual with this knowledge could work with multiple teams. How do you enable the skills transfer to multiple people so that no one individual has to be involved with more than 1 or 2 teams?
Will your team structure minimize communication paths and enable communication between technical experts who would otherwise not communicate together?
Does the team structure make accountability clear?
Creating these teams implies the building of redundant skills and overlap. This helps to create teams with no single point of failure–a necessity for business continuity. Doing so may feel inefficient. The value is reduced project risk, smoother flow, better throughput, and happier teams. If you are forced later to move team members between projects, the redundancy you build in gives you added flexibility and agility.
Creating teams is not just about maximizing short-term value for the project. It is about balancing the short-term needs of the business while building in long-term flexibility and resiliency of the teams and their capabilities to support the goals of your business. Don’t think of this as a trade-off. Think of this as an integrative process that gives you the best of both worlds over time.