Helping Your Boss Help You with Ken Kousen

Hello everyone. Just to let you know, our online software development conference, Qcon Plus, is back this November 1-12. You can expect curated learning on the topics that matter right now in software development. Qcon Plus is a practical conference, laser focused on learning from the successes and failures of domain experts at early adopter companies. If you enjoy the conversations we have on this podcast, you'll get a lot out of QCon Plus. To learn more about the conference, head to qcon.plus.

Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. I'm sitting down today with Ken Kousen. Ken, good to see you. How are you doing, sir?

Ken Kousen: Wonderful. Thank you very much, sir. I appreciate you having me on the podcast.

Shane Hastie: You and I have spoken and corresponded a bit. We've got some of your stuff up on InfoQ, but let's explore. Who's Ken?

Introductions [01:13]

Ken Kousen: Well, I am very active in the Java ecosystem basically, especially alternative languages like Groovy and Kotlin. My day job primarily is that I teach software development training classes. Now I have a one-person company, which I call Kousen IT, but my wife refers to as Cousin It. That was her idea.

Through that company, I do a lot of teaching on say the O'Reilly learning platform, I teach the intro Gradle class for the Gradle people, and I do a lot of direct work with other companies. There's a tour of the US called the No Fluff Just Stuff Conference Tour. I've been on that tour for about 10 years. I give talks on many different topics. I'm also a Java Champion, if that helps any. An Oracle Groundbreaker Ambassador ... Boy, I hate that name, but at any rate that too. Got a strong academic background, but that's a long time ago. I've been in the community for about oh, 20 some years now as an active trainer and everything. Prior to that, I was in the engineering and science communities. I did a lot of Fortran, a lot of math. So I was a career changer into IT, if that helps.

Shane Hastie: So in your classes, the ones that you teach directly with people today not so much in person, but at least synchronously, what are some of the most common challenges that the people that you're working with have to tackle?

Ken Kousen: Well, generally with a training class, we're dealing with working professionals in a business of course, and that means that as opposed to academic training, which is a whole different business, with training classes, people come in with a need to know something. They're there because they have a job to do, and they have something they are hoping that they will learn in order to do it. So that my is to figure out what everybody really needs to know, and then customize the material to better suit their needs so that they get their particular approach or their particular information. I also do a bit of technology transfer because I work with so many different companies this way that I get to meet people from all over the world. That way I can say, "Oh, I've met people who are taking this approach," or that approach or working with this in the industry.

Of course, that's one of the interesting things about technology in the industry is it evolves at different rates at different companies. Not everybody's on the cutting edge. Some people are way, way behind. You can watch trends roll through the industry like the migration to say, Git as a source code control mechanism or the rise of mobile apps, that sort of thing. You can watch that happen. So basically what everything comes down to when you really come down to it is that I'm not grading them, they're grading me. So I have to figure out what they need and give it to them. I also try, of course, in these classes to help anybody who needs extra assistance or to help women or underrepresented minorities. Any way I can help that situation as well, I try to do that also within my limited abilities to do so.

Shane Hastie: What are some of the trends that you're seeing? What are some of the things that are exciting to the technologists today?

Ken Kousen: One of the things that's funny is I teach a lot of classes based on the Spring framework. When we're talking about Spring years ago, we would always have been talking about a Java person building a backend web app that would produce views in HTML and serve them up to a browser. Everything was what we would now call a monolith. Everything was deployed on a server inside a company, and you'd have to set up your data source on that server and everything and everything was serving up HTML.

Now when I talk to people about Spring MVC, for example, I have to hesitate about even talking about serving up HTML because anybody under a certain age like 30, 35, something like that, everything's RESTful Web Services. I have to say, "Yeah, okay. We also do RESTful Web Services, and this is how you go about it," but I have to change all my analogies, all the background. Of course, the big challenge for me too, is I have to update all my jokes because all my gags, my pop culture references, get dated so quickly now. I have to move them forward as much as possible.

Shane Hastie: One of the reasons that we're in touch is you have written a book and published a lot of articles and stuff around the concept for technologists managing your manager or the book I believe is called, Help Your Boss Help You. Tell us a little bit more. Why do we need to manage up?

The need to manage up [05:39]

