Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Category: personal development

  • The Fallacy of Shu-Ha-Ri

    Shu-Ha-Ri is frequently used as a good model that shows how we adopt new skills. The general idea is pretty simple. First, we just follow the rules. We don’t ask how the thing works, we just do the basic training. That’s Shu level.

    Then we move to understanding what we are doing. Instead of simply following the rules we try to grasp why the stuff we’re doing works and why the bigger whole was structured the way it was. We still follow the rules though. That’s Ha level.

    Finally, we get fluent with what we do and we also have deep understanding of it. We are ready to break the rules. Well, not for the sake of breaking them of course. We are, however, ready to interpret a lot of things and use our own judgement. It will sometimes tell us to go beyond the existing set constraints. And that’s Ri level.

    I’ve heard that model being used often to advise people initially going with “by the book” approach. Here’s Scrum, Kanban or whatever. And here’s a book that ultimately tells you what to do. Just do it the way it tells you, OK?

    Remember, you start at Shu and only later you’d be fluent enough to make your own tweaks.

    OK, I do understand the rationale behind such attitude. I’ve seen enough teams that do cherry picking without really trying to understand the thing. Why all the parts were in the mechanism in the first place. What was the goal of introducing the method in the first place. On such occasions someone may want to go like “just do the whole damn thing the way the book tells you.”

    It doesn’t solve a problem though.

    In fact, the problem here is lack of understanding of a method or a practice a team is trying to adopt.

    We don’t solve that problem by pushing solutions through people’s throats. The best we can do is to help them understand the method or the practice in a broader context.

    It won’t happen on Shu level. It is actually the main goal of Ha level.

    I would go as far to argue that, in our context, starting on a Shu level may simply be a waste of time. Shu-Ha-Ri model assumes that we are learning the right thing. This sounds dangerously close to stating that we can assume that a chosen method would definitely solve our problems. Note: we make such an assumption without really understanding the method. Isn’t it inconsistent?

    Normally, the opposite is true. We need to understand a method to be able to even assess whether it is relevant in any given context. I think here of rather deep understanding. It doesn’t mean going through practices only. It means figuring out what principles are behind and, most importantly, which values need to be embraced to make the practices work.

    Stephen Parry often says that processing the waste more effectively is cheaper, neater, faster waste. It is true for work items we build. It is true also for changes we introduce to the organization. A simple fact that we become more and more proficient with a specific practice or a method doesn’t automatically mean that the bottom line improves in any way.

    That’s why Shu-Ha-Ri is misguiding. We need to start with understanding. Otherwise we are likely to end up with yet another cargo cult. We’d be simply copying practices because others do that. We’d be doing that even if they aren’t aligned with principles and values that our organization operates by.

    We need to start at least on Ha level. Interestingly enough, it means that the whole Shu level is pretty much irrelevant. Given that there is understanding, people will fill the gaps in basic skills this way or the other.

    What many people point is how prevalent Shu-Ha-Ri is in all sorts of areas: martial arts, cooking, etc. I’m not trying to say it is not applicable in all these contexts. We are in a different situation though. My point is that we haven’t decided that Karate is the way to go or we want to become a perfect sushi master. If the method was defined than I would unlikely object. But it isn’t.

    Are there teams that can say that Scrum (or whatever else) is their thing before they really understand the deeper context? If there are then they can perfectly go through Shu-Ha-Ri and it will work great. I just don’t seem to meet such teams and organizations.

  • Personal Ritual Dissent

    If I got a dollar each time I heard someone mentioning that they’d like to get more feedback I would be filthy rich by now. Heck, if I got a dollar each time I personally said that I would still got a decent sum. Most of us do want and like to get feedback. Most of us would love to get more of that.

    There’s obviously one thing to consider, which is what kind of feedback and received in what context is most useful for us. I’ve heard a lot of theories on that. One example is that we should always focus on positive or supportive feedback as people would improve their weaknesses subconsciously while they’re working on their strengths. Another is infamous feedback sandwich, which tells that each critical bit should but in the middle of two supportive ones. There are dozens of these.

    On one hand there’s a bit of truth in each. On the other I call bullshit.

    I don’t believe there’s a single, universal way of delivering and / or receiving feedback that works in majority of cases. Personally, while I like to hear positive feedback as it makes me feel good, I really learn when I get critical feedback. In fact, it doesn’t even have to be very constructive or factual feedback; I typically can make much sense out of non-constructive opinions too. And I don’t give a damn whether you add a sandwich to the mix.

    There are better ways of delivering feedback when we think about an individual context, but there is a universal answer in a general case. This means that the most useful feedback should be adjusted to the person who receives it. A nice thing is that we can tweak the situation so we get what works for us.

    If you learn from feedback in a similar way that I do, meaning that critical feedback is what makes you change, the following part is for you.

    I learned about the idea of ritual dissent some time ago. Back then I didn’t even know that it is Dave Snowden who should be attributed for creating it. Anyway, the basic idea is to create a situation where a group tears an idea apart looking for all the potential risks or holes. After a spokesperson presents an idea while everyone else remains silent, there’s a part when everyone dissents the idea while a spokesperson remains silent.

    There may be two goals in doing that. One is obviously improving the idea itself by making it risk-proof. The other part is that ritual dissent can be treated as a listening exercise. It’s not that easy to remain silent when someone tears your idea apart. At the same time this is what differentiates it from a futile discussion full of personal opinions.

    So here’s an idea: if you look for critical feedback you can use the same pattern in a personal context.

    No, it’s not a theoretical idea. I’ve done that.

    It hurt. A freaking lot.

    And I got more of what I wanted in half an hour than over the course of past year.

    And it was awesome. Once emotions wore out, that is.

    The thing is that adopting ritual dissent in personal context is, well, very personal. I was asking to be criticized. In fact, not-critical feedback was forbidden. No matter how much I learn from critical feedback it was nothing pleasant.

    I would even consider that idea as “don’t try that at home” one unless one has self-awareness in terms of how they’re going to react for such critique. Having a psychologist around when doing that wouldn’t be a bad idea.

    There are a couple things that make it work but two are essential. One is trust. I don’t say that everyone needs to fully trust a person being dissed. What is full trust anyway? However, there has be a decent level of trust so that anything that gets said won’t be used again anyone in any way. It may make the whole thing a bit tricky especially for managers or leaders where some sort of power relationship is involved.

    At the same time there’s a lot of followership. Once a few people who feel safe start dissenting others join. Especially when they see that a dissented person doesn’t break the rules and keeps the mouth shut.

    Another thing that makes personal ritual dissent work is listening, which is an inherent part of the exercise. It is a double-edged sword. On one hand the dissed person remains silent so the whole thing doesn’t turn into futile discussion. On the other the silence creates the pressure on the group. Someone eventually has to speak up even if it means going out of their comfort zone.

    An interesting thing is that it’s nothing pleasant on either end. The exercise, which we run mid-day, was basically a killjoy. At the same time it spurred a lot of spin-off discussions afterwards, which is a reason why I wouldn’t do it at the very end of a day.

    The best part is that getting critical feedback is not the ultimate value of the exercise. Since it creates a lot of tension and moves people out of the comfort zones it breaks some mental barriers that people had, thus makes sharing feedback later way easier.

    After all sharing one critical opinion is nowhere close to dissing someone collectively for half an hour in a row.

    Finally, some of feedback won’t be really addressed to the person who asked for a personal ritual dissent. It may be formulated in a way as it was so, but the real addressee would be somewhere else in a room and hopefully they’d get it too.

    So if feeling like shit for (at least) a few hours is a price you’re willing to pay for a ton of valuable feedback, this is an idea for you. Would you dare?

  • Why People Don’t Learn

    Josh Bradley in a comment under one of my older posts made me realize an interesting thing. Let me do the weirdest thing ever and quote myself a few times.

    “In general, people don’t care if you want to (and can) teach them something. They don’t want to learn.”

    Pawel Brodzinski, 2010

    “People are lazy. They don’t learn because it’s easier to leave things as they are.”

    Pawel Brodzinski, 2010

    “Theory X tells us that people are lazy and we need to supervise them otherwise they’d do nothing. If you ask me, that’s total bullshit.”

    Pawel Brodzinski, 2013

    Now I feel so much better – someone has just quoted me. Wait, wasn’t it auto-quotation? Oh well…

    The point is that three years later I seem to have completely opposite point of view. I used to think that people are inherently lazy and now I consider that absurd. Embarrassing, isn’t it?

    Let me start with defending my younger self. On one level lazy, not willing to learn attitude is as ubiquitous as it was. I still look at the vast majority of people and see the same dysfunction. People would complain how their organizations don’t support their intrinsic urge to learn. At the same time they’d idly sit looking as learning opportunities as they pass by making a swooshing sound.

    The symptoms haven’t changed.

    What has changed is how much of a cause I ascribe to the people.

    I’m not a systems thinking junkie. I do consider people co-creators of the system they operate in. At the same time though they start with a given situation and can’t change it freely, thus the system constrains them on many accounts.

    How does it translate to laziness and reluctance to learn? Well, the questions we should ask are how the organization supports learning and what the rewards (or punishments) are when one decides to invest their time to self-development.

    There are (many) companies which don’t support personal development of their employees. This makes the game whole more challenging. At the same time I’m yet to see an organization where there is virtually no opportunities to learn.

    In fact, I think these two perspectives are inseparably connected. An organization that doesn’t support learning would discourage people with an urge to learn to stay there in a longer run. What’s more people who rarely give a damn about learning would thrive there sustaining the existing culture. Obviously, the opposite is true as well.

    As Jim Benson said “people build systems build people.” Both of them have to be in place to see continuous learning culture flourish.

  • Against Rightshifting

    Rightshifting is a nice idea. In its origin it says about improving effectiveness of organizations. When an organization rightshifts it becomes aware of different approaches, methods and techniques that can be used to work better. Eventually, the company adopts some of them and starts treating them as non-optional. Oftentimes, it means that the organization refuses to work “the old ways” as it is clearly considered suboptimal.

    I do like to think about rightshifting in terms of personal development. Every one of us can (arguably should) learn new approaches, methods and techniques. With such an attitude we eventually learn how to work better. Oftentimes, we’d love to reject to work differently, on occasions we even do, although this time the case is more complex.

    Being a part of a bigger entity, we rarely have comfort do fully decide how work is being done. If you ever heard “do we really need to write unit tests (a client won’t pay for this)” discussion you know exactly what I mean.

    What happens then? Well, usually we develop our frustrations regarding lack of workmanship. Some leave in pursuit to find another job that suits better their expectations and skills. Some stay and try to change the organization from the inside. Sometimes they even succeed, although more often a success is local (a team level) than global (an organization level). Anyway, besides these rare successful cases usually much frustration is involved.

    Bad news is that a scenario involving frustration is a frequent one when we personally rightshift. More often than not, the pace of our personal improvements is better than the one of organizational improvements. On one hand it means that personal rightshifting introduces at least some dissatisfaction. On the other it should open new opportunities.

    Yes, of course. The problem is that there are fewer and fewer of them, the further to the “right” you are. There aren’t enough great companies, or I should say mature enough companies. I mean, maybe there are, globally. But few of us operate on a fully global job market and jobs in general, and jobs at great companies specifically, aren’t distributed evenly across the world.

    So sorry, in most places on earth “there’s no shortage of talent, only a shortage of companies that talent wants to work for” isn’t true. Even less so, when one has high expectations for craftsmanship and organizational standards.

    In other words, in theory, you can rightshift yourself to the point where you’re practically unemployable because you aren’t willing to accept anything but your impossible-to-meet standards of work. I’m pretty sure it’s not only theory and quite a few folks out there could tell by their own experience.

    I know by mine that definitely the more to the “right” you are the fewer companies you want to work for.

    So my advice would be: don’t rightshift… too fast.

    Be aware that rightshifting closes a few options here and there. Rapid rightshifting may close the option you’re exploiting at the moment too (also known as a current job). I wouldn’t call rightshifting a career-limiting move, although in some ways it might be considered this way.

    Is it different when we look from a perspective of an organization? A bit. When the company rightshifts faster than individuals working there, there is frustration too. However, people tend to adjust to the way their company works. After all, it is one of conclusion that may be drawn from famous Deming’s work (95% of variability is caused by the system). In other words, improving the system (the organization) we naturally pull people to the “right” too. Most of them at least.

    Unfortunately, raising standards means that there are fewer people that you’re willing to hire. It limits company’s pace of growth. It makes hiring people’s work way more difficult. Of course you can always fall back to good old growing people from basics but you can afford to have only that many of them.

    So again, don’t rightshift… too fast.

  • On Transparency

    One of things I’ve learned throughout my career is to assume very little and expect to learn very much whenever changing a job. In terms of learning, there always is a great lesson waiting there for you, no matter what kind of an organization you’re joining. If you happen to join a crappy org this is the least you can salvage; If you join a great one, it’s like a cherry on a cake. Either way, you should always aim to learn this lesson.

    But why am I telling you this? Well, I have joined Lunar Logic very recently. From what I could say before, the company was a kick-ass Ruby on Rails development shop with a very open and straightforward culture. I didn’t even try to assume much more.

    One thing hasn’t been a surprise; We really are a kick-ass Rails development shop. The other has been a surprise though. I mean, I expected transparency within Lunar Logic, but its level is just stunning. In a positive way of course.

    An open discussion about monthly financials, which obviously are public? Fair enough. Questioning the value of running a specific project? Perfectly OK. Sharing critical opinions on a leader’s decisions? Encouraged. Regular lean coffees where every employee can come up with any subject, even one that would be considered embarrassing in almost any organization I can think of? You’re welcome. I can hardly come up with an example of a taboo topic. In all this, and let me stress this, everyone gets honest and straightforward answers.

    Does it mean that the company is easier to lead? Um, no. One needs to think about each and every decision because it will be shared with everyone. Each piece of information should be handled as it was public. After all, it is public. So basically your goal, as a leader of such an organization, is to be fair, whatever you do. There’s no place for deception, trickery or lies.

    One could think that, assuming goodwill, it is a default mode of running a company. It’s not. It’s very unusual to hear about, let alone work at, such an org. There are a number of implications of this approach.

    • It is challenging for leaders. You can’t hide behind “that’s not for you to know” answer or meaningless blah blah. People won’t buy it. This is, by the way probably, the number one reason why this approach is so uncommon.
    • It helps to build trust between people. Dramatically. I don’t say you get trust for free, because it never happens, but it is way easier.
    • It eliminates us versus them mentality. Sure, not everyone is equal and not everyone has the same role in the company, but transparency makes everyone understand better everyone else’s contributions, thus eliminates many sources of potential conflicts.
    • It heavily influences relationships with customers. It’s much easier to be open and honest with clients if this is exactly what you do every day internally. I know companies that wouldn’t treat this one as a plus, but being a client, well, ask yourself what kind of a vendor you’d like to work with.

    All in all, transparency is like a health-meter of an organizational culture. I don’t say that it automatically means that the org is successful, too. You can have a great culture and still go out of business. I just say that if you’re looking for a great place to work, transparency should be very, very high on a list of qualities you value. Possibly on the very top of the list, like it is in my case.

    By the way, if you are a manager or a company leader, ask yourself: how many things wouldn’t you reveal to your team?

    This post wouldn’t be complete without giving credits to Paul Klipp, who is the creator of this unusual organizational culture. I can say that during first few weeks I’ve already learned more about building great teams and exceptional organizations from Paul than from any leader I worked with throughout my career. It goes way beyond just a transparency bit but that’s a completely different story. Or rather a few of them. Do expect me to share them soon.

  • Scott Berkun on Consultants and Practitioners

    Continuing the discussion on differing perspectives of consultants and practitioners, I have asked Scott Berkun a few questions on the subject. I chose Scott because for the past few months he has been coping with both options: while publishing his next book – Mindfire: Big Ideas for curious Minds – he spent a year and a half having something like a regular job at WordPress.com.

    Not only was I curious about Scott’s views on the subject but also I think we can learn a lot from him, especially those of us who are considering coupling both roles. So here are a few gems of knowledge gleened from Scott.

    Scott, you’ve recently left Automattic where you worked for some time and it has triggered me to ask you a few questions about your spell there. The difference between insider versus outsider or practitioner versus consultant perspective is something that draws my interest for some time already. You’ve decided to try living both lives concurrently and it gives you a unique perspective on a subject.

    Reading your blog and your tweets over time, my impression is that your enthusiasm for having a regular job while pursuing your career as a writer and a consultant was diminishing. Was that only an impression or there is something more to it?

    The plan was always to stay at WordPress.com for about a year. It’s a great place to work and it was hard to leave. Any complaining I did was probably just to help convince myself I needed to leave, which was hard to do as I enjoyed it so much. I stayed there for 18 months, 6 months longer than I’d planned.

    What was the biggest challenge of having two so different careers at the same time?

    Having two careers sucks. I don’t recommend it. My success in writing depends on full commitment. I can write books because I have no excuses not to. I succeed by focus. It’s the primary thing I’m supposed to do. Having two jobs divided my energy and I don’t have the discipline needed to make up for the gap. It also changed my free time. I noticed immediately the amount of reading I did dropped dramatically. I used to read about a book every week or so. That dropped to a book every few months. Having two jobs meant my brain demanded idle time which came at the expense of reading. I felt like I was working all the time, which isn’t healthy for anyone.

    And what was your biggest lesson from this time?

    The next book is about my experience working at WordPress.com and what I learned will be well documented there. Professionally I learned creating culture is the most powerful thing a leader does, and WordPress.com has done that exceedingly well.

    Do you think that coupling consultancy and a regular job is doable in the long run?

    I don’t know why anyone would want to work that much in the same field, honestly. For anyone who thinks I’m good at managing teams, or writing books, a huge reason why is the other interests and experiences I’ve had in my life that have nothing to do with leadership or software or writing.

    Do you plan to get another job at some time in future again? Why?

    As long as I’m paid to speak to people who are leaders and managers, it’s wise for me to periodically go back to working in an organization where I’m leading and managing people. It forced me to test how much of my own advice I actually practice, and refreshed my memory on what the real challenges are. Any guru or expert who hasn’t done the thing they’re lecturing others about in years should have their credibility questioned. I figure once a decade or so it’s a necessary exercise for any guru with integrity.

    Why we should consider moving to (or staying in) a consultancy role?

    When I first quit to be on my own I did a lot of consulting. As soon as the books started doing well and I had more requests to speak, I did less and less of it. I do it rarely now. Consultancy can be liberating as you are called in to play a specific role on a short time frame. If you like playing that specific role and like change (since who you work with changes with each new project), consultancy can make you happy. It pays well if you are well known enough to find clients.

    Why we should consider moving to (or staying in) regular jobs?

    Consultants rarely have much impact. Advice is easy to ignore. Consulting can be frustrating and empty for the consultant, even if you are paid well. Anyone serious about ideas and making great things knows they have to have their own skin in the game to achieve a dream. You can’t do that from the consulting sidelines. In a regular job at least there is the pretense of ownership. Everyone should be an entrepreneur at least once in their life: you can only discover what you are capable of, or not, when you free yourself from the constraints of other people.

  • On Feedback

    I’m not a native English speaker, which basically means my English is far from perfect. Not a surprise, eh? Anyway, it happens sometimes when one of natives I’m talking with corrects me or specifically points one of mistakes I keep making.

    And I’m really thankful for that.

    I’m thankful most of the time such feedback happens instantly so I can refer to the mistake and at least try to correct it somehow.

    This is what happened recently when one of my friends pointed one of pronunciation mistakes I keep making. It worked. It did because feedback loop was short. It worked even better because it was critical feedback. I didn’t get support for all the words I pronounce correctly. It was just a short message: “you’re doing this wrong.”

    Of course it is my thing to decide whether I want to do something about this. Nevertheless I can hardly think of positive feedback I could receive that would be that helpful.

    When you think about this, it is contradictory to what we often hear about delivering feedback. It isn’t uncommon that we are thought how we should focus on positives because this is how we “build” people and not “destroy” them. Even more, delivering positive feedback is way more pleasant and for most people easier as well. It is tempting to avoid the critical part.

    When we are on feedback loops I have one obvious association. Agile in its core is about feedback loops, and short ones. We have iterations so we deliver working software fast and receive feedback from clients. Or even better, we have steady flow so we don’t wait till the end of sprint to get this knowledge about the very next feature we complete. We build (and possibly deploy too) continuously so we know whether what we’ve build is even working. And of course we have unit tests that tell us how our code works against predefined criteria.

    It is all about feedback loops, right?

    Of course we expect to learn that whatever we’ve built is the thing clients wanted, our code hasn’t broken the build and all the tests are green. However, on occasion, something will be less than perfect. A feature will work not exactly the way a client expected, a build will explode, a bunch of tests will go red or pronunciation of a word will be creepy.

    Are we offended by this feedback?

    Didn’t think so. What more, it helps us improve. It is timely, specific and… critical. So why, oh why are we that reluctant to share critical feedback?

    It would be way more harmful strategy to wait long before closing a feedback loop, no matter what the feedback is. Would it really tell you something if I pointed you this two-line change in code you did 4 months ago, that broke a couple of unit tests? Meaningless, isn’t it? By the way: this is why I don’t fancy performance reviews, even though I see the point of doing them in specific environments.

    Whenever you think of sharing feedback with people think about feedback you get from your build process or tests – it doesn’t matter that much whether it is positive or critical; what makes the difference is the fact it is quick and factual.

    You can hardly go wrong with timely and factual feedback, no matter whether it is supportive or not.

  • Kanban and Behavioral Change

    One of my favorite and yet most surprising things I learned about Kanban over the years is how it steers change of behavior among mature teams. It shouldn’t be a surprise that at Kanban Leadership Retreat (#klrat) I ended up facilitating a session covering this area.

    Those of you familiar with #klrat format would understand me when I say I didn’t have any specific expected outcome of the session. I wanted to start with exchanging stories and see how it goes. Maybe we would be able to observe some patterns of behavioral changes steered by Kanban and learn from that.

    Fast forward to what we ended up with. For me it is still work in progress, so will see more on the subject soon. Anyway I pushed my thinking forward in terms of how we can stimulate our teams to improve.

    One thing you instantly notice on the picture with the session summary (click to enlarge) is that there despite the fact we were gathering unrelated stories we started building a chain of dependencies. Another observation is how frequently visualization pops up in different examples.

    What I believe we will be able to build is sort of a graph showing what kind of behavioral changes can be influenced or even incentivized with adopting specific practices. What more, I don’t want to keep it purely about Kanban. Although at #klrat Kanban context was set by design I’m pretty sure we can, and should, go beyond this context.

    A few highlight from the session, basing on stories we’ve shared:

    • Visualization combined with WIP limits and daily meetings around the board improve general team-wide knowledge about what’s happening. In short term this influence how people deal everyday tasks, encouraging them to get involved in work done by others, thus removing personal queues. As a result it pulls people toward generalization as they’re involved in many different tasks.
    • Visualization and measuring flow improves understanding of work. It makes people to focus on pain points and incentivize them to improve problematic areas. As a result a team takes more responsibility for how the work is done.
    • Rich visualization along with slack available to people results in better decisions and better use of slack time. It bases on a notion that rich visualization derives more meaningful data so whenever people decide what to do, especially when they aren’t constrained, e.g. when they’re using slack, improves the quality or potential outcome of these decisions. The final effect is building team’s collective intelligence both in terms of what they do and how they do it.
    • Making visualization fun fuels viral adoption of the method. It bases on a fact that people like having fun with tools they use. More fun means more people trying to find out what this cool thing is and how to use it. Eventually you get more people willing to introduce the method and better attitude toward the adoption.
    • Measuring flow (again) and understanding and visualizing (again) the nature of work can have impact in a multiple ways: creating incentive to change, building trust to a team and getting rid of 100% utilization. A simple fact that we were able to address so many effects to improved understanding how we work is a strong indicator that we do have problems with that. We might be onto something here.
    • Avoiding 100% utilization and slack time, which is generated this way, may be a tool to build leadership among the team (people are free to make decisions on what’s being done) and at the same time can improve fun factor (people can choose to work on fun stuff). In both cases we strengthen our teams and develop people.

    By the way: if you add a real story to each of these highlights you may imagine the experience we exposed ourselves to.

    In retrospect, one thing that is definitely worth stressing is how little we seem to know about nature of our work. Actually if you think about it, Kanban deals with this issue in a very comprehensive way.

    Visualization vastly improves information availability so we know better what is happening. Explicit policies force us to define, or agree on, the way we do work. Without explicit discussions on that we often believe we know how exactly how the work is done even when it’s clearly not true. Then we have flow management with a focus on measures that can change our perception of work highly. It’s a common situation when, being an outsider basing on a handful of simple measures, you can surprise a team showing them specifics of their work.

    If that wasn’t enough we get WIP limits that steer changes in the nature of work and give us an important lesson about nature of work in general.

    Anyway, leaving tools aside the lesson is to invest more effort to understanding how we work. It will pay off.

  • What Do You Want To Do In Two Years From Now?

    As a manager of 130-something people I often have these chats on what opportunities people have to grow within the organization. You know, with such crowd you can pretty safely assume that people do want to grow, to change their role, to get promoted. So they eventually land on a sofa in my office to discuss their future.

    On one hand these discussions are always challenging. I mean we’re discussing here one’s future. That’s a serious matter. On the other most of the time I find it easy to share a flurry of ideas on where someone could push their career.

    The context of organization is pretty much set – we know what we do, we roughly know how we do it and we definitely know how, in general, we want to improve it. And yet people often need a lot of guidance to show them what they can do in a couple years from now.

    One thing is people often constrain themselves to just the lowest hanging fruit. I’m a developer so the next step is senior developer. Then a tech lead and then a software development manager. Oh so creative. How about business analysis, project management, product management, quality assurance (yes, this one too) or what have you?

    While we are going beyond mental constraints, why not running a startup, consulting or freelancing?

    Or simply doing the same thing you do and rightshifting at the same time? Do you really need a new title on a business card to feel fulfilled? Maybe you just like what you already do and the fun comes when you shift toward improved effectiveness?

    One could say that having much power it’s easy to come up with different ideas but I do as I preach. I mean I consider myself a leader. My current team has, at the moment, 130ish people. The previous one had 4. Another 35. In each and every of them I was self-developing like crazy. In each role I could imagine myself in a year being in any of others as well as doing a bunch of different things. I didn’t feel constrained either by the current situation or by current organization. These things change very rapidly in IT.

    When you are asked a question what you want to do in two year time (and believe me, I ask this question a lot) it’s not a question about current options in your organization but it’s a challenge to your mental constraints.

    As simple as that. No one is going to offer you a project management position or their biggest software development division unless they’re convinced you will manage. You won’t convince them using your will solely. You need to know what it takes to do the job, understand different approaches and have a vision of your own path.

    My wild-ass guess is that you don’t know all that at the moment. That’s great. Because I’m not going to judge anyone on their current knowledge. I’m going to judge them on their potential and their urge to learn.

    With such attitude you render your mental constraints irrelevant and you don’t need to ask anyone about your options anymore. You know the answer.

  • Better Conferences or Better Learning?

    Bob Marshall recently published his ideas how to improve conferences. Pretty radical ideas I’d say. Basically what Bob proposes is to move from traditional one-way communication to bi- or multi-directional conversations with expertise available on demand (read the whole post – it’s worth it). By the way similar points were shared by Jurgen Appelo in his writing as well.

    I’m no conference animal, even though I helped a bit to organize a few of such events and attended a few more. I went through different formats, from whole day long workshops, through few hour long tutorials, through anything between 90 and 30 minute long sessions, open spaces, TED-like no-more-than-18 minute-long performances, lightning talks, pecha kuchas and whatnot.

    While I understand Bob’s desire to change knowledge consumption from push model to pull model I find it hard to buy his ideas uncritically.

    There is one reason. The conference isn’t better because this or that format is generally better, but because the very set of people attending the very event learned much. In other words, thinking about an event we should think how this specific set of attendees is going to learn, which is a function of how they expect to learn and how they are prepared to learn.

    One of the best events I ever attended was Kanban Leadership Retreat. It was an unconference. It exploited many of ideas Bob shares. From a perspective of attendee, who was willing to learn even though they brought significant knowledge on the subject, it was great. The learning process was very multi-directional and pretty much everyone was both: a teacher and a student.

    At the same time on occasions I speak at events where such format would fall flat on its face. It would, as people who attend generally expect knowledge to be pushed to their heads. You may laugh but actually even such approach is sometimes expected in a whole spectrum of behaviors. On one end there’s mindless zombie who was sent to the event by the company (yet still they can learn something). On another there’s TED, where you know close to nothing on vast majority of subjects being discussed and actually expect expertise from people on the stage. Note: we’re still in “Dear speaker, I know nothing of whatever you’re talking about” land. I know there is another dimension where you move from one-way learning to everyone’s a teacher attitude.

    So basically my thought on the subject is: first, understand what the effective method of learning is for this very group you’re sharing your knowledge with. And yes, I’m talking here about majority, or average, if you excuse me such vast oversimplifications. I’m saying so because we don’t measure success of event by happiness of most demanding person in the room. Even more, probably the most demanding person in the room shouldn’t be happy with the event, because arguably it would usually come at a price of having many others not catching up with the content.

    Having said that I believe that generally speaking conferences should head the way Bob describes as our focus is still on pushing knowledge, not pulling it. I wouldn’t be so quick to revolutionary change all the events though – I would rather look for opportunity to broaden variety of methods attendees can use to learn.

    This is what a better learning is all about. And better learning is something better conferences should be all about.