Not all software roles are created equal. Seems pretty obvious when you say it, but if you read comments on social media, blog posts and even the general conversation around the industry, you'd be forgiven for believing that product companies or start-ups represented - to a greater or lesser extent - the entire operating culture of information technology. Clearly - things are never that simple.
Whether you refer to companies that build software or solutions for external clients as a "consultancy", "professional services vendor" or some variation thereof, the nature of how those organisations manage their people and deliver their work is inescapably different to that of a business concerned with a single offering or focussed on a single market segment.
The nature of the product or service a company produces has a direct relationship with the types of business metrics and priorities that must be focussed on for that business to succeed. A product shop (e.g. Raygun, Timely, Sharesies) will be driven by shipping features as quickly as possible that respond to their customers' needs and therefore drive more sales of their product. By contrast, a professional services vendor will look to identify new customers with a business technology need (or a new need at an existing customer) and sell solutions that satisfy that need.
Both organisation types have software developers; both seek to grow their revenues within the business. But one generates value internally from innovation and efficiency gains it invests in; the other generates value from the volume of work it captures externally from businesses seeking to invest in technology through the skills and expertise of a professional services vendor. An external business is less concerned with how innovative a solution is than it is with how efficiently or cost-effectively a solution can be delivered that returns a certain added value (obviously innovation will be a factor to some extent, but this will not be the core drive in most cases).
Why is this distinction important? It's all software after all, so what difference does it make where the software's being written?
The language used predominantly to describe the software industry generally - from its challenges to its tool sets, workflows and, of course, team and culture structures - leans very strongly toward the form of a product shop: "shipping", "sprints", or "fail fast and break things". The language of a consultancy, on the other hand, looks for "value", "chargeable" or "service level". As with any social structure, knowledge work being no exception, the language in use within that structure influences the culture of the people within it. The ingredients of the interactions we have when we communicate with our end users / customers and each other include pitfalls and nuance that we often don't recognise or don't unpick.
Recognising these cultural differences between types of development teams is important because it's too easy to become demotivated, disorganised or myopic in how we structure and lead those teams. It's an unfortunate irony that, as software specialists, we can recognise when code can afford to be refactored and improved but the same can rarely be said for teams, even though there are many parallels.
Whether it's as a start-up or a consultancy, one of the most important tasks people can undertake as leaders is curating a strong dynamic. Teams don't just happen: you can pool a group of people together and call them a "team" but it's also a very safe bet that you won't see any actual "teamwork" on week one and unless there is space and time devoted to allowing the members to test out ideas, communicate and recognise and adapt to mistakes, the team won't truly function as an effective, collaborative and gelled unit regardless of how much process and management is imposed.
In a professional services organisation, it can be very easy to look at the conversations on social media or in blog / news articles about "failing fast", "shipping" or "features" and feel that the development world is leaving you behind while you're at the mercy of clients who are much more selective about how they invest in their solution. This is considerably more true when in a development support / operations role and you're still working on solutions that are several years old and across a range of outdated technologies. One conversation that I remember in particular was when a developer said "I'd quit rather than do support. I want to do real development!". There was an implicit cultural hierarchy in this person's mind where certain skills were more worthwhile or respectable than others.
On the other hand, product companies can face considerable pressure to deliver new features quickly, ensure they're constantly innovating, expect long hours - especially if a deployment breaks production and of course cost pressures in relation to revenue growth. They're working on the same product the entire time and this may create its own challenges around team training, exploration and personal growth.
So different businesses have different cultural heritage. So what? That surely isn't news any more than different phone companies have a different culture or different schools.
There are a couple of points that I believe go largely unnoticed. The first is that it's important to recognise the constraints that professional services vendors are under with regard to the way in which they're enabled to adapt to "best practice" methods and tools used by product shops. Typically, established clients who've been with their company for some years will not be willing to invest heavily in restructuring their solutions to accommodate the latest approaches. This can lead to tension, frustration or resentment when people in support development roles or long-running projects can see better ways to do things but are prevented from being exposed to them.
Identifying and responding to these needs such that people are empowered to implement gradual improvements or changes as the opportunities arise leads to better sharing of knowledge, skills growth and higher engagement from staff. Look at your shared goal and support improvements that contribute to it.
The other point here is that it's important to recognise the needs of the team and listen to - and recognise - the language being used and the dynamic of the team. From there, it's also incredibly important to empower that team to safely change that environment for the better. The word "safe" is very important in this context. To ensure you understand what frustrations or obstacles are holding back the team's potential success, it's important to actively remove barriers that make it uncomfortable for people to have open and honest conversations about the team’s sensitive issues.
Just like refactoring code, a team should be cultivated in such a way that you are contributing to its growth and leaving its people and the team's cohesiveness in better shape than you found it. Unless you are measuring the actual dynamics of the team; as distinct from measuring individual performance (or for that matter, the team's Key Performance Indicators, which are usually financial in origin), then it's impossible to fully appreciate where to focus effort on enablement and encouragement.
All of this is important because the team culture is a direct input for productivity, information sharing and quality of outputs. There is a cost that can be attributed to all these things - and that's before accounting for potential costs in disengaged team members or resignations. Understanding a team's cultural needs and recognising where gaps or constraints lie informs decisions around training, quality, work flows and a raft of other organisational goals. The conditions under which a team is empowered to perform directly relates to better decisions for all stakeholders within the organisation.
Those decisions are informed from the language the team works with, the signals being sent from within the organisation and the messages being picked up from outside the organisation. Listening to, and analysing those messages; their language and the interactions between them informs the responses that drive the self and system esteem within the team and through that, translates to the productivity, engagement and profitability of the business.
This post is one in an occasional series on team dynamics, training, culture and leadership.