Showing posts with label Culture. Show all posts
Showing posts with label Culture. Show all posts

Friday, June 8, 2018

The Big Five + Johari Window: Creating the Holy Grail of Personality Tests

As for personality tests, there are many options to choose from but which will guide us to the truth about ourselves? Meyers-Briggs? What kind of Ice-Cream are you?

Grouping and Sorting


We like to group and sort. At a young age, we learn this skill. But it doesn't mean that the world fits the models we create so nicely! And that's just it—we create models as substitutes when reality is beyond our comprehension.


Models help us communicate more easily with others. Imagine explaining a bird, for example, by iterating the entire set of species within the bird family. We didn't really get the classification of planets right until we found such an outlier that we had to redefine what it means to be a planet!

Binary Choices

We seen to like binary choices - 'A' or 'B'. A-B testing is the common paradigm for proofing a new feature design in application development. We default to two political parties in the US almost to a fault! I've noticed that my children respond more readily with binary choices. It's just easier to reason about!


The trouble is, binary choices are mis-leading. If you have two compasses, and they're slightly different, which do you follow? Either you need a third compass to prove out the faulty one, or you need to just pick one and go with God!


Is it accurate? When you move beyond the fervor of political campaigning, can you thoughtfully agree with everything on one platform vs another? Am I an INTP or an ENTJ? I've come out with both! Sometimes I align with E and sometimes I. Sometimes I'm Perceiving other times Judging. Seems logical that I straddle the line on those two factors.


Finally, with Autism they've done away with binaries. It isn't as if one is either autistic or not autistic. It really that we're all autistic to varying degrees. It's just another way of thinking 😔.

Beyond Binary Lies a Continuum

As it is with many things, our personalities lie on a continuum. If we take something like the Big Five, and rate each of the five traits on a continuum we will have a closer model of reality.
There is, however, a specific problem I want to address in how we collect the data. Self-selected ratings are prone to bias. Therefore, those surveys you take for yourself are highly prone to error. They may tell you more about how you perceive yourself or how you'd like to perceive yourself than how you actually are. And what good does that do you? After all you know yourself anyways, right??

Crowdsourcing

Besides the self-affirming nature of those questionnaires, the sample size is way too small—it's one! Thankfully we have social networks of friends who are generally willing to participate in social games. If only we can make it enough of a joy to participate in the game, that they'll readily participate. 50-100 question surveys aren't very rewarding! Enter Johari.

Making it a Game

The Johari Window model is kind of like a game. The subject and his/her friends, relatives, and colleagues choose adjectives that best describe the subject. The intersection of those choices fall into four quadrants: Arena, Façade, Blind Spot, Unknown. They're classified by whether or not the adjectives are chosen by the self and others.

The adjectives in a Johari Window are generally good traits such as "cooperative", "intelligent", and "friendly". There's an inverse called the Nohari Window which uses negative traits like "Stubborn", "Quarrelsome", and "Dense".

Combined, the Johari and Nohari Windows can give you a pretty decent view of how you perceive yourself compared to how others perceive you. The tricky part is to get enough participation to get a well-rounded view.

If you're interested in doing your own Johari Window, this one at Kevan.org is pretty darn straightforward. There are some other fun things at Kevan.org including this personality test.

 #   |.
###u#+.
     |)
If I were a NetHack monster, I would be a unicorn. Most people are only after one thing - I try to maintain a quiet and respectful distance until I feel sure that I can trust someone.
Which NetHack Monster Are You?

How about that...I'm a Unicorn after all! And here I was all along thinking I was a Bridge Troll.

And... if you haven't lolled off into Kevan-land by now, I'll be getting to the point soon.

Participation

Getting participation for something unfamiliar or that's going too much out of one's way is challenging. As previously mentioned, social media can help with this. It has familiarity, where an unfamiliar and poorly designed website can make others standoffish. You've got to expend some social capital on getting folks to participate.

That's not good. We want to build social capital with these exercises, rather than spend it!

Combining FTW

