Swarming

This morning there was a large amount of bird chirping outside. When I looked out the window there were about a dozen sparrows, and mockingbirds chasing a hawk. They were swarming and chirping all over the place and working together they chased that hawk out of the area. They teamed up to defeat an unexpected problem that came out of nowhere which was bigger than they were.

When you stop and think about it, it’s no different when a critical production issue or overly difficult problem appears in front of a an engineering team. The problem is identified, the team drops everything they are currently working on, and they “swarm” the problem until it is eradicated. During the swarm some people may drop off the problem when their skills are no longer required and other may get pulled in as the team determines the next steps they need to complete the problem. Ultimately, think of swarming as Pair Programming on steroids.

As a manager or team lead you need to recognize when swarming could be a help, as it does take resources away from day to day work. Honestly, I think it’s usually pretty obvious when swarming is needed, and it doesn’t hurt that the team will usually say so. Swarms don’t often affect the outcome of the Sprint as the swarm has a force multiplying effect which gets things done faster, however it’s always wise to communicate to the stakeholders that a swarm is happening and when the possible risks may be to the Sprint. Regardless, if the team comes to you asking to swarm on a problem, let them, they know what they’re doing.

Swarming is a highly effective way for a team to accomplish a large task quickly. Even a bird brain can see that.

Release Notes

Everyone has their own opinions on what release notes need to be, or how in depth they should be. Some even go so far as to make them epic stories, like the now legendary release notes for Tumblr’s iOS 4.3.1 release. Regardless of your take, there’s a few simple guidelines to make things useful without giving away so much information that a competitor can pick up on all the new nuances of your product.

Make it Human Readable

This may sound obvious, but you have no idea how many times I’ve come across release notes which are just jumbled together from the commit history. Take the time to actually organize it. You don’t have to do much formatting to it; even just bullet points are fine.

If you want to break things down to make it even more human readable, consider breaking the items down in to the follow categories so that users can immediately jump to what they’re interested in:

SectionDescription
AddedAll your new features
ChangedAnything that has changed in current functionality
DeprecatedNotify your users of features which will be removed soon; include dates if possible
RemovedFeatures which are now completely removed
FixedBug fixes go here
SecurityTo be used with any vulnerabilities you’ve corrected and items you’ve preemptively strengthened the security

Don’t Just Dump Your Commit History

It honestly pains me to see things like “merged master in to working dev branch to fix a bug” or even just “Committed eb49c74e[…]778e”

This is nothing but tech noise. What was the bug? Did it affect the end user or just help improve performance on the back end? Just what exactly is Commit “eb49…” anyway?

Dumping your commit history also runs the risk of your customers wondering how stable your code is. If you’re like me,  you’ll commit your code often, especially on larger pieces of work. It makes sense to the engineering world. It doesn’t make sense to the rest of the world though, and could cause customers to wonder how stable things are if you’re constantly changing code.

But Don’t Leave Things Out

I heard a complaint from a colleague of mine a few months back that they were happy that the team they were working with was finally starting to put out decent release notes. This was immediately followed by a large BUT… (Oh my God, Becky!) You see, while they were finally putting out release notes, they were leaving out large portions of interface and functionality change. My colleague ended up losing over a day of productivity due to having to contact the team over what had really changed and then waiting for a response (we won’t talk about having to wait longer for clarification to the response…).

There’s nothing worse that reading through the notes and then going to the site to find that the entire process you used for something had changed, and there was no mention of it.

Customer Specific

In one job I was in we had not only a large number of customers, but several very large customers we would also do custom integrations and specialty work for. As the business was a SaaS model, all our customers were competitors to each other.

Imagine the joy Company X would have with finding in the release notes something to the effect of “Created new API integration to support Super Widget Customization Sales for Company Y.” When it comes to Competitive Intelligence on your competitors it doesn’t get much better than that.

We ended up having multiple release notes for each release. One set of notes was all the generic items which would impact all customers. This was what was posted to the general public. Custom release notes were then created and sent to the contacts for each of the customers where specific custom work was released. If no custom work was released we sent a copy of the generic release notes to the key customers as part of a bigger initiative to keep them informed of what was happening.

Have Some Fun With It

