I Love Craftsmanship

I love the word "craftsman."

This word isn't anything new--to the contrary, you've heard it in everything from medieval guilds to most of the tools in my garage.  It has connotations of quality, creativity and professionalism.

But, I have only recently started to hear it being used relative to technical workers.  The first time I heard it used with respect to engineers was 15 years ago from an old boss of mine.  He is a brilliant engineer--built a whole company of developers who go around solving problems few in the world can.  He talked about craftsmanship just like an artisan would.  And he was exactly right--good workers ARE craftsman.

So, what does it actually mean?
A few years ago, a group of software folks came out with the Manifesto of Software Craftsmanship (these guys really like their "Manifestos").  I heard one of the guys who created this speak last year and he said that they created this in response to people's use of the Agile Manifesto (another one!  told you they liked these...).
While I think this originates as a bunch of consultant gobble-tee-gook, I think their message is sound.  I'm making their message more generic, because it fits most things we do:

1. Not only working solutions, but also well-crafted solutions
2. Not only responding to change, but steadily adding value
3. Not only individuals and interactions but also a community of professionals
4. Not only customer collaboration but also productive partnerships

Craftsmanship is about putting in the tongue-and-grove when nails would work.

Craftsmanship is about addressing the problems with the system when all anyone will thank you for is addressing the symptoms.

Craftsmanship is about making life easier for the next person to maintain your stuff.

Craftsmanship is about creating a world where your customer experiences small delights from being surprised by exceptional quality.

We spend so much time focused on the mission mode of user experiences--and that's important.   But, imagine what it would be like if we dedicated a proportional amount of time creating areas where our customers can appreciate HOW we created something as much as WHAT we've created.

Simplicity and Flexibility

That’s been one of my mantras—focus and simplicity.  Simple can be harder than complex:  You have to work hard to get your thinking clean to make it simple.  –Steve Jobs

Simplicity is the ultimate sophistication.  –Leonardo da Vinci

Why Do We Estimate?

A conversation has been going on lately among a community of experts around the concept of #NoEstimates. A lot of great points are being made, but as with every business topic, the swirl always evolves back to "It depends."  It depends on what your stakeholders require to give you funding.  It depends on the maturity of your team and the maturity of your partners.   But, most importantly, it depends on the expectations of your customers (external and internal).

In my world, there is only one real goal to estimation—buy-in.  Buy-in from Marketing that the product we will make is what they want.  Buy-in from our Executive Leadership that there is a path to profit and we are the right team to do the work.  And, buy-in from us that we understand what is being asked of us and that we will commit to do what it takes to earn the business.

As a new product development department, we are running an engineering services business.  As business owners, our goal is to be profitable.  This means we want our customers to pay us as much as possible and to come back time after time with more for us to do.  As a captive design services business, the benefits get realized in the following ways: 

• Growth:  we are able to hire more people so we can do more cool things more quickly
• Competition:  we capture a higher percentage of the work, without it going to outside firms.

But, at the end of the day, there are two key deliverables that govern whether or not we’re a useful team:

1. Dependability
• Are we in control?  Does what we say match what we do?
2. Value
• Do we help the company do what it needs, with a higher value proposition than any other option?

Value is not created if we are not dependable.  Being a captive engineering services house, we get benefits—biggest among them, that our partners must consider using us first.  But, even there, if we do not deliver to our customers' expectations, the organization will look for alternatives (3rd party houses, partnerships, etc.).  Dependability, therefore, is first and foremost about getting what we DO to match what we SAY.  This requires control at the beginning:  we need consensus with our partners on requirements to increase the probability that we will delight them.  Our estimates are our first deliverable on the requirements--they are the basis of our promise of dependability.

Assuming dependability, our biggest differentiator is value.  Simply put, our goal is to meet the needs and wants of the company more efficiently than anyone else can.  Showing value is a difficult balance between exceeding expectations through awesome execution and managing expectations through education and partnership.  Our success is directly dependent upon how successful our customers (the marketing and sales teams) are.  From the beginning , estimates provide our customers the value proposition they need to make the case to "hire" us.

Ultimately, marketing exceeds expectations when they deliver business opportunities that bring in a bigger pile of money than anyone expected.  They have their own challenges to work through to manage expectations and delight their stakeholders as they define opportunities.  But, as their partner, we have a huge stake in their success—our participation determines their timing and and our estimates determine the payback time period on their business cases.  Our work estimate is the basis of our contract—the basis of our reputation.

As a result, estimation is a core skill for the success of our team—and of every engineer.  While we can't guarantee that we're right, we create a series of conversations with our customers and stakeholders.  To provide #NoEstimates is to bypass those conversations and that misses the point.

Fixed Points in (Project) Time

There are fixed points throughout time where things must stay exactly the way they are. This is not one of them. This is an opportunity! Whatever happens here will create its own timeline, its own reality, a temporal tipping point. The future revolves around you, here, now, so do good! - The Doctor, Cold Blood, 29 May 2010

When I worked at a big technology company, we had a stage gate process on steroids.  This thing had 16 different gates, with full enforcement of each.  What was good about this structure was that it showed the distinct cadences within a project that the team needed to account for.  I liked that it tried to account for these cadence differences--most frameworks that I've seen don't even try.