Ken Kousen: It's actually an interesting situation because I've written four books before and they were all technical. I've written a book on Java recipes and a book on working with Groovy and Java together, and a book on Kotlin and a book on Gradle with Android. All these things were very technical and yet on the No Fluff Tour, there was always an interest in building a talk for people in business and industry on how to work with their boss, how to work with their manager, how to work with others in the organization. Here's the thing. Most of the literature about management is written for managers. It's written for people who have become a new leader, the sort of thing you do, where they learn how to create change in an organization and how to motivate people to try new things and eventually move up the ranks into what we would normally call the C-level suite, something like that.

Very, very little is written for the working professional, the person who cares more about the details of their current job than about rising through the ranks. I found it notable on one of your earlier podcasts, the one with Tim Olshansky, I think it was, where he said he surveyed his developers to see how many developers actually wanted to become, I think the term was people managers at the time, and it was barely 1%. Yet we all have to deal with managers on a regular basis. In fact, your best ally is your manager inside an organization. If that relationship has problems, you're going to have problems. The problem is one of the other things that comes up is that as technology people, we're not on the management hierarchy so we're normally dealing with the managers who are the lowest rungs on the totem pole.

Therefore, they're people that have the least amount of experience and the least amount of proficiency. This can give us, IT people especially, a very low regard for what managers are like. The thing is, however, is that what managers want and what we want overlaps, but it's not identical. That means two things. One is that conflict is inevitable so you might as well plan for it. Two is that it's possible to come up with solutions that satisfy both sides. That give the managers what they need while also encouraging them to take our wishes and our needs and our desires into account so that when they make decisions that affect our job, our career, they keep in mind what it is we want as well as whatever they want at the same time.

Any rate that's the genesis of the book. It started off as a presentation I used to make on the No Fluff Just Stuff Tour called Managing Your Manager. Eventually I turned that into a bit more of a training class and a video, and I'd threatened for years to actually turn it into a book, and this book is finally the end result of all that time and all the talking to people and getting feedback and turning it into text-based form.

Shane Hastie: Let's explore. You mentioned conflict and that the goals between the technologist or the working practitioner and the manager, while they're aligned, they also have conflict. What are the common causes of that conflict and how can people tackle that or avoid that?

Conflict in the goals of manager and practitioner [08:46]

Ken Kousen: Well, the term we use in industry all the time is incentives. What are people's priorities, what are people's goals and what are they rewarded based on? The biggest difference between a manager's job and our jobs as working professionals is money. I don't mean money in salary or anything like that. We all want more money, but managers are evaluated based on money for the company. Is the project making money, is the project costing money? That could include things like extra resources and training and consulting and so on and so on.

I often use the analogy of ... I read an article once and I'd tell you, but I can't remember who it was ... It was an actor who was a director for the first time. He was giving an interview about being a director, and he told the interviewer ... Happened to be a guy in this particular case ... That the other actors on the movie knew this guy as an actor, and therefore wanted to have actor type discussions. How do we set up the back story? What's the motivation here and everything? He loved having those discussions. He'd been an actor. He was the normal technologist promoted into a different job. The problem was, is in the back of his mind the whole time, there's a voice going, "We're losing the light. I'm going to have to pay the crew overtime. I have to prepare the dailies. I have to talk to the investors." This constant refrain of, "Hey, there's money stuff going on here, and I have to pay attention to it."

Now, I put a little Venn diagram in the book that basically shows you have an agenda for your job and your career and your life. Well, your manager has an agenda as well. Most of the time they overlap, and we live in the overlap primarily. But the other things can still happen. Another example I've used before ... This is not a good example because well, it's telling for me, unfortunately ... Say you attend a conference or learn something ... Say it's a new JavaScript MVC framework or something. You would learn something about Vue instead of React, or instead of Angular. You go, "Ooh, I want to try this out." So you get eager, but you know that if you go to your boss and say, "Hey, I want to try out this totally new framework to me. I don't have a lot of reasons why it's going to be better, although I could show you the website. I don't have anybody to ask questions to if something goes wrong. But if you let me carve off a piece of our project, it'll be great."

That's a hard sell. That introduces a lot of risks to the process. So what often sometimes people will do is they'll carve off a piece very quietly, work on it "after hours." They'll figure out the problems on their own. Of course, it will creep into work time, because it's still a work project. Then if there's a happy path, if everything works, then they'll have a meeting with the boss and maybe the whole team and say, "Hey, look how easy it is to apply this framework to our problem, and all these advantages we get. Isn't this wonderful?" Now, from a manager's point of view, you've done some problems here. Now, assuming they're happy about it, which is not necessarily true, but assuming they're happy about it, you've now introduced a single point of failure into the system. I mean, you. What if you decide that you want to do something else now? Or what if you're very popular because you know this new framework and therefore you're too busy to keep up with all the projects they want?

