Thursday, 19 September 2019

How do you Re-energize a workforce?



Drive... what a great book. And great TED talks.



One thing though, many of the things Pink describes in "Thirteen Ways to Improve Your Company, Office, or Group", I've tried them in several jobs. But they don't always work!

I have tried:

  1. Time for the non-comissioned big idea.
  2. The 20% "Operations Excellence" time.
  3. The Google or Fedex day.  (Or the Hackathon.)
  4. Inversion of control.



I have not tried:

  1. Autonomy audits.
  2. DIY performance reviews.
  3. Peer-to-Peer performance reviews.


The problem is how to foster intrinsic motivation?

I've been in big ideas meetings where literally I was the only one putting out ideas. And this was at a time when myself (and most of my PM peers) were getting assassinated by management.

I've been in a group where the first Hackathon was scheduled with good participation, but the next had no engagement. Turns out engineering had a hate on for management because of lack of transparency.

I've been promoting hackathons and OE time when management fully supported it. Yet few wanted to participate because there was so much fatigue due to non-delivery. There was no trust in management, because there was no perceived leadership.

So what I really want to know (Do I really want to know?) is how to do a Whole 30 style reset of engineering and product culture - to get a toe hold back in building the relationship between engineering and product.  Ideas?  Anyone?  Bueller?  Anyone?

How to rebuild trust. How to regain enthusiasm. How re-energize the organization.

When I figure it out, I'll let everyone know.




Friday, 3 July 2015

Transferring Domains

Sorry, I've been offline for a few weeks.

Recently I transferred a domain from Network Solutions to GoDaddy... there were some hick-ups. First Network Solutions didn't want to let me go (and give me my transfer confirmation key) without a big upsell.  Any information on the web that you can do this without talking to someone is wrong. Second, the registrant contact info was so old on Network Solutions that it didn't appear to come from any current record I had there and so the email address notifications were going to didn't exist anymore.  That got solved when I updated the information in GoDaddy after transfer (and getting some warning messages on other contact accounts.)  Finally, DNS is not automatically transferred, so I lost my zone file.  I had to detach the DNS from Network Solutions manually and create the zone file on GoDaddy (and hope I didn't forget any of the Google special auth URIs.)

Hopefully now it is all better.

Sunday, 13 July 2014

Technology Road-map Outline

I've been considering the following outline for a technology road-map.  My main goals are to focus on the gap assessment between current state and trends, and the risks and relationships between the parts.

Business 
1. Vision, Mission, Goals
2. Business Drivers
3. Business Capability
4. Maturity Assessment / Measures

Shared Governance
5. Stakeholders
6. Workflow / RASCI / Structure
7. Communication Plan
8. Organizational/Functional Relationships

IT Risks and Strategy
9. Technology Trends
10. SWOT Analysis / Key Risks
11. Contingencies / MoSCoW
12. WISE Grid

IT Tactics
13. IT Alignment
14. Concept Diagrams (As-Is, To-Be)
15. Context Diagrams (As-Is, To-Be)
16. 5 year Gant (-1,this year,+3)

IT Details
17. Dependencies
18. Initiative Details with CAPEX/OPEX
19. Parking Lot
20. Sign off

I've thought about a section of success and accomplishments; something to show measurement against objectives.

Saturday, 12 April 2014

How to Kill Innovation

It annoys me sometimes when people introduce me as "The IT Guy."  I went to school to become a computer scientist.  Computer science is about creating and/or synthesizing solutions to problems following the scientific method.  It is innovative and it is creative.  IT is about management.  It is a profession that, for the most part, is about control.  Control and innovation are at different ends of the spectrum.

Aaron Schwartz (1986 to 2013) was a brilliant mind who went places he shouldn't have gone and did things he shouldn't have done.[1]  He had a thirst for knowledge and he believed it should be free.  This got him in a lot of hot water, even given his accomplishments, and ultimately he took his own life rather than face massive fines and jail time for stealing academic knowledge.  His end purpose for this knowledge?  Increasing his intellectual ability.  How many of us have had our wrists slapped for doing the wrong thing for the right reason?  (In my professional life, I can think of numerous reprimands for doing the right things for the right reasons.)

Aaron tried unsuccessfully to get on the board of directors at Wikipedia; as his intuition told him things were not quite right at this breakthrough of community involvement and intrinsic motivation.[2][3]  The momentum of Wikipedia was immeasurable.  Wikipedia as a source of knowledge was game changing and saw the death of Encyclopedia Britannica and Microsoft Encarta.  The biggest collection of human knowledge ever collected and edited by volunteers.

And here is what changed.  The momentum stopped.  A small portion of content was being vandalized.  So control was needed, and Jimmy Wales facilitated the rise of the administrator.  He justified it by saying that only 500 or so core people contributed content.  What Aaron showed was that there were outsiders and insiders, and outsiders - infrequent expert contributors - accounted for most of the new content, while insiders provided most of the editing.  So Jimbo focused on supporting the insiders and the new administrators.  Though the motivation of the editor was to maintain a consistent quality, the motivation of the administrator was to implement control.  Outside contributors started to decline.

