Management

Thoughts On Neurodiversity And Management

Posted by

0

This is a re-posting of an article I wrote on LinkedIn on July 17th. It’s re-posted here as a record of all my thoughts on neurodiveristy in one place.

Diversity in general must be a deliberate effort. This starts at the organizational planning stage. When developing an organizational strategy you need to include diversity as a factor. The same as you would consider different roles and experience levels in your plan. Diversity can be called a “big thing,” and it is. It covers race, gender, sociology-economic background, neurodivergence and more. I’m not qualified to talk about these in detail. So rather than try, I’m going to talk about team diversity in the abstract and then dive into one area that’s close to me. Neurodiversity.

To talk about diversity and leadership I’m going to lean lightly on Nietzsche’s theory of perspectivism. “A thousand goals have there been so far, for there are a thousand peoples. Only the yoke for the thousand necks is still lacking: the one goal is lacking.” Think of diversity as the 1000 perspectives that match those goals. Each brings something rich. As a leader it’s your job to be deliberate in which perspectives have a seat at the table and the role they play. In other words to craft the one goal. It means being thoughtful about what’s needed by the organization. How each perspective supports and enhances the others. Diversity doesn’t happen by talking about it. It happens through thoughtful planning and actions. Too often organizations get caught up in the notion that a role is a cookie cutter. Everyone must fit that shape. The reality is that lot’s of gingerbread people have missing limbs. There is no such thing as a pegacorn (part pegasus, part unicorn). But there are eagles, horses and narwhals. Managing to the cookie cutter is easy. Taking a look at the over all shape of the team and finding the perspectives that fit that shape is hard. Being a leader is hard. I find it sad that so many people, who are otherwise good leaders, choose the easy path of management when it comes to diversity. Be better.

That said, I’m going to pause for a moment to look at Neurodiversity. This is a broad category that includes things like Dyslexia, Attention Deficit Hyperactivity Disorder, (ADHD), Autism Spectrum Disorder (ASD), Obsessive Compulsive Disorder (OCD), Chronic Depression and others. Some estimates claim that between 20% to 25% of the population falls into this category which spans all other diversity categories. I’ve recently discovered that I’m one such person, having been diagnosed with Level 1 ASD (ASD-1). According to the CDC about 1% of the world’s population has autism spectrum disorder. That’s over 75 million people.

What does it mean to have ASD-1? ASD-1 is inclusive of Asperger’s syndrome and has replaced it as a diagnosis. ASD-1 also covers the unofficial term “highly-functional” autism. Beyond that my diagnosis is new and I’m trying to figure it out. I’m still me. Nothing changes that. ASD is and always has been a part of who I am. Only now I have a name to it to start developing mechanisms to help me in areas I struggle with. But in general it does mean a few things. I’m a person with autism. It gives me certain super powers. It makes me vulnerable to types of kryptonite. And it means I’ll never fit the shape of that cookie cutter.
I’ve been fortunate in my 25+ years in technology. For the most part I’ve had leaders who let me stretch and grow my super powers. They exposed me to safe doses of kryptonite and didn’t force me to play with it. They let the job reshape to me instead of insisting that I conform to the shape of the job. To me this is a key aspect of a neurodiversity strategy. Honestly this is good leadership in general. Over time I hope more managers see it this way. Diversity is another factor of organizational strategies. Good leaders leverage it to build stronger teams. This isn’t an alien concept in management. When I was leading my last team I leveraged a tool called strength finders. What I’m talking about here isn’t that different in concept. Diversity uses different criteria but follows the same principles. You’re building a team that works stronger together by sharing strengths to overcome challenges.

