Skip to main content

Addressing scepticism

Trying to convince your organisation's management team to do things such as eliminating estimates and deadlines may seem out of touch with reality. My problem with this reaction is that I have experienced first-hand what it is like to work under these principles.

True leadership​

While I was a Microsoft MVP, I had the honour to spend a little bit of time with Anders Hejlsberg, Daniel Rosenwasser and other members of their team. I witnessed what happens when a product team tick all the boxes: True leadership, trust, clear goals and strategy, product-led, customer-centric, pragmatic engineering approach that sees technology as a tool, not a goal. The key realisation I had while observing the TypeScript team at work was that having a clear mission, vision, and strategy was extremely powerful, so powerful that as long as you had it, you almost didn't need any project management overhead. All the members of the team were aligned like a high-precision laser. It was made up of missionaries, not mercenaries. This level of alignment is rare and is only achievable by true leadership. I also witnessed master levels of customer-centric and balancing technical debt with delivering customer value.

To be 100% fair, I must disclose that the TypeScript team operates under a Scrum-like methodology and have a quarterly release cadence. However, their version of Scrum was supercharged by the best parts of Lean UX, DevOps and product-led growth. The team performs nightly beta releases, high amounts of user research, and direct conversations with customers. The team also has a quarterly release cadence, but it didn't feel like a deadline because, by the time the release date was reached, the team had already mitigated 99.99999% of all potential risks.

Open-source​

My open-source project (InversifyJS) had the following characteristics:

  • Clear vision
  • Transparency
  • Trust
  • Open collaboration with customers
  • High autonomy (100% remote, async work, documentation)
  • Organic release cadence
  • No sprints (No estimates, No meetings, No time boxes)
  • Deep customer understanding (for developers by developers)
  • One team (there are no divisions or departments)
  • High code quality
  • High automation

The preceding should not be a surprise, as this is how most open-source projects operate.

While working on InversifyJS, I experimented with the power of some of these ideas first-hand:

  • Lean UX: I was in direct contact with my customers; I had to deal with support queries, create documentation to facilitate onboarding, and discuss feature requests. Whenever a new feature request arrived, instead of thinking about the implementation complexities, the first question that I used to ask myself was: What would be the best possible developer experience for this feature? I would design the API to delight customers and ask them for feedback on GitHub issues.

  • The three ways: If the feedback was positive, I implemented a few unit tests that invoked the yet-to-be-implemented API. As expected, the tests failed. Then I proceeded to implement the feature. As soon as the tests passed, I released a new version of InversifyJS. The code had 100% test coverage, and I could change the code with a very high confidence level. Sometimes I was able to deliver a feature that was requested just a few hours before.

  • Clear vision and pragmatism: Sometimes, feature requests were super smart and easy to implement. I often asked myself: How did I not think about that before? Sometimes the features were good, but they added too much complexity. I learned to say no to my customers, that listening to customers and being reactive are different things, and that we need to listen to our customer's problems but not so much to our customer's solutions. I learned that vision and strategy are not just about what is OK but also what is not OK.

Today InversifyJS has over 100M downloads on npm and seeing my customer's delight was the most fulfilling professional experience of my career to date. At that point, I realised how much we miss when we are not part of a high-performance team.

Being part of a high-performance team doesn't mean being in a group under a lot of pressure; it means being in a team that is highly motivated to achieve a goal as a team. It means being part of a winning team. Being part of a winning team can feel very good. Winning can bring a sense of accomplishment, pride, and a positive self-image. It can also boost morale and increase motivation as team members work together towards a common goal. In a winning team, everyone's contributions are valued, and everyone feels a sense of ownership and responsibility for the team's success. This can lead to a strong sense of unity and a shared sense of purpose. Being part of a winning team can have a positive impact on an individual's well-being and can help to foster a sense of community and belonging.