Now that you’ve improved your release notes, it’s time to have a little fun with them. You certainly don’t have to, and some organizations may even frown upon it, but if you can, add a little levity to things. Having a bug fix note of “Corrected issue preventing users from uploading a new profile photo” isn’t nearly as engaging as “We know you’ve been trying to show off your new hairstyle/beard/glasses/etc to everyone, so we’ve fixed the bug that caused an error when you tried to upload a new profile photo. Sorry about that, it seems our developers don’t change appearance as often as our customers do!”


As an engineer or a manager, you should be able to help with writing the release notes. Yes, many Agile processes say this is the responsibility of the Product Owner, but that doesn’t mean you shouldn’t offer to assist and make their life a little easier. Adding in specifics from engineering can often help the end user, especially when it’s a technical update such as a new API. After all, isn’t that what teamwork is about?

Further Reading

The Rocket Fuel of a Project – Good Acceptance Criteria

I had a manager once who would constantly harp on both the product team for not writing stories with good acceptance criteria and on the engineering team for accepting these “poorly written” stories. He would claim that his engineering team was the engine, and it would only perform as good as the fuel you gave it.

Better fuel makes things perform better, whether it’s high octane gas for your car or great acceptance criteria for your engineering team

If you’re familiar with Agile, then you’ve probably had the general story format of “As a [USER] I should be able to [DO SOMETHING] so that I can [ACCOMPLISH SOMETHING].” beaten in to you. It’s a great concept, and as a Scrum Master, I can say that it does work. Of course, you don’t have to take my word for it (even though I hope you will). Mike Cohn of Mountain Goat Software, one of the authorities on Agile and Scrum discusses the advantages of the As a User, I want User Story Template.

Here’s the one problem I have with using that format: Engineers get their hands on it. They bastardize it. They take it to be gospel. They use it to not have to think.

I’ve had engineers who would write system level stories with things like “As a System, the System should have Logging, so that the Developer has something to look at with things go wrong.” Gee, that’s nice. What are you trying to log? How will you access the logs? (which should really be another story quite honestly…) What sort of things do you mean by “go wrong?” And of course, my favorite bit, “As a System, the System should…” Is the web server actually sentient and have a concept of self? (Try and bend the process and I’ll pick anything and everything apart…)

Then there’s the individuals who just don’t want to follow the format. “Why?” they whine. “What’s wrong with just attaching a picture of the white board from the meeting we were all just in to the story? The devs who will build it are in there.” You should definitely add the picture. It’s an artifact to the process.  But don’t rely on it! Weeks could pass before the team gets to that particular story. A crucial team member could get hit by a bus or win the lottery. You need context to the story.

I’ve seen issues even following the format to the letter. This arises from the statement being too vague and the product owner expecting more than they wrote. The engineers take those vague statements as gospel, and then hide behind it as the story doesn’t pass, or ends up having three more stories written to clarify the original work. They use it as a crutch to not have to think about more than what was written and potentially not deliver greater value.  I once saw a story rejected because the statement was “As a User, I want to be able to log in and see what I have permission to see.” A little vague, but tolerable. The story was failed because of a different issue; the product owner didn’t like the error messages displayed if it was a failed login attempt. Funny, I didn’t see anything in the sentence regarding failed login attempts… You know what would have alleviated this issue? Acceptance Criteria.

By explicitly stating after the “As a User…” statement what the expected results would be this could have been avoided. Acceptance Criteria for the above log in story could be as follows:

  • The user will be able to enter their user ID (email) and password and select the button labelled “Login” to log in to the system.
  • If the user enters an incorrect ID and password combination they will be presented with the login screen and an error message above the fields stating “You have entered an invalid ID or password.”
  • When the use successfully logs in they should see content appropriate to their User Roles:
    • Standard users will see their dashboard with content they have subscribed to defaulting to the last 30 days ordered from newest to oldest
    • Staff will see the internal dashboard
    • Admins will see the internal dashboard augmented with extra tabs for user account management and subscription payment management

So how do you write good acceptance criteria?

Think of acceptance criteria as a helping guide for how you or someone else would test this work. No amount of detail should be spared on your road map of how to verify the story. In some cases it could be as detailed as an AAA TripTik (If you ever had a paper one made for you, you’ll know what I mean).  It often helps to draw out a flow chart or build out a spreadsheet of desired actions and possible outcomes. For the login example, the spreadsheet might look something like this:

Login Acceptance Criteria Example