Am I saying that every job and role should make accommodations for everyone who’s neurodivergent? No. This is an area where neurodiversity differs from the other diversity categories. Though I’m still learning and may feel otherwise in the future. For example, I don’t think I’d ever be very good in a sales role. But, I can and have used my super powers to partner with and support sales people. Does that mean that someone else who’s neurodivergent wouldn’t be great at sales? Of course not. Leaders must be thoughtful and deliberate in planning and making decisions about diversity. They need to understand how different perspectives can elevate the team and how they might hinder. Saying, “there’s no way a neurodivergent person can do this job,” is managing to the cookie cutter. Be better. After thoughtful planning if you may determine there are certain non-negotiable perspectives needed. Be deliberate and transparent about them. To do otherwise invites failure.

The pandemic has thrown many of my normal routines in flux which has made the last few years rough. In some ways that may have been a good thing as it’s lead to my recent diagnosis. I’ve also found myself in a job that expects me to fit a cookie cutter. I’m learning that no matter how much I may raise the bar through my super powers, the kryptonite won’t allow me to be successful at all that’s expected of the role. We live. We learn. We move on. And so shall I. But I’ve found myself wondering a few things. How many good people have been discarded because they don’t fit “the shape?” Or worse, how many never had the chance to try?

Epilogue
Deciding to publish this article was more difficult than I anticipated. I’ve been processing my initial feelings about my diagnosis. Part of me wants to shout from the roof tops and share every thing I’ve learned in these first weeks. One thing I learned through the diagnosis process is that I’ve become good at hiding my symptoms. There’s that lizard brain part of me that want’s to keep hiding. The lizard whispers to me, “It’ll hurt you if people know. They’ll treat you differently. It won’t change anything so keep it to yourself.” I don’t know if sharing this article will change anything or help anyone. I do know that saying nothing guarantees its own outcome.

My mechanic gives great back rubs…

Posted by

0

And it’s a good thing too, because I spend a lot of time at the shop. Seems like there’s always something wrong with my car. Whenever my car starts making noise or leaking oil I get so stressed out, and by the time I leave the shop I feel so much more relaxed. I go to my mechanic at least twice a week, and it just melts away my stress.

Are you focused on the right thing, or are you visiting your mechanic to relieve your stress?

The Cloud and Corporate Compliance

Posted by

0

I think a main point of consideration for any company looking to use the cloud, in any of it’s various forms, needs to be to have a strategy before going hog wild. Not only to asses for cost, but also to expand existing policies, such as data governance, to include rules and guidelines for when and how to use the cloud.

For example lets say you already have data classifications of “green”, “yellow” and “red”, green being data that is already publicly accessible and red being data that is deemed to be so confidential that it could be damaging if released. I’m simplifying things a bit, but you get the idea. Because all of your data, and any applications accessing it, already fall into these classifications, you can go through an exercise wherein you certify a cloud platform, first as being suitable for green, then yellow etc. These certifications should be setup with guidelines and security protocols that also needed to be implemented in order to be considered in compliance. You could find that initially you do not certify it for red. Not so much because you feel the platform has security issues, but perhaps because Legal may feel the risk is too high based on their understanding of the platform. (Yes Legal should have a hand in your data governance policies.) In a case like this you may go through a cycle of educating Legal and the business in order to reach this certification, or you may decide that you never use cloud resources for certain aspects of your business. There is no rule that says you need to use the cloud for all of you business needs.

I’ve also heard concerns about data access and international law. I’m not a layer, but do want to try and address this to some degree. The argument I recently heard was that if a company in the UK uses the cloud and then that date ends up on a server in the US, the government can then go after the data on the US servers and that grants them access to the data in the UK servers as well, even if the data in the UK didn’t exist in the US.

I’m not going to disagree with this per se, but with respect, I do feel that this argument simplifies the legal aspects to the point of being misleading. For example, in all of the PAAS cloud platforms I’ve ever worked with (I’m not including SAAS models like salesforce), they don’t just place your data in a random location. You have to explicitly specify where you want your data to live, and this includes CDN’s. A CDN doesn’t just drop your data everywhere, it only replicates to the nodes you select. One of the main reasons for this is because of the very root of the previous concern (The other being cost differences). The argument is not actually cloud specific, and applies equally to a UK company doing business in the US, with data hosted on their own servers living in a building owned by the company. In fact, in that case it’s even easier to for a law enforcement agency to get the court to grant access to the data, as there are no concerns of accidentally granting access to another company’s data. OK I’m guessing as to whether a judge would take this into consideration, but that guess is based on having spent a few years in the electronic discovery industry. As a part of that job I performed litigation readiness assessments, and had to be versed in US laws involving electronic data discovery.