The manager will think, "Well, you know what? I've got this junior person here. I'm going to have you train them, bring them up to speed on this new framework and help out." The problem is from your point of view, you are rewarded by your manager saying, "Here, I want you to train a low-cost version of you so I don't need you anymore. You've just demonstrated you're going to go off and do your own thing so let me use somebody more malleable." Both sides have done perfectly natural things and yet gotten themselves into a conflict because their incentives are different. We care more about the technology and the respect of your peers and solving the problem the right way. They care about those things too, but as long as they make money.

A more productive way to solve that is to build a relationship with your manager based on frequent periodic meetings, where you discuss these things and say, "Look, I attended this conference. Thanks for that, by the way. I learned this new technology, and I think it's got real promise. I'd like to try it out on our project." Then the manager can say, "Well, this project's on the critical path. It doesn't really fit our business goals right at the moment. We've got this other project." Or they could say, "No, we don't have time now, but I'll keep an eye out. If there's opportunity comes up, we'll definitely do it." In other words, it's part of the process now and part of the relationship. Building a level of trust and a level of loyalty, constructive loyalty, though, that works. Now I use this term constructive loyalty, and that's very loaded. I have to be very careful because the word loyalty has a lot of emotional overtones. People say, "Why should I be loyal to them if they're not loyal to me? Isn't loyalty something that has to be earned," and all of that.

Constructive loyalty [13:25]

Ken Kousen: What I try to establish is you're not trying to find somebody to marry. You're not trying to find somebody for your family. You're trying to build a professional relationship that respects both sides. That means by the way, when they do something you don't like, you have to learn how to push back in a way that doesn't threaten the loyalty relationship and that doesn't necessarily win. Because as soon as you're thinking win or lose with your manager, you're in trouble. You've already lost. You've got to find ways to make things, get both sides, achieve what they want. Build a long-term relationship so the manager knows they can count on you and that you can do the job, and you know that they will look out for you and handle administrative issues and do all the things we don't want to do. So any rate, that's more or less where everything is based.

Shane Hastie: Another intriguing topic when I was looking through the book was the good enough answers.

Good enough answers[14:18]

Ken Kousen: I have to admit, I got this idea somewhere and it's so long ago, I can't find where I found it. I don't want to pretend this is new to me. But boy, when I adopted it, it changed my whole life. The basic idea is this concept: a good enough answer today is way, way better than a great answer next week. It comes from the fact that we all come up through somewhat compatible educational institutions. In a school setting, when a teacher asks you a question, they have an answer in mind. They know. In fact, not only do they want to hear it, they want to know how you got it. They want to see all the steps and everything. I call this the game of school. The easiest way to win is to know everything, but even so, you have to figure out what is the teacher asking and how do they want to hear the answer?

Well, in business, when someone asks you a question, it's not because they have an answer. It's because they're stuck. They don't know how to make progress. So a manager will frequently ask an employee a wild open-ended question. Pick an example, like the manager will send an email saying, "Look, how do you think the recent changes in artificial intelligence and machine learning are going to affect our product?" As an employee, my first answer is, "I don't know. How am I supposed to know about? That's not my expertise." Yeah. Well, look, you create a good enough answer. If you're a Pomodoro person, you set a timer for 20, 25 minutes, say, here's what you do, the template you write down. "Okay. I don't know. But here are the things I do know. Here are the things I believe. This is what I think is going to happen. Here is what I would do to find out the answer."

You're giving them a very rough cost estimate of what it would take to really answer this question. Then you ask the magic question at the end, which is, "Do you want me to look into it?" Let them make the decision as to whether you put project work aside and spend days digging into this problem. Or if they just want to get an idea of what you know, because one of the easiest ways to build loyalty in any relationship, frankly, but also in business is to be responsive.

People really get frustrated when they ask somebody something and they can't get an answer back. This has been made so much worse when you're working remotely. People send something off into the void. They can't even go by your office and say, "Hey, didn't you get my email?" By setting up a technique of giving good enough answers like this, you become a very responsive person. Even if the response boils down to, "I don't really know," but you're giving them something and you're giving them an estimate of what you think it would cost. 90% of times or more believe me, the response to that will be, "Yeah, that's all I needed." It will be good enough. It's just amazing. It's a way of getting those questions off your plate in the least disruptive way possible for you. That's the real goal here.