PageURLActionExpected ResultData Needed
Login Page/loginLogin as a standard userStandard users will see their dashboard with content they have subscribed to defaulting to the last 30 days ordered from newest to oldestUser: standard@sample.com
Password: password
Login Page/loginLogin in as a staff userStaff will see the internal dashboardUser: staff@sample.com
Password: password
Login Page/loginLogin as a system adminAdmins will see the internal dashboard augmented with extra tabs for user account management and subscription payment managementUser: admin@sample.com
Password: password
Login Page/loginAttempt to log in as an invalid userUser is redirected to the login screen and is given an error message above the fields stating “You have entered an invalid ID or password.”User: baduser@sample.com
Password: badpassword

While this will often fall to a designated QA individual or team, not every organization is set up to have a dedicated QA group. Regardless of if you have QA available to you or not, be sure to write the acceptance criteria with enough detail that anyone in your organization could follow the steps. It will help with testing, and it will help with development. If you do have QA available, engage them to help you write Acceptance Criteria that will help all of you. They’ll have plenty of tips to give.

So back to the fuel… You can give your engineers basic requirements, or you can give requirements and acceptance criteria. One will act like 87 octane in a Corvette; you’ll get there, but there will probably be some sputtering and a few issues down the road. The other is going to be like putting in 93 octane in that same Corvette; it’s going to purr and give you much better performance in the end.

Patience. It Matters.

In this fast food, same day shipping, not even one hour photo processing anymore world we live in, change is expected to be visible immediately. However, just because you have put process changes in to effect, or wrote a few new tests for your code, doesn’t mean you’re going to see immediate results. Be patient with getting the results. That goes for both you not losing faith in your own work and for your superiors to understand (manage up!)

I’ll admit, I’m a bit of a speed demon. My leaden right foot has certainly gotten me into trouble a few times. But there’s one time where I’ve learned that patience is definitely worth it: heavy traffic. Over all the years of my commuting I’ve done a little experimenting. One week I’ll (safely) drive aggressively, lane change to the lane that’s moving just a little faster, hard stop and start, well… you know the drill. You’ve probably either done it yourself, or have seen others do it day after day on your own commutes. Other weeks I’d just pick a lane and relax; just go with the flow and not be impatient. Believe it or not, over a 30 mile commute, the difference in times was only about 5 minutes, but the difference in stress levels and blood pressure was significant. Thanks to a little patience on the road, I was more relaxed and productive in the office, and much happier once I was back home.

But enough of the psychology of having some patience on your commute… How does it relate to being an engineer or a manager?

A little while back I was talking shop with some old colleagues of mine. We commiserated over how bad some of the coding practices were at that old job. One thing we never were given time to do properly was write tests, and that bothered all of us to one degree or another. Since that job, he’s started his own development company, and has vowed that everything they produced would be done with proper TDD (Test Driven Development) and he always shoots for at least 80-90% test coverage. He said that in the end it paid off, as the tests did catch an introduced bug before they launched the new release of one project. Here’s the kicker: it took almost 18 months for the tests to actually fail. On the one hand, that’s awesome that his team was able to go bug free for that long. However, it also highlights where patience matters. They worked hard to follow their processes, which admittedly slowed them down from time to time, but were eventually rewarded by seeing their test work catch an issue before it affected a customer. Comparing that to the job we had both shared before where the tests didn’t catch anything in a month, so management insisted that we stop wasting time writing tests. That project ran for over three years, and never launched; partially because of the number of bugs which kept being introduced but never caught until after the fact.

Similarly, I recently held a position where I was asked to introduce new processes with the engineering team to try and speed up their delivery as well as reduce bugs and better schedule feature delivery. Before I arrived the best delivery times were often “sometime in next quarter.” It’s just a little hard to sell something to a customer on a promise of sometime in the next three months… I put processes in place, opened up communication, tracked down answers and issues (like a Scrum Master on his third pot of coffee). The problem is, old habits die hard, and change didn’t happen overnight the way my boss wanted it to. I explained that it takes time and showed data to back up the small progress which was made. I corrected course based off of the data, and off input from the engineering team. None of that mattered though, because I wasn’t performing the miracle of overnight perfection that my boss had in his mind. I wish him success, but I also wish him a smidgen of patience and a willingness to let things properly run their course to be able to judge success. Some changes really are a long game, and need the patience and strength to stay fully committed to them.

