Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Big Companies Are The Best… In Maintaining Status Quo

    What happens when company grows from 10 to 100 people?

    Initially there’s a group of highly motivated and hard working people led by one or a couple of visionaries. Everyone knows each other well. Everyone knows what anyone else is doing at the moment. Then some success happens and organization grows. At the beginning it scales up trouble-free. Somewhere along the way teams emerge. Suddenly company needs a few managers. Who is promoted? What a question. Of course those who were in the pack when employee counter was one-digit.

    First hierarchy self-emerges. No one really thinks about this much. After all it’s all about a couple of teams, not full-blown organization. Then the company grows further and by the time it reaches 100 people there are probably at least two levels of management. First managers add new folks to their teams to the point they need middle management to deal with their 30-something people.

    Note: at that point there still isn’t much planning when it comes to organizing company structure. It is created in the meantime while people aren’t focusing on their work.

    What happens when company grows from 100 to 1000 people?

    By the time organization has 100 employees self-emergent structure becomes suboptimal. It is no longer a bunch of people working toward common success. If you don’t hire great candidates only, and let’s face it: you don’t, there are some people on board who just work there and don’t really care for anything beyond their paycheck. There are also few managers who shouldn’t become managers at all but should stick to engineering. To add some spice the company still grows at constant rate.

    The bigger it grows the more power management gets. Execs no longer work with line employees most of the time. They work with excel sheets and if they meet someone they are other execs or senior managers at best. Real power is moved one level down – to managers who make hiring decisions, promote employees and deal with all people-related issues. Who are they? Remember this few veterans who were around from the very beginning and become very first managers in the company? Well, now each of them leads one of multi-team departments with close to 100 pairs of hands each.

    Sure, there are reorganizations but most likely they happen out of the center of the company. Core remains unchanged. Why? Well, that is damn good question.

    A short answer is: because big organizations are great in maintaining status quo. I don’t want to argue whether a few hundred people make a company big (it does not) but somewhere between 100 and 1000 people this attitude appears and it is there for good.

    And here’s a long answer.

    • Think about management skills of early-managers. Most likely it is their first management job. Most likely they were engineers initially. I’ll be brutally honest: chances are good they doesn’t really suit management job. The problem is they don’t even know that. They can’t. They may even do their best and still suck as managers. If they have grown with the company they may lack just good role-models in management. I could bet my money against their management skills in this situation and, on average, I would win.
    • Now, put yourself in shoes of these veterans. They are with the company from the beginning. They career seems to be well-earned. They aren’t aware they may suck at what they do. When they were engineers they had simple verification of their work: test passed, client didn’t complain thus everything was good. With management it isn’t so easy. Their team won’t come to them to say they suck. Hey, you just don’t go to tell such things to your boss. We can even consider managers are aware they suck a bit. And what would they do? Resign to leave a position for someone better? You must be kidding me.
    • So what do execs do with this? Pretty much nothing. They’re chewing through their Excel sheets and as far as numbers are fine everything else is too. And if numbers start to stink who would they talk to anyway? Well, managers I guess. They’re disconnected with most of the rest of people for a long time already.

    Maintaining status quo is a safe choice for everyone who has enough power to make any important decision in the company. Those who see problems and would like to change something are either somewhere on periphery of organization or very low in hierarchy structure. The former aren’t taken seriously the latter hit the glass ceiling.

    What more, existing status quo propels the same behavior all over again. If the company promoted three out of four engineers from early setup to senior management the fourth one pretty much expects the same. And most likely he will get the promotion, no matter whether he was the best candidate or not.

    Of course you can find counterexamples. I don’t say every company works that way. I guess when Google hit 500th employee mark they were still nothing like that. I know startup where all 3 co-founders had experience in management so they aren’t likely to hit this reef either. I know companies which will never make it past 50 people so they definitely shouldn’t care about these issues.

    Anyway more often than not defending status quo is a problem. I’ve seen it at all stages from few dozens to few thousands of people. And it always looks like decision-makers weren’t aware of the fact or, if they were, like they didn’t care. When company grows to specific size it is just easier that way.

    In the next posting I’ll give an idea what can be done to change the situation. Stay tuned.

  • What Makes You a Great Professional

    I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.

    Now a second step – try to name one attribute which is common for each of them. Something which isn’t, by definition, related to specific role or specific job. Depending on variety of people you’ve chosen this can be pretty hard, but try for a while – there must be something. Got it? Great.

    What you’re trying to achieve here is finding a kind of success factor. Something which would differentiate good from great, but at the same time probably not something which would guarantee a mediocre person to become a star. That just isn’t so easy.

    What have you chosen?

    My choice is: urge to learn.

    This is something which constantly pushes us ahead, out of our comfort zone. Even if we err along the way the overall result is positive. As the time passes we get better and better since, well, learning is all about getting better. We grow to the point when someone thinks about us when asked the question from the beginning of this post. We’re not likely to get there though, so chances are good there’s still plenty of room for self-improvement.

    Learning can be a part of your job – in this case you should be pretty happy with it. You can also do a job which doesn’t develop you much at the moment, but it is a lame excuse to stop learning. There are tons of great places to get better at whatever you do or learn something completely new. If you stick with whatever you already know you’re heading to side-track.

    I have great news for you: if you reading this, odds are you have this urge. If you take time to look for content discussing personal development in context of your domain (I don’t expect many dustmen here really) you’re well ahead of the rest of the pack. You’re here to learn something new. Otherwise why would you spend your time reading this?

    If you’ve chosen something else than urge to learn tell me what is your choice and why.

  • The Kanban Story: Pseudo Iterations

    One of reasons why I like Kanban so much is because it doesn’t force you to formalize your process. You don’t need to set strict time-boxing for example. If you want to – fine do it, but if it doesn’t suit you fine no one forces you.

    If you happen to work in environment where priorities change very often, and we do work like that, you’re likely to reject time-boxing since this approach doesn’t reflect process you follow. We didn’t want time-boxing and this was one of main reasons we rejected Scrum initially.

    Iterations were bad. At least that’s how we thought.

    After some time I realized we basically had iterations. Sort of. We didn’t set time constraints like “we’re going to do features which fit 2-week period.” But we started grouping features into releases like “stories A, C, E and F which are top priority at the moment are going into the next release.” It was taking as much time as needed to complete a group of stories so it wasn’t time-boxing really but still a small and (mostly) closed set of work items to do.

    Why we started doing that?

    • To make releases easier to plan. As I saw sticky notes moving from the left to the right I could estimate when we were going to deploy new set of features in production environment.
    • To have more frequent releases. With no real release planning we ended up with not very frequent deployments. At least not frequent enough for me. When we added some planning we set some boundaries for our work and made it easier to deploy more frequently.
    • To make version control look less like hell. We don’t use distributed version control so every time we want to release we need a branch in our code repository. If we had a few branches actively used bugs would have to be fixed in each of them, so we’d like to avoid having plenty of active branches. If we had only one branch and we wanted to release only completed features, leaving those under development aside, it would be quite a challenge. Having small feature sets going into development and adding a branch every time we start new set brings an order to version control.

    So we ended up having pseudo iterations. Not as strict as in Scrum but still. I can’t say how long the next iteration would take but it most likely won’t take more than 3 sticky notes. I can’t promise I won’t add anything to the scope during the iteration but if it happened I had good reasons to do it (e.g. adjusting the app which would stop working after deployment to take latest case).

    Seems like iterations aren’t such a bad thing after all.

    Check out the whole Kanban Story.

  • The Kanban Story: Throwing Sticky Notes Out

    When you read about Kanban the thing which usually isn’t described in details is what happens with sticky notes which make their way to the right side of the board and are in the last column of your Kanban Board (however you call it).

    To be honest I didn’t put much thought in that when we were starting with Kanban. Our sticky notes were just stacking up in ready-to-ship column until we no longer could read them easily. And it was just a matter of time when they were going to come unstuck and fall being trashed by cleaner and forgotten forever.

    What we decided to do is to file a sticky note when a feature is actually shipped.

    We don’t ship every MMF separately although there are some who do that. We rather look for a complete set of features and ship them in a package. That’s why out “done” column was named “ready to ship” since it is one thing to have some feature ready and completely separated to implement it in production environment. At least it is so in our case.

    The key thing for our team is to have feature ready to deploy as soon as possible, not to have it live as soon as possible. It is so because due to a bunch of external dependencies (interoperability) deployment is pretty painful and rather long process which we definitely don’t want to do twice a week.

    However when we decide to ship something – there comes everything which is ready at the moment. This is the operation which empties our ready-to-ship column. I take all sticky notes which were in the column and add them to the stack stored in my drawer. After all we need some documentation, don’t we?

    Read the whole Kanban Story.

  • The Kanban Story: I Don’t Know, Experiment!

    I really liked Scrum versus Kanban session I made along with Piotr during Engineering Academy “Diamond Polishing” (both sites in Polish only). The theme of my part of presentation and the following discussion was the sentence I took from Henrik Kniberg must-read article on Kanban:

    “I don’t know, experiment.”

    – What kind of columns I should have on Kanban Board?
    – I don’t know, experiment. Our team’s Kanban Board looks like that. But don’t take is as a universal schema.

    – How many columns should be there?
    – I don’t know, experiment. See our board as example but don’t treat it as a bible.

    – What limits should I set?
    – I don’t know, experiment. Have I shown you our board we came up with? You know, that’s the result of our experiments, yours will be different.

    – How big should be the team to make Kanban most effective?
    – I don’t know, experiment. There are 5 of us, but your team is different I guess.

    – Should we put bugs along with MMFs on Kanban Board?
    – I don’t know, experiment. We don’t. Others do. How about you?

    – How long should we experiment before Kanban Board is ready?
    – I don’t know, experiment. We do it all the time because I’m never 100% happy. If you think yours is perfect than stop. If you change your mind then start again.

    If there’s one universal advice applicable basically to every light-weight method it is “I don’t know, experiment.” Light-weight methods leave many things flexible – you can apply them this way or another or don’t apply them at all. This creates a place for experimenting with what works well and what doesn’t.

    The less the method prescribes, and Kanban prescribes close to nothing, the more you can, and should, experiment. Especially that little prescription means you need to add some practices to run projects reasonably.

    Check out the rest of Kanban Story.

  • The Kanban Story: Kanban Alone Is Not Enough

    Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.

    I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.

    What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.

    We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.

    All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.

    So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.

    Read the whole Kanban Story.

    If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.

  • The Kanban Story: Kanban Board Evolution

    Our initial Kanban board was pretty simple. It looked like that.


    From the beginning we were set up to experiment and adjust it on the way. Here’s what we have changed.

    1. Documentation

    First thing was documentation. I know that’s not even trendy anymore to write documentations but yes, we do it. It helps us and if you add that we’re considering selling our products for the big companies which require documentations it isn’t even a matter of choice. Anyway, this was the part of our process and was usually started during testing and finished after testing was done.

    The problem was documentation was sometimes omitted and specific features could go live undocumented. The answer was another column which appeared between Test and RTS. We set limit to 2.

    To be honest after some time I’m not very happy with the column, or rather the way we incorporated documentation to the Kanban board, but for the time being it’s here. If it changes I’ll definitely let you know.

    2. Design

    Another issue which appeared was connected with research we sometimes did. That time it was about choosing a framework to support web application development in Java. It wasn’t development of a specific feature, but rather a prerequisite to do one. However we wanted to see some kind of representation of the fact on the board.

    So we added Design sub-column for Dev column. During design stage we split sticky-note feature to development tasks, adjusted architecture when needed and did research in cases like mentioned one. Usually sticky note made its way through Design stage very fast, but occasion it stood there for a few days so we knew what’s actually happening.

    Design didn’t get its own limit but was incorporated into Dev limit since it more an early part of development or preparation for development than a separate stage which result in some kind of formal design document or something.

    3. Testing limit

    After clearing initial overload in test stage limit of 4 seemed to be a bit too loose. I also believed it gave too little incentive to push our post-its to the right side of the board as fast as possible. We changed a limit to 3 and it appeared as a good decision since only once there was a threat to break this limit, but quick reaction allowed us to avoid that.

    After all these changes our board looked like that.


    This is definitely not the final shape of our Kanban board, but we aren’t in hurry when it comes to adjusting it. It is much better to do just one change at time and see how it affects your work. Then you decide whether the change was good or not. That’s how above adjustments were done – incrementally one after another. And if you do your changes I encourage you to choose the same approach.

    Check out the previous and the next version of our Kanban Board as well as the whole Kanban story.

  • The Kanban Story: What We Do and What We Don’t Do

    Last two posts of the series (on Kanban Board and on setting up whole thing) were Kanban implementation-in-a-pill kind of story. As you may guess that’s not all since Kanban doesn’t prescribe many things which you can use and, most of the time, you do.

    To show the big picture there are two lists: practices we use and these we don’t.

    Things we do

    • Cross-functional team.
    As I mentioned at the very beginning (the_beginning) we have cross functional team which is a great thing. Virtually every action connected with our product in any way is performed within the team.

    • Co-location.
    We sit together in one small room. That’s so damn great. I wouldn’t change it for private office even if you paid me.

    • Roles.
    We have old-school roles within the team. Developers who, guess what, develop. We have our commando guy who mixes roles of QA, system administration and maintenance. He could work as our bodyguard too. My role is project and product management which in our case could be called Product Owner as well. We also have a guy responsible for business development. Nothing fancy here. Everyone just knows what they’re supposed to do.

    • Measuring lead time.
    When I initially wrote a draft for this post this was on the “things we don’t do” list. For some time it wasn’t needed much since with no production environment it wasn’t crucial to know whether specific feature will be ready in 2 weeks or rather 16 days. Now, as we need more precise estimates, measuring lead time emerged as useful tool so we started doing that.

    • Continuous improvement.
    Implementing Kanban was an improvement to the old methodology. Starting to measure lead times was another. We look for tools or frameworks which improves the way we develop our products in terms of speed, quality, code readability etc. Nothing fancy here – we just try to make our lives a bit easier whenever we can.

    • Unit testing.
    We write and maintain unit tests. We don’t have 100% coverage though. I trust our developers would write unit tests wisely. Most of the time they add unit test covering a bug scenario as they fix bugs too.

    • Continuous integration.
    Oh, is there someone who doesn’t do that?

    • Static code analysis.
    There are coding standards we follow. They’re checked during every build. After a couple of weeks coding standards became native and basically invisible so it’s hard even to say that it’s a real practice.

    Things we don’t do

    • Iterations.
    At least formal iterations. We don’t have sprints whatsoever. To bring some order we group some features and call them “iteration,” but that’s nothing like scrumish iterations. I’ll write a bit more about our pseudo-iterations soon since that isn’t something very standard done by-the-book.

    • Stand-ups.
    We have permanent sit-downs instead. Whenever something needs to be discussed we just start the discussion not waiting for morning stand-up whatsoever. No-meeting culture works surprisingly well so far.

    • Formal retrospectives.
    Same as in previous point. We just launch “I don’t like it, let’s change it” kind of chats whenever someone has some valuable input. You could call them informal retrospectives on call.

    • Burndown charts.
    We have no fixed scope within iteration to burn since we don’t have real iterations. I occasionally draw burndowns for a specific feature (a single sticky note). I do it mainly to check how my well works schedule simulation (estimates plus statistical analysis).

    • Code review.
    I’m a big fan of code review. I tried to implement it twice in my teams and failed twice. As long as developers won’t want to do code review I’m not going to force them. That just doesn’t work this way.

    • Pair programming.
    This one I don’t believe in. So do our developers.

    • Test driven development.
    We write unit tests. We do this after not before. This is another practice I’m not a big fan of and another which takes people who strongly believe in it to make it work.

    If I forgot to mention something on either list just let me know what I omitted and I shall provide update.

    I encourage you to read the whole Kanban Story.

  • The Kanban Story: Kanban Board

    One of stages of one-afternoon Kanban setup we did was creating our own Kanban Board. We just discussed what we wanted on the board adding columns which appeared reasonable for everyone.

    This is what we came up with.


    To describe stages:

    • Backlog is a big bag where I willingly throw in anything anyone wants our project to have. Now we have the best product around. It will virtually have every feature in the world. I would also be a best Product Owner around. The guy agrees on every feature idea you could possible come up with. Unfortunately he can’t say when the product will have all these features.

    • Todo is a short list of current top priority tasks which aren’t yet started. It usually changes every time I come back from a meeting with one of our customers or partners. I keep the rule that whatever is on the top of this column is also the most important at the moment.

    • Dev, which comes from development, is a group of two columns: one is ambiguously named Dev, which comes from “in development” and another one states CC from “code complete.” The former groups tasks which are under active development. They make their way to the latter after developer’s tests. This couple is grouped since code complete is just a technical stage to tell us specific functionality is ready.

    • Test is what it sounds it is. Testing. Checking whether we could deploy version if we wanted to. Finding bugs and fixing them. On and on.

    • RTS comes from ready to ship. For the moment we set up the Kanban Board we weren’t planning to have regular deployments in production environment so we just wanted to have versions which would be possible to ship if we needed that. Whenever something reaches RTS column the work is considered to be done.

    Then, we wrote down all tasks which weren’t yet completed, including these being under development and these which were in plans only. Every task was written on a single post-it note and was posted under relevant column.

    We ended up with a post-it in Todo, two in Dev, one in CC and six in Test. The overwhelming rest was in Backlog. And yes, long Test column made our problem with finishing tasks painfully visible.

    When we were done playing with sticky notes it was time to set limits for each column.

    • Backlog doesn’t have any limits. That’s natural. Hey, I don’t want our product to lack any feature. Give me all of them. And I mean all.

    • Todo column was limited to 3. I think this is good maximum queue length – it makes clear short-term perspective. As it appeared later quite often it was hard to decide which sticky notes would make their way to Todo column and which would not. And it wasn’t rare when something was going back to Backlog before guys here were able to start working on this.

    • Dev was limited to 4. This included sum of both Dev-Dev column and Dev-CC. Basically we came up with the number assuming it’s still acceptable that each developer has one task completed (CC) and another one started (Dev).

    • Test was a biggest problem. We finally set the limit at 4. We knew 6, which we had in Test at that moment, was too much. On the other hand we didn’t have any clue what should it be. I was far from setting there a number which is too low and supporting fiction. So we used some guesstimation and use 4 as our lucky number. And it created an instant incentive to work hard on cutting this queue a bit.

    Finally our first version of Kanban Board looked like that:


    This is by the way much simpler board than Henrik Kniberg proposes as a kick-start example. Personally I encourage you to start as simple as possible. You’d adjust things later on. Henrik’s proposition is too complex for the team which isn’t familiar with Kanban. It pushes too much detail to the board which makes it hard to read.

    Read the whole story from its boring beginning up to this point, where things hopefully become interesting enough to keep you irresistibly waiting for the next chapter. Check also version 2.0 and version 3.0 of our Kanban Board.

  • The Kanban Story: Implementation of Kanban

    So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

    There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg’s article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

    Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

    The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server… OK, just joking here.

    Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t “marketable” at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

    To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

    Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

    Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

    Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

    Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

    I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.