Shane Hastie: What if I really want to do that deep exploration because I want to find out about this new technology?

Ken Kousen: Well, definitely, that's great because then you go and you make that part of your meeting with the manager, weekly, biweekly, whatever you've arranged with the meeting. You can then bring up ... I mean, you still give them the answer right away so that they have something to work with because you don't know why they asked it. Maybe somebody else in a meeting brought it up or maybe they were approached by a vendor. Or who knows? Maybe they're asking a bunch of people. Who knows? But in your next meeting, you can say, "By the way, I've been thinking about these issues for years. I want to learn TensorFlow. I want to dig into machine learning. I want to look into character recognition," whatever field you're interested in. Then you make it part of the plan. Then you make it part of the overall goals and discussions conversation as opposed to putting a question on hold for days while you dig into something.

Shane Hastie: One of the things that I find intriguing and vexing is how do we measure and how are we as technologists measured? There's KPIs, there's OKRs, there's acronyms all over the place. As a practitioner and as a manager, what are useful measures in software development space?

Relationships over metrics [18:15]

Ken Kousen: Well, that's a really tough question. As you say, there's a myriad of choices and there are entire books written on that sort of thing. Frankly, as a software developer, I look at it somewhat differently. I would say what do developers really want? What they want is the freedom to make decisions, to use their skills in the best way possible to accomplish tasks the right way and get them glory from their peers and from the organization, all of these things. None of those actually have metrics per se. There's no way to measure that. They're intrinsic motivations. That's why it's so hard to come up with evaluation mechanisms or whatever that can drive that because those things come from inside. If you come up with any metric at all, people will try to find a way to game the system.

Like for example, when I was in business, I would have managers who would try to be hands-off and we'd have to do a performance review. So they'd asked me to fill out, what did you do this year? What are your accomplishments? Then we'll go talk about it. That's what I would write my goals for the year so I'd write them retroactively. What did I do this year? So those must have been my goals, except one has to be a stretch goal and one, I have to exceed it. You game the system, whatever it is. I don't have a good way to measure any of these things actually.

Instead, what I'm more after is a relationship with management that gets you the freedom and the flexibility and the learning opportunities to do what you do best while making the manager feel like they've got an ally and they've got a great asset that they should find ways to keep happy. To do what you want and any numbers that go around that, well, you decide as a team how you're going to address that issue. Now, of course, if promotions are involved or things like that, then there generally are metrics, but that's a whole separate discussion. That's a big, long way of saying, "I don't know," isn't it?

There's one other topic, by the way, that comes up a lot in the book that you haven't mentioned yet. Let me just mention one thing, and the reason I hype on this is because it's a trap I fell into year after year after year. It's a problem I always had. I have a whole chapter on this. Your boss is not your friend.

Shane Hastie: That was one of the things I was going to explore. You say in any television show, coworkers and their managers become friends. Why not?

Your boss is not your friend [20:36]

Ken Kousen: Here's the thing. I'm not suggesting that don't be friendly. You do be friendly obviously. But again, mentioning like women or underrepresented minorities, as anyone in that position can tell you, and you know yourself in a relationship with your boss, there's a power relationship going on because your manager has power over your career, over your promotions and your raises, future assignments and things that can really affect you. When you have a big gap like that in power, then the problem with having a relationship as a friend like that is that it conflicts with the power relationship. The real attitude behind saying your boss is not your friend is not to tell your boss, "Hey, we're not friends anymore," it's to protect yourself because if you believe your boss is your friend, there's two traps you'll fall into or well, okay, there's two traps I always fell into.

My experience may generalize here, you let me know. One is that when your manager makes a decision that goes against you, you're going to be surprised and you're going to be hurt. Like if you get passed over for promotion, or if you wanted an assignment and they gave it to somebody else, or if a resource that you really wanted got given to someone else on the team or something like that, you're going to be like, "Hey, I thought you were my friend. I mean, friends don't do that sort of thing to each other." That's completely wrong. You have an agenda for your career and your life. They have an agenda as well. Most of the time, these things overlap. Sometimes they don't. The manager has other considerations to think about and sometimes they don't include you. If you think your boss is your friend, you get a whole emotional level that can wind up getting you hurt.

