Showing posts with label engineer. Show all posts
Showing posts with label engineer. Show all posts

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.

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.

Friday, 31 July 2015

Managing Engineers Is Like Herding Cats

You've just been hired or promoted as manager of engineering on the back of your business and management skills. Or maybe you are a small branch manager who doesn't have any middle-management between yourself and the engineers. But these guys with poor social skills don't listen to you or respect you, even though you are managing them the same way as has built great teams before. Why?

Managing engineers is hard, especially if you don't have the technical background. Engineers think differently and have their own hierarchy which doesn't respect the orthodox chain of command. This blog will teach you how engineers think and how you can get the best out of them. Posts targeted at you are tagged manager, but reading the other side will help you understand where your colleagues are coming from.

Equally, you are an engineer who has run out of technical promotions and has thus found his way into management. You've gone from being primarily focused on technical problems which you can solve yourself to having to rely solely on the work of your other engineers. A role where your people skills are more valuable than the technical ones which earned you the position. How do you make this transition?

Managing people needs a completely different toolset to what you have learned so far in your career, especially if you are to make the most of the opportunity. And now you need to navigate the political waters of upper management as well if you are to get the right resources for your team. You could go get yourself an expensive MBA, or you could read this blog. Posts targeted at you are tagged engineer, but for you especially being able to see things from a purer managers perspective will be very useful too.