I and others have experienced this personally.  I stopped contributing to Wikipedia last year.  I tried to start an entry about the accomplishments of my recently deceased father.  He did a lot of good things for the City of Calgary that had not been recognized.  I have (he had) volumes of photographs of Calgary history that you wouldn't find in the city archive.  So I started the draft Wikipedia entry.  By the time I had the outline done, the draft had already been tagged as non-standard for deletion by an administrator.  By the time I figured out what was wrong, it was expunged.

A good friend who is very active in the tropical fish community was an avid contributor on the topic.  He was disappointed so many fish on the tropical list didn't have pictures.  So he reached out to the community to contribute their personal photographs - copy left - under Wikimedia.  He had a great response; over forty contributions, that he started to link into the Wikipedia page.  After a few, an administrator tagged the images as "stolen" because they were" too good" to be free.  The justification, later learned, was that he found one image contributed to a photo stream site by the same user whom contributed it to Wikimedia...  Wait a second.  An enthusiasts posts a picture of his fish to the public, grants public license, and that's theft?  And justification to remove 40 superb images?  Suffices to say that was the last time my friend contributed to Wikipedia.

Motivation is a fragile thing.  It doesn't take much to quash enthusiasm. Those two things are the keystones of innovation.






http://www.wired.com/2013/12/swartz-video/
http://www.aaronsw.com/weblog/whowriteswikipedia
http://www.aaronsw.com/weblog/whorunswikipedia

Wednesday, 15 January 2014

It's the Little Things that Count

It has been a while since I posted from the Armchair but today I was reminded of something so important to IT shops: It's the little things that count.  I did a quick job for a company - an out of band job - in that their internal IT was not able to do it - and it took me 23 minutes.  15 minutes of that was trying to figure out what the problem was.  Another 5 minutes to generate a wee bit of VBA code to change all control formats in an Excel spreadsheet.  And two days of someone's time saved (multiplied by how many spreadsheets, and there were a lot, as they were audit worksheets.)

I felt good about this.  This is one of the reasons why I liked being in IT: helping clients, saving time, saving money, and saving frustration.  And then the reflection on my past experiences and why I was popular in groups I worked in and why the IT machine disliked me.  Productivity solutions are not big projects.  They're tiny things.  They don't require high priced software or managers.  It is the practical execution of LEAN principles.  Identify those little, repetitive things that waste time and money and get rid of them.

In three local companies over the last 10 years I saw the "office productivity" groups get disbanded.  Each of these groups had "too much work" yet were eliminated anyway. They were very popular in the organization because everyone used PowerPoint, Word, Excel, and even Access and had these tools on their desktops. End users just needed a little bit more out of those applications - slightly beyond the reach of a power user. Personal productivity software is often the right tool for the job.  But big IT seems hell bent on killing the spreadsheet, etc.  Why?  Because its not manageable.  Because its not supportable.  Says who?

Says the person who measures themselves by projects and project price tags.  IT is ultimately a service within a company.  Technology enables people to work effectively and efficiently.  Isn't it fascinating how IT is trying to reposition itself these days as the agent for business transformation?  We can help our internal clients do better by being champions of continuous improvement.  Unfortunately many C.I. groups I know are very keen to coach others on how to work better without actually being able to do the work.

Givers Take All from McKinsey is a fascinating article about corporate culture that promotes the belief that workforces that help enable each other are the most productive.  For me that is true transformation: break IT silos and help lighten the load.

Monday, 21 January 2013

5 Project Management Pitfalls

There are always good intentions when starting any project, in particular when those projects are championed by new leaders eager to put their name on some corporate leaderboard. Today I had a sense of déjà vu, and I wrote and deleted a message several times to a new, old colleague about my appreciation of the book Death March by Edward Yourdon. So I’ve decided to put up an inspired top five list of pitfalls for friendly project managers everywhere that face similar dilemmas.

  1. Change for change’s sake is a mistake.

  2. Introduction of new processes, tools, technology, or methodologies into a project will blow any reasonable guess at a timeline.

  3. Throwing people at problems doesn’t solve them, it just makes it worse.

  4. Lack of change management is analogous to planned chaos.

  5. Process methodologies are philosophies, not standard operating procedures.



Change for Change’s Sake
Some old clichés come to mind. If it ain’t broke, don’t fix it. Why reinvent the wheel? It is okay to be the voice of reason and present the been there, done that in the face of change. New people tend not to be too excited to dig into corporate history to see what has been attempted and what learnings were produced. There is an oral history obtainable through discussions with the old timers that you won’t find in documented reviews, because failures tend to get less documented attention. It’s good to do a little research beforehand to discover if there is an audience for the change. I think of this as the counter to Einstein, who said crazy is doing the same thing and expecting a different result. In this case, crazy is doing something different and expecting the same result.