It's a professional relationship. It's not friendship. Now, the other trap that happens if you think your boss is your friend, is you will tell them things that you would only tell friends and then gamble that they'll forget about those things when it comes time for assignments or promotion. Like the boss comes by, "So how are things? What did you do over the weekend?" You say, "Oh, well, my wife's not happy. I've been spending too much time in the office and the kids are acting up and I've got this problem and that problem," and the boss was thinking, "Jeez, I was going to put them up for this possible promotion, but there's a lot of work involved with that." You don't want them thinking about that. You don't want them to even have that enter into their mind. Your boss is not your friend.

Don't tell them things you would tell friends. The only two messages you really want to give to your boss on a regular basis are, "I got this." Whatever it is, "I'll handle it. I'll take responsibility," and, "I've got your back. If things go wrong, we're a team, and I'll back you up. I'll say we made these decisions, even though obviously you did." Those are the relationship building issues to keep with your boss, not friendship where anything could happen. Heck, when I was young, I sometimes tried to make friends with my boss thinking it will protect me when things went wrong in the organization, and of course it didn't. It's just a source of pain. As you say on television, in the movies, any office environment not only turns into friendship, it turns into families. Nobody ever leaves, and the boss is a parental figure and all that. That's just not real. People come and go and businesses all the time. Your boss is not your friend. Just save yourself from that is the attitude I'm taking.

Shane Hastie: How do we cope with the so-called micromanager?

Coping with micromanagers [23:58]

Ken Kousen: Now, micromanagers again, there's many types. The ones I've experienced personally generally were what I call fear-driven, technology-based micromanagers. In other words, it was a technical person who got promoted into management, took the promotion thinking somehow would give them more control over their lives. Sadly disappointed of course. The problem is you've got a person who's got a job they don't like, and they don't understand and they have very little training for, and they were so successful at the technical job. They really love that. Here comes a task they know how to do. They're going to want to do it. And the good news is, well, the bad news first. The bad news is you can't fix it because you're not the problem. You didn't enter into that at all. Even if you would have done the task the exact same way the manager would have, that only validates their decision.

If you weren't going to do it that way, they get to show you how good they were at the technical stuff. In other words, it's nothing you can do. But on the other hand, it is a self-correcting problem. It just can take a long time. The manager's peers are going to be saying, "You can't do both jobs successfully. You've got two jobs here. You cannot be technical and manager at the same time." Eventually the boss's boss is going to say, "Look, I hired you to do this management job. If you can't do it, tell me I'll get somebody else." It is way easier to find a new low level manager than it is to find an experienced technical person, and they know it. They're very vulnerable. So my attitude is that again, there's not much I can do about it now.

You certainly can't do anything during the crisis while the micromanagement's going on. I have a high-risk strategy I sometimes throw in, which is basically to remind the manager how much time all these tasks are taking. How much time and effort it's taking to solve these problems because any real problem takes real time and effort. They don't have that time. So eventually hopefully they'll realize, "Okay, I've got to get back to what I'm doing. Let me know how it's going." Eventually I start in our meetings with the pushback of, "Look, I got this. Let me solve my problem. I'll let you know when there are issues," and try to handle it that way. Not during the crisis, but later.

Shane Hastie: You mentioned the regular meeting with your manager, and this is something that is important. What is that cadence, and what's in those conversations?

The value of one-on-one meetings with your manager[26:15]

Ken Kousen: Well, I first of all mention because this comes up ... Especially with low-level technical people who are having difficulty getting meetings with their boss ... Every good manager I've ever met has always insisted on weekly or biweekly meetings with all their technical staff. In fact, that's one of the reasons when a manager has more than say, 10 direct reports, I always think a reorg is coming because they spend all their time in those meetings with the direct reports. But the motivation is that you tell the manager, for example, that this is a way to get ahead of problems before they become crises. So you can find out about things that are what we would consider technical debt, or you could find out what's going on with a vendor you're trying to talk to or when you're trying to work with a particular piece of software. You could find out about small problems before they become big.

You can also let them know what's going on with you. How are you making progress? What have you accomplished? The little accomplishments, which wouldn't necessarily show up on a big performance review or on the tasks themselves. Because part of the key in building the relationship is you have to get to know the manager and the manager has to get to know you. They have to get to know that when you make it sound like you're lost, yeah, it's a normal stage you go through during the learning process and it doesn't mean you need help right now. Versus when you actually need help, and the only way to know that is to meet and build a relationship together.

