Discussion Topics | Geek 2 Man

March 14, 2018

What is Digital Transformation?

One term I’ve seen recently is Digital Transformation. The first time I encountered the term the first thing I thought of was small businesses integrating more software and processes in to their brick and mortar presences. I know one shop that still hand-writes their sales tickets, and adding some technology to their shop and processes would be a perfect transformation. That’s close, but not quite right.

Digital Transformation has been around for decades, each time infusing organizations with more technology, more processes, more ways to potentially deliver faster. However, with each new infusion comes new challenges. Challenges which are not necessarily related to the technology itself, but how the organization handles it. You see, as wonderful as new technology is, without changing the processes you manage, all you’re doing is the same thing, but faster. That’s great, but eventually you have to change your processes and even your organization to continue to succeed. If you’re in the music business, it doesn’t matter how much faster you can produce CDs if you haven’t leveraged your technologies to deliver digitally as well as change your overall strategy to make digital delivery your main product with CDs being secondary. I know I’m over generalizing here with the music industry, but bear with me…

This isn’t about products, or even specific technologies. What Digital Transformation is about is organizational cultures and how well they are able to adapt and change. It is about how easily can they take the technology they have, or are about to implement, and deliver faster that their competitors. Remember my music example? Which organization can take their technology (digitized music) and deliver it faster to the consumer? The organization that uses digital files to produce CDs for distribution (because that’s what we’ve always done) or the organization that offers the same digital music files for immediate download and consumption? Obviously the one who offers it for immediate consumption will succeed in getting the immediate advantage over their competitor.

Technology changing how organizations do business is what Digital Transformation is about. It changes the expectations of the organization, it’s partners, and ultimately the customers.

Don’t expect this to happen overnight. It takes small steps, with each department buying in to the change, for the transformation to succeed. You can’t just hire in a new executive and expect to be transformed. They can help, but without the rest of the organization’s willingness to change the only thing that will happen is a large investment in new technologies to do the exact same thing that you’ve been doing. The entire organization needs to be ready to adapt, and the processes need to reflect that. As the culture changes, so does the organization, ultimately leading to greater value to the customer.

Digital Transformation is the ability for your organization to adapt and change using the technology available to you.

Questioning the Boss: Challenge to Authority or Collaboration Opportunity?

I recently was declined for a job interview. Not because I wasn’t qualified, but because one of the managers turned out to be a manager that I had worked with in the past, and they felt that I would not be a good fit for their team. They didn’t think I’d be a team player.

You see, back when we worked together, I questioned him.

A lot.

I questioned everything from task prioritization (shouldn’t the ability to login and have user roles be ahead of 90% of the heavy work we need to do which is role based and not three months down the road?), to team selection (why are we putting PHP developers on a Ruby on Rails project when we have enough Ruby developers to spare?), to just about anything else you can think of. Yes, I challenged some of it because I really did think they were poor choices, and I didn’t want to be held accountable to an impossible delivery schedule. However, the majority of it I challenged and questioned because I wanted to learn more, and at the same time I wanted to share my knowledge and experience with him.

The manager saw my questions as challenges to their authority; a lack of respect. Where I thought I was being a collaborative team player, I was being seen as a trouble maker. A subversive employee whose goal was to make the manager look bad, and promote their own self-interest. I tried changing tactics to ask questions in email and in private meetings as opposed to in large meetings in front of their peers and subordinates. Unfortunately, by that time, I was still deemed a threat.

My wife was recently in a situation where a new manager came into her company. My wife has been there for nearly 20 years, and rather than take the questions she was asking as guidance, the manager took it as a challenge.

A good manager knows that not only should they surround themselves with people smarter than they are, but they need to utilize them. My wife’s situation is a perfect example of that… someone who is new to a company should want to leverage the knowledge of someone who has been there for a long time. You cannot become a truly effective manager without fully leveraging your team and their abilities. Some of these “smart” people will have very specialized knowledge. Others will have a broad knowledge base to draw from, or they always look at the problem from a different angle. A good manager fills out their team with people which will fit the gaps in their own knowledge and experience, as well as people with different viewpoints and problem solving skills. The total of their knowledge and experience will greatly exceed the sum of their parts with a wise manager leading the way.