So while the concern is valid, it isn’t just valid because you are considering moving to the cloud. It’s why I encourage clients to evaluate the cloud in the context of current policies, rather than thinking those policies don’t apply, just because they don’t own the servers. If you’re a serial litigant (you get sued a lot), or are a target for government investigation due to your business practices, chances are you already know that and have policies in place to compensate. For example; in the US if you also do business in China, you already have a whole series of policies and procedures to make sure you stay in compliance with federal law. Those same policies don’t stop becoming relevant just because you are now using cloud computing, and need to be incorporated into your overall cloud strategy.

__I originally posted this as a response to a thread in the LiDNUG forums. While I’ve tried to modify it enough to stand on it’s own, please forgive any incongruence’s.__

More Spikes Early in the Process

Posted by

0

Late last week I was working on a problem where I only had about an hour and a half to try and come up with a working solution before reviewing the code. While working on this I went down several false starts, and by the end was not very happy with the progress made. I was trying to create a working solution to a problem I didn’t fully understand.

This morning as I was getting ready for work, I was recapping various things in my head, as I’m oft to do. I began thinking about this situation from a different perspective. What if instead of thinking of the effort as trying to code a working solution, I thought of it as a spike. Suddenly where I was disappointed earlier, I now felt more confident in my progress. The fact that I had tried several approaches, failed, and thrown them out in favor of something else, was now a good thing. This is the purpose of a spike. Not to produce final code or even code you will move forward with, but to determine the approach you will take with the actual code base.

Generally I think we tend to consider spikes to be tied to complexity, and things that we don’t know how to estimate. What if we were to consider doing spikes early in the process in order to help drive out architectural approaches, and help find hidden requirements. I normally try to include a sprint 0 in a first release to allow for time to get project basics and infrastructure in place. We also normally do a few spikes during this time, but suppose we expanded our spike efforts. We could target business elements that are key, don’t have a lot of complexity, but that may have multiple ways of implementing. Once these spikes were complete the team could review the findings as a whole. It may be that architectural directions that are sometimes discovered over time, can be set correctly from very start.

This may not seem strictly agile to some, but it certainly does not break our agile principals. It simply means that you can take a wider view of what you consider for a spike. Early in the process where understanding of the business domain might be low, spending some time on a few targeted spikes you might not ordinarily consider, could save some hassle down the road. Remember that sometimes it’s the moderate problem with multiple solutions that a team can spin on while trying to decide the “best” way to solve it. Now in reality all of this is straight forward agile, but often times there can be pressure to reduce spikes in order to get right to usable code. We only create spikes for what we deem necessary and not to prove out architecture, or design path.

Now back to the original situation that brought this topic up. I have to wonder if I had walked into this session with the thought in mind that I was doing a Spike, would I have gotten further? Would I have stopped writing code sooner, after I determined my approach and switched to documentation? I’ll never know because I entered into the effort in the wrong mindset. Now, when placed in the same situation again I hope that I augment my thinking up front, but I’m human and occasionally I need to make the same mistake a few times before it sinks in.

PS: I think there is another topic hidden in here that may be worth exploring. The notion of integrating Domain Driven Design into Agile. Unfortunately DDD is not a topic I have much experience with, so any investigation down this road will need to be theoretical at the moment.

Agile As a Sequential Art Team

Posted by

0

Last time I ended by bringing up the metaphor of the agile team as a team of sequential artists with the Customer in the role of writer. This time I’d like to further explore that metaphor and see if we can find something viable here we can latch onto. So while this is a thought exercise I’m always looking for ways to explain how agile teams work to those not familiar with the methodology. I’m also always looking for ways to improve how our agile teams work. Let’s see where this metaphor can take us…

