Trust your gut.

I’ve interviewed literally hundreds of candidates over many years (possibly in the thousands territory now that I think about it) and one takeaway to share is that if you need to use an Excel spreadsheet to try computationally derive and convince yourself that someone is a right fit – that’s your automatic cue that it’s probably not. Especially when on the surface they’re technically hitting all the checkboxes, but your management spidey-sense is telling you something doesn’t fit, and analytically you try to prove it yourself that they are; that spidey-sense is coming from your intuition, which isn’t something you want to ignore.

And when you do find a candidate that’s the right fit, it’s clear as day. Or “right as rain,” as the Oracle from the Matrix would say. On a separate note however, sometimes you stumble across *amazingly* talented people, and although they may not be the right fit for the particular role you’re hiring for, in that situation you either modify the role or create a new one. Do everything in your power to find and attract talented people!

So check this out… Successful modern management is about moving away from command and control towards coaching, mentoring, supporting, and guiding. Your job as a manager is to empower, enable, and unlock people’s potential.

I recently read an interesting article on this topic in the Dec 2019 Harvard Business Review, which is about teaching managers to be less task masters and more masters of coaching.

The general premise is as an individual contributor you excelled in your area, you had all the answers, got promoted into management, and knowing what needed to be done, tasked others with how to do it. But in this era of rapid evolution, what worked in the past is highly unlikely to be a blueprint for success in the future.

The article describes four styles of coaching:

1. Directive: Telling people what to do. Requires high energy input, and you don’t get much in the way of energy output.
2. Laissez-faire: Let the team figure it out on their own (somewhat akin to Scrum based self-organizing teams). Low energy input, don’t get much energy output either.
3. Non-directive: Asking a lot of questions, and doing a lot of listening as well. Ultimately guiding individuals to solve problems on their own without you explicitly telling them the answer. Fairly low energy input, but you get high energy output as individuals feel a sense of autonomy and freedom to solve problems on their own.
4. Situation: The ideal dimension, walking the line between the directive and non-directive styles.

Coaching may not come naturally, especially to new managers, so the articles cite a few basic steps:

1. Assess the situation
2. Listen
3. Ask open-ended questions
4. Practice non-directive coaching

This is just to wet your appetite, the article is very in depth with a clear framework and guide with how to take your coaching to the next level. If you’re interested, you can pick up the Nov/Dec 2019 issue here:

https://store.hbr.org/product/harvard-business-review-november-december-2019/BR1906

Often organizations can find themselves under a mountain of requests and they can’t see the forest from the trees. It’s overwhelming and management may not know where to start – so they don’t, and what ends up happening is the organization becomes short sighted. Meaning that priorities are a reaction to today’s biggest issue, efforts are directionless, and most requests are escalated up the management change.

[box]Vision[/box]

The source of the problem stems from lack of vision, and the corporate objectives that come as a result.

To get a grip on priorities you have to start with having a vision – even if it’s just a simple one line statement of where you’re aiming at; it’s the step to narrowing a blurry view into a focused one by getting everyone pointed in the same direction.

In essence all a vision is, is a statement of where you aim to be. Without one, there is no direction – you can move fast, but moving fast in a circle results in moving no where.

[box] Corporate Objectives[/box]

From that vision, define your corporate objectives or goals. These are specific, measurable, achievable, realistic, and time bound (aka S.M.A.R.T goals).

For example:

• Increase delivery time of widgets by 10% over the next 12 months.
• Decrease customer complaints by 5% over the next quarter.
• Decrease network outages to less than 5 minutes by 06/01/13.

[box]Nested Objectives[/box]

As a corporation you only need 2 to 5 of these; each organization underneath you will have nested objectives that support your top level goals. And now that these have been defined, you have the various projects that support each of these objectives.

[box]Alignment of Projects[/box]

So go back to your endless laundry list of requests, priorities, enhancements, and projects and first determine which ones are supportive of the goals in your organization. If they do not support the goals, then you have to simply put them aside – even if they’re good ideas.

[box]Executive Sponsorship[/box]

What’s left requires evaluating if projects have an executive sponsor. If a project is unsupported, you’re taking a huge risk by investing any effort in such a thing. There may be ROI, and it may support the goals, but without executive sponsorship the chances that the project will be successful is highly doubtful. This is because the project will then hinge it’s success purely on the ability for all the teams involved to function by consensus; and of course all serious projects come to serious forks in the road where differences in opinion will deadlock the project – an executive sponsor can make those tough decisions.