If an employee comes to their manager with a question, particularly one regarding the current project, processes, or even staffing, the manager should listen and respond accordingly. Sure, sometimes it will just be an off the wall question, or just someone having a grouchy day. More often than not though, the question is an opportunity, not a threat. It could be an opportunity for the manager to help mentor the employee (help them see the bigger picture, not your view of how things “should be.”). It may be an opportunity for the manager to learn something new (especially with new technologies and tools which could speed up development or delivery time).

The CTO for the company where this manager and I worked had a habit of sitting back in meetings and listening, and then just asking one question. Granted, it was one question that sparked a series of other questions by the team. He didn’t point out the holes, or the flaws in the plan, or come across as challenging the process – instead he simply would ask “Why? How? When?” I admired his ability to spark discussion and his openness to listen to questions from the team. He encouraged questions, and I asked him a lot of questions. He would constantly tell me, “You’re not asking the right question.”

Returning to my prior blog post about Who Owns the Scene, I want to elaborate on why asking questions should be taken as a compliment, and not a challenge by a manager. When people ask another individual questions, it’s generally because they want to gain something from them – besides the answer. It could be, as I’ve pointed out already, to learn something new, or to understand a process – both physical and mental. Through asking my brother-in-law questions about who owns the scene at an accident, I learned more about the processes and regulations that are behind law enforcement. He not only got to “show off” his knowledge, but he gained a bit about IT processes in the conversation. Amusingly, both of us sat down with my father-in-law to ask questions of him due to his expertise. My brother-in-law needed to understand some accounting rules as he was reconciling the books for the fire department, and I needed to understand some tax law implications as I was working on a project to try and compute tax depreciation differently. Through the conversation, I learned what I needed and more, as did everyone else sitting around with dessert and coffee. While my mother-in-law was a little bored, she made comments, which made us think differently.

If it’s the right question (you’ll know it when you hear it every time), then it gets both the manager and the employee (or the team, or in the prior example, my family) collaborating together. This results in a better understanding of the issue from all sides, and a solution which now has full buy in from all parties. If that collaboration isn’t a win for the company, then I don’t know what is a win.

I guess being shot down for an interview by a former coworker in a new company (at least this ex-colleague in particular) isn’t such a bad thing after all. Once I found out that I would have been working with him I probably would have thought long and hard about whether or not I should accept the position. The question would be, can I work with someone who is not open to questions? Can I accept that by asking questions I could be seen as difficult? Again, my intent is not to make my manager look bad, whether it’s a line manager, the CTO, or even the CEO when I reported to one. The intent has been, and always will be, to learn and ensure the project is successful.

What do you think? What is the right question to ask to make a project, manager, or employee successful?

February 7, 2018August 7, 2020

Who Owns The Scene?

Not too long ago I was visiting my brother-in-law and he was telling us about some of the more unusual incidents he’s had to respond to as a volunteer firefighter. Putting the colorful storytelling aside here, there was a common thread with all of it: ownership.

Photo courtesy of San Leon Volunteer Fire Department, San Leon, Texas

If there is an accident on the road, or a burning building, or pretty much any incident where emergency services are required, the firefighters own the scene until an all-clear is given. Later, if investigators are out recreating the scene, the police own the same scene, with firefighters blocking the road and providing any secondary support. In each situation, there is a clearly defined chain of command to make decisions and protect the first responders. Others can make requests (“Move the fire truck, my officers can’t get their cruisers in close.”), but the ultimate decision rests on the commanding individual (“No. They’ll get in the way of my crew extracting the victim from the wreckage. Now tell your officers to divert traffic and make space for the helicopter to land so we can airlift them out of here.”)

However, in the IT world, in an outage scenario, who owns the outage?

Yes, I know, there are quite a few ways to go about this, and if you’ve got good processes in place, you already know. What if you don’t?

As a Release Manager, part of my role was to own any potential incidents and outages and delegate any task as needed, including the ownership of the outage. Any incident which was discovered went to a key list of individuals for us to determine the best course of action, including no action. This was me, the Release Manager, the QA Lead, the Engineering Managers, the Architect, and the VP of Engineering. Before this was in place, management, and even half the engineers, had no idea something was happening, and thus the outage would just drag on until someone finally did something about it. It was an unfortunate case of “someone else will fix it” more often than not. Adding ownership to this scenario helped ensure that not only was the issue recognized faster, but there was a single point of contact to direct inquiries and information through. Now, instead of management disturbing the individuals actively working to fix the outage, they go the Release Manager (or whomever I handed ownership to). The same thing occurs with the engineering and operations teams, where they would pass information up to me, and I would be responsible for distributing the appropriate information to management. Through ownership of the issue, both management and the individual contributors were able to focus on what needed to be done to resolve the incident.

