Ways of working is a commonly used term to describe how two parties will work harmoniously together to meet an agreed outcome. Defining ways of working is negotiating the intersection of cultures, processes and personalities which can result in a rainbow of different outcomes.
We often start our engagements with a discovery phase, usually, these are workshops, (my previous blog article helps paint a picture of our methods) or they could be one or two hours of conversation understanding your needs and what needs to be delivered before we start engineering.
Once the technical detail is agreed upon, we will discuss how to deliver the engineering, defining our ways of working. There is never a one-size-fits-all approach, it depends on company size, company values, preferences, time zones and ROI adjacencies like upskilling and knowledge transfer.
Tip 1: Identifying your ways of working needs
When defining ways of working it’s important to start with reflection. I have outlined some questions to reflect on, there is no right or wrong answer here, but it’s important to start to understand what information someone may need to know so they can collaborate with you.
What are your values/company values? What are your goals & aims for the collaboration? How do you like to learn? How do you like to receive feedback? How do you like to collaborate? What are your stressors and constraints that you need to mediate between?
Once you have a solid understanding of what others need to know about your style of working, it’s time to talk with your collaborator and agree on a path forward.
Ester Perel has a brilliant outlook on what is ‘I’ and what is ‘we’ as part of collaboration, her views are more aligned with personal relationships but her thoughts can be applied to business relationships too. This episode of her podcast helps elaborate further: In This Relationship What Is “I” and What is “We”?
The Scale Factory’s ways of working
We are a flexible, remote-first business. We encourage our consultants to be constantly learning and to prioritise their health and well-being. We offer development days (days for self-learning) to keep our skills sharp, and co-working events where we can come together and collaborate in person. Our consultants are supported by their managers and project managers, their planned absences are communicated up front and we collaborate to mitigate risks to any project velocity.
We also encourage feedback, defining ways of working with our clients is a temporary ‘merger’ of sorts, and with potentially different cultures we encourage open and honest communication to make sure we are aligned and if we aren’t aligned, diagnose effectively and agree on next steps that meet both companies’ needs.
Case study 1
Our first case study is taken from an engagement with an enterprise security SaaS business.
They were an established business that had mature processes, and legacy infrastructure and were transitioning through a period of change under a new revenue growth strategy. We hosted a workshop to find opportunities to reduce manual overhead, improve security (to help achieve their ISO 270001) and cost optimise their infrastructure.
We were able to amalgamate easily into their delivery rhythm: daily standups, written slack summaries and agile delivery ceremonies. However, we started to see tension and task priority conflict between the project objectives and the client engineering team. Our project managers with project leads started the diagnosis of the issues knowing that continued tension would derail the delivery timelines and affect the return on investment.
Through conversation and root cause analysis, we discovered that the infrastructure improvements were causing their engineering team anxiety. The improvements were going to affect how they work and potentially expose skill gaps. Our intention with every project is to collaborate and work alongside our clients, but we knew in this instance that we needed to increase our pairing and coaching opportunities to help the engineers own the incoming changes, become more familiar with the new technologies quicker, in hope of reducing their anxiety and the project tension.
We hosted show and tells, wrote documentation & facilitated pairing to help minimise the skill gaps over time as we delivered the outputs. These types of diagnosing conversations are challenging but necessary and reap huge benefits. By tweaking how we were collaborating each day our client didn’t need to further invest in training time and had upskilled engineers to take on the newly improved infrastructure.
Tip 2: Diagnose using the 7 whys
Diagnosing relationship issues can be a hairy topic. A simple but effective tool to help diagnose issues is using the 7 whys which is a technique to dig deep to the route cause of an issue. After you have described the issues, you can ask yourself ‘Why?’, and after each statement, you ask ‘Why?’ again.
We now know through diagnosing, we need to increase the communication of the value of our request and speak to our stakeholders, informing them of the velocity change, our diagnosis outcome and the solution proposal.
While this is a rather curated example, I hope this has helped you see how using the 7 whys can draw out the dependencies and nuances with relationships and most importantly encourages you to have the conversation.
Case Study 2
The second case study is taken from a startup in health technology. They had fluid processes, fledgling architecture and asked us to assess how they can continue to scale while maintaining strict health information security compliance.
After our workshop, we started the engineering to help establish best practices and get them moving on their path to growing their IT landscape. As their processes hadn’t been established yet, we owned on their behalf the backlog and delivery cycle which was agreed with them in our workshop. After a few weeks, we noticed small and frequent requirements changes were being made by different stakeholders.
Our team recognised the risks that these small and frequent changes posed to the schedule of work, the project lead collaborated with the founder to establish a process for technical change decisions to be made. We drew up a map of the stakeholders' roles and performed a RACI (responsible, accountable, consulted and informed) analysis, which helped provide the client with a process for requesting changes and helped funnel requirements to our team knowing due diligence had taken place beforehand.
In this case study we diagnosed with the client the need for more established guidelines to make technical design changes, these were incredibly important to understand who is accountable for what and the boundaries of everyone’s roles within the project. At the end of the project, the client had a new architecture landscape, established processes and defined roles to help make and manage change decisions in the future.
Tip 3: Knowing your role and the role of others
Human-to-human mapping can be a quick and handy tool to understand who within a collaboration you would need to interact with. It can be as simple as a table with names, roles/titles and vested interests in the collaboration. If it’s between two companies, you can ‘match’ individuals, the reason could be they have the same interests in the projects, and both might handle the relationship or finances. This can also be a great tool to know who your escalation paths for particular topics are, there’s nothing worse than something needing attention and fumbling to see who you should speak to.
It’s also worth being objective about your role and strengths within a project, what do you do in the project, won’t do, and what are your limits? Myself? I do not have a technical background, I lean on the expertise of our consultants to help translate the tech to business outcomes, while they lean on me for organisational and people support.
Working with others is often a trade-off, balanced on understanding your needs and the needs and expectations of others.
Interested in joining our team? We’re friendly and inclusive, so if you have the skills and experience, I hope you would consider applying regardless of your age, gender, sexuality, race or physical ability. The Scale Factory is hiring.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
