It’s International Women’s Day! Meet Lucy, a Software Engineer at Barbal

Amy and Lucy chatting on a web call

Today is International Women’s Day, to celebrate Barbal Knowledge Partner, Amy, is speaking to our newest recruit, Lucy Blatherwick. Lucy joined the dev team just before Christmas as a Software Engineer. 

What first attracted you to Barbal?

I’d say that the main thing that initially attracted me was the nature of the company and their purpose. Coming from a software background, the idea of version control is second nature to me, so it makes so much sense to pass the value that it brings on to users who wouldn’t normally have access to this kind of document support! I was also excited by the prospect of working within a smaller company – having come from a multi-national organisation I’m definitely finding working at Barbal to suit me better.

Can you tell me more about your role?

I’m a software engineer, and I work in the dev team with the other developers at Barbal to create our software. It’s definitely a collaborative process, identifying what the next steps are, and working together to build a really useful tool.

You’re working in a role, which is typically associated as male, how have you found it?

I do have a limited range of industry experiences to draw from, but I’d say that while there have been a few moments that I have felt it to potentially be a disadvantage in the past, my overall feeling is that the industry is definitely starting to shift from being heavily male dominated to something a little more balanced. At university, it was evident from the increase in the percentage of women on the Computer Science course in comparison with previous years, that computing and technology is beginning to attract more girls, and this will hopefully begin to filter through to industry as my cohort and younger grow into their careers. Of course, the ideal situation is not to have to even consider gender as a factor while in a profession, and I think we are beginning to approach that. I’ve definitely never felt that it impacts me at Barbal!

What advice would you give other women considering a career in Software Engineering?

Definitely go for it! Whether you’re considering a computer science degree at uni, thinking about giving software a go as a career, or want to get involved with new technology, it’s definitely worth it. There’s so much more to Computer science than just programming, and it opens up a new world of opportunities with so much variety and potential! Pretty much everything in the world around us has been influenced by computing, so you can apply what you learn in computer science to almost anything, whatever you love!

What changes would you like to see in the world to make it better for women?

While a lot of change has already taken place within the industry, there is always room for improvement, and it’s important that both individuals and organisations remember to keep striving for better. As a new cohort of young women begin to enter the industry it’s crucial to support and encourage them in their endeavours within technology. The alternative is to find that the industry loses women as fast as it gains them as they take their skills elsewhere. Equally, it’s also key not to reduce support for early opportunities in technology, and to keep engaging young girls with technology and STEM subjects more broadly to make sure that this change isn’t temporary.

Anything else you’d like to add?

It’s going to be exciting to see how software engineering diversifies, and how that affects how we work and what we make! And of course thanks Barbal for welcoming me onto the team!

Comparing document collaboration types: linear, real-time and concurrent

Drafting documents with others is one of the most important but stressful parts of many professionals’ roles. At a minimum any organisation with a quality management system will have a review process, where someone else will add comments or suggestions to drafts before approval. There are many scenarios where multiple people need to contribute to the same document because they have different fields of expertise or they have different viewpoints that need to be expressed.

Historically document collaboration meant circulating hard copies or disks and receiving comments or markups which someone would need to painstakingly combine. In recent years, many people have moved their document drafting to online methods.  These methods allow for quicker interaction between collaborators, whether that is using email, document management tools, or real-time tools.

Why different types of collaboration are necessary

Important documents are often drafted by teams of people who might have competing objectives for the document. In this instance, it can be beneficial to ensure that there is a clear process for controlling who can draft edits,  create safeguards to make sure unwanted errors aren’t introduced, and manage traceability of how decisions are made. 

Drafting an important document with multiple stakeholders is a consensus-building process. It’s more than just putting the right words in the right order; it requires expectation management, negotiation skills, and good communication. 

five people working at a desk on different devices

We created Barbal because we saw that people working on important documents don’t have the tools that let them collaborate efficiently. Different document editors promote different behaviours between collaborators and we wanted to make something that allows experts to do their jobs and negotiate faster.

A key aspect here is trust. Technical trust means can you trust someone not to make a mistake which can undermine the credibility of the document, this could be competence in drafting or expertise in the field. Even administrative tasks need to be undertaken by someone competent in the field, lest a seemingly minor error causes a major problem.

Another aspect of trust is the alignment of interests between the different parties to the collaboration. 

The concept of the “master document” is how trust is handled in collaboration. Who can edit the master document? Who is responsible for making sure the document is coherent overall? Who can approve changes?

