Believe what you want, it doesn’t mean you’re right
As a youngster in England in 1974, as far as I can remember, I wasn’t much interested in that year’s Health and Safety at Work etc. Act. In those days manufacturing and resource industries seemed to dominate the British economy, and the act’s long title seems aimed at the physical risks to health at that time:
An Act to make further provision for securing the health, safety and welfare of persons at work, for protecting others against risks to health or safety in connection with the activities of persons at work, for controlling the keeping and use and preventing the unlawful acquisition, possession and use of dangerous substances, and for controlling certain emissions into the atmosphere; to make further provision with respect to the employment medical advisory service; to amend the law relating to building regulations, and the Building (Scotland) Act 1959; and for connected purposes.
In the four decades since I’ve moved to another country and the nature of employment and its terms seem to have changed impressively. We’re told that the “job for life” has turned into the “gig economy” and we’ve seen manufacturing industries move from the rust belt and midlands to other countries and the manufacturing jobs be replaced by easier to outsource “knowledge economy” jobs which are easier to move than the people who do them. Businesses have changed from being staid purveyors of office/personal computers to organizations which might pitch an idea and culture to lure investors before they can break even.
Although my work has always been centred around computers I seem to have become less involved with the people whose lives are directly improved by the use of the computers I sold or the software I wrote. I’ve moved from selling hardware which private individuals used to solve their problems (for example Commodore Pets, and the great variety of 6502 and Z80 based personal computers which flourished before the “beige goo” of MS-DOS powered IBM-PCs and their compatible brethren), to writing code for small family companies, to writing code for factory floor measurement systems, to administering systems used by people developing code for other people, and so on until I’m writing code which runs in “the cloud” to support marketers who support salespeople to sell things to other people to do something with. The real user has become a more abstract idea, and that has driven me to search for satisfaction in the work itself.
The quality of my life has changed as time has passed. In my early jobs I could leave work at the end of the day, maybe have a pint with some of my coworkers if it was near the end of the week, and then go to my flat with no television, telephone, or computer so I could listen to music and sleep with no worries about work. These days TV, land line phone, mobile phone, and internet are available all day every day, and I’m breathlessly bombarded by the software developer “industry press” with news that I need to “level up” on the latest framework or development technique. I find it hard to avoid twinges that I ought to be working to keep up to date with “stuff”.
As I’ve moved from more physical work (handing over physical items, sweeping floors, producing tangible goods, pulling cables) to the “knowledge” work I’ve come to think that we need to extend the scope of health and safety. It seems to me that I’m more productive and inventive when I’m well rested, in an environment where it’s safe to make mistakes, and where it’s possible to work in a number of different ways depending on the task at hand. I think that health and safety should be extended beyond the physical realm to encompass the mental and emotional realms.
In my experience serious work is serious play, and I do best when I respect and trust the team around me. I feel that it takes time and effort to make the team jell. It seems to me that some of the things that can help creative software development teams jell are:
It is difficult for an “outsider” to see what’s happening in a team, as the team’s output can be influenced by much more than the number of people on the team and their technical skill levels. Once a team has jelled (a performing team in the Tuckman model) then the members have made many explicit and implicit agreements which allow them to perform well in a particular context. Adding or removing team members disrupts its dynamic and shouldn’t be attempted lightly; the team should be involved in the new member’s selection and the timing of changes.
If the team are all co-located then they should have an identifiable space which can be theirs in terms of decoration, arrangement, and rhythm of work. This helps foster identity as well as providing the conditions where teams can expose vulnerabilities in a safe context (which is when I think the real work of team formation happens.) I have yet to work successfully on a distributed team, but my experience of mixed co-located/remote teams is that it’s all to easy to unintentionally exclude the remote people from socially important interactions.
It seems that managing a knowledge team is radically different from managing a team producing something to a recipe. A creative team operates in partnership with management, and needs space to make mistakes. Both groups need to share a vision of the direction to take, and both need to share an understanding of why the direction is important. Many industrial era management techniques (appraisals, bonuses, etc.) actively militate against an effective and motivated team forming, so there has to be open communication between the groups.
A stable vision helps the team stay aligned with the company’s direction. As long as the goals are coherent with the vision then the team can grasp why they’re worth striving for. For me this is what drives me to turn up and do the best I can even when there are mundane things to be done — they are the necessary foundations and maintenance which lets us build toward the meaningful vision.
To me the ideal software development team is a tightly-knit group with a unity of purpose and vision who are working to make a step towards realising the company’s vision. Teams have a big say in their constitution and they can dissolve after a project is done. The effectiveness of the team doesn’t just come from its membership, it also comes from the context of the work, so it’s natural to change the constitution of a team when we transition between projects.
I don’t believe you can manage the social side of team formation with the same precision as a construction project. I prefer the analogy of gardening to engineering when dealing with the personal dynamics in an organization, and my conclusion is that the best a manager can do is provide the best environment for teams to form, and be prepared to change the environment if the teams don’t thrive. A good gardener knows lots of principles and rules of thumb, yet is alert to what’s really happening; they’re working to a multi-year plan that has to accommodate the vagaries of weather and individual plants as well as all their interactions.
One way to provide a rich environment is to protect all the team members’ mental and emotional health and safety in the workplace. If all members of a team feel safe and are able to contribute then the odds of the team jelling have improved considerably. That seems like a good start to me.