Hacking Mac Image Capture for Higher DPI Scans

I have been frustrated that Image Capture (the built in scan and camera tool on the Mac OS) seems to be limited to 600 DPI no matter what your scanner's ability. What also surprised me is when I search for it I can't find anyone else talking about this limitation. 

I do find advice on scanning that says if you want quality don't use the OS or software that came with the scanner and buy third party software like VueScan. While VueScan is amazing software that seems to support every scanner ever made, it is also difficult to use and doesn't integrate automatically into PhotoShop the way Image Capture does.

There may be a really good reason for the 600 DPI limit in Image Capture. Maybe it follows the Apple philosophy of guiding you to the right tools. They assume if you need better than 600 DPI then you should  use more advanced software. But you don't have to if you're comfortable editing a plist file.

The following procedure worked for me and I've scanned dozens of images now at 1,600 DPI using Image Capture without issue. Possibly this is like overclocking and my scanner will die sooner because something is wrong here, so follow this knowing I'm really unsure if this is a good idea.

Here's how to scan at greater than 600 DPI in Image Capture:

0. Be sure to back up the file ahead of time and check your EULA to be sure editing it is legal. (This step is a reminder that your plist file may have zero based arrays.)

1. Find your scanner in the Image Capture settings in the system library folder. Typically this is:

    Macintosh HD > Library > Image Capture > Devices

2. In this folder will be a package for every scanner that your computer connected to. In my case I was looking for "Plustek Scanner". Right click on the package with your scanner name on it and choose "Show package contents".

3. You'll now be looking at the contents of the package. Look for the scanner plist. I'm not sure if it's always the same, but for a few I checked it was always this file:

    Contents > Resources > ScannerProperties.plist

4. Open the file ScannerProperties.plist. It is an XML file, but if you have Xcode it will open it as a plist file. Either way search for the first instance of ICAP_XRESOLUTION. In XML it will look something like this:

5. Notice the array of integers. These correspond to the drop down for DPI in Image Capture. Decide on what you want to add. My scanner supports 1,600 DPI so I decided to add a 1,200 as well. If you are using Xcode be sure to set both the value and the type. The type will default to text so be sure to set it to number. In XML my entry looks like this:

<integer>1200</integer>

<integer>1600</integer>

6. In step five the X DPI is set, so now the Y DPI needs to be set identically. Search the document for the first instance of ICAP_YRESOLUTION and put in the exact same entry you did in this location as you did in step five. Also to note, the order matters.

7. Save the plist file.

8. Open Image Capture and scan with the newly unlocked resolutions.

The microS Way

As a conclusion to my notes and reflections on the CA Microservices Conference, I wanted to share the MicroS Way that was presented there.

1. Establish the right boundaries in your code and organization

2. Have a system that balances easy and speed with safety

3. Have the right processes and standards

4. Steer the system and measure it

5. Accept that right, easy, and safe are a product of time and context

MicroS - lessons learned part 3

This is a continuation on my notes from (and reflections on) the CA conference on microservices.

How to Change

Use shock and awe to make change. Be a little outrageous. Do not pivot by spinning on your heel --sprint with a two-by-four, slam it in the ground, and spin round to a new direction. An enterprise is about maintaining stability, so it won't change just because you casually mention it. You need to prove this change is happening and motivate the teams. Have a crazy challenge motivator.

And make the rules of change embody your bold statement. For instance, Gilt moved to microservices by saying you cannot use the main database or commit to the Ruby on Rails depo. These two rules helped to build a completely autonomous system. The trick is to find something simple that forces a new direction.

Besides changing the technology focus, change the way you frame the problem. Gilt doesn't say "do this" but instead gets the best out of a team by asking, "how do you solve this?" You want to tell your team where you are headed, but not how to get there. This is partly because it encourages inguinity, but also because the people on the ground floor always have great knowledge of how things work. Even if management rises from within things can change and those that know the day-to-day need to be consulted.

Another way to get the best out of a team is to have the right team skills. Agile teaches that you put the key players on the team. You choose the engineers and developers that have the skills for the software and technology that you need. The expertise is built within the team so they don't have to reach out and wait for someone outside the team to have the time to help. But there's an expertise that can be overlooked in the team: the business. Having close allignment with the business is automatic when someone with business background sits as a member of the team. Furthermore that person will gain an understanding of the pressures on IT so that the whole team can make wise decisions on what is both business valuable, but not shortsighted of long term IT cost.

Part of long term IT cost is the fact that once something exists it seems to be able to justify its continued existence based only on the fact that it exists. "Someone might need it" justifies going to large cost to maintain an unnecessary system, while half of that cost will not be spent to build a necessary system if it does not exist yet. There are very human reasons for thinking this way that all of us are prone to. The way to combat this natural tendency is to have a Sunset Team. This team is charged with responsibily shutting down systems that are no longer needed. The entire organization should celebrate shutting down an old service as much as they celebrate a new one.


Building Teams

It can sound easy to just put together a team, but there is a lot to consider. Besides what I already spoke to about having the right skills on the team there is also attitude and size to consider. At the conference a team size of four to five people and a department size of around 20 was recommended. If you do not have at least ten engineers working on microS, then your group likely won't be able to handle the increased overhead that comes with microS. As for choosing the people watch how they naturally gravitate to each other. For instance, watch for those that want to work on the new and shiny stuff versus those that want to build a solid infrastructure that is hardened. Put them in separate teams and give them the projects that fit them best.

But do not build new teams and ask them to build microS right from the start. The team should always better understand the work than the technology. In other words you can be new to building a shopping cart, but you better be experienced in building websites and never vice-versa. Your first microS should be ones that you build to solve a business problem that your team already understands. Always know the business better than the technology.

One reason for knowing the technology better than the business is that debugging is always more difficult with something you do not know. This is especially true of microS, but true of anything. If you know the business part well you at least have a firm understanding of what going right means even if you don't know why something is going wrong when a bug emerges.

Focus on team culture. Change that goes against the culture will not be lasting and likely will not even take place. It is an attitude challenge. Culture can cause a team that always codes in Java to write Python as if it were Java. Changing technology does not change culture. Over time a balance will grow in a group between culture, technology, and structure. When you change one the balance is lost, but the group will try to find the balance they once knew by modifying the other two to make up for the change in the one. Unless of course the change to all three is thought out and the team is properly prepared for it.

You properly prepare by knowing that these three steps must happen in this order:

1. The technology and culture is stabilized. Things in flux are actually less able to change because everyone recognizes that the last thing you want to do with a shaky house is change the foundation.

