I believe in the engineering team using Cobol and Fortran ’77 (so much better than ’66) to develop the best modern websites. I believe in them using note cards and excel files and Jira and Trello to organize the Agile Product Backlog, and using nothing at all. I believe in the teams having a leader and having no leader. I believe in what the team wants to do.
While a bit tongue-in-cheek, I truly believe that a successful, innovative, and evolving organization must encourage its members to decide how they get the job done. Trust the team to find what works best to achieve their goals, which of course should be aligned with the company goals. The effective leader provides vision, values, and transparency. The leader must protect the team by setting up the metaphorical guardrails by the cliff’s edge, but between those guardrails create an open and fertile environment for the teams, who are professionals and most likely smarter than the leader (that’s why you hired them!), to do what they do best.
If you want to achieve the best, get out of their way and trust!
That said, how do we prevent the organization from falling into chaos where one team is using Clojure, another Haskel, another Go, another Agile, another Waterfall, ad-infinitum? If we allow that sort of chaos to ensue, the engineering team will have serious issues with business continuity (shoot, Bob the Cobol guy just left — who here knows Cobol, anyone, anyone, Bueller?), hiring, and maintainability. The other extreme, which large organizations often adopt, is a regimented approval process for all technology, down to the version level. Do you want to use Scala 2.11.7? Well, write up a report, submit to the engineering committee, POC, review, and 6 months later and dozens hours of your time, maybe get Scala on the restricted list. Maybe.
But there is a better way to do it and that is Managed Chaos.* Chaos can be detrimental, but if properly managed, it can be a powerful tool for an engineering organization to embrace innovation and drive the business forward through technology. When the engineering team comes to you asking to use Cobol, say, “Yes! I support you. But, I do have some questions. Where do you plan on finding Cobol engineers? What about mainframes? I don’t have any here. Also, can you build websites in Cobol? Didn’t know that. How will you leverage other teams to get the help you need since no one here knows Cobol?” If the team has justification and has reasoned out how this will drive the product and team, allow the chaos to happen. You have managed the chaos by asking the right questions, thinking things through, and aligning to the business and product. You have embraced change that can drive the business and product forward by giving your team control (e.g. the tech stack).
Create a great engineering environment by giving your team control.
What you really are trying to avoid is the “Oh, yeah, we should have thought of that” statement after the fact. For example, if our Data Science team wants to start using MongoDB and our Platform team wants to use Cassandra, that is totally fine if they have thought it through and discussed why each team needs to use a different no-sql databases. That is Managed Chaos. We don’t want to have the discussion 6-months after implementation and say, “I guess there is no reason we couldn’t have used the same.” That is just chaos.
Another example is from a recent decision by one of our Agile teams at TheLadders. Most teams are either singularly use either Jira or Trello. However, one team for our Professional website decided they want the Product Owner to create user stories in Jira and the Engineering Tasks be broken down and estimated in Trello. I was dubious — really, both? Isn’t that, well, chaotic? It isn’t. The team had thought though the complexity and determined it worked for both the product owner and engineers, and I’m happy to say they were right.
In conclusion, don’t be afraid of change, don’t be afraid of the decisions your team makes, and don’t be afraid of managed chaos.
* Managed Chaos is similar in concept to Fractal Organizations. Below is a great description from Pravir Malik on how a Fractal Organization works:
“In meta-theory all instances of organization, from the smallest, such as an idea or a person, to the largest, such as global markets and planet earth herself, are fractals: the essence of their way of being is repeated on scales both smaller and larger than themselves. There is however, a particular class of fractals, that of progress, of which The Fractal Ladder is an ever-present manifestation, which spawns organizations that are truly progressive and sustainable in nature. In the scheme of things this class of fractals is of critical importance, and to master its replication and to fully understand the impact it will have in creating sustainable and dynamic organizations is a practical necessity.”
Author: Geoffrey Bourne is the CEO and founder of Retirety, retirement planning for everyone.