I'm thinking of combining concepts from the Big Five (or six, or whatever) with concepts from the Johari/Nohari Window.

This will work like this:

  • Use traits from the Big Five or HEXACO or some other number of traits
  • Present adjectives that fit with each trait (positively and negatively correlated)
  • The subject participates and asks for participation from acquaintances
  • From each trait group, participants choose 3 adjectives to describe the subject
  • There are two questions about the participant's relationship with the subject
    1. What type of relationship (choose all that apply): business, friend, family, acquaintance
    2. Scale of 1-10, how well do you know the subject
  • The subject answers the same 2 questions about each participant.

Additional Setup Details

Adjectives in each trait group vary in scale. For example, for the trait "Openness" some adjectives might be as follows:
  • accepting
  • progressive
  • open-minded
  • close-minded
  • conservative
  • curious
  • dull
  • intolerant
  • tolerant
Another option is to use emoji or some other visual indicator which is more culturally neutral to represent the adjectives.

Scoring

The strength and number of times each adjective is chosen are combined to give the rating scale for each trait. For example, if the traits given for Openness were selected as follows:


adjectivestrengthweight
close-minded-55
dull-72.5
intolerant-42
conservative-17

The subject would be considered low in Openness (-57.5).

Besides the ratings scale, the quadrants of the Johari Window can be brought into the model to provide more useful information to the subject. The concept of "known to self" and "known to others" is powerful in realizing how well we know ourselves and how we present ourselves to others.

In our example of Openness, we can also see that the subject did not pick any adjectives which are positive indicators of Openness. Therefore, the subject is not blind to this trait. This is the Arena quadrant of the Johari Window.

Anonymity and Sample Size

Two must haves in order for this to achieve useful accuracy are anonymity of the participants and large enough sample size of participants. They support each other. Large sample size secures anonymity. Anonymity allows more people to participate without fear. Additionally anonymity allows one to be more candid with their responses.

Diversity

A diverse sample is also important to get a more holistic view. The subject will be known in different ways by different people. This is the nature of relationships.

Conclusion

By combining concepts from the Big Five and the Johari Window, a better personality test can be created. What's more, is that this type of test will find more willing participants because of the fun nature of choosing a few adjectives rather than using something like a Likert scale (strongly agree, agree, neutral, etc.). This test is not strictly self-reporting, therefore not as subject to bias.

Friday, March 9, 2018

Do The Gemba Walk

As a developer or analyst, you should sit in your users' seats so that you fully understand how to meet their needs. Interviewing is merely an introduction to those needs. In Kanban, they do a Gemba walk, which means going to where the work is done. We call it management by walking around. This is fine for management, but for actually creating something that helps the users or the business, one needs to actually do the work to comprehend the actual problems in order to solve them in the best way
While doing so, keep in mind the user's technical skill and framework. You may find that your applications have more than one persona using the application. A persona is different from a role. You can have many personas in each role. Let's say a Legal Assistant is a role. Those users may or may not be tech savvy. Consider that in your UX design!

Thursday, November 16, 2017

Culture of Interactions

The Agile Manifesto puts the value of "individuals and interactions over processes and tools". Meaning that a conversation is where the work starts. Meaning that if your processes/tools are getting in the way of human interaction then you aren't practicing this value and not getting the benefits of Agile. For example, work requests delivered long-form via email is not an interactive process.


Agile processes generally use User Stories as a starting point for any development work. Just what is a User Story? It's really a placeholder for a conversation, no details except a concise introduction of the user's goal - "As an end-user, I want to print my essay so that I can mark it up with red-ink and make revisions based on the markup." This is the user's perspective. It isn't even about the user story, it's really just there to keep track of something.


As a technologist, I might want to poo-poo the idea of printing and using ink...or even wasting paper as an environmentalist...but this user story is her story, not mine. Through conversation, there may be a change of heart, but that comes into the fold of negotiations.