Injection of New Increases Uncertainty
We’ve all been here. We have a new project and we really want to try out the latest silver bullet trend. It is, after all, exciting to try new things. The only issue is that finding expertise on new is impossible. You learn by doing. You learn by making mistakes. And by that time, you’ve invested so much time in it, you wonder why you didn’t use something proven because you could have, in hindsight, done it in a fraction of the time. New things just haven’t had the burn in time, or the evolutionary filters to prove they have the survival stuff. So, if you are on a critical project, reject new like it was the plague.

Mythical Man Month
Sometimes we have tight schedules and we figure it is easy to throw resources at problems to get tasks done in parallel. We know there is a logistical overhead. But there is also a quality and consistency hit. With brief training, not all temporary workers will produce the same quality work. They likely have a different understanding of what the task is than their peers. So it makes sense that we have a quality control group. It makes sense to do a lot of level setting, and knowledge sharing, between project folks even when they’re on parallel tasks. Though it is super tempting to keep our heads down and focus, and maybe even entertain cutting out things like testing and quality control, it really is the worst decision we can make (because we put controls in place to reduce risk.)

Change Management Good
Change management is all about reducing risk. You don’t want feature creep. You don’t want interruptions. You don’t want to get hijacked by low value, high complexity, and quite likely pointless flavour of the day type distractions. They are distractions. Work the plan. If it isn’t documented, and signed/authorized by someone in authority, be prepared to defend yourself when things go south because the execution of unmanaged change is the fault of the execution team, and the originator of the change will choose not to remember the expensive, out-of-band change request. Even if they do remember, it will be your fault because you were never asked to foul the timeline.
Change needs to be communicated gently to all stakeholders. And too much change is a bad meal because an organization can only digest so much of it at a time.

Methodologies are Not Holy Scripture
Thou shalt not treat all problems as nails and methodologies as hammers. Methodologies are guidance. They are good philosophies that apply in certain contexts. If you try to regiment a philosophy, be prepared to waste time dealing with exceptions. For example, DMAIC is for process improvements where the process has a good level of maturity. DMADV is for new processes in organizations that have good understanding of maturity. PDCA is better for immature processes. Like living things, some ideas are only viable in certain environments. Know your environment. Pick fit for purpose and settle on just enough method to attain incremental improvements and/or consistent quality.

So this is my sage rambling of the day. Enjoy.

Thursday, 13 October 2011

ArmchairCIO Mourns Dennis Ritchie

Dennis Ritchie, one of the most influential people in the development of modern computing, passed away on October 8, 2011. Dennis designed the C programming language, and developed much of the Unix operating system. Its not my intention to go into great detail on the evolution of either of those. It suffices to say that C was the spark for languages like C++, Java, C#, and Objective-C - upon which most of the world's software is built. Without Unix, we would not have SunOS, Linux, or MacOS X - heck, even the iPhone runs a stripped down Mach Unix kernel.

I felt compelled to write a tribute blog, because a lot of attention has been focused on Steve Jobs death on October 5, 2011. Without the work of the demure Dennis Ritchie, Jobs wouldn't have much to sell. I saw no mention of Ritchie's passing in the major news media. Most of it is still homage-de-Jobs and the recent Blackberry outage. I think that is truly a shame because Dennis Ritchie's contributions and what they enabled are truly astounding.

In the summer of 1986, I was in my second year of university, taking summer courses to correct a "lack of discipline" I experienced in my first year. The University of Calgary computer science department allowed me to have an account on their DEC mainframes, even though I wasn't taking any courses that really required it, because I had asked the administrators for access in order to learn C (in order to learn how to fully utilize the Unix operating system.) I'm grateful for the patience those administrators showed me, because I had a knack for getting into trouble (with computers.) Dave Mason and Keith Andrews, if you are out there, thanks.

I bought the K&R C book by Ritchie and Kernigan (on Dave Mason's advice), and I was amazed how quickly I picked up the language; literally two weeks. Previously I had learned the procedural languages Basic, Pascal, Modula-2, and COBOL, and one thing about C stood out: it was concise. In very little text, requiring very little typing, you could build sleek programs. In some sense, that lack of verbosity was very enabling - especially at a time when auto-completion and code-generation didn't exist because most terminals/computers didn't have the horsepower.

I spent the next 20 years programming in C, or C derivatives like C++ and Java. This language was really a keystone in the development of everything digital. From your digital devices, their drivers, operating systems, to desktop computers, or other electronic devices; chances are a C compiler of some sort was used to turn that source code into machine instructions enabling them.

So thank you Dennis Ritchie, thank you for providing us the tools that continue to allow us to explore and solution the digital future.