For the sake of our analysis I’m going to pick the most straightforward form of sequential art, the graphic novel or as it’s colloquially known, the comic book. I’m making an assumption that I don’t need to write a definition here, but if you feel you need refresher here is a link to what wikipedia has to say on the topic.

In order to dig deeper into this metaphor let’s try by defining the different roles in a typical comic team and compare them to an equivalent on an agile development team.

Writer: The writer is the one who owns the story. They define who the characters are, what motivates them, and what they do in the world of the story.

Agile Equivalent: Customer. As stated before, this is our agile customer. They own and define our agile stories. Too often I think people see the Customer as the Editor and place the Architect in this role. Unfortunately this places the Customer in an after the fact role and distances them from the team. We’ll talk more about the role of the editor later and I think you’ll better understand what I mean.

Penciler: Sometimes, though not always, referred to as the artist. This person takes the writers script and gives live to the story. They work closely with the writer and together are typically seen as the creative team of a comic.

Agile Equivalent: All Developers. I’d really like to make a case here that every developer has the potential of playing this role on a project. Remember that in agile we have many stories, and the execution or development of each story each story may be owned by a different developer. In this way each developer has the potential of being the penciler of a story with support from one or more other developers in the following roles.

Inker, Letterer and Colorist: I’ve lumped these three roles together not to diminish them, but rather to set them up as both support and specially roles. Indeed an inker on one store may be the penciler on another. And understanding how the application of certain colors will look in the final print copy is invaluable.

Agile Equivalent: All Developers. Again because agile is many stories, within the course of one project each developer may not only play the role of penciler, but will also play supporting roles for others stories, as their skills warrant.

Cover Artist: This is usually an artist of some renowned. While they may not be a part of the permanent team they are brought in to create the covers of comics. These are usually given more time and attention to detail as they are intended to draw potential readers in and entice them to purchase the comic.

Agile Equivalent: Change Management Specialist. It would be easy to say that this role is equal to a technical specialist brought in to solve some particularly challenging problem, and I can’t argue that this is a valid analogy. However; I think that a more useful correlation is with change management. A good change management plan is the number on away to improve adoption of a system, which after all is the goal of cover art.

Editor: The editor is responsible for the quality of the product. They need to make sure that the work begin done meets the needs of the publishers overall goals, and also help to endure that everything gets done on time. Editors also help to remove roadblocks and sooth artist egos when needed.

Agile Equivalent: Scrum Master. Nuff said.

Art Breakdowns: This role is not often seen in comics as the penciler will normally take on this duty. However; on occasion an artist will be brought in to sketch out all of the flows within a comic. this is usually done in cases where multiple creative teams are weaving a series of stories together. Each team is telling their own story , but this over arching artist is preparing the page layouts and weaving all of the story arches into a seamless whole. These breakdowns are usually rough sketches so as not to override the vision of any one team, and in fact the final art, while adhering to the page layouts will look dramatically different from the sketches provided. In many if not all cases the artist doing the breakdowns works closely with all teams to ensure that each teams vision is respected while at the same time guaranteeing the overall quality of the whole.

Agile Equivalent: I think there are two answers to this. The first is a bit more traditional and really only applies in certain types of projects, while the second tends to be overlooked or out and out dropped from scope, but in my not so humble opinion is potentially more important.

  • Enterprise Architect. In a large enterprise project or when dealing with multiple competing platforms, it is the job of the EA to make sure that all the pieces flow from one to another properly, each performing it’s part in the whole. In some ways this role can also be considered a part of the Editors role as an editor is often a key figure in preserving continuity across story arcs. Think governance and compliance.

  • Experience Architect. This is a relatively new role in the software world, and suffers from much of the same ambiguity that enterprise architecture did a few years back. Some feel it belongs more in the domain of the designer and others feel it belongs more in the world of the business analyst. Personally I don’t think either is truly accurate. This is a role that’s emerging out of a gap in the current skills and roles as we have them defined in software development. I’ll try to post more about the the definition of this role in a subsequent post, but for purposes of this topic, the individual filling this role needs to make sure that all of the various moving pieces come into play in a way that creates a satisfying experience for the user, and that going from one part of a system or application to another is not jolting or abhorrent. This means understanding all components of a system, and understanding how both design and technical decisions will impact the experience.