Now, what I've tried in the past is I suggest a 20-minute meeting because nobody ever schedules a 20-minute meeting. They schedule half an hour and they hope to end early. It sounds like it's easy that way. It's not that big a problem. But as I say, every good manager I've ever had always established that anyway. We always start off with, "What did you do this week? What are we going to do for next week? Let's talk about issues in the middle." But it's critical. It's absolutely critical to the relationship.

Shane Hastie: Another chapter that's in there, and you actually call it out as perhaps it's going to be controversial, but recognizing types of behavior and adjusting your communication accordingly. Tell me more.

Adjust your communication style to the needs of your manager [28:17]

Ken Kousen: Okay. The issue, of course, when you're talking in any relationship is communication. It's how do you present your ideas in the way that is most likely to be heard and understood? One tool that has helped me over the years in doing that is learning a bit about personality typing. Now, as soon as you bring up personality typing, then everybody becomes sceptical. They start talking about pseudo-science. They're like, "Oh no, not the Myers-Briggs type indicator," et cetera, because HR departments have a love-hate relationship with this thing. They get everybody to take a test and then they do the worst possible thing you can do, which is to make hiring decisions based on personality types. That's just ridiculous. It may even be illegal, but it's a disaster. No, the goal is, in my opinion, is to find the preferences that your manager has so that you can approach them in the way they best able to understand what you're saying.

Now I start with Myers-Briggs, and I move to something I like much better, something called the Keirsey Temperament Sorter. To give you a simple example, in the Myers-Briggs type, there are sensors and intuitives, that's one of the big scales. A sensor moves step by step by step when they're learning something. An intuitive looks at the big picture first and then breaks things down step by step by step. I turn out the test very high on the intuitive scale. I spent four long years working for an extreme sensor.

The worst question a sensor can ask an intuitive is, "How did you that?" Because then I'd give the worst possible answer, which was the truth. I would be talking about analogies and big picture and throwing things out and trying all over again. That's not what they wanted to hear. When my boss said to me, "How did you get that," he didn't mean, "How did you get that," he meant, "How does he get that?" Once I learned that, I would back and fill. "Oh, you know where you are? Step, step, step, step. This is where I am now." He'd go, "Oh, okay. Did you really do that?" I'd say, "No." He didn't care for real, but we have both discussions, the step-by-step discussions and the big picture pattern-matching intuitive discussions. The question is which order.

You don't go into an extreme sensor's office and talk about computer science from Babbage on down. You talk about steps that you want to take. Then when they go, "Why," then you talk about the big picture. Versus an intuitive you talk about, "Hey, let's talk about the wide world of JavaScript MVC frameworks," or anything, and say, "Oh, that's interesting. How would we get there?" Then you do step, step, step. It's the same discussion just in a different order. That's the sort of thing that has helped me a lot in my career. It's the George Box quote ... You're probably familiar with it. "All models are flawed, but some are useful." That's the attitude I'm taking toward the personality typing system. Since it is controversial, I even put in the beginning of it, "Look, if none of this works for you, that's fine. If any of it's useful, great. Here's my take on it. Do with it what you will."

Shane Hastie: Hitting some really interesting points here. If people want to continue the conversation, where do they find you?

Ken Kousen: Well. Okay. First of all, the book is available at the Pragmatic Bookshelf as they say. It's called Help Your Boss Help You. It just went into the production process. So the entire book text is available in beta form, but it's going through copy, edit and all the normal publication stages. I expect it to be out sometime during July. So by the time this podcast is heard, it will definitely have been published by them.

Now, I personally have a weekly newsletter that's free. Free weekly newsletter called Tales from the Jar Side, which is mostly just talking about whatever I happen to find interesting that week and whatever I've learned, and of course, issues related to the book come up a lot especially when I do have a couple of say, high maintenance managers to deal with. I should also point out by the way, I was a high maintenance employee. I often got the term, talented, but high maintenance applied to me. So I understand these things. That's a lot of the reason that I've encountered these issues. I'm online at kousenit.com. Of course, I have a Twitter feed @kenkousen and my DMs are open if you've got stories. So any of those, and you'll have my email address as well. Feel free to make that available whatever way is easiest for you.

Shane Hastie: Thank you so much.

Ken Kousen: Oh my pleasure. Thank you very much.

Mentioned

• Book: Help Your Boss Help You
• O'Reilly Learning
• No Fluff Just Stuff Conference Tour
• Oracle
• Ken’s newsletter: Tales from the Jar Side
• KousenIT Training
• Ken on Twitter