Beyond Skills: Exploring the impact of personality on project delivery
An exploration on different styles of working and their influence over shipping timelines
Ever wonder if personality traits influence project delivery speed?
In this episode, we're joined by Joanna Jachuła, a seasoned product manager with ten years of industry experience. Joanna brings invaluable insights into the dynamics of project delivery, from coordinating products for lead generation agencies to optimizing user flows and adoption strategies.
Join us as we explore the Cathedral and Bazaar theory, dissecting contrasting styles of software development. Through practical examples and actionable strategies, we uncover how identifying and leveraging these work styles can expedite project delivery and minimize delays. From breaking tasks into manageable chunks to fostering collaboration, Joanna shares insights to enhance team performance and drive project success.
Joanna:
Behind every product, there are individuals with varying skills, motivations, and approaches. Additionally, the development team may be at different stages of collaboration maturity and efficiency, which can affect the development speed. Equally important is the understanding of connections, in-product mechanics, code complexity, and why certain parts work as they do. Therefore, one project may be completed on time with one team and be delayed with another team of similar skills and size.
As you work with the group for a longer period, you gain a better understanding of the team dynamics. However, in some cases, particularly in startups, there may not be enough time to refine team performance over the years. In such situations, you can use techniques and frameworks to expedite the learning process and accelerate product delivery. One theory that has emerged and evolved in software development is the Cathedral and Bazaar theory.
Cathedral and Bazaar theory
Eric S. Raymond's essay 'The Cathedral and the Bazaar' compared the development of commercial solutions with that of open-source Linux. While commercial software was developed like a cathedral - meticulously crafted and released only when fully ready, the Bazaar style advocated for releasing early and often, and delegating tasks whenever possible. In many ways, it is similar to the differentiation between waterfall and agile methodologies. Raymond found great value in the Bazaar style, especially when coordinators could identify good ideas from others. However, he stressed that high-quality development fundamentals are also required to benefit from this approach fully.
The theory was initially perceived as a comprehensive approach to development as a whole. However, it was later observed that individual developers also tend to align more closely with one of these styles during their work. This observation can be applied to every team member.
The startup era is characterized by the development of minimal viable products, frequent pivots, and rapid achievement of product-market fit (in an ideal world, at least). This reinforces the Bazaar style and agile methodologies. Small businesses focus on solving a specific, pressing problem and acquiring initial clients, adding nice-to-have features later or utilizing ready-to-use solutions. In this environment, fast shipping is crucial. From my experience with startups, individuals who join them operate in rapidly changing environments and accelerate their learning by making mistakes quickly, drawing conclusions, and improving even faster. That is why people who can deal with good enough, but not perfect solutions, are so desired in startups. However, as the business and product scale up, both of these work styles bring significant value to the project. It is important to utilize the strengths of both styles and address their weaknesses promptly. This enables you to deliver products that are both efficient and polished.
Theory aside, how does it actually work?
Here is an example of how theory has become a reality. Like many product managers, I have faced the challenge of a few projects being released on time. Delays often ranged between 40-60% of the expected release time, which is painful. This aspect of my work was particularly frustrating, and I was eager to change it.
I started to look at how we worked, actively attending every meeting and trying to find ways to improve efficiency. The Cathedral and Bazaar theory, which I learned about, was a game changer. I then searched for patterns in the daily work of different team members. The table below summarises signals that may help you identify which style is closer to the developers you are working with.
While it may be difficult to change the working styles of individuals, it is possible to work with team members to find a middle ground in the long term. In the short term, product managers can assign tasks to team members based on their strengths and the benefits of each style.
The Cathedral style team members are most valuable to the project when they are:
They're not under time pressure. Their great ability to see the big picture and choose the best solution after analyzing different cases takes time, but the results can provide a complete and stable solution. Therefore, the more independent part of the system they work on, the better. The fewer dependencies for other developers who need that part immediately, the better.
The part of the system they are working on is high risk and you want to be sure that it has been thought through from many angles. Their scrutiny in handling edge cases is crucial when dealing with security projects such as a payment solution or a part of the system with sensitive data.
They will be code reviewers of their Bazaar colleagues in the critical tasks.
On the other hand, the people working in the Bazaar style bring the most value to the project when:
It’s crucial that this part of the system has to be delivered as soon as possible and perfection is not so needed in this part. It might be proof of concept, that will be expanded later;
There is no detailed UI design. As they are comfortable with improvising, the details of the design might be polished later. A good example might be a task opening a bigger project when more developers waiting for it to start their assignments;
An important bug has been discovered in the working system and needs to be fixed as soon as possible.
Core principles for working together
In a perfect world, the Cathedral developers wouldn't be assigned the time-critical tasks and the Bazaar developers wouldn't be assigned the detail-critical tasks. In the real world, however, this is almost impossible, and it's good to know how to deal with it. Let me share some tips.
When working with Cathedral style:
break the big tasks into smaller ones with clear and detailed scopes. This way they will be aware of the total scope and won't feel overwhelmed thinking about every possible corner case. It is good practice to include in the task information about what is not in the scope of the task;
often ask for the bottleneck, especially if the tasks last much longer than it supposed to;
if there are several possible solutions, let the developer explore them, note the pros and cons, and choose the right one together.
When working with Bazaar style:
break the big tasks into smaller ones to avoid missing important points;
discuss the possible edge cases and decide which need to be addressed in the MVP;
establish and emphasise a culture of code ownership. Typically, QA doesn't check low-risk tasks, so developers have to double-check that everything works correctly.
Implementing these strategies has enabled me to minimize or even eliminate project delays in the past. The team was more motivated when they saw that we could predict and deliver the solution in the time we had agreed. Putting the Cathedral and Bazaar theory into practice wasn't the only improvement we made to the projects, but I think it had a big impact and I'm keen to continue using it in future projects. The benefits to the business as a whole are obvious - it's easier to plan marketing, sales and customer success activities when the product team delivers to a predictable schedule.
Lessons learned
Recognizing the working style of each individual in the team is crucial. This will allow you to better manage the resources you have. If you have a whole team of people who work in the Cathedral style, it's great for projects where details matter. On the other hand, Bazaar people will feel like a fish in water when they are developing the MVPs.
Defining the exact scope of each task (what is included and what is excluded) helps the whole team to be on the same page. It's much better to spend more time refining the backlog than to find out later that different developers have different understandings of the scope.
Breaking down tasks into smaller pieces works for both developmental styles. What's more, breaking tasks into smaller pieces also maintains motivation in the psychological dimension. Developers also succumb to the theory of instant gratification, which means that they seek immediate rewards or pleasure rather than long-term benefits. Completing a few smaller tasks every two to three days is better than completing one larger task at the end of the sprint.
Key Takeaways - Wiktor
Joanna's insights go beyond software development, offering practical strategies for project management in any field. From breaking tasks into smaller pieces for focus to matching team members' styles with project needs. Here are me key takeaways and thoughts:
Although Joanna focuses on developer working styles in her essay, the approach seems universal and can be extended to other professions such as marketing, design, QA and so on.
No matter who you work with it seems to be universal that breaking down bigger project into smaller pieces makes the deliverables more focused on the goal you want to achieve
If you want to move fast, put Bazaar style person in charge. If your challenge is „rocket science”, then Cathedral style should take the lead
You want the Baazar style individuals if you are in PMF search stage, but the bigger and more mature your company is, you should balance them with Cathedral style
In most startup environments it’s the Baazar style that is favored
When Bazaar and Cathedral style individuals collaborate effectively, they can leverage each other's strengths and compensate for weaknesses, leading to enhanced creativity, productivity, and problem-solving capabilities
By aligning tasks with individual competencies and motivations, you can optimize resource utilization, minimize bottlenecks, and enhance overall project performance
If you want to hear more from Joanna, she recently started her own Substack, so be sure to subscribe!
Recent findings:
AI Search Engine for Research - Consensus
For PMs to improve writing PRDs - ChatPRD
Advancing career in AI world - Unsolicited Feedback Podcast
A guide to measuring the right data - FishmanAF Newsletter
If you are reading this, you are either very kind or you really liked this episode. Either way, thank you!
I’m interested in hearing from you - if you have any feedback, please respond to this email or hit me up on LinkedIn.
P.S. If you have an interesting case you'd like to share - contact me.
 | A guest post by
|