The 4 Obsessions of Hyper-Effective Engineering Leaders

I have occasionally helped companies recruit engineering leaders.  When I facilitate this process the first thing I want to see is the job description as it appears on the various recruiting sites.  Yikes!  Looks like you took all the skills from all the people on the team, rolled it up and said “Yep, the Engineering Director needs to know how to do all this” (c#, c++, java, hadoop, html5, NodeJs, AngularJs, Bigtable, Photoshop, CSS, Predictive Analytics, robotics, firmware engineering, chip design).

“Yes, but why?”

“Because the Engineering Director needs to understand what everybody else is doing.”

No.  The Engineering Director needs to understand what the business outcomes need to be, and create an outcome-centric environment for everyone to understand them and achieve them.  Meanwhile, he needs to be able to offer support, context, guidance, and resources to empower his teams to be successful.  Being a rockstar engineer and being a rockstar engineering manager require 2 different sets of skills.  There are very specific skills you should look for when hiring engineering leaders, and here they are.


Obsessed with recruiting top talent

It’s not about putting out a requisition and choosing the best resumes.  Its about creating and sustaining an external talent pipeline… before you have a requisition.  Peter Bugnattos, Strategic Sourcer at Lockheed Martin remarks,

“It isn’t about just finding resumes.  You have to understand the needs of both the candidates and your business and make the stars align when the timing is right.”

This is important because:

  • The people you want the most are not actively looking for a job.  The best way to get first dibs is to really understand who they are and what they’re passionate about
  • If you want until you “need someone” to start looking you are already too late.  By the time you need someone, the situation is dire, the recruiting effort is rushed, and the candidate is “late” the moment they walk in the door.
  • You get to vet candidates over a longer period of time.  Making a hiring decision based on a 30 minute interview (alone) is a horrendous way to make a hiring decision.

Unless they want to be stuck micromanaging and running projects themselves, your engineering leaders should be obsessed with recruiting top talent.



Obsessed with growing and developing existing talent

A huge pain point for many leaders is finding talent with the appropriate mix of skills and experience to make an immediate impact on the job.  Companies have been on unicorn hunting expeditions for a long time, and still have not been able to find the right candidates for the right roles at the right times.

There are a few solutions to this problem:

  • Grow your own talent.
  • Hire for the current challenge to be solved

Finding the balance between hiring external talent and developing internal talent is always difficult.  Unfortunately, most companies neglect to develop internal talent at all, which leaves them scrambling to fill leadership roles and makes those who are passed over frustrated.  Companies who are successful at growing talent create clear expectations for what it takes to reach “the next level” and create a transparent timeline to reach those goals.

Another problem that plagues companies is to find “unicorn leadership” that has the exact same blend of skills as the outgoing engineering director.  Instead, understand the current challenges that need to be solved, and hire people who have a track record of solving those problems in a major way.  It doesn’t matter that your last Director of Software Development was a math Ph.D. if the most pressing problem you need to solve has no relation to linear algebra.


Obsessed with creating teams of people who can get $h!t done

Its not just about people who are incredibly effective, its about finding people who are incredibly effective at the things you need them to be effective in…TOGETHER  How do you find people who can get $h!t done?  Create your job request as a list of outcomes and goals, rather than a list of daily activities and responsibilities.  Then, when you interview people, you will be looking for clues as to HOW people have accomplished similar goals in the past, and over what timeline.  As Yishan Wong, former CEO of Reddit says,

“The way to assess if someone is good at getting things done is to see what things they’ve gotten done.”

Then you need to hire leaders who understand how to create outcomes and goals then find people who have a track record of reaching similar outcomes in past roles.


Obsessed with building a learning culture

The ability of an organization to quickly learn and incorporate the lessons into execution is a class A competitive advantage.  Jack Welch postulates, “An organization’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage”

Alex Weinstein, head of product development at Microsoft Live Labs, makes the argument,

“You should not hire for specific skills (e.g., Java, Hadoop, Oracle) but the ability to pick up new skills… a high velocity of learning is a core competency of the team”

Why the obsessions?

Because its very easy for engineering leaders to be pressured in to focusing on the wrong things.  Creating “obsessions” around the 4 critical levers of technology leadership ensures focus, creates a learning environment, and supports business outcomes.  Hire talent.  Develop teams of people who can get shit done.  Steer the ship by providing business context and constraints  Build a culture around continuous learning and improvement.  Understand where the strategic and the technical intersect.

Until Next Time,
Stay Agile My Friends

Download a Sample Director of Engineering Job Description


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Write a Scrum Master Job Description

When I talk to clients and they start to get serious about their agile transformation, they soon come to the conclusion that they don’t have the right level of experience internally to lead the transition.  I usually recommend they hire an experienced Scrum Master from the market.


Most Scrum Master job descriptions suck

Here is an example..

Team leads for large teams or managing one customer with multiple projects
Responsible for delivery of assigned module/ components /phases of a project.
Responsible for people Management, including goal setting and providing performance feedback
Responsible for Status reporting
Responsible for guiding the development team.
Responsible for estimation, planning and execution  with specific focus on requirement analysis and design
Responsible for Knowledge transfer and arriving at SLAs for steady state
Technical problem solving skills

Employers spend a lot of time lamenting the quality of resumes and applicants, but very little time putting care and diligence into their job descriptions.  As a result, you have job descriptions that looks almost exactly like those bad resumes we get tired of looking at.  Coincidence?  Notice how the job description lists responsibilities, but not outcomes, objectives, or timelines.  This is a recipe for poor candidates.  Why?  Because every candidate, qualified or not, is going to look at the list of responsibilities and say, “Yep, I can do that.” Whether they have experience doing it or not.


Understand the kinds of problems you’re trying to solve

I’m a big proponent of giving people problems to solve rather than solutions to implement.  Unfortunately, most job descriptions are written in terms of “duties” or “activities” rather than outcomes.  This means the annual review process is ambiguous and subjective, since all you have to go on is a list of duties.  If people did the duties, then they will expect a top review.  On the other hand, creating time-boxed, specific, measurable outcomes creates a proper stage for screening resumes, interviews, and annual performance reviews.

Put the problems you’re trying to solve in the job description.  Companies at different points of their transition have different problems to solve.  Companies early in transition will probably need someone to help the teams get off on the right foot.  Companies that have been at it for awhile may have challenges in scaling out to larger projects and programs, while companies that are relatively mature in their practices may need a Scrum Master who can help with the challenge of re-configuring the organization to work in a more lean manner.  Different stages, different problems.


Write your job requirements as a series of timelines and outcomes, not activities and duties

This is why understanding (and prioritizing) the kinds of problems you are trying to solve is so important.  We should be able to map the problems to be solved to the objectives to be reached by the candidate.  These objectives should be SMART

  • Specific – The objectives should be unambiguous and easy to understand
  • Measurable – The objectives should be easily measurable
  • Achievable – Given the objective and the timeline, the objectives should be achievable
  • Relevant – The objectives should be relevant to the problem to be solved
  • Time Bound – The objectives should be time-bound


Bolster the requirements with critical competencies

Critical competencies describe how you expect a new hire to fulfill the job and achieve the outcomes.  Critical competencies are important because they specify some of the constraints around how the candidate is expected to accomplish the outcomes.

For example, if your company is a small company that does not have a change management team, and the candidate is expected to be an internal change agent, but has only worked at large companies with internal change teams, he needs to understand that a critical competency for the job would be:

Influence – Able to influence, persuade, and “sell” at all levels of the organization.

This would be important because if the candidate was used to having a change management “team” and only had the competency of driving change management from the strategic level and not getting down into the details, they would not be a good fit for a smaller organization that does not have a dedicated change management team.


Add cultural competencies to ensure organizational fit

Cultural competencies work at two levels.  They define the skills and behaviors required for a job, and they reflect the broader demands of your organizational culture.  According to “The Who“, 1 in 3 CEOs say that not evaluating cultural fit was one of the biggest reasons for hiring mistakes.  People who don’t fit fail on the job, even when they are perfectly talented in all other respects.  Is your company’s culture formal or informal?  Are decisions made based on analysis and data or gut feel?  While some people might think “Work hard play hard” sounds great, others may think, “Oh geez… I have to work 12 hour days with these people then go out for drinks with them too?”  Cultural fit is very important.


If we expect to get highly competent candidates, we need to do a better job of writing the kinds of job descriptions that will motivate highly competent candidates to apply.  Get rid of the “must be able to work in a fast paced environment” and add some things that really matter to the task at hand.

Click here to get a Free Example Scrum Master Job Description

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Agile HR: How to Bridge the Gap Between “Team Performance” and “Individual Appraisals”


When I work with organizations who are looking for ways to bridge the “collective responsibility” aspect of Agile team work with the “Individual Performance” aspect of their HR and review system, I usually recommend a few concrete steps:


Remove anything from the performance appraisal system that is clearly antithetical to making Agile Progress

Sometimes the HR and people management systems associated with companies in transition has not been updated for a very long time. As such, you might have some artifacts that have been lingering around since the stone age that negatively influence compensation, and thus behavior. Here are some examples.

  • Measuring developer productivity by lines of code
  • Measuring QA productivity by number of bugs found
  • Measuring Business Analyst productivity by length of documents created

The first order of business is to get these relics removed from the system, and anything else that is clearly counter to the current agile effort.


Add 3 additional dimensions: Teaching new skills, Learning new skills, and Performing roles outside your job description

Next is to add 3 dimensions to the current review process: Teaching, Learning, and Performing new skills.

Incentivizing team members to teach new skills has a few positive effects: It spreads skills through the organization, prevents information hoarding, and reduces the risk of only 1 person understanding a certain part of the system, a certain technical skill, or a certain business process.

Incentivizing team members to learn new skills provides a ready audience for the teachers, creates a now cost “knowledge factory” inside the organization, and allows people to learn new skills in the context of what they already know with people they already work with.

Incentivizing team members to perform new skills helps create more flexible cross functional teams, gives individuals an outlet to practice their new skills, creates more flexible career paths, and enables better mentoring inside the organization.

Wrap up

Remember, this is just a guideline to get started.  Most companies understand where they are and where they need to go, but need help in understanding what the intermediate steps look like.


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Optimizing for “Developer Productivity” is a Useless Business Metric


“So we need to build cross functional teams where the developers can help out with the testing effort….”

“Wait a minute, are you suggesting our developers become testers?”

“I’m suggesting people help remove bottlenecks and help all the work get done faster.  Testing is a bottleneck, so helping with the testing effort will remove the bottleneck to getting more stuff done faster”

“But if we do that, our developers wont be productive.  I want them to be productive and focused on writing software!”

I’ve had this conversation, and many others like it with client over the years.  The unnatural focus on developer productivity continues to boggle the mind.


There is no objective way to measure developer productivity

News Flash, developers are not widget makers in a factory, their productivity can’t be boiled down to a nice, clean, objective, numeric measure.  We have all heard horror stories about companies who use “lines of code” as a measure of developer productivity.  Thankfully, that practice has gone the way of the dinosaur.  However, engineering leaders continue to search for that “one true metric” like Ponce de Leon searched for the fountain of youth.  He ended up with mosquitoes instead.


Creating a local optimization does not optimize the complete system

It’s easy for me to rage against the developer productivity argument, but that’s not my point.  My point is:  As we look for ways to smooth the flow from “I have an idea” to “This idea is making money”, we look for ways to remove bottlenecks.

The bottlenecks are what prevent us from creating value as quickly as possible (concept to cash).  One of the biggest bottlenecks of any development organization is the bottleneck that happens when 5 developers finish coding at the same time and there is but 2 lonely testers to try to validate the code.  This in addition to the regression, the test planning, and whatever other duties they have on their plate.  Heaven forbid they’re part of a “testing pool”, then it really gets gnarly.

When we optimize for the developers “productivity” rather than the system’s “flow”, we are intentionally creating a bottleneck and limiting the flow.  Not good.

Developer productivity is not a business outcome

Lastly, when I talk to organizations about Agility I always turn the focus away from the particular terms and jargon of Agile, and more toward what we really want, which is positive business outcomes.  Most businesses invest money into projects for one of three reasons:

  • Save Money (automating business processes, less expensive platform, fewer people needed to maintain)
  • Make Money (revenue generation opportunities, adjacent product market, vertical value chains)
  • Reduce Risk (compliance, redundancy, disaster recovery, unsupported platforms)

Focusing on these business outcomes and creating the conditions to objectively improve them is a much better use of time, effort, money, and energy than optimizing for a software engineer’s so-called “productivity”

Until Next Time,

Stay Agile, My Friends

PS, Click here to download my special report:  5 Useful Agile Business Metrics

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Unknown Problems, Sloppy Goals, and Unclear Success Measures – We Can Do Better

“Our project is to implement a new widget management system”, she stated confidently.  “Ok”, I said, “but what is the problem we are trying to solve?”

“We need a new system…”, she reiterated.

“Yea, but to what end?  Whats the business goal?  And how will we know when we have reached it?  How will we measure success.”

“Look”, she said, steeling her glance and locking eyes with me, “My job is to get this project done in 9 months with 500k.  No more.  No less.  I let the business people look after the business goals.  My job is to deliver on time and on budget.”

Like many others, the project became a morass of blaming, finger pointing, and misplaced expectations.

Here is a 3 step process to avoid some of these problems


Gain clarity on the problem to be solved

You should be able to articulate to stakeholders and the team what the problem is you are solving for.  This has a couple positive side effects:

It gives your team context.  Context is important because it centers the attention on the outcomes to be achieved, not the activities to be performed.

It aligns your stakeholders.  Stakeholders may think they’re aligned, but when you put a concrete problem statement in front of them, you will quickly find the difference in opinion and disagreement among stakeholders.

It helps greatly with prioritization.  No project ever in the history of software development projects has ever had enough time, enough people, and enough budget.  Effective management is the art of getting the highest value outcomes given your constraints.  Since we know we won’t be able to do everything that everyone wants, we have to decide whats most important.  Clarity on the problem to be solved creates a framework for prioritizing whats important (items that help us solve the problem), and whats not (items not directly related to solving the problem at hand).

Click here to get more information and examples of problem statements, goals and success measures


Create a qualitative goal to be reached

A goal is a way to describe the end state of the solution your team will be developing.  The purpose of a goal is not precision (we will get to that later), its directional accuracy.  Goals are aspirational in nature and qualitative in description, and represent the opposite “end state” of your problem statement.  Similar to problem statements, goals help with prioritization, context, and stakeholder alignment.


Outline quantitative success measures to be attained

Success measures, or lack thereof, is the area where I see the most problems.  Companies, stakeholders, and project managers create success measures like, “on time, on budget”, which is a very lazy and undisciplined success measure.  This is because companies spend money and initiate projects for three primary reasons.

  • To save money
  • To make money
  • To reduce risk

In other words, software projects are initiated to help attain business outcomes.  “On time and on budget” are project outcomes, but should not be the primary measure of success for a project, because they are not business outcomes.  Not only that, but “on time and on budget” are only vaguely quantifiable.  What happens if the timeline moves out?  What happens if the budget increases?  You can quickly see how time and budget as a measure of success can quickly get divorced from the business outcomes.

A more concrete measure of success would be “Reduce support calls by 50%.”  There is a direct line between the amount of customer support calls and the overall support cost.  If annual support costs $1,000,000 for a given product, reducing that overhead by 50% creates an additional $500,000 in value.  Its easy to measure, easy to quantify, and easy to calculate the ROI of the project.  In this case, we have a clearly identified business outcome that is specific, quantitative, and directly related to business success.


Moving beyond the triple constraint

To get the most value from project efforts, business stakeholders and product managers need to work with project managers to create lightweight business cases that help everyone understand the problem to be solved, the goals to be achieved, and how we will measure success.

Until Next Time,

Stay Agile, My Friends

PS.  Click here to get more information and examples of problem statements, goals and success measures


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How To Help Management Forecast Progress in Agile

“My current client, like so many before, are asking “what percent complete are we?”. This is such a legacy waterfall question, assuming that we really understand what’s left and that our done state will not change. I am trying to educate them to instead ask “what value is remaining?” and understanding how to determine when/if to move to another value stream. What are your experiences with this issue?”

Hi Dwayne,

I don’t think this is a legacy waterfall question. The people paying for our services deserve to know the answer to this question, and the people providing the services should be able to easily answer it.

In an agile world, *how* we go about in answering it is significantly different than the waterfall world, and is based on data. Here is a straw man example:

The team has a backlog. The backlog has been estimated at a high level. Let’s assume, for the sake of discussion, the backlog is 500 story points total. Let’s also assume the team’s velocity is 50 points per sprint. This means it will take around 10 sprints for the team to be done, assuming little changes.

Things can change, and things do change, and if/when things change, the forecast changes, since forecasts are based on the best available information we have at the time.

So let’s assume the team is merrily running along, finishing ‘potentially shippable’ product at the end of every sprint, and they have finished 3 sprints/150 points. You can tell your stakeholders, “Based on what we know today, and the team’s current velocity, it looks like we are around 30% complete”

The big difference between a waterfall “30% complete” and an agile “30% complete” is that the waterfall 30% complete is based on a phase being done, and an agile 30% complete is based on 30% of the deliverables actually having been designed, built, tested, demonstrated, and pretty close to ready to go.

Based on % complete and value delivered (output and outcome) our business partners will be armed with the information they need to make the decision to continue building more value in the current stream or not.

Hope this helps.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More