Another reason why executive sponsorship is needed is because if each team involved doesn’t have their portions of the project as deliverables as part of their performance plan, there’s no incentive for them to put in the effort. In fact, putting in any time, takes away from projects they are on the hook for.

Lastly, if an executive finds out you spent a large amount of money and it didn’t pay off, now you’re in deep water with no one to support you.

[box] ROI[/box]

Ok, now you have a list of projects that are aligned to the goals of the corporation, and have the executive sponsor to back it. You still will have a list of projects that require more resources than you have, the next step is to evaluate the potential Return On Investment (ROI).

The ROI comes in the simple and tangible form of quantitative, and the difficult to measure qualitative. Projects that have more quantitative ROI are the ones you want to go after, as they’re easier to measure the actual results (increased revenues, cost savings, etc…). Versus the qualitative ROI which is almost impossible to measure, and even more difficult to actualize.

Of the quantitative ones you want to evaluate the actual potential ROI, how easy it is to actualize that ROI, and how you’re going to actualize the ROI (projects that don’t require anything to actualize are the best, e.g. switching to a lower cost vendor).

Here are some things to think about. If you reduce the time it takes to do something, what’s the return? From a financial and quantitative perspective the answer is none.

The return is when you see the impact to the bottom line – now saving time definitely has qualitative benefits, but the point here is as high as an ROI is, you need to assess how capable your management organization is at being able to actualize the ROI.

E.g. does it entail reducing overhead, reducing headcount, restructuring the organization, etc… Say that project can save $50M, but costs $100M – your ROI 50% in one year. Compare that to a project that costs $100, and saves you $100/yr, this has a 100% ROI.

So keep a relative perspective in mind as well; smaller projects may not have the huge total numbers of bigger projects, but their ROI is much easier to actualize and therefore lower risk.

The bottom line is you need to rank projects by ROI- giving extra points to projects with more quantitative than qualitative, giving extra points to the ROI ratio, and extra points to ease of ROI actualization.

You can only calculate ROI if you have the (I)nvestment portion, so you pick off the top x projects until all your resources are booked for whatever time frame you’re working with.

[box] Conclusion[/box]

Using this formula will help you get a grip on priorities and get your organization executing on a path that will allow the organization to achieve its goals.

Michael Wolfe on Quora posted an amazing analogy explaining why software development estimates are routinely way off, which results in developers padding their estimates to factor in the fudge of such inaccuracies.

Another thesis I’ve been pondering over lately are the terms “Software Engineering” and “Computer Science”, which imply that software development is purely scientific and engineering in nature. Most colleges run those programs out of their science or engineering departments, and the business surrounding technology (budgets, management, and processes) is premised on the assumption that coding is engineering in that it’s scientific, mathematical, calculate-able, and algorithmic.

All of that is a component for sure – but the process itself, the act of coding is much closer to art. You start off with an idea of what you need to do and how you’re going to do it, you start roughly putting it together, you realize later how things will really need to be put together so you make alterations/refactor, you get feedback from QA testers/analysts/focus groups, and continually refine until you get the final product.

So unless you’re solving the exact same problem every time, what exactly are we basing the effort on? If a carpet guy knows he can carpet a 2 bedroom house in a day, he can be very close with an estimate on a 4 bedroom house. And overtime, the variation of houses is fairly limited.

However, every software project is a new problem; why would the business ask to solve the same problem twice? So we’re estimating based off of as-similar projects done in the past, but unless it is purely a CRUD with zero rules, it’s unique.

Of course an estimate will always be an estimate. But plans & dates get created, promises are made around those estimates, and the estimates become commitments. Which then causes developers to factor in some fudge knowing that the estimate will become a commitment.

Would it help if we get rid of the word estimate and label that value for what it really is, the guess? Imagine updating all your change tracking, ticketing systems, and project management tools to replace the “Estimate” field with the term “Guess”? It would help manage some expectations as to what that number really represents.

The flip side

The problem on the flip side is that businesses are run by plans. They’re not designed to function off of guesses. For example Apple has to gets the contracts signed and dates sealed for the Apple WWDC, payments have to be made to Moscone, Moscone has to prep the building, Apple has to build their booths, sign up all the exhibitors, attendees, etc… so whatever software is planned to be presented has to be ready to roll by then.

It’s a fascinating challenge, and here are some thoughts.