While this metaphor isn’t 100% accurate I think it offers an interesting slant on the agile team and it’s dynamics. Particularly in illustrating the importance of certain non technical roles. I especially like how it points out the importance of the customer as a vital and active part of the team. To often clients say they understand their role in an agile project, but when it comes time to start work they don’t understand why the team wants so much of their time.

My company uses the slogan “The art and science of winning.” In that spirit I think this metaphor helps point out the fact that the methodology can truly be seen as the art of science as it pertains to delivering software.

Thanks for reading. I know this was a long one. And, as always, keep thinking malignant thoughts.

The Road Less Traveled

Posted by

0

In consulting there are always challenges to be faced around staffing projects and managing the bench. While some are difficult to control (the economy for example), others can be worked on, and in truth do not need to be issues at all. I frequently see the following two scenarios, which fall into the latter category.

Scenario One: One region may be overbooked while another is on the bench. The people in the overbooked region are working 60+ hour weeks, and if things don’t change some folks are in serious danger of burnout. Conversely the people on the bench are bored and looking for a good project.

Scenario Two: A developer is staffed on a project because they are “down the hall” and have availability. While another developer may not be down the hall, but is also available and has the required skill set that the first developer doesn’t. While availability may not be a skill, familiarity is simple and comforting.

Are there multiple factors that go into both of these scenarios? Of course, but please allow me a bit of freedom to focus on what I consider to be a major contributing factor. Fear of the unknown. People don’t want to risk introducing unknown factors into their projects. It’s much more comforting to burn the people you know even hotter. It’s still a risk, but at least you know what those risks are. Besides, chances are the consequences will either be someone else’s problem, or at the very least come after the immediate crisis is over. In my experience people tend to quit after the project burning them out is over. Now I can’t really fault them for this. Fear of the unknown is baked into us, and for good reason. The caveman who ventured over the ridge without knowing what’s on the other side seldom returned.

But let’s take this a little farther. What happened to that caveman? Was he mauled by a tiger? Did he fall into a chasm? Die of hunger? In some cases certainly, but in others I think something extraordinary happened. They found greener pastures and new tribes to join. Sometimes they may have come back to their origins, and sometimes they were simply never heard from again. And what happened to those who stayed behind? Did they persevere as the bravest of them left, or did they wither and die, slaves to their own fears?

Ok, so I’m exaggerating and generalizing to make a point, but that point is valid. We’re taught that you’re better off with the devil you know. Allow me to let you in on a little secret. Sometimes the devil you don’t know is much more fun. I’m not advocating jumping blindly into the maw of the abyss. Go in eyes open and be realistic. If you bring on another resource and expect them to dive into the toughest part of your project, you may be setting them and yourself up for failure. Conversely if you keep them on the edges of the project doing small bits of cleanup work, then you marginalize them, never truly integrating them into the project or the team. While you may not be setting up failure here, you also aren’t allowing for yourself to be surprised and delighted. And please, PLEASE, don’t pull in a resource at the end after, your core team has left the project and expect them to save you. That’s called putting the turd in someone else’s pocket, and will end in bad feelings all around.

So if you find yourself in the situation where you can either trod along in quiet desperation, or welcome a new member to your tribe, take a chance. Walk the road less traveled. Hopefully you’ll be surprised and delighted. At the very least you’ll learn something about yourself and someone else.

So. I didn’t quite end up where I was headed at the start. With this post I start a series of ideas and thoughts I have been gathering about the challenges of working in and across groups. Taking a chance is just the first step. In future posts I’ll be exploring some of the challenges you’ll face once you start working outside of your immediate tribe, and explore some tools to help you navigate the road ahead.