Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Technical Leadership and People Management

    The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

    They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

    Well, actually it is not.

    Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

    Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

    On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

    That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

    Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

    You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

  • Random Thoughts on Estimation

    A lot of discussion on estimation recently. A lot of great arguments but a lot of good old mistakes we’ve already went through. This brought me to a few random thoughts on estimating techniques.

    1. Estimation technique which involves discussion between different people is better than one which just simply uses their estimates as input.
    2. Using factual recorded historical data is better than basing just on experience.
    3. Smaller tasks can be estimated way better than big chunks of work.
    4. Every estimate starts with some kind of guess at the very beginning.

    I know these should be obvious yet I’m surprised how often people:
    – forget about them
    – deny these are true

    Then they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real estimation.

  • A Company Which Didn’t Know How to Fire People

    There was a company, which was doing reasonably well. When times were good they were growing stronger. Some people were leaving, as it always happen, but more were coming on board. Since things were rolling fast no one really had time to stop and verify whether all new faces are doing fine.

    Some time passed. Newbies were no longer newbies – they were semi-experienced people or at least their seniority would indicate that. Reality was a bit different. Some new people appeared to be great hires but other were, well, pretty mediocre.

    Then stagnation period came. There were reasonable amount of work but not as much as it used to be yet somehow everyone looked still pretty busy. Incoming stream of new people were limited and the company mostly stuck with these who already were on board. World crisis increased employee retention.

    Then people started telling stories. A story about the guy who was sleeping at his desk during one third of his office hours. A story about lad who was in the office barely 6 hours a day even though he was paid for 8-hour workday. A story about lass who was spending all days long browsing the web. A story about colleague from another office who claims she’s completely overworked yet she was doing about one tenth of what other people did on similar positions. Morale nose-dived. Productivity started dropping. On a side note – no, these examples weren’t made up.

    Where’s the problem?

    The first symptom was not doing much with poor-performers. OK, they were trying to fix their approach but when coaching and setting rules didn’t work there was no another steps. Underperformers soon learned they didn’t have to change.

    A real problem was: the company wasn’t able to fire people.

    They stuck with every single employee no matter how they sucked. And yes, I know they should try coaching, training, finding new role first. To some point they did. But face it: it isn’t possible to have only perfect teams and only perfect employees. It just doesn’t work that way. Even companies which have very strict recruitment process find black sheep in their teams from time to time. And vast majority of companies aren’t very demanding when it comes to recruitment. Especially when time is good and they need all hands on deck and would take almost anyone who can help at least a bit.

    I understand lack of will to fire people. Firing people sucks. But it’s a part of manager’s job and from time to time it just has to be done. Cost of rejecting to do this is way higher than just poor performance of a couple of people. It spreads like a sickness. Yet somehow I still hear about companies accepting underperformers for some reason.

    Update: Since the post received pretty much buzz in my company a small disclaimer: this is true story but not about my current company, not even about any IT company. Yet still it’s about a firm I know pretty well. Anyway I used the example since the case is pretty general.

  • Is It Possible to Over-Communicate In Project?

    While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”

    Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?

    Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.

    Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.

    John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.

    Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.

    The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.

    On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.

    How does it look like in your teams?

  • Sure Shot Method to Improve Quality of Your Estimates

    That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.

    Split your tasks to small chunks.

    If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.

    Why it works?

    • Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.

    • Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.

    • Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.

    As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.

    And yes, the only thing you need is some time.

  • Evidence Based Scheduling – One More Way to Improve Your Estimates

    Somehow my recent discussions are mostly about estimating. Last discussion on PM Clinic happens to be on the very same subject. It reminded me about great technique which can improve your software estimates. It is called Evidence Based Scheduling and I’ve learned this from Joel Spolsky’s article.

    The basic concept is pretty simple. Jack the Developer gets the task. Actually a bunch of them. He delivers his estimates basing on his guts. Estimates are most likely crappy but at the moment it doesn’t matter much. As Jack does his work he tracks how much time he really spends on the task. It may happen it takes two days instead of planned 4-hour effort. Velocity for this task is 0,25 and it goes to the history of Jack. When Jack’s history is long enough you can use it to judge how crappy his estimates are.

    Evidence Based Scheduling uses Monte Carlo simulation which takes some effort to calculate results. However Joel brings some good news here:

    “Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected. (…) This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}”

    After completing a dozen of tasks you can get pretty much insight which number you should use to multiply Jack’s estimates to get something close to reality. Of course full-blown simulation will probably lead to better results but you get the idea.

    There’s one more gem in Joel’s posting which is worth stressing:

    “Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.”

    I know it brings quite a lot of effort for Jack the Developer, since sometimes he fixes bugs really fast and accounting time spent on each bug fix to proper original task adds enough hassle to be reluctant to do so. However the ends are worth means this time.

    I strongly recommend you reading whole article as it delivers all the details about Evidence Based Scheduling.

  • Role of Leaders in Startups

    Who should be a leader of a startup? An easy question. One of founders. Or even better each of them. They are naturally predestined to leading role. They got the idea. They own the company. They keep all things running.

    Now the more important question: what kind of leaders are they?

    Why is it so important you ask? Well, having a great idea, being a CEO of a company and managing it on a daily basis tells you nothing about leadership. You can end up working either for a great leader or for a sick asshole. No matter which one is true as far as the startup has money leaders won’t change anytime soon.

    Because of a small size of the startup role of leaders is defined a bit differently. Not only they motivate their teams and set up a strategy of the company but they’re also personally responsible for building company culture and enabling company growth.

    In a big organization one asshole doesn’t make much difference – you either work for dozens of them or he’s going to be the only low-performer among great leaders. In a big organizations company culture is already set and it takes a lot of effort and a lot of people to change it (for better or worse). In a big organization one person won’t hamper growth even if that’s CEO who believes leadership is all about yelling at people.

    In a startup one person makes a difference if he leads the company. If he’s a sick weirdo don’t expect healthy atmosphere all over the place. If he makes working for him a hell you won’t see many long-runners in the team as everyone comes and goes as soon as they realize things just won’t change with that kind of boss. In small organizations poor leaders are the main reason why companies suck.

    If you worked for a person who is physically unable to build anything bigger than a couple dozens of people or creating healthy atmosphere at work you exactly know what I’m talking about. Big corporations can be filled with these types and they’ll manage. Startups don’t have luxury to be lead be them.

    That’s a final post of Entreprenurs Time series. I hope you’ve enjoyed it. Please leave your feedback and let me know whether I should post this kind of series in the future.

     

  • Lessons Learned: Startup Failure Part 2

    Last time I shared mistakes we made while working on Overto – startup which was closed down some time ago. Today another part – things we did right and are worth replaying next time I’ll be engaged in a startup.

    Setting up a company behind

    Setting a company, which is quite an effort in Poland, from the very beginning was really a good idea. All founders knew each other well so lack of trust wasn’t the main reason standing behind the decision. We just wanted to give ourselves a bit of motivation making it a real business. However thing we didn’t really plan was that we gained much credibility showing company’s details instead of letting people think the whole thing was created by some student during holidays and won’t be supported in any way in future. Seeing a company behind a service doesn’t guarantee you it won’t die but at least you can be sure someone cares.

    Long discussions before start

    Before launching the project we had very long discussions about what we plan to do and how we want to do it. Of course not every detail was checked but when I compare Overto to other startupish projects I was working on it was really well-thought at the beginning.

    Wide range of roles covered with our experience

    We had really good pack to run an internet service. Development, administration, user support – in all those areas we had experience from the past. There weren’t many things which could have surprise us. We weren’t forced to look for a specialist in any technical aspect of building our application.

    Working in the same place

    For some time we worked in the same building which helped much in decision-making process. We could all meet ad-hoc whenever something important had to be decided. After some time we spread among different places and suddenly we saw how much value was in working in the same office.

    Despite we invested some money to fund the project I don’t treat it as a loss. For experience I gained it was a low price. Another time when I’ll decide to jump to that kind of project chances of success will be bigger.

    First part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Lessons Learned: Startup Failure Part 1

    Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

    No one working full time

    From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

    Catching the market

    That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

    Lack of marketing skills

    Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

    Business model

    We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

    Screwed chance of selling the business

    After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

    Waiting too long with final decisions

    I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

    Second part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • Money as a Motivator

    OK, the subject will be controversial. Money as a motivator. If you ask people what motivates them to work, they’d throw a bunch of different things much more often than they’d say about remuneration. Self-development options are evergreen here, but good atmosphere, top technologies, interesting products or well-organized processes are all mentioned more often than pure cash. By the way that’s one of my interview questions and, believe me, I hear “money” much, much less than I’d expect. Rob Walling presents quite a long list of different qualities which are valued more than money by developers. That’s first perspective.

    Another one is pointing money actually does no good in the area of motivating people. David Carr in his post about money as a motivator shows a list of examples where money doesn’t really affect positively people’s work or even harm their attitude and, as a result, effectiveness. That’s other perspective.

    Personally I strongly believe in non-monetary motivating techniques. “CEO’s handshake” followed by several words of praise can have much more impact than a payload of money. That’s another perspective.

    Having said all of that, ask people if they’re willing to change the job for a better one in almost every aspect they can imagine. Better atmosphere, cooler technology, more interesting products and wide range of possibilities to self-develop. The only worse thing would be money. Few would follow. And if you leave aside those who are starting their own businesses you end up almost empty-handed.

    Now, do another test – situation is the same but in the second job money is better, but e.g. atmosphere is worse. More candidates? What a surprise. Oh, is that really such a big surprise?

    OK, where’s my point then? There are a few of them actually:

    • Money alone doesn’t work very well when you want to add motivation over the standard effort.

    • Money is very often used wrong. If it is so the result are usually opposite than intended.

    • When used well, which is rather rare by the way, money can work as a motivator.

    • Non-monetary motivation techniques are essential but they don’t substitute remuneration – they supplement money.

    • Money is more important for people than they’d be willing to admit.