1. Break down the problem into a collection of micro-small problems.
• Smaller problems are easier to size, internalize, and visualize. Many Agile based processes employ this in the form of small as possible user stories.
2. Get formulaic about it.
• If a team consistently applies a 2X b.s. factor, and is 80% accurate – you then have variables to build a formula & pattern around it where you project a target date -/+ x% based on the accuracy, and then build in risk mitigation strategies to make sure you’re managing the risk of not being accurate.
3. Prioritize & focus.
• A good practice at any level (from executive to individual contributor) at any thing (business, coding, personal life).
• Make sure you focus on achieving at least the top priority in it’s entirety by the target date instead of having advanced multiple priorities but never fully completing any. One thing done is better then 10 things almost-done, because almost-done is the same at not done.

I recently listened to the audiobook to Peter Drucker’s book entitled the Effective Executive. Here are my key take aways as to what makes an executive effective.

1. They ask what needs to be done?
• Do not ask “what do I want to do?”
• Concentrate on just one task, two at most, and never more than two at a time.
• Set priorities and stick to them.
• After completing tasks 1 and 2, instead of moving on to number 3 ask again what needs to be done as new opportunities may present themselves.
2. They ask what is right for the Enterprise?
• Not what is right for stock holders, employees, or themselves.
• A decision not right for the enterprise will eventually result in something that isn’t right for anyone.
• It won’t guarantee the right decision will be made, but failure to ask the question guarantees the wrong decision.
3. They develop action plans.
• Knowledge is useless unless you translate that into action.
• Before springing into action, plot a course of how you want to get there.
• Think about desired results, constraints, restraints, check-in points, and implications.
• The action plan is a statement of intention rather a commitment.
• It shouldn’t be ridged in that once sealed you’re locked in.
• It should be revised often as actions result in new opportunities.
• Time is the most scarce and valuable resource.
• Use check-ins to examine results vs. expectations, and revise the path.
• Without an Action Plan you are a victim of events.
4. They take responsibility for decisions.
• Decisions require an owner, deadline, those affected by it, those who need to approve it (or at least not oppose it), and those who need to be informed.
• People decisions (hiring and promotion) are one of the most important decisions.
• 1/3rd of people decisions have the desired positive result.
• The conclusion to make in cases where a people decision didn’t work out is that management made the wrong decision by not putting the right person in the right place (as opposed to viewing the person as “bad”).
• If someone is promoted into a job where they are underperforming, it may very well not be their fault as it wasn’t their decision to be placed in such a role. So if it’s not working out, offer them the previous job they held where they were successful. Odds are they won’t go for it, but it does send the message to the organization that it’s ok to take career growth risks.
• After making a people decision, set a check-in date to re-evaluate if it’s working.
5. They take responsibility for communicating.
• Effective executives make sure their action plans and informational needs are understood.
• Executives need to make sure that subordinates have access to the information they need.
6. They are focused on opportunities instead of problems.
• Problems can’t be swept under the rug, so don’t ignore them.
• However problem solving doesn’t produce results, it just prevents damage.
• Exploiting opportunity produces results.
• Changes present opportunities. For example changes in market conditions, economic conditions, consumer behavior, etc…
• Don’t let problems overwhelm opportunities. Find a way to promote opportunities over problems.
• Put your best people on opportunities instead of problems.
7. They run productive meetings.
• Make meetings work sessions (vs. a blab-a-thon).
• Decide in advance what kind of meeting it will be (press release, team meeting, etc…) as your preparations will differ, and what the desired result of the meeting should be.
• Terminate the meeting the moment the objective of the meeting  has been completed. Don’t introduce additional topics.
• At the beginning of a meeting, state its purpose.
• Follow up with meeting notes summarizing decisions, assignments, owners of each task, and deadlines.
8. They thought/said “we” instead of “I”.
• An executive only has authority because they have the trust of the organization.
• The needs of the organization come before the executive.
9. They listen first / speak last

Was watching this short discussion panel regarding strategic advice from Angel investors (Ron Conway and Mike Maples) to start-ups.

Here are some take aways:

