Submitted by Sebi on
Summary: I need suggestions for Metrics for my new job as engineering manager
I changed companies and am now a manager of an engineering department. My situation was well put by Mark in "first 90 days. your job": No real urgent problems to solve, good team, we do engineer for customers, every request is different, tough to measure.
My bosses job for this year is to make the production more efficient and only one of my team is assigned on this job. I can not spare more resources on this and would like to suggest at least one more good metric.
Office Perfomance Management
Typically, performance management measures start with your organizational targets. If you don't know where to start check your performance review. What standards do you need to hit to the gold star? Most of the time they are quantified. You simply need to break that number down one level to make it more attainable for your group. If you are lucky, see example above, and you can copy/paste right into your target.
Two warnings on this one. Don't be a slave to the tool. No need to create such a measurement system you need a PhD from Harvard to figure it out. Also, be sure not to measure yourself to death. I also often see places where there are 40 KPI's and one more measurement makes the people doing the work to want to vomit.
For example, let's say your organization needs a quick turnaround time from concept to print. You set a target based on 24 hour response time. You know that about 20% of jobs are extra complex. So you say that we want 80% of jobs turned around in one day. You build a sysematic where you know we got 5 jobs in yesterday and turned around prints on 3 of them in 24 hours. Our score is 60% vs target 80%. We would gather data for some time period (perhaps a week or two) then use pareto charts of the root cause to drive improvements to get to the 80%.
Hope this helps!
Thanks, lets go deeper
thanks. I think I skipped a step in my explanation.
So, my bosses goal is to make the production more efficient. This is the organizational target AND it will be one of my goals with an easy metric: Did we hit the goal.
My challenge is: Only one team member of mine is actually working on this goal actively. So I want to know what other goals could I have in order to "hedge" my goals. I do like the 24 h turn around and I will try to measure this.
Drucker said that an executive really only has enough time and energy to devote to one big initiative at a time (maybe two, if you're really effective). I have never had any reason to doubt this, looking at my own (lack of) ability to drive many things forward simultaneously. If you have more than a couple of goals, then either some of them aren't going to be hit, or some of them aren't really "goals", they're just part of the job ("keeping things going"). If you're worried about not meeting the goal that has been set for you, I'd recommend working harder on achieving that goal, rather than spending energy setting up a smokescreen.
And Drucker is right
thanks for reminding me.
You are right, Drucker says that.
I have to think about this a bit, because the yearly goal is not necessary "the one big initiative", right?
The yearly goal is driven by the daily work, not by the big, strategic, longterm initiative (like talent development) which has to be prepared for years and than, in the final year, can be the yearly goal.
For this year I have one person of 10 working on it. Not even full time. This is not "the one big thing", but I do agree with you in the sense that because I am new to the organization and still trying to figure things out, I should commit myself only to one goal and this one is absolutly achivable.
Thanks for pointing this out to me.
Metrics only help if you know what to measure
Perhaps I'm slow, but I missed at least two steps along the way here.
Your boss' stated goal is "make the production more efficient" yet "only one of my team is assigned on this job". So what is he trying to *do* in support of the business? Ramp up a new service for the business? Increase existing services provided (thus revenue)? Reduce costs by finding and removing non-productive people? Prepare for a sizeable change in mix and/or number of requests?
Production of what -- output of the entire team? If so, expressed how? Number of requests completed per person per unit time? Ratio of (new type of request) to (old type of request)? As an aside, if he's got some metric he's measured on, if you can construct metrics which show how the team contributes directly to that, good!
Only one one team member on this job -- in what sense? The point person for improvement efforts? The only guy actually fulfilling requests, while the rest perform other work (pre-sales, sales, marketing, IT) which somehow keeps the business moving (or no useful work)?
I'll speculate your case here is: entire team doing the same type of work together, business has customer requests it cannot serve because your team cannot take them on, boss wants to raise revenues without raising costs in supplying this ongoing service, one contributing team member "on point" for improving throughput. For this case, a fair number of metrics suggest themselves. Number of requests completed and paid on per team member per unit time (quarter?) -- likely already being gathered. Service revenue from completed requests per team member per unit time; costs of completing requests per team member per unit time. Number of improvements suggested per unit time; number of improvements attempted per unit time; number of improvements adopted per unit time.
Given my experience with technical teams in software development, I suspect the only real metric of interest *visible outside the team* would be 'number of requests completed by the team per unit time'. Revenue per request comes down to margin accepted/negotiated while trying to land the sale; your team likely has no effect there. Cost per request probably does not vary appreciably, aside from that of people's time. Any improvements inside the team to improve throughput should show up as ... improved throughput. Changes outside the team might affect the throughput metric; the team jointly can give a good sense of what those might be, small and large, and will likely have been informally suggesting many of these changes themselves to those non-team peers.
The point person can help the team track throughput, host improvement activities, coordinate (even actively go out to make) those informal suggestions, and give you an additional sense of how the team is doing and feeling.
Lets dive deeper
thanks for your post. I do see that I did not give all the necessary information. I am sorry and I hope you allow me to make up for it:
Our products are special cables. Our customers are usually not the end user, but manufacture more complicated systems and our cable is part of it.
Our production, the production that should be more effiecent by the end of the year, is the production of those cables.
My team is doing all the engineering work (Customer request: Give me a cable, this is my input, this is the needed output, this is my envirorment, this is my application. Our response: This is the cable you need.): clarifying what the customer wants, how the cable could look like, how to produce it, writing the instruction for the production, supporting sourcing needed materials for the production, root cause analysis for customer complaints and, here it comes, optimizing the production process.
So my boss has the production and the engineering under him. I am his engineering manager.
So, for the all those tasks I have 10 engineers, which do work in parts of those work for some special industries or product lines. One of the engineers is responsible with 50% for Process Engineering, which we define as optimization of the production process.
This is the organization I did inherit and while I am not confinced that this is the best solution, I am still in my first 90 days. So, please, lets not discuss best organization of the work in my team. I will open a new thread for this in Q4-2013.
So: It is not my team that needs to be more productive (well it should, but this is not the goal of my boss right now), it is the production costs we have must go down. Period. Yes, we need to ramp up production as well, but basically the goal is: Reduce costs in production by amount x.
He turns around to me and says: "Sebi, you have the person responsible for this in your team. This is your goal now as well. And you can give this goal to your team member as well. If you want additional goals, let me know."
So my question was: Which could be my other goals and how would I measure those?
I hope this makes it a bit clearer.
Goals are all about change
Goals should be separate from the "day to day work", insofar as the day to day work is about maintaining and continuing the status quo. It would be very strange to set a goal of "continue to do what you're doing", unless there were large external changes that you have to account for in maintaining your current results.
From that perspective, I disagree with your statement that "[t]he yearly goal is driven by the daily work". While your goal(s) should be aligned with the "daily work", they shouldn't be driven by the work, they should be driven by the needs of the organisation to execute change. If the organisation's need to change is a large, cross-disciplinary, multi-year effort, then that should be broken down by area and by time, and turned into annual goals. It makes no sense to have large, multi-year effort that is your annual goal only in the last year. Why were the earlier parts of the change effort not important enough to warrant making it your highest priority for the year?
Another thing to keep in mind is just because it is *your* biggest goal, doesn't mean that all of your team's time (or even all of your time) should be spent on it. Maintaining the status quo takes a lot of time, too. If I understand your description of your department, most of your department's job is to service customers and generate revenue. Unless your company is expecting to get a *very* large increase in productivity, it makes no sense to take nine people who are generating revenue and turn them over to cost reduction. Be thankful you've got anyone to help you -- plenty of my important initiatives are executed with no more available resources than a few hours of my time per week, with the rest of my time taken up with business-as-usual execution of the mundane but critical functions that make up the majority of my duties.
Ah, the plot thickens :-)
Hi again, Sebi!
Good, you've got something to measure -- production costs. A few more nits to pick on this: is this target across your company's entire production, your team's entire production, or per-cable? Or is that detail up to you?
If this is a multi-team goal, then there should be several others serving the same function as your 'process engineer' in different teams, including those who coordinate the teams. You get to make sure your process engineer is working well with his role peers -- perhaps one of your team's optimizations pessimizes the assembly's cost as a whole. He (and you) get to bring back insights to the team about this. Maybe no matter how cheaply you make successful cable, it's not even a blip on the costs screen. Maybe your team's the bottleneck to production, and the most effective improvement is to increase team costs by adding a person, thus increasing revenue by more than the cost of the new hire. But we normally start by presuming the business side of the house has decided based on what they knew at the time.
For the teams I've worked with, best seems to have been the "open kimono" approach. Here's how we're being measured, here's what it means to the team, here's what we have and what's expected from us, ask how do we want to go forward. What's I've learned from Agile software development comes to the fore now: incremental improvements, Lean Manufacturing, kanban, Scrum, wow there's a lot possible. The team needs to work out how they want to score themselves against the measure, how they want to learn and improve, and how they check their changes really are positive to downstream and the business. Be aware that the organization might not be ready to handle the improvements ....
Perhaps, while you're in the "quiet period" of your first ninety days, you and your process engineer can start brainstorming ways to support the team in improvements which don't trip up stuff downstream. Try you both taking a half-day of time with an Agile software coach, to gather more ideas on what's possible. Maybe, when you're ready to start initiatives, settle into a regular rhythm of scheduled team learning (ask that coach about "retrospectives") so everyone is consciously improving the process together. Maybe arrange for half the savings to be bonused back to the team, or reinvested into tools the team finds will improve matters further. Maybe clear away any policies which prevent (or even punish) experiments the team needs to make to discover certain improvements. Maybe spend some time building relationships and agreements in Finance to get quick access to cost numbers to digest and relay to the team. Maybe spend some time with your process engineer in refining his relationship skills, to make conversations easier and people more comfortable expressing complaints and ideas. Maybe have the team decide how they want to divide up work, roles, interactions, schedules. Maybe they get so good they have to start going upstream and downstream to be able to continue adding value.
Maybe the team will decide the two metrics in-team which best meet the larger over-arching goal are "number of cable-jobs delivered per period" (driven up to a reasonable range) and "number of cable-jobs returned per period" (driven to zero and kept there). That's equivalent to what many of my software teams use to great effect. Maybe they'll have a few they discard after a period of learning -- that too is normal.
Use this time to lay a solid foundation of trust. Spread it around. If you think they're a good team now, and you do your part well, just you wait ....
Sorry for not posting this earlier. Thanks for your inputs and the discussion. I will not hedge and I do agree with most of what you said.
I do appreciate your comments very much.