Psychology for IT pros

Conway's Law states that "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." It was first posited by Melvin Conway in the 1960s, and it's a hard constraint on software, networks, and other formal technical systems. What it says is that code is generated by human systems, and these limit how it will work. All software contains the same patterns and relationships that exist within the social systems of the organisation that created it. There's now good empirical support for the hypothesis, too with a paper published the Harvard Business Review finding that closed-source software produced in a single location tends towards a single, monolithic codebase, whereas distributed open-source projects tend towards modularity. Large organisations typically have support structures around those actually producing code or designing systems. There's management, proce

I recently had a very interesting discussion with Andy Davis of Venturi  about the role of technology in Higher Education and its effects on students, staff, and on the challenges the sector faces. Do check it out, particularly if you work in education or the third sector.

We're going to be launching a podcast over the next few weeks. The plan is to include interviews and some listener questions. If you've got any work-related dilemmas, comments about previous posts or psychology queries in general, drop me a line at matthew@psychfor.it and I'll do my best to answer them. If you want to send me a recording the please do, but there's no need to appear on the show, and you can be anonymous if you like. I'm also looking for interviewees who might be interested in appearing on the show. If you have a particular interest in IT and psychology, or have done some research in the area, then get in touch and we can arrange a phone interview.

In the past few posts I've covered quite a few potential sources of dissatisfaction at work. You might have found yourself in a job which sits poorly with your personal identity , or you may have found yourself in a workplace which lacks sufficient trust . This post is focused on some methods with a good psychological backing to help you change yourself so you can get closer to the things you want. I'm focusing on self-change here as it's perhaps the most fundamental thing you can do to address an unhappy situation, and has the most profound effects. There's a lot of resonance in this topic for me personally, and this blog is a part of my own change process. First, I'm going to discuss approaches that make change more likely, then I'll move on to techniques for determining what kind of positive change you really want to make. Making change more likely Much like actively designing a computer system is far better than letting circumstance design it for you, pla

Trust is one of those things, like air, that people only tend to notice by its absence, It's vital for personal relationships and for business to function. This post explores the role of trust in IT and at work, and what can be done if it is lost. Trust and computers One of the things that makes IT interesting is the requirement to formalise things that are only loosely defined in everyday life. The most obvious example of this is programming; the act of telling a computer, in a human-readable language, exactly what it is you'd like it to do. IT also requires that trust be formalised, particularly in the sense of being able to trust a person is who they say they are. The human capacity for recognising other people is huge, and surprisingly flexible. We can recognise people from the appearance of their face, their voice, and even from their gait, in very different circumstances to that which we've seen them before. We take for granted that we can successfully identify

"There's no 'I' in team" is one of my most despised business cliches. In this post, I'm going to look at two words also beginning with "i" to explain why it's such an awful saying; incentives and identity. If, like me, you've heard that phrase and felt oddly queasy, then this post might go so way to explaining why. Typically, organisations tend to use "incentives" to mean job-related perks, like financial rewards for hitting targets or free access to gyms. These incentive schemes are all about giving the individual employee a reason to behave in a certain, narrow way. All are doomed to fail . Whilst these schemes might give a quick boost to some metrics, the way they distort business process makes them more expensive than the value they create. Worse, incentive schemes like this are inherently anti-lean. I'm going to write more on lean process, and its benefits from a psychological perspective, in a future post, but for now