As an engineer, you’re selling yourself short if you’re not urging patience on your management. There’s nothing wrong with pushing back with a better solution that may take longer to implement. The challenge is how to explain it. You have to be able to explain that it may take an extra day, but the solution will provide even more value to the customer, stability to the system, preparation for the next feature, etc… to justify the time. Explain the reason for why you’re asking for patience. With a solid reason which ultimately positively impacts business, you run a better chance of getting the time and patience than just a “because I need the time to do it right” type answer. With each success after the request for patience, you’ll find management more receptive to the next time you ask for it. If you’re lucky enough, you’ll find that management even starts asking or offering the time for a better solution. Of course, you’ll just have to be patient for that to happen…

It’s also critical to be self-aware when solving a problem. Don’t just rush through to be able to grab the next task. Have a little self-patience and ensure that the code is done right. Double check your work. Make sure you’ve covered the odd edge cases you thought of while working on it. That patience in your own work will result in less mistakes in the long run, and even deeper tests which will cover more detail.  Of course, then you’ve got to be patient once more for those tests to catch something. But you already knew that, right?

In the meantime, I’m off to exercise that lead foot of mine. Patience is great, but sometimes you still want to go fast…

Hot Cross Buns as Acceptance Criteria

You’re probably thinking to yourself right now, “Great, he’s about to give us another recipe example for breaking down tasks and achieving the desired acceptance criteria.” Well, stop that. The food is merely a vehicle for this post.

First, a little background: I’m currently on a business trip, and as my hotel room has a kitchenette I did a little shopping at the grocery store; a Publix to be precise. Why Publix you ask? Well, we don’t have those in our neck of the woods, so it’s something different for me. After all, I can go to Kroger’s any time I want. Back home, all the neighbors have been asking my wife where I’m travelling and what I’m doing (they do the same to me when she travels for work). During the course of one of these conversations a neighbor brings up that there’s no good store-bought hot cross buns where we live, and that the best ones he’s ever had were from Publix. After all this, my wife texts me:

Publix Market has the best hot cross buns… Do I need to bring some home? You’d make [our neighbor] happy. I’ll head there tonight for some. LOL

Now, stop and read that again. This time, read it as a product owner and an engineer. The hot cross buns here are almost a feature request, but not quite. It could be a preliminary fact-finding discussion to see how feasible it was to achieve an objective; getting hot cross buns. Or maybe it’s just a discussion over some cool feature that was seen elsewhere that the product owner just wanted to share. Usually it’s something like “checkout this cool slide show transition.” This time it’s just a statement of where to get the best hot cross buns.

It just so happens that I’m in a position to find and obtain these incredible edibles. Being the engineer that I am I immediately see this as a problem that needs solving, and offer a solution: I’ll get some and bring them home from the trip. It’s not so different from, “You like that slide show transition? Let me see if I can slide that in to the sprint for you. Don’t worry about a ticket…” Nowhere in the text conversation did my product owner ask for hot cross buns. We had a phone conversation afterwards, and the conversation continued, and I said that I would stop and get a box. I figured I’d pick them up after dinner on my way back to the hotel.  Note: my product owner neither confirmed nor negated this suggestion. In fact, I think she may have been working on another project.

Off I go to dinner (I’m starting work on the slide show, and said that I’d add the undocumented, un-asked-for transition). The restaurant I went to (recommended by coworkers) had an hour wait, and being the hungry engineer that I was I passed and went next door since it had empty tables. Of course, with my engineer’s luck, it was a bakery. And wouldn’t you know, they had hot cross buns… Now, these aren’t the ones that would satisfy my acceptance criteria. They’re not Publix hot cross buns. But, being the engineer who always wants to please, and always wants to deliver more, I eye those hot cross buns. Of course, I still want to do the right thing, so what do I do, I contact a product owner. I text the neighbor. Not the product owner I had the initial discussion with, but now a totally different one! I chose to ask a different product owner on my own, not because the original product owner was unavailable or had passed me off to a new one – or was out of the office and designated a replacement. Now I’ve made promises to two different product owners (my wife and neighbor), for two different acceptance criteria (Publix and bakery hot cross buns), and still no official request within my sprint (dinner time/business trip). But I’m the engineer, I’m supposed to say how things get implemented, whereas the product owner gets to tell me what gets implemented. I decide to treat the purchase of the baked goods as a how, not the baked goods themselves being the what, and I buy some from the bakery. Better still, I don’t buy just one, but three boxes of hot cross buns. After all, if I were programming those transitions, then three unasked for transitions and some other features would be better and make my product owner happier than the one discussed, but still unasked for transition I offered to do. Right?

