Monday, 17 August 2015

The Engineer's Drive

Engineers are driven by the quest for the right answer. This can manifest itself in the ability to work long hours, sacrificing social life, hygiene and diet for this quest. Tech upstarts like Google, Facebook and Microsoft have been able to take advantage of this drive to change the world. But a forceful corporate culture can turn this drive ugly, into an Amazonian environment. Perhaps this is best for the company bottom line in the short term. But you'll have to get used to managing a constant stream of fresh meat for the grinder, instead of building relationships with your team.

Any good engineer with meaningful work will be self-motivated already. If you push them they will probably be able to work stupid hours in service of the quest. This is where you need to decide what kind of manager you want to be - do you relentlessly push for maximum productivity in the short term, or do you take a longer term view and keep your team together at a sustainable level. However, bear in mind that there is a point at which working more hours will mean less productivity.

Sunday, 16 August 2015

The Engineer's Social Hierarchy

Most engineers have a subtly different view of the social hierarchy than other workers. This comes primarily from being the smart geeky kids at school. Engineers or your other tech guys will have their own internal hierarchy, which might not match your pay scales or titles. To engineers, technical competency is substantially more important than other items. Other items can be important too, but a Senior Design Engineering Manager making twice the money but who only knows management and struggles with the technical aspects is not going to be respected and so will struggle to manage them effectively. The marketing guys who have great people skills and are making the sales will be looked down upon. As an engineering manager, you need to be respected by your team, but you might not actually have the background. How can you do this?
  1. Cultivate a technical background. This won't happen overnight, but if you are to manage these guys effectively, you need to know how they work. Once you've got the basics, feel free to lean on your team's expertise to build your knowledge, they'll respect that you are learning.
  2. Become a subject expert in a specific area or two, where you can demonstrate your usefulness to them. A great option is the Codes and Standards which apply to your work, your engineers will need to interact with these all the time but you won't need to do the heavy maths and physics lifting. 
  3. Show them the results of your management. This is going to be hard one, but if you can show your team that you are actively making life easier for them, then they may come to respect your non-technical abilities. 
  4. Work to their hierarchy. Don't be afraid of asking the new guy your important questions, if the rest of the team looks to him for advice then you should too. 
  5. Don't try and placate an engineer who is looking to leave with a promotion and a title. Titles mean very little to most engineers, because they already have the most important job in the world (to them). More money might be appreciated, but really if money was their prime focus they would have taken their maths skills into finance rather than engineering.  
There is also a bit of a technical hierarchy between STEM fields. This does vary by field and country, but should be some handy shorthand. This generally ties in with the engineer's respect for the person actually doing the technical work, rather than the facilitators. So if you are coming from another field high on the list then you'll get respect for that. Typically on this blog I've used engineer as shorthand for 'employee in a technical role in a STEM field', but here I mean actual degree qualified engineers.
  1. Rocket Scientists
  2. Physicists
  3. Engineers (non Software)
  4. Engineers (Software)
  5. Scientists (non Physics)
  6. Computer Scientists
  7. Pure Mathematicians
  8. Engineering Techs (machinists, draftsmen, etc)
  9. Applied Mathematicians (statisticians, actuarys, etc)
  10. Line of Average Respect - below here you'll be naturally disrespected unless you show otherwise
  11. Management
  12. Accountants (the maths is too easy)
  13. Businessmen
  14. People skills based careers (marketing, sales, etc)
  15. Arts graduates

Tuesday, 4 August 2015

Engineers and Meetings

Good engineers like to be productive. Every minute they spend not getting the problem solved (with the Right Answer) is an irritant. This is why Google tried to go completely without managers (as have other engineer-driven companies). But your bad engineers laze around on reddit and have to be prodded to get them to do any real work. As a manager you need to be able to keep both types engaged and productive, which seems like an impossible task.

To your good engineers, almost any type of meeting will be seen as a waste of time. They don't care what the other members of your team are doing, they just want to get back to solving their problems. The bad engineers will be equally annoyed, but because they have to excuse their lack of performance. However, there is one kind of meeting which I've found almost all engineers enjoy. Engineers love big picture brainstorming design meetings, where you get the brains trust around a table and they get to compete with their technical abilities to come up with the best solution. Its like a kind of mating ritual to see who comes out on top of the engineers social hierarchy. So when you can schedule your catchup meetings around these, the engineers will be happy to contribute some status updates beforehand.

But there aren't normally enough brainstorming meetings to use these for all your meetings. So here are a few pointers on how to make those status meetings work.
  1. Minimise them. If you need to know what Jane, Tom and Bob are doing, go and ask Jane, Tom and Bob separately and informally. If you've got half-decent engineers they'll talk informally between each other to make sure they don't overlap anyway. 
  2. Invite the bare minimum number of people. I find meetings are most effective with 5 or less people, beyond that you'll just be wasting your engineers time. Split it up into smaller, more precise meetings where necessary. 
  3. Your engineers will love it if you can get them out of meetings with the client or other stakeholders. Have informal discussions with the team members whose information you need beforehand and represent them wherever possible. They want to be left to do the problem solving, so this can earn you brownie points to spent on commercial solutions, crunch time or changes to working practices. However, there are still times where you'll need to have the subject expert present.
  4. Formality is death. Engineers with their own social hierarchy and poor social skills don't see the need for formality - this is why Silicon Valley dresses in hoodies and sneakers. This should apply to your meetings too, keep them free flowing and informal. Nothing kills creativity and interest more than running through a handed out sheet of talking points. 
  5. Minutes are for recording what happened last time, not deciding what happens this time. Keep last week's minutes out of this week's meeting. I've sat in more deathly meetings where managers droned through the last minutes and asked the person responsible for each item for progress on it in turn than I care to list. Nothing useful happened at any of them. Keep the floor open, the discussion organic and raise your talking points throughout the discussion as required to keep things flowing and get the information required
  6. Segueing into technical discussion is good, but only if the whole team in the meeting needs to be a part of that discussion. If your two electrical guys are arguing over details the mechanical and fire guy don't need to know, then invite them to take it outside later (see item 2 as well, did those other guys need to be in this meeting?). On the contrary, if you've got an organic team brainstorming session going on, then let it flow - only good can come out of these.
Make sure your engineers can see the meetings as productive and you'll get them more engaged rather than hiding away in a cubicle.