1. Keeping your burn rate extremely low buys the company the added probability of getting lucky.
1. The luck from a low burn rate comes from having the cash to experiment with various ideas until you find the right model/combination/technique/strategy. Whereas with a high burn rate, it’s all or nothing.
2. Once you find that right idea/model, you can then hone in on it and maximize it’s usage, which then drives more of what’s working (cash flow, sales leads, profits, etc…). With a now working business model, the profits come in, and you now have the ability to grow and take on more opportunities.
2. $1M should last you a year.
1. Starting with a team of 3 people, growing up to maybe 5 or 6 people.
2. Companies are the most productive when they’re less than 10 people. When you grow beyond 10, productivity goes down. So that first $1M is a team that’s lean and mean, and each individual contributes an enormous amount of productivity.
3. Have a Product Development Strategy and a Customer Development Strategy.
1. Most Silicon Valley start-ups describe an engineering project: Alpha, Beta, Limited Availability, General Availability, etc…
2. Author Steve Blank wrote a book called “Four Steps to the Epiphany“, the thesis of which is companies should have customer development milestones in parallel to the product development milestones such as customer discovery validation, creation, and scaling.
4. Discover the business before you scale the business
1. The companies that pursue the path of low burn experimentation dramatically add probabilities in their favor.
2. With off-shore labor, low/no cost open source technology stacks, and search engine marketing, companies easily have the opportunity to conduct low cost experimentation.
3. Use a business strategy of low cost experimentation done a lot to find out the winning answers, discard the losing answers, and don’t scale until you’ve figured out your business model.

Have you ever cleared your inbox down to zero? It’s the elusive dream we all hope to one day achieve.

One of the challenges we face in this information overloaded work culture of ours is that the sheer volume of information requires constant grooming, categorization, and prioritization.

Consider that your manager is probably getting about 5X-10X more email than you as they’re cc’d on every discussion, decision, and meeting minutes pertaining to the team. Consider that his/her manager is yet another order of magnitude as the scope broadens, and continues to get worse as you go up each management level.

At the executive level you’re going to employ techniques that help you stay on top of what’s going on with the business by prioritizing where your time needs to be spent. Which means they’re going to assess within 2-5 seconds how important an email is and either act on it right away, read and absorb in detail, delete it as non-actionable, or file away for further reading (which they’ll never get around to).

We live in the detail

The problem with people in the technical industry (developers, analysts, project managers), is that our lives revolve around detail. Detailed plans, specifications, unit tests, coding standards, acceptance criteria, etc… it’s all low level detail – and thus our brains are optimized to think at that level.

Executives however operate at a higher, broader, bigger picture perspective. They swoop down to lower level gears when they need to roll up their sleeves, but for the most part they’re focused on where the business is headed.

Follow these tips

Thus the style of communication that works for people who work with low level detail isn’t optimal for executives, so here are some tips to maximize your communication delivery and impact with executives:

• Don’t use narratives

I had always felt that the application could run faster, so I was looking into server performance and by running a number of queries through query analyzer I determined that performance could benefit by adding a number of indices (see initial results below). So I took it upon myself to add a number of non-clustered compound indices that my research has shown to be used in the commonly used join statement, and…

• Narratives are that story telling style of explaining things, where you end up with paragraph after paragraph only to get to the point at the very end.
• They’re time consuming to produce because you’re going to be meticulous considering the audience, and even worse they’ll just quickly scan through it.
• Or if they do want to read the detail, they’ll put it in the read-later category when they have more time, which they rarely do have more time.

• Strategically title your subject
• Don’t use one or two word subject titles, e.g. “performance”. It’s too generic, and not actionable.
• The goal is to try engaging them into reading your email.
• If you have good news, or are trying to pitch an idea that can really help the company – then try to pitch that in the subject line. Many execs deal with a lot of issues, so it’s nice to have an email come in that won’t cause your blood pressure to rise if you read it.
• Tag your subject with the content type, e.g. [idea], [kudos], [proposal], etc…
• E.g.
• [idea] quick solutions to improve application performance
• [proposal] side project to improve performance
• [kudos] Jeff Wilkers landed the Amcom account

• Start with your conclusion/proposal/point first
• The technical/analyst/PM thing to do is build up a case leading to a conclusion. Stating observations, criteria, supporting data, assumptions, etc… Execs don’t have time for this. Get to the point, first.
• Make the rest of your email support that point.
• This opening statement has to be very brief! No more than two sentences. It has to capture the essence, and be written in such a way that it can be absorbed at a glance.

Good news, we’re able to improve application performance by 30%.

I recently wrote an article for RIARockStars regarding my take on the CF ecosystem and my challenge as a manager to find talented CF developers – along with some our hiring strategies to work around that. I’ll follow up soon with a follow up post more focused on putting together a hiring strategy for managers of Flex and ColdFusion developers.

…read the full article