Another part of my role was after the incident was resolved. At this point, I had ownership of the analysis of the incident. Just as the Police, when recreating an accident at the scene can request the assistance of the firefighters, I had the authority to pull the necessary engineers out of their normal work to be able to perform a root cause analysis (RCA) of the incident. While this RCA often occurred at the end of a Sprint in the discussions over what went wrong/could have gone better, key information could potentially be forgotten if the incident had occurred at the beginning of the Sprint. Getting everyone involved in a room the day after an incident at the latest, ensuring that timelines and steps taken were still fresh in everyone’s mind.

Having an individual dedicated to incident ownership in a smaller organization may not be the most optimal use of resources. In that scenario, I would strongly recommend (if you don’t have one already) that you have an incident response document that outlines the steps to be taken. Then, incident ownership can fall to any member of the team, including junior members, so that there is a single point of communication in and out of the engineering and operations teams (or single multi-function team of course) for the stakeholders. This would also help to define getting the RCA and any associated documentation completed in a timely manner.

I’d be interested to hear how others handle their incident responses within their organizations.

January 30, 2018

How Long Until You’re Truly Effective?

I had a boss once, who in the middle of an important meeting exclaimed, “I think I’m finally starting to understand!” and then proceeded to explain how it takes a new manager nine to twelve months to truly understand the environment they are working in. He was just past the nine month mark when he blurted that out, and he couldn’t have looked happier. It turns out that he once had a boss who did just about the same thing as well.

There’s plenty of discussions out there over how long it takes a new employee to get up to speed. Thanks to our instant gratification world, an astonishing 27% of executives think that an entry level employee will be successful or not in the first two weeks. That number reaches 78% when the time frame is at three months.¹ While I’m all for using your gut feeling on people, and there are some that will certainly stick out as awesome or awful in just two weeks, two weeks is just not enough time to navigate the waters (especially at a large company) and show what you’re capable of. According to one study, it takes up to two full years for a new employee to become as productive and effective as the prior employee.²

And just think, that’s only a new individual contributor.

Let’s say that after three months, the new employee is at 80% productivity. That’s pretty good. But what about the new manager? If this person is new to the company and wasn’t promoted from within, then they have to learn the product, learn the company, learn the culture, all on top of managing a team and learning their strengths and weaknesses. You would be hard pressed to be operating consistently be at 80% effectiveness at the three month mark. You could safely double that to six months and you’d be getting close. But at nine months to a year, that’s enough time to fully immerse yourself into the company’s culture, product, and processes, to the point of comprehending some of the nuances that would not be so obvious when you were only three months in.

So as a new manager, don’t worry if it feels like you’re not as productive as you were down in the engineering trenches as soon as you change roles. Just keep working hard, push forward and ask questions. Your effectiveness and understanding of the job will come.

Existing managers, please be sure to do all you can to help those who are just stepping in to the management role, especially if they are new to the company as well. Remember that it takes time to be effective, and please be sure to give them all the tools and contacts they’ll need to be successful. You’ll be glad you did.

I’d like to add one more link in there though, to Harvard Business School’s article on getting new managers up to speed.³ While it doesn’t back up my time frame claim (or even give timing), it does give some very good advice over how to help new managers succeed, and that’s something I want to remember in nine month’s time…

Resources

1. http://fortune.com/2015/09/18/new-employees-onboarding-training/

2. http://www.nxtbook.com/nxtbooks/trainingindustry/tiq_2012winter/index.php?startid=40#/40

3. https://hbswk.hbs.edu/archive/getting-new-managers-up-to-speed

January 16, 2018

I’m Not a Point of Failure

When it comes time to ensure that there is redundancy in your organization, how do you refer to that necessary redundancy? I recently came across an example that quite honestly, made my skin crawl…

Having “name” as single point of failure should be addressed.

See the key word in there? Failure. To make matters even stickier, the person this sentence was referring to was on the email. How would you feel being referenced in an email by your boss as a point of failure? This is demoralizing. I don’t care how much I know that I may be the only person in the company who can do a certain job, but I’d rather not be referred to as a point of failure. Personally, I’ll tell you that I’m not a failure, I’m a specialized expert who needs a back up.