In this article, we explore three different collaboration options available:

  • Linear
  • Real-time
  • Concurrent

Linear collaboration

Description

Linear collaboration involves a single master version of a document that is passed between stakeholders, usually via email, file sharers or a more sophisticated document management solution that allows check in/checkout . This creates a game of email tennis where it’s often unclear who’s holding the ball. A collaborator makes an edit and forwards the document as a file in an email, and another collaborator either revises or accepts the changes and emails the document back or along the chain. 

Great for

  • Personal documents which won’t be shared with others
  • Letters and correspondence
  • Essays and dissertations 
  • Documents where people different people work on distinct sections that can be stored as individual files
  • When only one person will be working on a draft at one time

Pitfalls

  • It is easy for changes to the document to get lost in translation due to a lack of version control and issues with comment tagging
  • High risk of human error when making edits
  • Security risk, as everyone who is sent the document has the master version controlling who has access can be problematic
  • Communication, as there is no real-time communication method with linear collaboration, those who should be involved in a direct line of communication can often get isolated. This can lead to edits made to the document getting overlooked

For large teams co-authoring the same document, linear collaboration is the opposite of a streamlined process. Collaborators spend more time sending emails, chasing feedback and searching for the most recent version of the document than actually working on the document. This leads to quality issues, delays and team member frustration. The entire process is fraught with distractions and complications which can make it stressful, turning experts into administrators, constraining their ability to do the best job they can.

Real time collaboration

Description

Real time collaboration involves multiple users  producing work on the same single document at the same time. Co-authors can make comments, suggest edits and revise documentation in a web application or collaborative software simultaneously in real time. 

Great for

  • Small teams working on informal documents
  • When there is small number of authors drafting in a linear manner
  • When there is a high level of trust between all collaborators
  • Idea generation and rapid iteration 
  • Documents that are drafted or reviewed during a meeting or workshop

Not suitable for

  • Teams with more than five members collaborating on one document
  • Complex documents
  • Asynchronous collaboration
  • When privacy is needed
  • Working with third parties

Real-time collaboration can be great for creative teams that need to collaborate synchronously. For example, when teams are brainstorming ideas and need complete visibility of each other’s work. However, when more than five people are working on the same document the process becomes painful as there is very little control. Co-authors can easily step on each other’s toes whilst making changes to work. This becomes particularly problematic when teams are working on complex documents or working with clients. With real-time collaboration, privacy and control are sacrificed, leading to a disorganised workflow. 

Concurrent collaboration (Barbal’s Solution)

Description

Concurrent collaboration involves co-authors working on their own copies of  the same document, where the editor automatically merges and disseminates updates between the collaborators. Unlike real time collaboration, co-authors have full control over their workflow; granting collaborators the ability to focus on their own work, draft in private and share their edits when they are ready. Everyone has access to the content relevant to them. Contributions are systematically reviewed before they are merged into the master document. 

Great for

  • Collaboration between distributed authoring and editing teams
  • Engagement with stakeholders throughout development
  • Maintaining a full audit trail of dialogue, decisions and justifications
  • Collaborating with clients or other parties
  • Progress monitoring and reporting
  • Accurate version control
  • Shared ownership of work
  • Instant communication between stakeholders

Not suitable for

  • Synchronous collaboration
  • Intense creative collaboration

Concurrent collaboration allows for decentralised(?)control over different sections of a document. Allowing stakeholders to concentrate on specific sections of a document without interfering directly with the master document. When authors are working on complex documents asynchronously, other co-authors having instant visibility can add unnecessary pressure. Concurrent collaboration supports individual team members working efficiently with each other without explicitly exposing their thought processes. 

Conclusion

Although both linear collaboration and real-time collaboration certainly have their respective advantages, when teams of over 5 members work on the same project their pitfalls can not be ignored, when compared to concurrent collaboration. When teams collaborate in real time the workflow can become abrupt and chaotic. When teams use linear collaboration the process becomes stagnant and unnecessarily time-consuming.

Barbal was created to bridge the gap between linear and real time collaboration by adopting a concurrent methodology. Incorporating a catalogue of all contract drafts, version control and comment flagging directly into the user interface. The software eliminates any security or privacy risks keeping a full audit trail of contributions and changes by all parties in one place without the need for any exterior tools. Barbal frees teams from needless admin and waste, ensuring business-critical documents get signed-off faster.