Through the initial conversation, we should come up with some Acceptance Criteria. It's documented, but not written in stone - it's just a first pass. It should be fairly basic and relatively quick to implement. May not be complete yet, but could be. The Acceptance Criteria is also known as the Acceptance Test...User Test...Story Test. It should describe how the user would validate the implementation (then we automate it, but that's for another time).


"When I click a print button, the essay should print. I should be able to go to my printer and get the printed essay from the printer. All pages should be there."


What can go wrong there? If have any experience with printers, we know there are too many ways that can fail! Printer out of ink, paper, jammed, just not having it that day, not connected, off. Computer/OS not happy with printer config, dialog comes up before printing, not connected to network. Network failure. Mercury in retrograde.


Perhaps in some future world, printing will just work, but for now we need to revise the Acceptance Test...that's why we need to work on it together...


"I can't promise the essay will print, but I can make it so that there's a print button which will tell your computer to print all pages of the essay to the default printer, or I can have it launch the print dialog."


There's some negotiation. There's supposed to be, it's another Value. But first, we should try the simplest thing that works...do whatever the OS does when you want to print. And that just might get the job done.


Without the conversation, we'd have wasted half the project schedule on documenting something that was nearly impossible and then attempting to implement something that was doomed to fail anyways...at least when Mercury isn't playing nice!

Monday, October 9, 2017

Cause of Death: Optimization

So you've got this team - developers, business reps, product managers, QA engineers and they all need to work toward building out products that add value to the business (either directly, by reducing risk, or increasing efficiency). The business has some goals. You have some goals. Bonuses and career advancement and frankly job security are tied to those goals.

At the same time its difficult to find the right people. There are plenty of applicants but who can be trusted and who has the right level of expertise to jump right in and get things done because the backlog is growing and the work is piling up and everyone wants to know if you can deliver and of course when.

The New York Times wrote up a great article on how to find the right candidate. The thing is, once you've found the right candidate (well-qualified, energetic, enthusiastic, etc..) what happens next depends. Lets walk through the process and see why.

Ramping up


In order to make good on your deliverables, you need more headcount so you can get more done. You're at capacity and just can't ask your people to put in anymore. Once that's approved you now have the task of staffing the right person. You need to throw someone in straight away and start knocking things out because your way behind already and in order to justify the added cost, you want to show results.

So now you ask around internally - this is the standard pattern - if anyone knows someone who is ninjas at xyz. I'll tell you right now everyone who is ninjas is currently working. You'll need to do some sales - or typically hire a salesperson (recruiter).

So now you're in it with the recruiters for about 20% give or take. For a 100k salary, that's 20k...say I bet that 20k would make a great training budget! The person you really think you need actually costs more than $100k. First off in a supply and demand economy where supply is limited and demand is high you're on the downside of that. So $130 plus all the other costs and recruiter fees.

After the Onboarding

Once you've shelled out the upfront costs and now this maverick is on your team they'll need to be brought up to speed. For a while this will slow down overall production. One or more of your resources will need to be involved regularly in working with the newbie to get them up on the tools, practices, procedures.

It'll take some time before the dust settles. Lets estimate 4-6 months depending on the learning curve for a well-designed, documented, unit tested, and maintained system...1-2 years for most systems...longer for train wrecks. You are likely to be in the 1-2 year range and please don't lie to yourself because that's counterproductive and were focusing on being more productive. If you know I'm wrong in your case, then you probably don't need me to tell you all of this anyways, you can close the tab and carry on as you were.

Once the Dust Settles


If you're still with me and haven't gone back to balancing your budget or sipping your morning coffee while touring your friends' feeds, I'm glad you decided to stay because it's about to get real.

Taken on the surface and without considering long-term stability, hiring the right person in that moment is a greedy optimization. Greedy optimizations seek to optimize the whole by optimizing the parts of the whole with the hopes and assumptions...well...that it will improve overall performance. Often active stock traders attempt to do the same. Rarely does it work out; one reason is that active traders are likely to sell when things go south. In stock trading, emotions sabotage long-term results. In the same way, needs-of-the-moment hiring practices sabotages long-term health of the team when not considered along with overall team dynamics, culture, and performance implications.

A rockstar-unicorn-ninja-whatever is not going to solve your productivity issues if those issues arise from broader optimization issues - morale, communications and team cohesion especially. What WILL happen if there are deeper rooted issues is that the ninja will come on for a bit, do some things and ninja-smoke off when they figure out how deeply rooted the issues are which causes a degradation of the three most important factors to said ninja - autonomy, mastery and purpose. Not only do we strive for those three, but we are inherently social beings - nature calls for having social well-being. When our social well-being is not upheld we will fall behind our potential.

And you're still on the downside of the market, so there's that problem. I will guarantee you that salespeople are at it regularly pitching the great folks on your team. Any give one of them has inboxes full of emails and messages from recruiters. The other side of most of those openings are mirror images of yours in that their either adding or replacing staff because they've got a pile of work to get done yesterday. Some aren't but most are.

Solutions

You've got to offer something they don't. Compensation, bonuses, and benefits are a given in any decent market. Anyone worthwhile can get those anywhere. Your business may operate in non-IT markets and perhaps are on the upside of the supply chain (unlike in IT). But in your technology departments you're on the demand side - you need good people and the supply is limited.

In order to combat such a position and come out ahead you have to optimize for the long-haul. There may be some short-term goals that occupy much space in the present, but even if those are met you may end up in a position that doesn't set you up well for the next steps, the next goals...it's all about being strategic! Look for more global optimizations rather than local ones - unless the local optimizations truly do lead to a global optimum.

What you've got to do if focus on 2 things - optimizing your workflow and retaining talent. Both of those involve investing in the talent you've got on-hand. If you are willing to take a $20k hit for hiring new personnel or a $120k+ hit annually you certainly have the ability to work on improving the personnel you already have. Additionally, you can certainly afford to improve your system or process. Take a serious look at any bottlenecks - technical or otherwise - and address knowledge gaps, personnel conflicts and process issues BEFORE adding more calamity to the mix by hiring.

Get out there and spread some buzz in the developer community about your organization. When you're ready to hire - when your house is in order and you are prepared to properly on-board - you'll have developers coming to you rather than having to hard-sell. Basically you'd be marketing which makes it easier to sell. Having a great team, process, and organization to brag about is a great way to attract the top talent that you will now be able to retain.

Non-Solutions


Consider hiring all rockstar devs. They may all be fantastic in their own right. And at the same time if they can't work well together or communicate or the process hinders productivity anyways or they end up building the wrong things - it doesn't matter how good each one is.

And how about the case of pushing to get a release done? By pushing I mean everyone working late and just churning away...dropping principles and mounting up debt to get the thing done. That's a way to burn folks out and in this heyday of IT, that's a recipe for exodus. As far as turnover goes, going back to the active traders, fees are costly and chew away at the gains. You've got to have retention for the long-haul.

But that's not the only danger with churn and burn. What's left behind may end up slowing things down significantly in the future. Move too fast, slap things together, drop important practices and time for reflection, team building, etc and it'll only lead to further entrenchment of negative reinforcement - a negative feedback cycle. This has been well-known for a long time now.

Adding people will always slow things down for awhile. Adding them to a late project is classic mistake that no-one should be making anymore.

Outcomes of Successful Solutions

Once you've applied a successful solution, you should be able to compare the outcome to the baseline. That's right, make sure to capture your current state so that you can KNOW that you've solved solved the problem.

You should be seeing better employee retention, improvement of skills, lower stress, higher morale, engagement, proactive behavior, lower bug count if you'd like to address that metric, and more valuable production if your process is really in order. The latter may be beyond your own sphere of control, but perhaps it is not beyond your sphere of influence, but since this post is about the productivity of your own group it may well be beyond scope for now. However, that's arguable since your productivity should actually be measured by the actual value delivered. I'm sure to do a post in the future about that.

Friday, October 6, 2017

Cultural Evolution Part Three

First off, I must apologize for skipping over the topic I promised in the last post in this series. I'm working very hard on that promised post about the algorithm that looks good on paper. Something has come up during the course of a book I'm writing that I feel an urgency to blog about. It fits nicely with the theme of this series, so here it is.


Think about how we are biased from a very young age to play against other teams. To compete and even to think of the others as lesser beings or the enemy. We play soccer, softball, football and chess with the intent to beat the other side and celebrate victory. In our passive involvement in professional spectator sports, we get fired up about our team and even hurl insults at fans of the opposing team in and out of the stadiums and parks. Some of these are our colleagues we work with, others just fellow humans - probably good people too. But that's how we're biased from such a young age. It crosses political boundaries as well - cities, states, nations. As well as cultural boundaries. Always there is this notion of "the others".


In business, and at your company, you've got many teams working in different areas. This "team bias" that's built-in has to be overcome if your company is to act as a whole. While there will always be some level of internal competition, for better or worse, you can tilt those scales to better by setting and socializing the overarching goals of the company. In this way all if your players will be running in the right direction.


How does this help? Setting, socializing, and tracking business goals at the organizational level puts everyone together into the same team. Who or what do you compete for in that scenario? Rather than competing between departments, units, or teams the competition is aligned toward the achieving those goals. As always the organization's goals need to be in alignment with its mission, vision and values!




Thursday, September 28, 2017

Cultural Evolution Part Two

Yesterday I posted about how I evolved the process by improving the work tracking and planning tools. Today I will tell you about what we did that brought people together into a more cohesive team with high morale.


One day, I got an awesome board game as a gift (thanks to my amazingly thoughtful wife). It was a fantastic little strategy game that anyone could play. Gameplay involved dynamic shifts in both political alliances and strategy. This game was called Quorridor. There is beauty in its simplicity. It's easy to pick up which makes it the perfect catalyst for bringing people together for some clean, competitive fun. We played over lunch maybe a couple times per week. Our manager joined us and we all had a good time together!


What inspired this? Something stuck with me from when I was in the live sound business. One day, while working a gig at the Cadillac Theater I saw the house crew playing chess backstage to pass the time between setup and performance. There's a lot of hurry-up-and-wait in that business and usually you'd try to get a little shut eye since the nights were late and the days were long. I recall many days of just sort of sitting there trying to get some rest or exploring; but playing chess was how I really wanted to pass the time. That was the only crew I ever saw passing time that way and it stayed with me.


When I started my development career, I was itching to play some strategy games with colleagues. We'd go out to lunch together and they even had a Foosball table in the lunchroom. But none of us really spent a lot of time in the lunchroom because it was on another floor. Game playing started small, maybe a couple of us. Then we had some regular players and swapped others into the fun.


It was great for morale and a fantastic way to take a break from the work and go back in with a fresh start. Another benefit was the way it brought people together. The benefits of brining teams together are enormous...companies will send their teams on weekend retreats for such things. They'll have weekend events with BBQs and after work parties. Those are all well and fine and maybe often a little forced - those mandatory extra-curricular activities that often cause disruption in busy personal schedules. On the other hand, game playing over lunch is easy, optional, and not disruptive.


Something like this has to be driven by the team! And it needs to be supported by management. There's a fine line there. Sometimes a manager can just be a person and this is the context for it. At the same time, managers can have a BIG influence in the success of such things by jumping in and especially by not shutting something like this down. Heck, take some time for these things during working hours! Maybe on that Sprint Wrap up day after you've shown off your accomplishments for the Sprint. What else would you do for the rest of the day? Try to jam in another feature? No way! Sharpen the saw! Do games, coding challenges, put together a jigsaw puzzle...whatever the team decides!


I know there's some counterintuitive thoughts around this (I've encountered them)...were not being paid to play games were being played to build features. That's true. Fortunately, teams that play together stay together and there's no better way to get more done than with great team cohesion and high morale. It's an investment in a more productive team. So keep on organizing the work at a nice steady pace and helping each other out (by working together) and you'll have the time anyways - its a positive feedback loop!


Next post I'll talk a bit about local optimization vs overall optimization as it applies to teamwork and workflow. Here's a hint - there's a class of algorithm involved.