2. Optimize them. Once you have stabilized you can build on that and have a better system, which helps motivate the team to believe in their ability to create effective change.

3. Transform them. Now you are ready for real change.


Embrace Change and Risk

I wrote in a previous post about how to talk about failure. Netflix has a great culture that embraces this at all levels. The fact that they can openly talk about Quickster proves they understand that innovation comes with risk and the best way to learn from it is to talk about it openly. They trade lessons learned in an open way, which transfers knowledge between teams in a radically better way than in a workplace where competition means not admitting what went wrong or could have been better.

MicroS - lessons learned part 2

At the CA Microservices Conference, Vijay Alagarasan spoke about some anti-patterns. I have reworded them to be patterns to follow and added a couple of my own thoughts.


Automation is Litmus

The litmus test on whether you can handle microS is if you can automate. Automated testing and deployment is key to microS, but beyond that if what you have is not regular enough or so eccentric that automation is not possible then you either still in R&D land or you simply are not ready yet. You do not need to automate everything, but if there is something about the software that inhibits automation then that will be a problem for stability, scale, or your own sanity when problems occur.


Centrally Manage Config

Design a configuration manger. There should be one server (not literally one, you're allowed redundancy) that can send configuration changes to your services. If you don't start from day one then you will be unable to control scale. The time to centrally manage the configuration of a service is when you deploy the first instance. Once you are running 15 instances of it, you are likely to miss an instance when you need to change a setting on it. Just think to the last time you were debugging an issue that was intermittent and you checked everything only to finally discover that one of the servers was configured differently. Sometimes it is obvious, but given that you always assume someone was diligent and set them all up identically you can often overlook that sort of bug. Avoid the headache and always manage configuration centrally.

The one argument you can make against central config is security. As I write this it does occur to me that a malicious actor who merely wanted to reek havoc on your network could do it through the config server, but that is more the case of a disgruntled employee with system knowledge. Chances are your hack is going to be by someone that wants to find their way to something valuable and changing something like a rate limit on an API is not likely to help much. Maybe talk to your security officer about this if you are concerned.


API Gateway

An API Gateway has many benefits. It can reveal a lot about network traffic and help to control it with things like caching, routing, throttling (limiting particular calls), and authorization. It can also help you transition from one version of a service to a another by slowly moving traffic to the new one. For example: consumer A is routed to version 2, but all other consumers are routed to version 1. Then consumer B moves to version 2 and so on. A good version strategy allows you to to introduce new versions of a service with a minimum of risk.

However all of the stability a gateway can offer can be reversed through misuse. Every bit of business logic that works its way into the gateway is a potential production issue. The point of the gateway is to abstract you from the business logic so that you can change your business logic carefully (as mentioned with transitioning to a new version of a service). If the business logic is in the gateway then you cannot change that logic without risking all of your traffic being negatively impacted. There will be some business logic in your gateway, but assume anything you put in there may need to be changed and cause a full system outage. Each IF statement should be put in place with that realization.

I'm unfamiliar with these products, but CA Layer 7 and AWS Mobile Gatway are examples of API Gateways.


Question Every Layer

Abstraction is a useful tool, but it needs to be used purposefully. For instance, having a policy to abstract the connection to every database is not good. Each use of abstraction should be for a strong reason about that particular case. Unnecessary layers should be avoided. A coworker told me "no one ever wants to be the middle man" and you should think of layers like middle men. Most of the objections to middle men are the same reason you don't want extra layers in your software. They introduce complexity and the potential for translation issues, they constrain your message into their terms (admitidly this can be a pro), and they consume resources. People would always rather go to the source, but they will put up for a middle man when there's a good reason. Don't just have an extra layer in place like in Office Space.

Do not separate your layers by bussiness logic, data access, or orchestration. One layer should likely embrace all three of these things. The boundaries of a service should be based on a business solution and not a technical one. You are building services to solve business needs. Being able to switch your database out to another one should not be the guiding star by which you design your services. If you have a good version strategy then that should be all you need for technical changes.

Microservices (microS) - lessons learned part 1

This is a continuation on what I learned from the API Academy's microservices conference. None of these are rules, they are all principles. My personal belief is that the only rule should be to embrace continuous improvement.


wAgile

Holger Reinhardt introduced the concept of wAgile which is a blend of waterfall and agile. On the one hand this sounds like an oxymoron and certainly there were laughs at the term. (A colleague of mine suggested perhaps watgile for WATerfall aGILE would be more successful as a term.) If you consider however how the triad of thesis, antithesis, synthesis works of history works though it makes sense.

The industry started with waterfall which is great for project management and it helps managers place timelines, staffing, and schedules of other projects, but waterfall has the danger of mapping things out in such detail and so far into the future that by the time you get to the end of the project you find it fell victim to the rapid pace of change of technology and business, which did not respect your careful planning. A well planed and executed project that solves a problem that no longer exists is sadly as much a failure as a disorganized one that couldn't even complete.

There have been various solutions to this, but agile is the recent darling of the industry. For startup culture the focus on MVP (minimum viable product), which gives early results means you begin to learn and adapt to your market rapidly. Not having a timeline of more than a few weeks out is fine for a company which isn't entirely sure what the business will be by then. Removing the long term calendar and only deciding on when you will complete the next task vastly increases the accuracy of a developer or engineer's time estimates.

In agile training I picked up the razor for separating a candidate for waterfall from agile, which is to ask where the unknowns are. If you know your technology well and know the business problem well then you can probably have a very successful waterfall project. Waterfall depends on your ability to predict and if you have previous experience that applies to all aspects of the project then you should be able to reasonably predict. However if you are building a new business model with new technology then you will do better with agile.

In the enterprise world though things are rarely so clear. To balance innovation with safety you are likely introducing new technology carefully and not all at once, so it is a partial unknown. The same goes for the business which tends to solve problems with mostly familiar solutions and doesn't jump into completely unknown markets in big ways. Also my experience is that no one likes to hear "we'll be done when we are done."

What wAgile says is do the planning and accept the unknown. You do that with the old trick of padding the schedule, but you do it in a smarter way. If you pad each task or phase on a Gantt chart then invariably the time will get used. If someone is done early they likely have pressures on them to get other work done for the business and they will do that work. Yes, it is time spent productively, but it is not helping to get the project done.

Instead of padding parts within the schedule, Holger says, you pad the entire schedule at the end. Keep every task or part tight without any extra time and try to stick to that. When the inevitable happens though and something does not work as planned or the time allocated was simply not enough then take some time out of the padding at the end of the schedule.


New Technology

How do you keep current with new technology and have standards? On the one hand you want to pick a few tools and make those the standard so everyone can know them well and technology can be reused or repurposed easily. Yet this closes the door on introducing new technology and keeping current.

Gilt does this by having an architecture board that brings various groups together to talk about what works and what doesn't. They celebrate when you try and fail (more on that below), because that is how you learn and you cannot innovate without trying new things. The process is to drive consensus on the standards.

There was support at the conference for what I believe is also Amazon's take on this. The policy should be if you adhere to standards you can expect full support. So things like monitoring, off hours support staff, production hardened environments, and infrastructure automation are all available to you. However if you want to code in a new language then all bets are off. If the system crashes at 3 AM you take the phone call and fix it. Sure your colleagues may help you, but you cannot expect it and you certainly cannot complain.

This not only is a policy that allows the introduction of new technology, it is also a policy for retaining key talent. Teams often have a mix of those who constantly play with the latest tech and those who hone their craft on their current skills, but the former will be discouraged if there are no opportunities to use the new tech in their jobs.

When evaluating new technology have metrics on the new and old. If new technology is a narrow improvement then be skeptical. There is a lot of overheard in learning new technology and implementing it which has to be outweighed by the improvement.

I cannot speak to how useful it is, but a few people said that Thought Works' Tech Radar is a good start to conversations on new technology.


How to Talk about Failure

A blameless postmortem is pointless. You need to learn from mistakes, but you need to also accept that everyone is human and mistakes happen. Pointing fingers is not helpful. People need to be encouraged to feel comfortable saying, "it was me, I broke it, and here's how I fixed it." A good programer is one who knows how to recover well from a failure. A programer who hasn't had failures is lucky and lacks that experience needed to handle that inevitable failure when it happens. This is what is at the heart of the concept of "fail quickly" which assumes you will recover quickly. You can only do this in an environment where failure can be discussed openly.

Microservices (or microS) - overview

The API Academy hosted a conference on microservices in Manhattan. I only stayed for the morning due to a busy schedule for myself that afternoon, but I was impressed. When a presentation includes pros and cons or includes stories of what went wrong I regard it as honest (more on that in my next post). A flawless IT project or technology is a rare thing and probably more about luck than skill. If you are solving a challenging problem with new tools then things will go wrong. I have always felt the mark of professionalism is not avoiding problems, but quickly recovering from them. (When you only seek to avoid problems then you stop innovating.)

What follows is what I learned from the conference about microS along with some of my own thinking. The presenters of the conference are owed credit to the good ideas, and the mistaken and flawed should be credited to me.

To cut down on typing and just because I like it, I'm going to refer to microservices as microS from now on.

Why microS?
As we have embraced SOA (Service Oriented Archetecture) we now have a mess of confusion on the network. Just as when the automobile first hit the road, it was fine when you just had a few cars, but once everyone had a car on the road there was chaos and traffic rules needed to be introduced. It is not sustainable to blindly create a service whenever there is a need if you lack an overall structure and plan. The hope is that microS give you "speed, safety, and scale in harmony" which is what the highway system, DOT, traffic regulations, and traffic conventions brough to the roadway.

What are microS?
As an evolving buzzword about an evolving concept it is difficult to define. The discussion seems to be centered around the concepts in the image below. Everyone's definition is basically a collection of a handful of these concepts. (ignore that small is highlighted)

A word about small: microS are not as their name suggests all about size. It is more about thoughtfully setting boundaries. If you divide up your services based on rules such as "it's a different service each time a different system is involved" or "it's a different service each time it's a different dev team" then you are setting boundaries based on an irrelevant thing. Set the boundaries based on what the software is doing. Systems suffer when the service size is made too small (often caused by trying to abstract and layer everything, which ironically makes change difficult) and they suffer when the service size is too large.

Another misconception that microS are trying to fight is the urge to not repeat code. Multiple version of the same thing are not only acceptable but encouraged. MicroS are trying to manage change. The desire to have, for instance, just one search engine might be making change management intolerable. If having your HR system and product system share a search engine results in exponential complexity then don't solve search with just one service. Build a service, clone it, and have two.

Startups vs. Endups - speed vs. safety
When you are a startup you can afford to be less safe and you can be like Facebook and declare that you are going to "move fast and break things." But as you grow stability becomes part of the business model and even Facebook finds itself with a less sexy slogan like "move fast with stable infrastructure." Endups (established businesses) need to balance speed and safety. MicroS exist in this space where they are not like monolith system design where safety requires a very slow pace of change and they are not like the constantly updating system that 10 developers can maintain in a startup mode.

For instance one difference is that unlike at a startup where you might edit code directly in production you do not edit production code in microS. However unlike in a monolith culture where you need sign off from lots of parties and full system testing, with microS you have automated testing which allows you to safely push your code live without that beaurorcrasy in the way. It is a balance.

The MicroS Way
Rather than define what microS are we can define what it looks like when you have the right environment for them:

1. establish the right boundaries (size) in code and your organization (developers and business people)
2. balance safety with ease of change in the system
3. have the right processes and standards (more on this in my next blog post)
4. steer the system (from a high level) and measure it (data driven)
5. accept this: right, easy, and safe are a product of time and context

The word you see continually is "balance" and when you think of the old monolith design (one huge system that ran everything) contrasted with the small individualized world of SOA, what microS offers is a balance between the two. We will also see this in my next post in the concept of wAgile (waterfall agile) which attempts to balance the approaches.

Drive

https://www.youtube.com/watch?v=u6XAPnuFjJc

Holacracy - notes from a taster workshop

Instead of structuring a company around the people, as we do in traditional management hierarchy, holacracy says you should structure the company around the work that the company needs to do to express its purpose.

If there is nothing that makes you skeptical about holacracy then you're probably missing something. It is a radical shift from traditional management hierarchy.

Holacarcy is a replacement, not something that can be added or incorporated within traditional hierarchies.

One of the ways holacracy encourages process improvement is that it acts as a mindfulness exercise for the whole organization.

Traditional management hierarchy is the unconscious choice of business. You should at least consider if it was the correct choice.

In holacracy power is not held by a CEO -- all power rests in the constitution (which itself is a definition of the process). The way you enter into holacracy is by the CEO ceding all of their power, much like the way in history kings would decide to dissolve a monarchy for a new system like democracy. There are a lot of interesting observations to be made about holacracy and traditional management hierarchy when comparing the strengths and weaknesses of a monarchy versus a constitutional democracy.

While you might expect diffusion of responsibility as a result of placing power into groups, there is actually a structure to who makes which decisions. There are point people who have specific responsibilities. Who are those people? Everyone decides that as part of the process.

The most unintuitive thing for me about holacracy is that even though there is a huge focus on autonomy, there is actually a lot of highly structured process. It is not anarchy. What one could say is that instead of using the unspoken rules of politics and power dynamics, holacracy asks you to make all of the rules transparent and gives you the power to change those rules in order to make the business function better.

Another common misunderstanding is to think that without hierarchy you do not have structure. There is a well defined structure in holacracy which places everyone into circles. A circle is a group of people based on a part of the work that needs to be done. In a small company you would have a finance, marketing, advertising  and other circles that roughly correspond to departments of today. However in a large company you would have many circles that handled finance activity. A circle (much like a meeting) really can't function well once it starts growing above a dozen people. Once circles get too large they should be divided in two -- much like a cell dividing in an animal.

Each circle in a company defines someone as the "lead link". This is a position that can rotate and acts as a liaison to other circles. The lead link also has the responsibility of speaking for people who are unable to attend meetings.

Speaking of cells in animals, to continue the metaphor for holacracy circles,  every circle is a cell and even though there is no boss or master cell that tells the other cells what to do, cells organize as organs and then as animals and are fully functioning. What is nice about his model is that it explains how a really large organization can remain as flexible and adaptive as when it was a small organization.

There is no one definition for how to fire people in Holacracy. One company handles it by having a circle responsible for it. If you are honest about it though the traditional system does not have a great solution -- it is always a difficult thing. What holacracy does say is that you should define your process and that's an important thing. We often leave difficult things vague, but holacracy gives you a tool and responsibility for defining the process.

Another difficult topic can be compensation. How much should you pay employees should be something you have a defined policy for and holacracy again asks that you figure that out for yourself. There are "apps" in holacracy which are basically optional add-ins to the process and there is an app for compensation.

Of course one consideration in firing people and compensation is employment law. One way to avoid this is to declare that everyone in the company is a partner (they have a K1 not a W2). This way there are no employees, just partners. While this is how Holacracy One handles the challenge, it has yet to be tested in court.

Normally in a status meeting how much you say is inversely proportional to how much you got done. If you're done you just list what is complete. If you are not done you spend a lot of time explaining the reasons you are not done. Unless you are asking for a solution to what keeps you from finishing, this process is a waist of time. This is why in holacracy you say "done" or "not done" at a status meeting which saves a lot of time.

Holacracy starts by empowering everyone equally. Instead of saying here is a small set of things you can do, it says we are all empowered to handle whatever needs doing. Before we run straight into chaos with that though we do define some requirements of certain people and do place some constraints on who can do what. This is an evolved process however and everyone has the ability to call the requirements and constraints into question and the expectation is that they will change a lot at first. The advantage is that there is a built in system for process improvement. Holacracy may start out worse than traditional systems, but because it can evolve through process improvement it allows an organization to constantly get better. A traditional system tends to live with its problems and consider them facts of life instead of solvable things.

We are not always asked to be self actualized people. We grow up in a hierarchy of parents, teachers, and various authority figures. Breaking from our parents and becoming adults is a difficult process, but it is not always a complete process. Some people jump from that straight to having a boss and never learn to be their own person. It is difficult to do this, but it makes for better psychological health and in holacracy better employees. The great difficulty it takes for individuals to do this underscores the challenge in transitioning from traditional management hierarchy to holacracy.

The process for integrative decision making is very structured. It has the following steps:

0. Before the process begins everyone goes around the room and voices what is bothering them. This can be something that is irrelevant to the meeting, like "my shoulder hurts" or something like "I don't want to be here -- I have a fire that I need to put out." The idea is that we all have things that are distracting us from being present and the mere act of voicing them can silence them in our minds and allow us to focus.

1. present proposal - At this time only the presenter speaks. The proposal is captured and displayed so everyone can see it.

2. clarifying questions - The participants may ask questions of the presenter, but they can only get data out of the presenter. They will be silenced if they are trying to voice their opinion or influence the presenter to change the proposal. It is just for understanding the proposal.

3. reactions - Each participant gets a moment to speak honestly about what they think of the proposal. There is no discussion -- each person takes a turn and should be speaking independently. The idea here (much like step zero) is that we can feel compelled to voice certain opinions, but sometimes all we really want is to get the idea off our chest. It acknowledges that we are emotional creatures and gives us a chance to succumb momentarily to the emotions so we can then move on and get something done.

4. amend/clarify - The presenter is allowed to change the proposal at this time. This is not allowed in the previous steps because that would let the participants quibble about wording and get into an endless wordsmithing exercise. The point is not to have an eloquent or perfect proposal, but instead to have something that works. So at this time the presenter may choose to change the proposal based on the input up to this point. Only the presenter speaks during this step.

5. objection round - Each participant is asked if they have an objection or no objection. If they say they object then there is a highly structured way of dealing with those objections.
* If you object because you have a concern, then you are asked if that concern is something known or an assumption. We often voice concerns as if they are known facts when they are actually just something we fear will happen. It is important to be honest whether the objection is fact or assumption. 
* If the objection is an assumption then the question is if that is true would that be something we can adapt to later and fix. If we can adapt and rectify the issue then it's not really and issue. Knowing that we are in a system of process improvement we know mistakes will be fixed. Of course some risks are of things you could never repair and if that is the case then it is a valid objection.
* Another way to judge the validity of an objection is whether the objection is about something not directly related to the proposal. For instance if I needed an assistant and the proposal was to spend more money I might object to the proposal because it would take away money that could otherwise go to highering an assistant for me. When I voiced that objection I would be asked if my concern would still exist even if the proposal was not on the table. Since I still need an assistant regardless of the proposal, the objection is not valid.
* Holacracy does a good job of finding solutions by keeping a sharp focus on the question at hand and not allowing everyone's concerns to muddy the conversation.

6. integration - If there are no objections then the proposal is carried out. If there are objections then step 4 and 5 are repeated until the proposal is carried out or withdrawn.


Since I think invalidating objections is a really important part of the process, here are some more examples:

-- "Is that objection based on a concern you are feeling that would still be there if the proposal didn't happen?"
-- "Yes."
-- "Then that's not a valid objection."

-- "Is there any reason this proposal would hurt the company or our way forward? If not then it is not a valid objection."


What I called a "concern" above is referred to in holacracy as a "tension" which can refer to concerns, but also interpersonal tensions and it extends to what you might call a "difficulty". In traditional hierarchical management tension is not handled well. We tend to avoid dealing with tension and do our best to steer clear of it because it is difficult and often has political implications. In my experience tension resolution only comes from a person of power dictating something which tends to create new tensions. However instead of tension resolution we usually ignore the problem or make decisions that make no sense except that they allow us to work around the tension.

Resolving tension is hard work. It is not easy and it can be awkward and uncomfortable. That is just a reality of any system; however, holacracy gives you tools like the integrative decision making process that allow you to dehumanize the process and find real solutions. The idea is that it will be hard, but as you repeatedly address tensions you will get better and better at it and soon find you are solving tensions instead of avoiding them.


Instead of saying "I'm too busy" the thing you should say is "that's not a priority to me." Maybe there is a need for a discussion on the priorities, but there is always a lot of work to do and we can be very busy but not doing anything important. We should stay focused on the idea that we need to work on priorities. Having autonomy empowers people to do that.


If there is a conflict (disagreement) over priorities then the "lead link" (a special role in holacracy, see above) makes the decision. For the long term though there is a process of governance that lets you set requirements of people.


We get in our way so often in our own organizations by trying to be smart or clever. Our minds are not always our friends. We say things in meetings for this reason and we are not adding much value to the actual work that needs to get done. This is especially true in policy formation. The idea is do something, learn from it, adapt. You'll wind up with something that works well because it is based on the real world and not how clever you are.


The above was from my experience at the Holacracy Taster Workshop and much of what is above comes directly from what Brian Robertson (the primary developer of holacracy) said at the workshop. 

Agile Scrum - a few important points

Empirical process control says we should observe what happens in the world, learn from that, apply the knowledge, and repeat the cycle.

In generic terms: Plan --> Do --> Asses (test) --> Act (adapt) --> repeat

In Agile Scrum terms: Adapt --> Scrum --> Inspect --> Scrum --> repeat

At the center of both of these cycles is transparency.

What can be useful is to send a tracer through the concept. A tracer is like a tracer bullet -- it is something that can mover through all of the complexity of your process and be seen within each step.

Build / Run

The build / run concept says have one team totally focused on new development (build) and one team totally focused on operational issues, help, day-to-day (run). The problem with this is that most developers want to be on the build team and the run team doesn't encourage growth. The solution is to rotate members in and out of both teams. Being on the run team should always be a temporary condition.

When does the traditional waterfall method work?

1. when you are working with known technology

2. when the components are stable and standardized

3. when the requirements are complete and unchanging

4. when the process is highly repeatable (you do it a lot)

Velocity

In agile scrum velocity means the average number of story points divided by sprints. In other words: on average how many stories do you cover per sprint?

Refactoring

Rewriting code without changing the functionality. This lets you clean up the inefficient code that results from constantly adding new functionality. It allows the developer to redesign without input from the business as the functionality must remain the same. "Rework is better than no work"

User Stories

The 3Cs of user stories:

Card - the story should fit on an index card

Conversation - the story is a commitment to a conversation/negotiation

Confirmation - you need to know the acceptance criteria for the solution

Adobe Conference

Recently I attended a conference from Adobe about Creative Cloud and marketing. Although there were more presentations, I found the first three most interesting. Here are my notes with some photos of the presentation.

1. Debbie Millman

Branding = deliberate differentiation 

Human beings metabolize everything quickly. We see this literally with food, but metaphorically with love and with the delight from new products. Being the first on the block with the newest product is temporary and equally fleeting is the joy that aspect brings.

The inward isolation of the iPod has been replaced by the virtual connectedness of social media and this represents a complete change in marketing.

The next wave of product management and advertising is in managing the anxiety of measuring ourselves and our connections.

In today's world if you want to succeed focus on giving the consumer these three things: connection, purpose, fulfillment

Limbic branding - brands as connectors

Have a focused message and don't completely change it for multiple audiences or locals. Do not be ambiguous. We always perceive ambiguity negatively.

---

2. Ashley Still - Creative cloud

Connected assets allow assets to sync and remix across apps

Experience manager assets - central content storage - connects design with marketing

---

3. Scott Belsky 

This is both a good thing and a bad thing. We need time to concentrate on the ideas that should happen.

Organization with a bias to action. Write with verbs. If nothing actionable comes out of a meeting then you didn't need it. There should be follow ups. Leaders often write reminders to themselves of "ensure this" and "ensure that". Prioritize projects visually -- use an energy line. Compromise and put some things at low energy -- if everything is at high there's no point in having a line.

Work with what's working and keep optimizing. Never say "if it ain't broke don't fix it".

Share ideas liberally and don't worry about them being taken away. You'll receive far more necessary input than stealing of ideas. For instance share ideas in a blog and then take of with the ones that seem to have an impact on readers.

Seek competition - drive comes from seeing another doing the same thin, which makes you want to do it better.

Great creative teams fight a lot.

Fight apathy as well. Don't let people check out and give up the fight.

Leaders talk last. If you start a meeting with "Here's what I think, what do you think?" then that won't engage others. Don't make them try to find an idea that's similar to yours. First allow for input from others

Value the immune system of the team. The doers will fight off something new. Once in a while suppress it for the dreamers to bring in a new idea. Be the bureaucracy breaker - try to keep moving even if it is inch by inch.

Make people (even your bosses) make decisions.

Gain confidence from doubt.

How to discover a server's mail relay

On Solaris 10 run the following command as a regular user:

grep rhmailer /etc/mail/sendmail.cf

On RedHat/Centos 5 and 6, first discover the OS release level:

cat /etc/redhat-release 

For redhat or centos 5 run the following command:

grep rhmail /etc/mail/sendmail.cf

For redhat or centos 6 run the following command:

grep rhmailer /etc/postfix/main.cf

Opening large files with Oracle SQL Developer

Oracle SQL Developer is my go to SQL tool. It is powerful, easy to use, and free. The only issue is that it can easily produce SQL files that are larger than it can open. For instance if you want to quickly back up a table, you can just run an export in "insert" format and it builds all the insert statements for you. Trouble is if that file's over around 30 MB you can't open it. The issue is that this is a Java program and the space allocated to the JVM at startup isn't large enough for big files. The way to handle this is to increase the memory available to the JVM. Keep in mind when doing this that your OS may limit how much actually gets allocated and of course you could hit a hardware ceiling. So just because you can type a huge number in the configuration file, doesn't necessarily mean you'll get that much memory. Otherwise though this is a simple change that works well.

What you need to do is find the sqldeveloper.conf file. You can just do a search on your system, though keep in mind that some systems (like Mac OS) consider this a system file and don't expose it in the GUI. You may need to use a command line to run your search.

On a Mac you'll likely find the file here: /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf

Just open a terminal, use your regular UNIX editor and open the file. Add this line to the file:

AddVMOption  -Xmx2048M

If you find you still can't open your file and that you have more resources available, increase that number until the file opens. Do pay attention to system resources though and leave some memory available for the OS and other apps.

I Hate Meetings - Michael Lopp - Palantir

A bad meeting = Nth discussion on the same topic and no one owning the decision.

books by Michael

Bored people quit - that's what they do.

You are (at most) three years away from building something new. Look at resumes you'll see that people do this.

Irrelevancy is always just around the corner. And shows up usually when you're happiest.

Meetings exist to scale communication and to try to keep track of what might be about to go off the rails.

The process for making something happen = idea -> analysis -> execution
This process happens all in your head when it's just you. When it's two people you need to discuss it and sometimes it takes debate. What this is is a meeting.

The first meeting = it's not just you, together working to solve a problem, in a finite amount of time, and done as needed

All ideas get better with more eyeballs.

But now we have 30 people, not just two. Ideas are coming from every which way. Rapid and organic error correction. Low cost situation awareness. The most random shit becomes culture. Everyone knows everything and does everything.

This first round of 30 people represent the Old Guard. They don't write anything down and keep everything in their heads. They will likely have disproportionate power. Their instincts say that everything they learned at this size will work at a larger size. They run meetings based pretty much on the "first meeting" rule.

Now the company is larger and has 300 people. The company is working. Ideas are still showing up but there's lots of them, decisions are happening slower because it's hard to get input from everyone, and execution is now becoming stove piped. People are a little sad because they used to get to do everything put now roles are solidifying. Stories are retold and becoming myth. Situational awareness is now expensive. Increasing communication friction. Learning can no longer occur via osmosis (a clue to this is when people ask for a wiki). The New Guard is now here. It's stranger town.

The Old Guard can handle problems and fix things based on their political knowledge. They keep doing things the old way but this is where things go off the rails. The issue is that groups of people do not communicate at scale. We think we do, but we don't. The Old Guard just talks to the right people and things get done.

In this setup the Old Guard has no ability to anticipate problems because communication isn't scaling. Then inevitably something bad happens and someone says we should meet.

Meetings go viral when: the perceived value of the meeting goes up, it begins to seen as the only hammer available, and certain people are really good at running a meeting (they are meeting infectors and it is in their interest to exploit this talent).

The Mutated Meeting = Random people who aren't contributing, a lack of agenda, that doesn't respect attendee's time, that goes on forever and ever

Apple called people out of meetings who didn't contribute. And noise didn't count, it had to be signal.

What you need is consistent useful communication in all directions. There are three essential and good meetings that avoid things going off the rails. Preventative maintenance meetings avoid stuff exploding. The reward is silence which does take the fun out of saving the world when the sky is falling.

The one to one meeting
 the update meeting = every week, no matter what, 30 minutes at least (when you skip it trust erodes). Cheat sheet - three prepared points, a performance review, the supervisor's current disaster. The topic should be what you care about. Assume someone has something to teach you in the one on one
 the vent meeting = just nod and listen (don't get sucked in or commiserate, but lend an ear)
 the disaster = you don't want to have this
  
    
Staff meeting - every week (early), no matter what, 30 minutes (at least)
Dashboard: At apple there is the ET which is about everything going on in the company. It sets the tempo for what will happen next week. It handles the state of business
Special guest meeting: information from others and there is serendipity where you learn more
Tapestry meeting - frequently, not just when it's on fire, possibly over poker
        trying to build improbable relationships, culture, to get people to bond
        serendipity focus

All other meetings except those above need an expiration date. Never have it recur forever. You need an expiration date.

Success is (confusingly) silent. These 3 types of meetings are a way to nip problems in the bud. You should find out who is bored and who needs honest feedback.

You can only manage 3 - 7 people. Beyond that someone is suffering.

Meetings should frequently justify themselves. Vote with your feet on whether a meeting is important. Prune aggressively and get rid of unnecessary meetings.

Leveraging Logic as a Leader - Patty McCord - Netflix

It's not what you aspire to do - It's what you actually do

Fundamentals
    Company First (if you don't have a successful company you don't need a culture)
    Judgment trumps everything (intelligence, speed, intuition)
    You can just tell the truth

Teams: Visualizing Greatness
    Imagine in six months if everything was amazing and you had the perfect team. What would be occurring then?
    What would you measure (metrics, deliverables, reporting, cross functional alignment, timeline, deadlines, due dates)?
    What would it look like (winning debates, winning tests, customer feedback, data & analysis, influence)?
    What would people have to know how to do in order to pull it off?
    What kinds of skill and experiences would lead you hear?
    And only after that do you think about who is on the team.

To build the right team first you need to know what you are going to build.
If you start with who you have, you may be limited in what you can do.
You now can tell the truth.
Which means people can decide if they are motivated by the work.
They know what they can do.
They can own their careers.
They can opt in or opt out.

The steps above would allow for a world where there would be no need for performance improvement plans. In truth a PIP just exists to justify letting someone go. It is better to be honest about the work and needs of the employees from the start. Also the steps above would keep interviewing from being a sin. It allows people to be honest and for people to do their best work.

If an employee is unhappy you should tell them to go interview. It will make it easier for them sometimes to articulate to a complete stranger regarding what they want. Also it will let them know what market value is for their job. And they may realize that the grass isn't greener and they'll come back more motivated. The catch is that if someone comes back you need to say "what did they offer you" and you need to offer it because that's what "market comp" means.

Good interview question: tell me about the day you went home and said to yourself "damn I'm good"

Netflix didn't have performance reviews. They had gantt charts and knew who was performing and who was lagging behind.


Pattern recognition - how to lean people. Pay attention to patterns. Learn to observe. People are rewarded differently, wired differently, and need to be treated differently.

Learn to observe how people react to: change, challenge, the unknown, each other, unexpected interruption, learning

What Patty did to innovate within HR is to just stop doing things. No more PIP. No more vacation policy.

Humans are organized for efficiency. You cannot avoid organization, it will form.

Leading from First Principles - Scott Chacon - GitHub

One hundred years ago there was a knitting mill where the employees were not paying enough attention to the spools of thread running out. The solution was to put kittens on the factory floor to play with yarn. What's more amazing than that it worked is that people were open to it.

Five years ago the four founders of GitHub were open source developers without business credentials. They worked from their homes. They ran the company on business minimalism which means they ran until they had problems and then fixed them. They ran an open source business which means:

- no meetings
- no offices
- no work hours (work when you feel productive)
- everything is asynchronous
- people self-assign work
- maintainers, not managers
- everybody contributes ideas (maybe only a couple provide vision)

The entire company works this way (even the legal department). They call these ideas their first principles (borrowing the concept from philosophy). There's no dogma that says "no managers" -- there's the argument of "is a manager the best way to get the value we want".


The 3 year old prosecution = "why" - your ideas should survive this. Direct the three year old prosecution at your business. Same idea as the Toyota "five whys" concept.


Examples of 3 year old prosecution

OFFICE - is it the same as the factory 100 years ago. Are you doing something because it has been done in the past or because it works for you?
First principles of the office:
- a place to work (maybe you have kids and you need a space you can get away to)
- creative collaboration
- serendipitous interactions
- meet the suits (auditor meetings etc)
- interviews and onboard people
- physically ship things to and from
- event space (for public or internal)

Note that at the office GitHubbers don't talk to each other because it's more fair to those not at the office and are on chat.


THE SCHEDULE - most people work about the same hours - 9 to 5 is "core hours" for meetings - why?
How often do you need to meet in person? Only for one of these things: strategy and brainstorming and serendipitous interactions OR heads down, uninterrupted implementation
Think about the university environment: you go to a couple classes a day and then you make up your study time on your terms. You decide who you work with and when you work on what. On the other hand kindergarten is someone watching you all day. Which does your office represent?
- set your own daily schedule
- mini-summits a few times a year (hack-house) to come up with a vision - it's up to the team to decide based on need for vision of communication issues
- whole company gets together once a year
- autonomous - there are benefits to allowing your people to work on their own. This also allows you to bring more diverse people into your organization. It's easier since good people will leave other companies to work for yours. For instance GitHubbers don't miss dance recitals.

MEETINGS - what is the output of a meeting? Who generally comes out ahead in these meetings? Does it support the best ideas or certain personalities?
- chat rooms
- discussion lists (@ mention people)
- as long as it is logged someone else can find out about it on their time. you never leave people out


MANAGEMENT - what does management do? Managers solve a lot of problems, but they are not the type of problems that GitHub has right now.
Why would you have managers?
Assign tasks, coordination, facilitating communication - at GitHub they assign for themselves (everyone is a mini-manager)
Hiring and firing - informed by team, but the four founders make the decisions

Venn Diagram: your skills and interests - problems GitHub has = overlap: what to work on
This is what they tell new employees to work on

By using software to allow cross company communication they have not put personal bias or selective memory in the mix.

Pay structures - why are you doing bonuses? is it maslovian based or reward based?

Long hours - do you implicitly or explicitly look for this and is it important for the business? Is it a badge of honor or a badge of foolishness

Benefits and perks - they've decided against free food because they want to be good community citizens and have people dine at local establishments

Retention counteroffers - in the long term is this in the interest of the company to have people there only for money?

With everything go to first principles and see if the thing is supported.

For their IP assignment legal document they passed it around and let employees fork it and give input which resulted in a better legal document in the end.


Ask these three questions on everything:
What are our values?
What are we trying to accomplish?
What is the best way to get there?



Are you willing to put kittens on your factory floor?

How to Create a Culture of Shipping Product Continuously - Hiten Shah - KISSmetrics

Founder Bombs - when someone high up gives ideas to others and they have no idea how to deal with this thing that came out of the blue and seems to be a request, but it isn't clear. One person realized that a founder bomb only matters if in a seven day period it is mentioned three times

The solution to founder bombs has been for founders to be more mindful and also to find someone who can handle that kind of input. The challenge is to effectively balance all the forces.

What are you working on? Why are you working on it? - ask these questions to a lot of people and you'll learn a lot about the company culture. What's most important is to watch how they articulate what should often be the same message for everyone. It's important that people understand why the company exists and what they are doing and how it fits in.

Closed door decisions - you shouldn't hear "they walked out of the room with a decision about what we are going to do". You should be sure everyone on the team understands the goal.

"Build products people want" - Paul Graham

Shipping continuously is not enough. You have to ship the right things. Great products are created by people for people. Don't ship shit. Make the right product.

"Hire the most amazing people you can. Communicate goals. Turn them loose. Profit." - Sam Schillace, Box

Amazon's Two-pizza teams (2PT) - 6 to 10 people - this is the maximum size of a team. This reduces communication barriers and group think. Kahn likes the one pizza rule of 3 to 5 people.

At Apple they have cauldrons, 3 to 5 people. During a 2 to 3 hour meeting you put all of the ideas into the cauldron. The idea of it is that the best ideas can bubble up from the cauldron without people thinking about who had the idea since all of the ideas go in blank into the cauldron. Don't worry about who's idea it is, value the idea on its own merit.

"The ultimate goal of building a company is to have the right product thesis at the right time." - Josh Elman

A product thesis is problems, use cases, and examples

Working backwards - "We try to work backwards from the customer rather than starting with an idea for a product and trying to bolt customers into it." - Ian McAllister Amazon
Amazon will create a fake press release first. KISSmetrics will write an internal blog post in the same sort of way. It forces you to really focus on what you want to build and why. It gets everyone on the same page about the project.


Cust Dev + Research + Metrics = Thesis -> solution team review (cauldron) -> Q&A on thesis -> plan solution -> defend the solution (iterate where necessary)

Golden motion - pick one metric or goal and build around that - happens with the solution team review


Seek feedback from your team. Have a postmortem.

Send a survey to employees - ask who hit it out of the ballpark last month, what feedback do you have. They are anonymous and optional. Find ways to get feedback.

KISSmetrics recently hired a happiness manager - half of her job is like an office admin/ executive assistant - the other half was helping the whole company be happy. She handles the monthly anonymous surveys, when is someone's birthday, what is someone's favorite beer. Someone focused internally and on the whole team.

Nothing to Hide: Living with Complete Email Transparency - Patrick Collison - Stripe

Had unconventional ideas: no office, pay everyone the same, not having a phone number, not having a receptionist

Later realized an office is needed if you have a few employees. Also that compensation has to vary.

Believer in ambient transparency, where you can overhear things in the office and join in if it is important to you.

At first it was just a couple brothers and they shared an email address so they'd be on the same page. With a third employee they configured gmail so all 3 could log into each other's inboxes. Later they configured the server to automatically BCC everyone on every outgoing message. This scaled to around 6 people, but of course they needed a new solution to scale further. For each functional area there was an email address. So for instance there was "ops" and "finance" which you could CC on any email if it was relevant. A new employee configures which of many accounts they will subscribe to (there's a script for it). It gives an ambient feel of what's going on in the organization. This means they aren't surprised by things that are happening. Employees are able to discover a lot just by searching through the stream. Also people get to learn about things outside their area, like for instance "legal" is a popular list for many who have nothing to do with it. A benefit is that this system seems to reduce politics. Some of politics is controlling the flow of information, but no one can do that. Some issues are that people get confused by things or a little surprised, but they seem to get used to that. Also it can be used as a crutch for implicit agreement by merely CCing and not getting authorization. People can loose too much time in email if they don't have good time management.

Overall there is a hive mind mentality where everyone can be involved. Other tools that can help for this are HackPad. It allows for transparency. By having this overall transparency meetings can be more efficient. Especially it calms fears about the board meeting. At Stripe a random employee is always invited to the board meeting to take notes and pass them out to everyone.


Lessons learned
 
1. get an office
2. it is net better to not have project manager. better to have engineers to manage. there is a faster iteration cycle when this happens. you get twice the amount of iterations
3. self discipline matters most in hiring people
4. hiring individual contributors who can be highly useful (have people do real life activities like find bugs or refactor code instead of text book problems)
5. a change of environment can have an amazing impact. hack trips to foreign countries are extremely impactful
6. happy culture is built from hiring happy people
7. don't underestimate how much people will want to learn about other areas of the company. bring them to important meetings, be transparent
8. have as much discussion about your code as possible - ways of doing things - idioms
9. have a build and run distinction in your team. every week have 25% of the team handle run while the other 75% handle build
10. make sure that group chat happens in your company. its a communication tool and a culture tool
11. have a shipped@ email address for people to send to when you have shipped something. it feels good to send to that email address and allows people to see what has happened. do pay attention though to the results of shipping (it's not a good thing to ship a bad product)
12. have a social@ email address to allow people to easily set up group outings (like, I'm going out for a drink, who wants to come along)
13. at around 25 people have a company chef it actually makes financial since versus eating out and people love it
14. visit your users on a frequent basis and get the rest of the company to do it too
15. offices are often not good for working late into the evening. the lights are often too florescent for evening hours. get ikea floor lamps to give a warmer feel at night. it helps people do their best late at night. (this lesson has been proven each time Stripe moves into a new office as they immediately see few people staying late until they correct the lighting)
16. tell everyone why you've fired someone. it helps reassure others about what happened and why.
17. thank people profusely if they give a criticism about the company (it's hard to speak up, so reward it)
18. constantly find ways to praise those who do the undervalued work.
19. preserve values more than culture.
20. don't talk about someone who's not present and incourage others to do the same

get involved: hack pad at bit.do/cultivate - https://hackpad.com/Culture-Hacks-8WwaHfFfZfl

Things that would be helpful - group chat lines (searchable logs, all OS, inline images) they use IRC - screen sharing collaboration for code (both terminal and screen)

What *Do* You Do All Day? - Kate Matsudaira - popforms

praise isn't always proportional to effort

how do you measure performance? hours (this isn't great), lines of code (supports inefficiency), bugs & tests (doesn't work), features (how do you measure the effort though)

the better you are at your job, the less people know about it because you don't ask for help or lean on others -- you gain autonomy

in teams without managers each member is actually expected to be a manager -- someone still has to lead

we need leadership, not likership

Abraham Lincoln lost almost all elections and failed at what he did until he was 51 and became president

leadership is a decision not a position

positive use of power is good leadership

sources of power: formal & informal

informal power is charisma, expertise, or relationship based

charisma - you have it or you don't. luckily it's not required

expertise - educate yourself and you'll gain it

relationship - build trust (it is essential)
    what is trust? your relationships with everyone are important (it is a weighted graph)

    elements of trust: relationship architecture, reputation, contribution

    contribution - what you do, setting an example, practicing what you preach (never ask something of someone you wouldn't do yourself)

    have integrity - even when people aren't watching

    ask for engineering integrity - how does the system fare a few years after go live

    know your timing - analyze (incorporate) -> estimate -> (confidence) -> actual -> (validate) -> analyze
  
    being on time shows you think other people's time is as important as your time
        ... and if you show up on time you've predicted the future accurately

    think about your coworkers - who is the person you admire the most? what qualities? Now, think about yourself, do you have those qualities?
      
     make sure others feel that you feel they are important - when you walk around imagine everyone is wearing a sign that says "i want to feel important today" - how can you help them with that
   
    celebrate wins - let people know when they've done a job well - help people celebrate
  
     be open to ideas that sound wrong. ideas are fragile. take an interest in other's ideas. take a moment before responding... then explore the idea
  
     empathy and attitude - when you come to work you should have sunshine not rain clouds. be cautious about commiserating with people. listen with empathy, but try to have good attitude and not take sides, but instead reframe (are we sitting on a boat in the rain, or are we on a great adventure?)

        relationship architecture - it's the trust graph of your relationships with others. Make 2 ordered lists: 1. the most important people on your team (those that get things done) 2. the people you have the best relationships with
        there should be a lot of overlap in these lists. you need to be more intentional with your relationships
        you are the average of your five best friends
        start with the leaders. don't' focus on title, look for the people that everyone follows. the people who stand up and everyone follows.

relationship troubleshooting
            - relationships are like filmstrips
            - apologize swiftly and sincerely (don't go to boss or HR)
            - don't deflect when there is confrontation

archetypes            - the jerk - dealing with difficult people - pause - a lot of times people are difficult because they need recognition or to feel important
            - sharkasm - the passive aggressive - seek resolution with someone's interests not their position - people hear what they want to hear
            - the outspoken one - has opinion on anything - sometimes experts - repeat back what you hear to them - list options and vote (put what people say on the whiteboard so they know they are heard)
            - the strong silent type - using post it notes to vote helps - talk to introverts one on one after meetings and pay attention to them, focus - ask questions wait for answers
            - the complainer - whine and act defeated - stay positive but realistic - just state the facts and how they'll be addressed

        Focus on the long term - be deliberate with who you have relationships with. difficult people change if you change. with your support and interest people can change.

where does success come from? it's not projects or work, it comes from people