So what do you call that singularity of expertise that needs a back up?

I had a manager once who referred to it as the Bus Factor. Yes, Bus Factor, as in, how many employees need to unexpectedly be hit by a bus before this function can no longer be performed? A bit morbid perhaps? Well, a little… But think about it. Nobody knows if they’re going to get hit by a bus. Nobody wakes up in the morning planning on stepping in to the street right in the path of a moving bus. Some people like to call this the Lottery Factor, but winning the lottery (or leaving because you found another job, which can sometimes feel like winning the lottery ) takes effort and planning. Getting hit by a bus is unexpected. The upside is that it’s not even terminal. You could just be laid up in the hospital for several weeks recovering. That’s still long enough that you would need a back up for your tasks.

Bus Factor 1

This is where there is no back up. Only one person needs to be “hit by a bus” to cause problems in the company. This is the “single point of failure” mentioned in the snippet of email by the one manager up above. As a manager, you don’t want to have this scenario longer than is required to identify and train a back up. That training may just be having documentation and a process in place to grant the appropriate access to anyone else on the team if the need arises. Still, avoid Bus Factors of 1.

Bus Factor 2

Great, you’ve got a back up in place. Two people are capable of performing the specific task. Is this enough? Well, now it’s up to you to decide. But you have a plan in place and someone who is capable of performing the the task in case the primary person is hit by a bus. So you’re at least in a stable place.

Bus Factor 3 (or greater)

Obviously the more people who can perform a given task or have the knowledge to do it, the better. At this point you have solid documentation over tasks and roles, and with a little training you could start swapping people between teams with minimal risk.

Bus Factor 0

Oh dear. You’ve identified a need in your organization. Maybe it’s because the single individual who performed the task has actually won the lottery and just turned in their notice. Maybe you’ve identified a hole in your processes where it turns out there never was anyone who did something and the team has stated that someone needs to be accountable. Regardless, if you ever find yourself in a Bus Factor of 0, do yourself and your team a favor and plan for a Bus Factor of 2. You never know when someone is going to get hit by the Lottery Bus…

I know, Bus Factor sounds a little cheesy and a little morbid, but it’s still better than “single point of failure.” Having a Bus Factor (or even a Lottery Factor) makes the personnel back up issue sound like a process statistic. It’s something that you can fix, and your singularity of expertise is still great at their job. There’s nothing demoralizing about a process statistic. Calling someone a point of failure implies that they just don’t do their job correctly, not that they are the only person who knows how to do their job.

Oh, you thought I’d just leave it at that? Sorry. You know I had to look up the origins of the term “Hit by a bus” while I was at it. To find the origin we have to go back quite a bit, to the 1907 novel The Secret Agent, by Joseph Conrad.

But just try to understand that it was a pure accident; as much an accident as if he had been run over by a bus while crossing the street.

But don’t take my word. Feel free to read it for yourself…

January 12, 2018

That “Ah-Ha!” Moment

I was asked recently when my ah-ha moment happened when I knew I wanted to be in management.

I had to think moment, and then I realized that my career has actually been a series of revelations, not just a single one. So bear with me as I back up for a second and have my little moment, much like Miriam Maisel during her wedding speech…

When I was younger I wanted to know how everything worked. No, I didn’t take things apart and try and reassemble them. Instead I built things. My parents still have the wind chimes I made out of metal conduit and a metal junction box… It was this building and experimenting that made me have my first ah-ha moment. I knew that I wanted to study Physics.

So off to college I went. A B.S. in Physics, and an M.S. in Electrical Engineering later it was time to find a job. Not the kind of job I had all throughout school building websites (I kinda enjoyed it and seemed to have a knack for it), but a real one where I had to go in to an office and do something. I liked the science side of things, but I liked the programming side too, so two resumes went out. Each one highlighting a different set of skills.

Wouldn’t you know it, the programming resume got some good traction, and off I was programming websites. Not just any site mind you, but the e-commerce site for Nokia in the US, nokiausa.com. It was there that I honed my skills and put all that education to use by solving problems in unique and creative ways. It was there that I had my next ah-ha moment. I know that I truly enjoyed programming, enjoyed seeing the instant results of things working, and that there were thousands of people who were using something I had helped to build. You could say I was hooked.