The two main goals they were trying to achieve with this stage gate process were:

1. To support stakeholder monitoring and control
2. To guide the team on the path so that they do things in sequence

Monitoring and control are very important, but need to be separated from the development framework.  The development framework needs to focus on the team.  The "fixed points" within the framework need to guide them at a high level, but need to support their being efficient.  Given this, I want to focus on minimizing the number of fixed points to maximize the team's ability to manage and adapt.

For systems, there's a necessary flow that progresses through the subsystems.  In a mixed hardware/software environment, the minimum number of fixed points includes:

1. Requirements/project plan lockdown
2. Concept freeze (though this may realistically be part of the first line)
3. Hardware freeze
4. Software freeze
5. Product release

I am thinking there may be additional points.  For instance, the above points cover development, but not release to the factory.  I haven't quite worked that out--but I'd rather start with too few than too many.  

What is Agility in Hardware?

One area that I've been working through lately is how to relate the good habits of the Agile ideal to mixed hardware/software projects.
There are significant, good behaviors in Agile methodologies that relate directly to all product development:
1. We can't be 100% sure of what done looks like when we start, so stay flexible and have a constant conversation with stakeholders/product owners to ensure that the design is, in fact, meeting the needs.
2. Perfection is the enemy of good enough.  Don't add extra cost/time into solving problems that don't need to be solved.
3. Focus activity on maximizing feedback.  Spend time de-risking your approach as quickly as possible--addressing both technical and business risks as quickly as you can with actual implementation
4. Swarm activities.  Single piece flow is the key to optimizing the queues.  Activity should be focused on tangible outputs, at the expense of perfect efficiency in utilizing staff and project resources.

"Being agile" is fundamentally about managing "fixed points."  These fixed points include everything from getting buy-in (feedback) on decisions to architecting in such a way that designs can adapt.  This affects your approach to every stage of the project.  Here are some things I'm trying to work through:

How do you manage change from a hardware perspective?
How do you build in flexibility in hardware so you can enable that change?
How do I adopt a framework that will work for not only hardware--but software?  How truly applicable are Agile frameworks like Scrum, when I'm operating in an environment where getting MVP requires fixed-bid, multi-month project plans?

Below is my scratchpad of what I have so far.

• Requirements
• When developing marketing requirements, the goal is to capture what is needed now, but also to maximize your options for the future.
• Architecture
• Architect for high option value
• Portability, scalability, maintainability
• Have a wish list (technical roadmap) so the team can see where flexibility is required
• Allow flexibility to adapt to an evolving definition of what "success" means
• Most times, we don't know perfectly what will sell. This understanding will also evolve during a project.
• Architect for your economics
• In particular, consider whether your company is more sensitive to staffing or to unit cost
• Development
• Find--and take--one big risk per project
• You'll have plenty of risks, but refine your plan until you only have one "project killer"
• Keep in mind that risk usually originates from doing something new--which means you're learning! 
• Then, mitigate risk aggressively--almost irrespective of the project plan

The Cost of a Staff Hour

People are the most precious resource you have in your company. As a manager, you will spend more effort planning and estimating the costs of the people you work with than any other expense.  How you make these staffing decisions will affect everything from the culture of your company to the kinds of people you are able to attract and retain.  It will also define your cost structure.

For budgeting, you likely estimate projects in terms of staff hours.  And, you likely estimate costs based on a blended hourly rate.  This is not perfectly accurate.  Once you have accepted that you have a team of a certain size, the true cost of an hour is your price to buy another hour of work.

Consider these questions:

• How do you account for risk in your estimate?  
• Do you include a risk premium or some other pile of bulk hours to cover the unknown, or do you assume you’ll be able to “manage” it?
• How do you obtain additional help when a new opportunity presents itself?  
• Do you bring in additional limited term staff or do you wait for your team’s availability?

Your answers define your culture—and your cost of a staff hour.

If you consider contractors, your hourly rates can vary wildly. 

• What level of skill is needed to do the job?
• Do they need to be on-site?  Do they need to be on the same continent?
• How much of your team’s time will you need to devote to training and managing this temporary team?

With contractors, your goal is to maximize their efficiency—unless they will share the risk with you by providing a fixed bid on the work, you’re paying for every hour.  Work needs to be more completely defined and you need to manage scope aggressively.  If these don’t mesh perfectly with your model, you will need to budget for more hours than you may typically expect. 

As for your internal team, your base estimates likely assume a 40 hour week.  The dirty secret of many successful engineers and teams is that the marginal cost to your company of an extra hour is likely $0.  Assume a team of salaried engineers nominally costs $100/hr (including wages/benefits). As the team’s average hours per week increases, their annual blended rate decreases:

• At 45 hours per week, their rate would be $89. 
• At 50 hrs per week, their effective rate would be $80.

But, in all cases—whether the engineer works 1 hour or 100 hours—the salary and benefits are a sunk cost and the marginal hour costs $0.  The degree to which you can count on any “increased efficiency” will be capped more on the drive and commitment of your team, the culture of your company, and how often you ask everyone to push.

How you make these decisions will determine your company culture and, with that, will help you understand your true cost of a staff hour.