Guess what? My product owner wasn’t very happy when I told her what I had done. Where my engineer mind thought I was going above and beyond, in reality I was adding my own scope creep, wasting time and money on something that wasn’t asked for. If this was development, I would have put my sprint and deliverables in jeopardy, and wasted the company’s money on my salary for doing things I wasn’t tasked to do. I still put my deliverable in jeopardy, as these aren’t Publix hot cross buns, but fresh bakery ones, which won’t last nearly as long.

Plus, since the Hot Cross Buns were not in the original sprint plan (business trip), I have circumvented a process that is in place for a reason.  Remember that as a developer, the process is there to protect you too, but if you start agreeing to do things outside the process and without documentation, you could find yourself in a lot more trouble than you initially bargained for.  Plus, there’s always the “but you did it for me with the Hot Cross Buns…. Why can’t you do it for me with the Coffee?” argument that the product owner can make.  Or the you did it for product owner 1, but you won’t do it for me…. argument (which could get you into all sorts of HR issues.)

So the next time you want to do a favor for your product owner, make sure to agree to what is being requested, then prioritize the work, and document it. Don’t go assuming that they want something just because of a conversation or email. Don’t go involving other/different product owners with your questions because you’ll only get conflicting marching orders, and acceptance criteria. If you think there’s a better way of doing something, discuss it with the original product owner, as there may be a reason they are specifically asking for something, and there’s no need to add in all the extra work you’re considering. Instead make suggestions on how to improve upon their improvement.  And finally – Just remember the hot cross buns, and your product owner won’t get cross with you when you deliver.

As for all those hot cross buns? It looks like I have a lot more breakfast items than I had planned for…

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.

Further Reading

Digital transformation: The three steps to success

What digital transformation really means

Digital transformation: online guide to digital business transformation

‘Digital Transformation’ Is a Misnomer

 

Asking the Right Questions

I once worked for a CTO who had a very different leadership style than any other manager I had ever worked for in the past. He pulled from several different management techniques, but was ultimately rooted in the Socratic Method. Yes, he asked questions. Better still, he encouraged questions from those around him.

If you’re not familiar with the Socratic Method, it’s actually rather straight forward. This is the practice of teaching by asking open-ended questions with the intent on the students answering through examining their knowledge and beliefs. It is done to get students to think on the fly and not have to always rely on straight fact memorization. This discussion among students (and the instructor or leader) also adds the benefit of everyone involved buying in to the proposed answer, or at least knowing their their dissent was recognized and discussed and not just dismissed.

This CTO would quietly sit in meetings and listen. When the meeting was about over he would pose one, maybe two questions, and then watch and listen as we debated further. Occasionally he would have a predetermined outcome he wanted us to all reach, but more often than not he was just as interested in our discussion and path as we were.

More than once I would find myself in a one on one discussion with him and the only thing he’d say was a variant of “you make a valid point, but what is the real question you are trying to solve?” He challenged me to think deeper; to try and find the underlying question to the problem I was trying to solve. Some days it drove me crazy, but then I’d have that epiphany when I hit upon the “right question,” and it all became clearer to me.

I have always been inquisitive. It’s just my nature to ask questions. However, watching him in action was enlightening. I could wax poetic about how he had elevated it to an art form.

Those who didn’t like his methodology felt he was ineffectual because he didn’t always have a clearly defined agenda. They couldn’t have been more wrong. He knew what he wanted to achieve from the very beginning, but he asked us questions which in the end made all of us feel as though we had the ideas. In turn, that gave us a deeper ownership in the project as individual contributors as opposed to just receiving marching orders and being told what to do.

Since working under this person I’ve tried hard to “step my game up” with Socratic Management. I’ve tried to not just manage those around me, but lead them by asking questions and getting them to buy in to the ideas I have on their own. I’ve had some strange looks from some people, and have even had a few tell me that they’d rather just have me tell them what to do instead of asking all those questions. That’s fine, and I am happy to adjust for them. Others though really took to the questions, and I’ve watched them grow and become leaders in their own rights.

I still hear that CTO as a little voice in my head, telling me “You still haven’t asked the right question.” It drives me every day.

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?

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.

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.1 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.2

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.3 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