Several promotions and companies later I found myself in a slightly different role; the role of team lead. There was still programming, but there was a lot of mentoring the more junior members of the team as well as being one of the points of contact for senior management to know what was going on with the project. I saw that by helping the other members of the team to grow and collaborate better allowed our team to deliver more than we could have individually. That excited me. As I shifted my role more I was able to help multiple teams deliver larger projects with less defects, and that excited me even more. It was during this time that I had my latest ah-ha moment: Being a successful manager was helping your team or teams to achieve more, both in their jobs, and as people in general. There are a few individuals I still keep in touch with as I greatly enjoy knowing how they are continuing to achieve greatness with (hopefully) some of the foundations I helped set down.

And that’s where I am now. Following my latest revelation that I enjoy managing teams and helping them to achieve greatness.

So that’s my string of ah-ha moments to date. I’m sure I’ll have more as I continue to grow in my career. And don’t worry, there’s really no shrimp in the egg rolls…

December 29, 2017

Can I See Your GitHub?

During the interview process I often get asked to share my GitHub account. Of course, then I get chided for not having much in it. In particular, I get questions about why I don’t have work from prior jobs in it.

Um, hello? Has anyone heard of a little thing called Intellectual Property these days? Seriously folks. Every job I’ve held has been a corporate job, and every job I’ve held I’ve had to sign something stating that all of my work is the property of my employer. This is one of the main reasons they pay me; to produce code which does things for them that their competitors are not able to do. If I were to go saving this on GitHub, or any other publicly accessible location, I could be liable for exposing industry secrets (OK, a lot of what I’ve done is commerce related, and a shopping cart is a shopping cart for the most part, but that’s not the point). If those little code secrets were really good (like proprietary algorithms, or better still passwords and hashes) I could find myself in a lawsuit. On top of that, I’ve just potentially exposed their security, making that particular site easier to hack or spoof.

Once I explain this I’ve still had some come back and ask me to share work in another manner. Wow. What part of Intellectual Property do you not comprehend? Even if I did have copies of my prior work (which would technically be illegal, even though we all know almost every developer has some snippets of code in their arsenal) why would I share that with you, once more potentially giving out competitive secrets? All I’m doing is showing you that I don’t care about the IP of any job I work at, including yours.

This is why I don’t share much on GitHub. I’ve worked hard and I’m not going to just hand out someone else’s IP, even if I wrote it, just to prove to you that I can code. I’ve been at this for 20 years. Please don’t insult my ability or integrity.

Curious about just how much I do or don’t share? You can see my GitHub account here: https://github.com/ercubed
(The only real thing shared, is the work I’ve done with teaching, so that all the students would have examples of the work once we were done with it.)

As for you hiring managers out there reading this: Do you really want to hire someone who has copies of, and is willing to share, other employers intellectual property? If they’ve done it with others, chances are they’ll do it with yours as well.

December 15, 2017

Welcome to Geek 2 Man

As a software engineer, scrum master, and, in my humble opinion, generally intelligent guy, I have often found myself sitting in meetings thinking, “I could do that.” and on a few other occasions, thinking to myself, “What in the world is that manager thinking?” And so my quest to leave development and enter the magical, mystical realm of management began.

This site exists for several reasons.

Think of this as a diary

This isn’t some super secret diary with a lock on it stashed away in the night stand. While it might do me some good to have one of those, it won’t server the full purpose: dialog. Let me get me thoughts out, and in exchange for reading my diary, I hope some of you will respond back with your thoughts. Tell me I’m nuts. Tell me you agree with me. Either way, ideas can’t grow or help others without the open dialog.

I like to tell stories

I’ve heard lots of great analogies over the years. Quite a few were stories when I first heard them. Others were just good ideas that then were turned in to parables (of sorts…) when I explained them to others. So why not share?

Consulting

OK, yes, there is an ulterior motive here… I’d like to think that some of my thoughts are good enough, or important enough, or even just entertaining enough, that maybe someone out there wants to pay me to use those ideas. Maybe that’s a speaking engagement. Or maybe it’s just for help with instigating change within their organization. ~~Or maybe I’m just so darn handsome.~~ The sky is the limit with what I can accomplish and what I believe I can help others accomplish. Like what you see? Let’s talk.

It’s because of this journey of being a geek to becoming a manager that this site exists.

Category: Discussion Topics