At Blue Stingray, we don’t devote work time to traditional product development.
Work-for-hire or contract software development agencies like Blue Stingray have unique problems to solve. When a team develops a single software product, they can rally around a common vision or set of goals. At work for hire agencies, a relatively large number of projects are spread across a team of developers. Each developer is tasked with understanding and working with multiple projects. These are projects developed for different technologies, often in different industries, with different clients — focused on different goals.
Stack on the complexity of the work-from-home model — a model that most companies have been forced to incorporate — and you have a really interesting problem.
In an environment like this, communication needs to be constant and clear.
A New Role
The word “manager” isn’t exactly celebrated in the Blue Stingray office.
I’m talking about titles like project managers, engineering managers, and people managers. We’ve avoided those titles because they haven’t felt right; there isn’t anyone in the office performing the actions of a traditional manager (or, at least, not a manager that you would see in a Fortune 500 office). We’ve always considered “managers” to be support roles, so if they are supporting the teams, then what exactly were they managing?
Instead, we saw that the people who would be called managers in other countries had one overarching responsibility: They were a communication liaison between teams, clients, and vendors. With that in mind, we’re introducing the idea of a Project Communicator to our company structure.
Each Project Communicator will be the glue between everyone involved with a project. They will listen to everyone, learn about projects, and make sure the right people have the right information. Ideally, a specific role like this will lessen the burden for updates and meetings while lowering the risk of miscommunication across a complex set of projects at any given moment.
Approach to Team Structure
In one way or another, Blue Stingray has followed the guiding principles of agile software development. We have never subscribed to a single methodology, but we’ve pulled bits and pieces from all over. We’ve adopted ideas like Squads, developed at Spotify, with each independent team developing processes that work best for them. We host a weekly Tactical Meeting over a daily stand-up, a concept first implemented by Holacracy. Each project has a product owner — an innovation developed byScrum — and we follow Continuous Integration, made popular by Kent Beck with XP, along with Continuous Improvement, first used by Toyota nearly 100 years ago.
Naturally, Blue Stingray wanted a flexible team structure.
With the large number of projects flowing through our company, one large team was an impractical goal. Instead, we have two development teams, each with 4-7 team members.
Each Project Communicator at Blue Stingray is focused on a few high-level goals:
- Providing the development team with the correct information so that they can work on the highest priority tasks that bring the most value to the customers.
- Providing customers with a clear understanding and reasonable expectations for the project.
- Making leadership aware of the most important aspects of each project, risks to the overall business, and potential for high-level improvements to better support the development teams.
At the end of the day, the Project Communicators are the maintainers of transparency. They are the people who spend their time developing an understanding of everything going on within the organizations and clearly communicating that information to keep each function of the business on the same page.
Methods and Tools
How do Project Communicators get things done? Here are some of the tools they use:
However, written updates from each team lead are extremely useful. Updates allow the team leads to get work done on their own schedules. An enforced meeting at a certain time of day — or a certain day of the week — can disrupt the development team substantially. Instead, if team members write a thorough, thoughtful update — whether that update arrives at 1 p.m. or 10 p.m. — the Project Communicator has the information they need to do their job.
Along with protecting the autonomy of the development team, written updates also create documentation. Keeping written project updates over the course of the project can help onboard new team members and cut down on even more meetings and questions (“I know I asked you this last week, but what did we decide on for XYZ?”).
Since replacing a daily stand-up with a weekly Tactical Meeting at Blue Stingray, we transitioned to doing written stand-up style discussions in a Slack channel every morning. Each team member, on their own time, takes a few minutes to write down what they are focusing on for the day and whether they need help. This is another great written update tool that the Project Communicator can review daily to keep up with the project.
Routine Client Check-Ins
Outside of project updates, clients do not typically have a dedicated forum for voicing high-level thoughts and opinions. Yes, you will get emails about problems, but those are pretty focused and typically revolve around specific tasks. For many contract agencies, the clients aren’t included in the majority of project planning or project retrospectives. I believe that many businesses have an imposter syndrome — fear of letting clients peek too far into the inner workings of the business. We fear what they might think.
A great first step is a routine check-in with every client. The Blue Stingray Project Communicators take clients out to lunch at least a few times each year to simply listen to them. This is a meeting specifically for discussing potential organizational improvements and how to improve the collaboration. The customer has a second to take a breath and shake themselves out of the routine task management work that they typically do with the development teams week to week.
There are probably 100 “goal-setting” frameworks out there. I’m not going to get into the specifics of how those systems are used, but I will focus on the reason why those systems exist.
One of the core pillars of building a happy, efficient, and stable development team is understanding the motivations of your people. Each person is unique. For most of the history of software development, companies have treated programmers like machines in an assembly line. Projects like Peopleware, Project Oxygen, and Project Aristotle have opposed these ideas and have proven that they don’t work. You cannot treat software developers like indistinguishable parts if you want to maximize efficacy with minimal turnover.
Working together with each individual to set goals is one way for the Project Communicator to learn more about individual motivations, relay that to the right people, vouch for the teams, and ultimately help build a better overall environment for each team member.
This role requires getting into the trenches. Project Communicators at Blue Stingray are not always technical, even though some are, but being heavily involved with the day-to-day work is important.
Every project is different and every Project Communicator is different, but participation may look like this:
- Reading, writing, and reviewing requirements. Getting a feel for what type of work is being done. Where is the project heading functionally? Are these things going to bring the most value to the customer?
- Attending technical development meetings. Understanding how technical product development affects all other parts of the business is important. This allows for the ability to communicate risk, delays, etc.
- Meetings with end-users to gather feedback. It’s all about the customer. Again, are we bringing value to the customer? There’s no better way to figure that out than to meet with the people for whom we are trying to bring value.
- Attending weekly project update phone calls. Along with the routine check-in style meetings, there is typically a more tactical weekly or bi-weekly update meeting. This is another method for producing a quick feedback loop, and it’s vital for the Project Communicator to be part of that feedback loop. The team gets together with the client to collaborate on priorities, direction, requirements, and progress updates.
While the specific tasks may change, as long as Project Communicators are staying involved to develop a complete understanding of each project, they’re on the right track.
At Blue Stingray today, there are three employees that are performing all of or components of the Project Communicator role. We’ve always had someone doing some or all of these things, but this is the first time we’ve clearly defined a role for it.
As with everything that happens at Blue Stingray, there’s a passion for continuous improvement. There will be small improvements to these processes, tools, and responsibilities over time.
We are excited about the new change and for the improvements to come.