If you’ve ever run a personality profile test, such as the controversial Myers-Briggs Type Indicator, across your software engineering population you might have guessed at the result, but did you ever stop to think about how that matches with a general population; or even more, stop to think about how that personality type deals with communicating with other parts of the population?
Well if you found that your software engineers were introverted, data junkies, with obsessive attention to detail then that would be no surprise, as this matches the demand of most software engineering jobs.
So imagine you are trying to be a good leader, using your enthusiastic, gut-feel for what is right, to champion the project while attempting to create a cohesive team by using your perception of their strengths and their perception of one another to identify the group, roles and organisation. Yep, you’re an alien!
Put software engineers in the room and, acting as proxy customer, give them a problem and they will a) not talk to you, but b) want more data, c) suggest solutions based on their own experience or domain and d) argue that theirs is the best solution, all without waiting for a complete description. Give them complete, structured, unambiguous data and an assurance of certainty and they will go off and generate a good implementation; leave anything undefined and you will need to revisit, to understand their assumption set!
Although they may make good abstract thinkers (there is not much physicality to a software engineer’s world) especially if they have been exposed to many and varied projects, they like concrete information, so not many make the jump to systems engineer.
The hardware (electronics) engineer may have a different domain, but can be very like the software engineer.
The systems engineer has to, at least initially, withhold judgement regards a solution, has to ensure that the description of the system is complete, analytically identify gaps and solicit information from the customer about system behaviour in those hidden corners. Yet at the same time, the system engineer has to be sufficiently expert in all possible solution domains to recognise the strengths or weaknesses of those solution domains whilst partitioning a problem with many competing attributes.
With an agile development, that ‘incompleteness’ can lead to significant refactoring, whilst in a traditional project the rigidity of the solution may cause the system to feel ‘brittle’ and ‘unforgiving’.
To manage software engineers you need to hide uncertainty and remove fear of rejection; Allow them to work productively on what is certain and structured and keep their gaze, and worry, from the incomplete; Introduce their ‘date’ at the other side of an interface and act as chaperone.
As far as programme management is concerned, the big problem is risk management. Asking a software engineer to risk-reduce a programme, by experimenting, and you’ll end up with an ostrich. Risk management tasks needs to have structured objectives with clearly defined scope.
___________________________________________________________________________
Let us help you maximise the business potential of your product and its software
Email me on stuart.jobbins@sofintsys.com
Visit our website, or follow us on your preferred Social Media for our latest views. 
___________________________________________________________________________