Value engineer’s original idea

pros_cons_idea_left

When a system or a project under the design review is based on the original engineer’s idea that fact should be explicitly acknowledged as an advantage. That’s right, put it into the “pros” section of the “pros and cons” list. In bold.

An original engineer’s idea could be a new invention but doesn’t have to be it. For example, it could merely be a suggestion to apply a well-known technique in a new way. An original idea, however, must excite an engineer or a group of engineers who suggested it. Ideally, it should excite the whole team (and the whole company and all the way to the customers). So why give it an advantage during the design review?

First of all, it is just plain not fair to compare an original design to a well-known solution without adding extra point (or more) to it. Give it a benefit of doubt! It is going to be a new territory, and, of course, during the design review, you are going to miss a couple of goodies which you will for sure encounter down the road while implementing it. At the same time, you’re most likely able to list all the pros and cons of the well-known solution.

By applying an original idea at the very least an engineer and the whole team will learn a lot more about the problem and will deeper understand the solution. You will have to think carefully about the requirements, as many of them will pose a serious challenge. On the contrary, by using a common solution many of those requirements won’t be even visible because they are “covered” implicitly. Similarly, you will spot more design decisions and understand available options when you have to work through them one-by-one.

An original idea gives a chance to make something better. Yes, it increases the chance of a failure as well. But if you are not in a special situation when the failure cannot be tolerated, I’d definitely optimize for the former. And, let’s be honest here, it must be a very rare project when no failure can be tolerated at any cost. Even in the spaceships, there are numerous of systems exist to handle minor and major failures to avoid jeopardizing the mission.

Make a loud statement that the original ideas are welcome and believed in, by explicitly acknowledging that each has an advantage to it from the start off. Show that you believe this team is able to produce the highest mark or better than the competitor’s results. It is incredibly important, especially for the high-profile teams.

Double the points (use italic font in “pros and cons” list) if the idea originated from the engineer who will be doing the implementation. She’ll work harder on it, which, when you trust your teammates, increases the chances of success.

When you decide to pursue the original idea, watch out for a couple things, though. First, the very fact of originality should not be the only or the biggest advantage that outweighs everything else.

Second, be explicit about when the experiment must end and when the “original idea” fact should be removed from the list of advantages. The latter, if you think about it, makes perfect sense in the broader context: the idea becomes less of an original nature after it was battle-tested and e.g. proven to be not the best. Try to set the boundaries and termination conditions ahead of time, however, to avoid postponing this moment too far, when you are already attached to the idea too much (and you will be).

In the very end, when the original idea succeeds do not forget to look back to reflect and be proud of your fearless team.

 

Follow @abaranau to not miss future posts.

Tech lead’s performance review checklist

pr4

What are the talking points that you go over during the performance review of a tech lead or a software engineering lead? Here’s the list of the most common I’d start with (and extend with more specific to account for particular projects and responsibilities):

Risks

  • Risks are well-managed
  • Technical debt is well-managed

Execution

  • Priorities are well-defined, communicated and executed
  • Provided quality of products and services is well-defined and consistently meets expectations
  • Infrastructure/operations provide required support for the quality of service and team’s efficiency
  • Number and severity of bugs and incidents stay within expectations and are well-handled
  • Value added vs quality ratio meets expectations and sustainable

Process

  • Team operates at a maximum possible efficiency
  • Engineering process is well-defined and executed
  • Planning process is well-defined and executed

Integration

  • Systems and services are well-integrated into an organization’s infrastructure
  • Team’s plans, execution, products, services are well communicated to the rest of the organization
  • Relevant organization’s information is well communicated to the team

People

  • Career growth, learning capabilities and specific interests are well supported
  • Team has strong morale, supportive attitude and turnout rate is minimal
  • Work schedule is sustainable

Individual Contribution

  • Vision, new projects and ideas leadership is provided and executed
  • Technical leadership is provided
  • Execution (“get shit done”, “make things happen”) leadership is provided
  • Individual engineering contribution is significant
  • Potential candidates and hires are brought in to meet the growth demand

The above list is by no means full or applicable to all teams and organizations and is given in no specific order or the priority. Engineering and technical leads at a different time and place may have completely different responsibilities and expectations. A lot depends on the organization’s size and structure, on the team’s place in the organization, current projects and their priority and more.

It is usually helpful to grade the points with scores, e.g.:

1 – terrible – puts organization’s big projects, competitive advantage, success at risk or causes direct failure
2 – bad – consistent performance at that level puts organization’s projects at risk
3 – satisfactorysupports on the proper level (and does not jeopardize) organization’s projects, etc. and other team’s work
4 – goodunlocks/enables new and boosts existing organization’s projects, etc.; boosts work of other teams
5 – exceptionalcreates new organization’s projects, competitive advantage, plays big role in the success of the organization

I find it not only incredibly useful, but many times fun if the reviewee and reviewer perform grading independently and then compare the scores. This helps to identify the gaps in expectations and priorities, and ultimately bring both sides on the same page by setting the right focus for the future.

What are the talking points that you use during the tech lead performance review?

 

Follow @abaranau to not miss future posts.