Management

My workshop: ‘Motivation in IT’

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A few days ago, together with Anita Przybył, I had a pleasure to run an open workshop titled Motivation in IT – How to create inspiring environments in which developers love to work.

The goal was to help the attendees understand the latest science of human motivation and learn how to use that knowledge in helping their teams become better.

Photo from the workshop: Motivation in IT

The overall reception was very positive, and we also learnt quite a bit about various cases encountered by the participants and the challenges they face. This will help us evolve the workshop and make it even more helpful.

Mateusz, one of the participants, has also written his own review of the workshop on his blog.

If you are interested in organizing this workshop in your company or as part of a meetup group, please contact me. You can also find the overview of the workshop program at Bottega website.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Development Process, Management, Technical Leadership

My talk about DevOps culture at the 4Developers conference

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A couple of weeks ago I had a pleasure to present a session at the 4Developers conference in Warsaw. The talk was about the DevOps culture and its growing impact on our industry. The full title in English was: ‘DevOps: (r)evolution in the development of people, teams, architectures and products that you can’t miss.’

Photo from my DevOps talk at the 4Developers conference

I was presenting it together with the distinguished Grzegorz Kozub (a.k.a. the Best-Dressed Speaker), a technical lead in one of my teams, working in the middle of the DevOps and cloud transformation of our products.

Here you can watch the video of the talk (we are speaking in Polish, but the slides are in English). Enjoy!

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management

Making the Most of OKRs: Top 8 Non-Obvious Tips

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Are you using the OKR (Objectives and Key Results) framework in your organization to drive goals? Check if you’re leveraging their full potential!

Here are the top learnings that I acquired after several quarters of working with this model.

objectives photo

1. Do not decompose OKRs too deeply.

OKRs are not meant to be task lists or replace backlogs. Their purpose is to set a common direction for a wide group of people.

If you have dozens or hundreds of small, team-level OKRs in the organization, that purpose will get likely get lost. According to some OKR mentors, companies under 100 people shouldn’t decompose their objectives at all – just do them at the company level.

2. Make OKRs ambitious.

If you defined them right, you will likely not achieve many of the objectives – and that’s OK! This is a different model than SMART, for instance, where you are supposed to ensure that goals are realistic.

Here the confidence level around 50% seems to be the sweet spot. Much higher than that usually means sandbagging, and the organization ends up being driven by fear rather than by opportunity.

You will be afraid of feeling like a failure, or of your people getting burnt out by frequently missing the objectives. But get past that! It’s worth it, as only a very high bar will drive people to accomplish big leaps.

3. Don’t measure performance through OKR achievement.

This will automatically cause OKRs to not be ambitious. There will arise a pressure to make them easily, safely achieved.

Don’t compare teams based on that, don’t make bonuses dependent on achieving them, and don’t use them for individual performance reviews.

punish photo

4. OKRs should be cross-functional.

If you have separate marketing OKRs, engineering OKRs, sales OKRs – you’re doing it wrong.

OKRs are about getting people together to achieve a common goal. If you split them between functions, you will end up with a siloed organization – which is likely exactly what you wanted to avoid when you started with OKRs.

5. Make OKRs measurable.

You need to be able to determine whether an OKR was achieved, and how much of it was achieved. Defining good Key Results in quantitative means is the key for that. They shouldn’t be binary, that often indicates tasks (‘do X’).

And you should be able to grade them, e.g. on a sliding scale of 0-1 (0.6-0.7 being a reasonable target). Ideally, even if you achieve 60-70% of the original (ambitious, remember?) goal, that will still be valuable.

A well-defined Key Result can be a great feedback tool throghout a quarter, when people need to see if their ideas are making the right impacts (moving the needle), or if they need to explore alternative ideas.

progress bar photo

6. Measure outcomes, not outputs.

It doesn’t matter how many features are delivered in your product if they don’t make the expected impacts. A good OKR is oriented around the actual outcome (increase of usage, sales, satisfaction, conversion, etc.).

Instead of saying ‘deliver feature X’, seek a key result that measures the impact of that feature, e.g. ‘20% more users decide to try out the premium subscription’.

Sometimes you will need leading indicators as well, when the influence over the ultimate outcome isn’t direct, and that’s OK – but you can still express them through outcomes (like: ‘Double the number of subscription page views’) instead of outputs (‘create a fancy feature X that will attract users’).

7. Do not set OKRs top-down only.

A dictatorial approach causes disengagement, cancelling out the inspiring effect of an ambitious objective.

Companies experienced in OKRs claim that a combination of top-down direction and bottom-up feedback works best, with the sweet spot being around 60% in terms of objectives coming from the teams.

Another reason is that it helps with relying on data instead of stakeholder or customer opinions. Remember, majority of their opinions are wrong! Bottom-up involvement helps shape them in a less biased way.

8. Don’t give up and keep improving every quarter.

The first quarter after introducing OKRs will likely be horrible. People will think that it’s just another disguise for KPIs, and you will end up with many output-based, non-measurable goals, that are really just unvalidated feature ideas from stakeholders and higher management.

The second quarter will be a bit better. Patterns and antipatterns will start to emerge, learnings will appear in people’s heads. There will still be many mistakes, but more and more people will start to see the value and real purpose of this tool.

That has been my experience as well. While I initially felt that the concept makes sense, it took me a few months to really understand how to apply it and get value from it.

And once I did, I went all in. I even started to apply this approach in my personal life, and it has made a huge difference for me already. But that’s a story for another post.


What are your experiences and thoughts about the Objectives and Key Results framework? Are you interested in learning more? Leave a comment below.

 

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

Top 10 Beginner Mistakes of Technical Leaders

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

It’s usually better to learn from others’ mistakes when possible. Today I list the top mistakes that I either made myself, or saw others make when leading teams for the first time.

accident photo

1. Assuming you need to be the smartest. As a leader, you are expected to give advice and coach your team members. However, this does not mean you should know all the answers, have the highest technical skills or be the most experienced in every area.

You can and should give direction, but you don’t need to understand all the details of every technology your team is using. Your job is mainly to let your people be the experts in their respective areas, helping them grow and utilize those skills most effectively.

2. Setting incorrect priorities. In most cases, you will be trying to keep too many technical duties when performing this role for the first time. It’s important that you quickly switch your focus from your own programming tasks to ensuring your team members are satisfied, and are able to work and grow without obstacles.

3. Trying to enforce or fake authority. Some new leaders assume they have to present tough behavior or give some strict orders, just so the team can see who’s the boss now. Others think they should appear as being always right.

Neither of these will help in building authority. As a beginner, you need to remain humble, honest and respectful. Over time, after doing a ‘good job’ in the new role consistently, the results shall come.

4. Worrying too much – or not enough. In the first few weeks it’s probable that you will be especially concerned with any project risks that you see. After all, nobody wants to start with a failure. You may also be thinking other people don’t trust you as a beginner, or that some are even plotting against you.

However, this approach may lead you to trying to control things too closely, getting too stressed out with small mistakes of your team members, and letting the emotions takeover.

On the other hand, you obviously don’t want to appear like you don’t care about the results, as it will be demotivating for the team and you may build a bad image for your customers. As usual, finding the right balance is crucial to have a good start in the role.

5. Making decisions with full information only. As a developer, you were probably used to doing thorough investigation of solutions before choosing to go with one. As a leader, you will have to make many quick decisions (not just technical ones) to avoid holding off important work.

Don’t try to do extensive research for everything. Review what you know now, and take the risk. You can’t avoid mistakes in this job anyway.

6. Not delegating enough. Desire to control every aspect of your team’s work will quickly turn you into a micromanager that all developers want to avoid. Don’t assume you have to make all the technical decisions now that you’re a team lead.

For many it’s also natural to be afraid of appearing ‘lazy’ when asking others to perform tasks you used to do until now. Don’t fall into the trap of thinking this way. In fact, if you try to keep all the duties you had before, it’s likely that your leadership duties won’t receive enough attention.

7. Ignoring education. Leadership skills are just like technical skills in that they need to be learned. You use different methods for that of course, but it’s still something you have to invest time and effort to do well.

For some people it will come naturally, others will require a significant investment and a lot of practice to introduce new behaviors, but everyone should be actively growing such skills. If you like to read blogs, add a few ‘soft’ ones to your subscriptions list. Put some books on the topic into your reading queue. Look for leadership conferences or user groups if you’re more of an ‘offline’ person.

8. Getting discouraged after initial failures. You will run into problems, that’s for sure. Maybe you were the ultimate problem solver as a developer, but in this role not all of them can be solved just with time, focus and technical knowledge. In many cases the results of your decisions – and the learning from them – will come much later.

It tends to discourage a lot of beginning leaders and they decide to fall back into technical positions, feeling much more in control there. That may be premature and often a better approach would be to retrospect on the failure, bite the bullet and try again.

9. Defending your position. So far you may have felt you had a secure job. You were a solid developer with many alternative opportunities in case something didn’t work out.

Leadership positions are obviously less secure and it might leave some people with a strong feeling of discomfort. If you embrace such negative thoughts, it may result in making wrong decisions just to defend your position, while under pressure from your customers or managers.

10. Not caring about your customer enough. Having said the above, putting the right level of effort into building relationship with your customers is still crucial. After all, the business value that your team is producing is the main reason for its existence.

The key here is finding the right balance between protecting your team from interruptions and pressure, and remaining open to changing customer needs.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Recruitment

10 Reasons Why You Won’t Get That Developer Job

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

You answered all the technical questions perfectly. You have solid experience with some shiny projects and companies in your resume. Your financial expectations are reasonable. Still, someone else will get the job. Why???

alone photo

I participated in tens of recruitment processes as a developer. Then I hosted even more when hiring to my teams. Based on that experience, I am listing the 10 not-so-obvious reasons for hiring managers to reject your application.

If you’re a developer, they may help you understand the reasons behind rejection. If you’re a manager, you may consider some of the below when recruiting for your team (and avoid the others…).

1. You are not likable. We spend a lot of time at work, so interactions with our co-workers may have a significant impact on our general happiness. Managers know that, and many prefer to hire a solid, but not great developer that has a friendly, positive attitude, rather than a top performing jerk.

2. You are too smart. A good manager will not hire an overqualified candidate, to avoid their disengagement with too simple tasks. A bad manager will not hire them from the fear of being ‘overthrown’.

In both cases, you should be thankful for it and look for another place.

3. You are too confident. If you’re acting arrogant during an interview – when people usually try to control their behaviors – what will happen once you’re faced with serious problems during actual work?

4. You are not the best match. Building a team doesn’t just mean ‘let’s hire the top X candidates that apply’. It’s a complicated process that requires some strategy, balancing the skillsets, experience, career aspirations etc.

The company might decide that the most skilled candidate isn’t necessarily the best one for the current gap – they might need someone more junior, or focused on different types of projects, with different ambitions and goals. What you can do is try to fully understand the need, and – if you still think you’re a good match – justify it clearly for the hiring manager.

5. You complained about your previous employer. This is a red light for many interviewers (whether that’s smart or not is a different discussion). They immediately start thinking of you as a complainer, or someone not trustworthy, who will spread gossips and negativity.

6. You didn’t show respect. Everyone needs to feel respected. A manager won’t hire someone who is not acting properly towards them or other employees. Even if you say something inappropriate by pure mistake, it’s likely they will notice and remember it.

7. You lack a good ‘why’. If you are unable to clearly explain the motive for seeking a new job, it will usually be assumed you’re going after money. And unless they are the highest paying company, they will be afraid you’ll do it again soon, or that you won’t be fully engaged in your duties.

8. Your resume doesn’t tell a story. This one is especially difficult to understand for many job seekers. Most managers aren’t stupid (no, really!) and they often realize that candidates may have a carefully-crafted answer to the previous question, so they look at their employment history in more detail.

Do your past job transitions make sense? Do they fit the bigger picture of declared career goals? Do they tell a consistent story of a growing developer? Be sure to analyze your resume from this perspective.

9. You weren’t honest. That’s an obvious one. If they spot you lying, or notice some signs of hiding information, that’s a red light. A good manager will prefer to know the ugly truth. If you made some bad decisions in the past, but are able to speak openly about them and explain what you’ve learnt, that may even be an advantage.

10. You are changing jobs too often. Some managers treat this very seriously, others – not so much. Some companies won’t even invite a job hopper to an interview. Project situation might affect this as well – if they are seeking someone to help with an urgent, critical initiative, they might not be too worried of the risk of losing you soon after.

However, if you are a job hopper, this will be one of the most common reasons to get rejected, regardless of your skills and personality.

 

Would you add anything to the above list? Feel free to leave your thoughts in the comments.

 

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Development Process, Technical Leadership

FAQ for Your Project Manager

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I decided to summarize some of the most frequently asked questions that I’ve been receiving throughout my career as a development team leader or manager. They usually come from project managers and product owners, sometimes also from stakeholders or customers.

I believe many of us often need to respond to the below, so putting these all together might save us some time. Feel free to copy & paste the answers as needed!

questions photo

1. Why is such a small change taking so long?

  • What might seem as a small tweak, can sometimes require re-designing a part of a system, if we didn’t originally predict that this particular aspect might need to change. And no, it’s not possible to predict all possible changes. Even if it was, you wouldn’t be happy with the cost…
  • Aside from making the code change, we have to test it, ensure it doesn’t affect anything else in the system, deploy it and verify in various environments (development, test, staging, production). No, we can’t take shortcuts if you don’t want to risk a major production failure.
  • Even when making tiny changes, magic can happen and we are never able to predict the impacts with full confidence. That’s just the nature of software development.

2. Why is it so expensive?

  • As developers, we have to take many aspects into account: code quality, security, performance, scalability, maintainability, usability and more. All of these require attention from the team. We have to plan for those concerns, verify them, write automated tests, etc.
  • Yes, we are putting business value as our top priority. We’re just not thinking about today’s business only. What will be the business value of the software if it stops working after the database exceeds 100K records? Or when hackers bring the website down? Would you accept a huge cost of future enhancements if we take design shortcuts today?

disaster photo

3. Are you sure it’s bug-free?

  • No, and we can never be sure. Even worse – every larger piece of software has bugs. That’s just one more thing to accept in this industry.
  • There are many factors that can cause issues, code is just one of them. Some of the other ones are: network infrastructure, server and client hardware and software, system integration mechanisms, web browsers, etc.
  • We are using tens or hundreds of third-party components. Each of them may contain bugs. No, we cannot get rid of them if you want the release to happen this decade.
  • Even when all the other components are fine, there’s a risk that we missed some edge case that nobody ever thought of – not even the analysts or the users.

4. Why can’t you just add more resources to finish earlier?

  • First, developers are not resources. They are not interchangeable, and you cannot easily add or remove them with proportional impact on the results.
  • Recruiting developers can take a long time. If we hire the wrong person, the impact on the project could even be negative.
  • Training developers takes time. The more complicated the system is, the longer it will take before a new person is fluent on the project. And they will make more mistakes that will need to be corrected by other developers.
  • All of these require time investment from the team, which will leave less time for growing the product. That’s why you won’t usually get any short-term benefits. Oh, that next month’s release you wanted to speed up? Better move it till next quarter.

5. Why can’t you tell me when it will be done?

  • We can estimate, at best. We can never predict with full certainty.
  • As explained, even the smallest and simplest change can have unpredicted complications.
  • Every task is a bit different. Even when building similar features for the same application, the related code areas might have been designed differently. Until we start working on them, we won’t fully know what lies beneath.
  • Even if tasks were identical, people working on them can vary in skills and experience. The differences in development time between team members can sometimes be an order of magnitude.

building photo

6. Why are you less productive than that other team?

  • How do you know that? How can you measure that? How do you define ‘productivity’ at all?
  • Every team is different – different people, skills, experiences, distractions, additional duties, etc.
  • Each team may be following a bit different set of practices, which have an impact on development time, as well as quality of the final product. For instance, some teams write unit tests, which increases development time, but also improves the system’s long-term maintainability (when applied properly).
  • Every system is different. One could be based on more problematic technology stack, have poor design, less readable code, etc. Or, quite contrary – it might actually be designed in a better way, having better security or scalability, at the price of more expensive future enhancements.

Are you getting similar questions frequently? Or maybe you have other typical examples? Please share your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

Are You a Conscious Technical Leader?

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

How many times did you hear a story about a good software developer, whose performance went down after getting promoted into a technical leader role? Unable to focus on either of the duties, frustrating himself and the team, he ended up backing out of the position. Or, alternatively, he kept running the team, but was generating frequent issues with project delivery or employee attrition.

Sounds familiar? It seems to occur much too often in the IT world. Companies often end up losing a good developer for a weak manager. That’s why I believe we need more Conscious Technical Leaders.

pilot photo

A Conscious Technical Leader is someone who was able to make the mind shift after transitioning from a developer’s role. Someone who understands the difference in priorities and expectations, and was able to change their behavior to fit the new situation.

In my opinion, every development team needs a Conscious Technical Leader in order to be fully empowered, to operate in the most effective way, keeping both customers and employees satisfied. Even when it’s not a formal position, like in self-organizing agile teams – most of them could still benefit by having someone with these traits on board.

But what does it really mean in practice? In my opinion, you can call yourself a Conscious Technical Leader when:

  1. You understand that you’re not just a senior developer anymore.
  2. You put the needs of your employees as high as your own.
  3. You understand that leading is not the same as giving orders.
  4. You are focused on increasing your leadership skills and growing in that direction.
  5. You see employee satisfaction and engagement as a high priority, even during difficult times.
  6. You prefer to leave the most interesting technical tasks to your people rather than coding them yourself.
  7. You seek mentors among more experienced people in this role.
  8. You are able to identify the most important soft skills that you need to improve.
  9. You allow your team members to participate in decision making.
  10. You limit the time you spend on technical tasks to make enough space for leader’s duties – and not the other way around.
  11. You actively seek opportunities to help your employees, rather than having them apply and wait.
  12. You know you don’t have all the answers, and you understand you don’t need to have.

Would you add anything to the above list? Please leave your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management, Technical Leadership

Help! There Are Introverts in My Team

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

In my last post I described some theory behind introversion, and mentioned that probably most software developers demonstrate such type of personality. Today let’s discuss some practical implications it may have for your team and things to consider as a leader.

office photo

Brainstorming should be abandoned. You won’t get the best ideas, you’ll just hear the ones your extroverts can come up with off the cuff. Introverts need time to think through a problem, and they won’t usually say anything just to appear ‘creative’. Use different discussion patterns instead, and if you really care about valuable input, give your people some time to prepare.

Open spaces are counter-productive. They result in your most talented introverts being frequently distracted by the most ‘active’ employees. And you thought you can just put people together into a large room so that they ‘communicate’ and be more creative? Think again.

Some agile techniques require a second thought. Pair programming? Maybe two developers working closely together, communicating all day long, is still fine from an introvert’s perspective – when they know each other well… That’s yet to be researched though. Maybe that’s why some people consider such techniques to do more harm than good.

Review your recognition approach. Many of your team members might not actually enjoy the ‘unique opportunity’ to present their idea in front of the whole company… Some might even see it as punishment. You may still need them to do this, but don’t pretend it’s a reward in such case.

Collaboration is not always the way. We might have been too aggressive in promoting the collaborative style of work, thinking it’s a solution to all problems. Allow your people to work in a bit of isolation sometimes, give them more privacy, and see if the results won’t actually be better.

Limit the number of meetings. Well, nothing new here… Just one more reason to do it (does anyone even need it?!).

These are just some basic observations. I’m sure once you start to look at your team’s everyday work from this perspective, you will notice many more situations in which the environment doesn’t help your introvert team members. Feel free to share them in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management

The Quiet Revolution?

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

The topic of introversion is particularly important in the IT industry, which seems to attract many people with such mindset. In this article I am reviewing ‘the book that started the Quiet Revolution’ (or at least that’s how it’s been advertised). Is it really that powerful? Read on to find out.

The Extrovert Ideal Considered Harmful

Susan Cain starts her book – ‘Quiet: The Power of Introverts in a World That Can’t Stop Talking’ – with a brave attack on the icons of modern self-help techniques and business approaches, like Anthony Robbins, Dale Carnegie and the Harvard Business School. While the personality model promoted by them has dominated the Western world, she argues that it’s actually harmful for a large part of our society. The ideal of a dynamic, open, outgoing individual, attracting others’ attention, with great presentation skills, showing a lot of ‘energy’ and raising many ideas, is not natural for at least one third of the world’s population.

Those people, who we call ‘introverts’ for the lack of a better term, seem to prefer thinking before acting, calm behavior, limited amount of social interactions, careful decision making and working individually rather than in groups. On the other hand, they lead a very rich ‘internal’ life and usually have great imagination. Because of all these traits, introverts are often seen as shy, unpleasant, sad, or even cynical and unhappy. In most cases, this is far from true, yet extroverts find it very difficult to understand.

sad photo

Why are you so sad today?

– is one of typical, frustrating questions that introverts would repeatedly hear from family or co-workers. Many of them give in and try to comply with the established standards of behavior. They would fake enjoying interactions with people, appearing open and expressive – just to be more ‘successful’.

Susan claims that such forced behavior is not necessary, and many famous people achieved something spectacular not just despite their introverted nature – but even thanks to it. Warren Buffett, Bill Gates, Gandhi, Charles Darwin, Isaac Newton – she gives many examples of very successful people who demonstrated behaviors typical for introverts on a daily basis.

Introverts Are Not ‘Cool’

The author tries to understand the reasons behind such behaviors. One lead is that many introverts are also oversensitive (in psychological sense). It means they would feel stronger emotions in reaction to a beautiful piece of music or a poem, but also to explicit violence and ugliness, than an average extrovert. They also tend to be meticulous and conscientious. That’s why they feel more nervous in situations like meeting new people or presenting in front of a large audience.

You’ve got to come over to the party tonight – you will relax, I promise.

After digging deeper and reviewing some more research, it turned out that babies with highly reactive behaviors (e.g. squealing with delight when seeing colorful toys) tend to grow into rather careful and serious teenagers, which seems counter-intuitive. Further investigation suggested that such behavior is tied to having an exceptionally sensitive amygdala. The more reactive it is, the faster the baby’s heartbeat will be when experiencing new stimulus, the more cortisol will appear in its saliva, and so on. For a grown-up, who tries to control reactions, such response from the nervous system will mean more stress, and thus an incentive to avoid confronting the unknown.

Another interesting observation is that extroverts sweat less than introverts and therefore seem ‘cooler to touch’. Some people think that it may be the origin of the saying ‘be cool’. If you think that’s a positive thing, consider that the ‘coolest’ people in this context are sociopaths, who are the least reactive and thus don’t care or feel guilty about their deeds…

Why do you always have to be so anti-social? No excuses this time!

In general, the balance of introversion and extroversion for each of us seems to result from the ‘fight’ happening between our ‘old brain’ (the part coming from our evolutionary ancestors, primitive mammals – eat more, take pleasure, seek reward, take more risks) and the neocortex (think, plan, decide, be careful). Highly reactive people are more susceptible to the guidance of the latter, while extroverts’ behaviors are more frequently driven by the former.

Who needs introverts after all?

Susan claims that the world would be a much better place if we stopped pushing those people into the ‘standard’ model of behavior (the Extrovert Ideal). She suggests that some past accidents and tragedies might have been avoided if we had more introverts as decision makers, for example the global financial crisis of 2008. Wall Street was dominated by people with specific personality, who pushed away more careful people pointing to disturbing statistics.

Society doesn’t seem to trust introverts. They are too quiet, they avoid interactions, maybe hiding something bad or deeply hating humanity… That’s why it’s more probable for an extrovert to have a successful career, get promoted or sell a product.

However, this approach is gradually changing. Not only because of this knowledge being spread, but also due to more and more great companies and products being created by introverted minds, making them famous, rich and powerful. The software industry is full of such stories and this trend shall continue in the coming decades. The growing virtual world is the perfect space for introverts to show their abilities without negative stimulus for their brains.

Summary

I hope this article got you interested in this wide and important topic. I can certainly recommend Susan Cain’s book, as it contains much more detailed information and can prove very helpful not just at work, but in your whole life – regardless of where you are on the introvert-extrovert scale.

In the next post, I’m going to write about some practical implications of this concept for us as IT leaders, and what we can do to allow our introverted employees to reveal their full potential.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

8 Very Specific Things about Software Developers

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Software developers are a specific group. While every person is unique, some behaviors and qualities of many developers, or aspects of their work, are clearly different than the average employee’s. In this article, I am going to list what I believe is so specific about programmers, and how it may impact your job as their leader.

If you’re working in a different industry, the below list may help you understand some challenges that managers in IT (or software development, at least) face. And, quite possibly, see things from a bit different perspective the next time you want to blame the IT department for not solving problems in the way you would expect (like ‘why can’t you just add more developers to this project?’).

science photo

1. Developers are very smart

First of all, you’re going to be working with people whose IQ is usually much higher than the population average. It’s an honor and a truly exciting opportunity, if you think about it. It also means an extra effort for you in order to make sure that their work remains challenging and that you keep their engagement high.

Developers will also be more resistant to various pseudo-leadership techniques, and will easily see through even slight manipulation attempts. Forget about sugar-coating, feedback sandwiches etc. Be open and honest if you want their trust.

2. Hiring developers is difficult

Even if you haven’t had a chance to hire anyone yet, you’re probably aware that this job market is very challenging. Finding someone with really good skills can take a long time. You’ll be competing with many other companies to attract the best people, and it won’t be enough to just pay them higher than others. Organization’s culture, working environment, tools and processes in use, types of projects, skills of the current team members – it can all count for your candidates.

Opinions about employers spread quickly throughout developers’ communities, so you may need to work on your brand for a long time. Moreover, it’s not easy to properly assess a candidate’s potential, and hiring the wrong person could mean wasting another few months.

3. Developers are narrowly specialized

You can’t simply replace one developer with another. Not only are they usually focused on a specific technology stack (like Java or .NET), they also typically have preferred lower-level technologies, tools or system layers that they focus on (like front-end or database). Changing that can take a lot of time (we’re usually talking years to become an expert), and it may be a similar case with knowledge about a particular system or project.

This makes replacing people who leave the team more difficult, as well as affects flexibility when planning projects. You can’t just move developers from one team or project to another when the business changes priorities – you need to make sure they will fit in with their skills, and give them time to learn the insides of the other application. And for a complex system, losing a developer may mean an irreversible loss of knowledge for the company. This is a much higher risk than for most professions.

4. Developers can differ in abilities vastly

Another reason why you can’t easily replace a team member is the difference in their skill level. Being a great developer does not only mean delivering software a bit faster or with higher quality than an average one. Such person may actually be able to accomplish things that others won’t, e.g. due to the problem’s complexity or deep understanding of some technology that required years to master. For some types of software, you may not even be able to move on without hiring some top talent in the field.

5. Developers hate being managed

This point can obviously be related to other professions to some extent, but it’s the software development world where Agile concepts have gained the widest adoption so far. Because of that, many developers are used to working in self-organizing teams and are especially sensitive to attempts of interfering with the details of their work by management. If you don’t have a fresh technical background, better stay out of the way and trust your developers to make good decisions. Even if you do, avoid forcing the team to use your own ideas for technical solutions. Help your people grow, coach them and facilitate discussions, but allow them to find the path to building high quality software on their own.

boss photo

6. Developers’ work is a creative process

There have been many attempts to fit software development into manufacturing patterns, treating employees like factory workers that have a detailed plan and execute it in a predictable and strictly controlled way. So far no such process has been applied successfully on a larger scale, simply because writing code is a creative activity that cannot be defined, estimated and planned so easily.

Building software means solving a different type of problem every day, even for very typical, ‘boring’ business applications. There’s always some unexpected obstacles or issues to investigate, new technology aspects to understand, high- and low-level technical design considerations, not to mention writing complex algorithms or designing UI details. Each of these activities may depend on having the right idea ‘click’ in a developer’s head, and thus each of them may ruin a carefully crafted plan.

That’s why programming is difficult to plan in detail and estimates are frequently missed. There are also other implications, e.g. developers need to work in peace and quiet most of the time, to focus and eliminate distractions. However, they also need the freedom to discuss ideas in a group, consult solutions or get help from others. Think about it when planning the office space or coaching the team in communication practices.

7. Most developers are introverts

It’s usually estimated that between 1/4th and 1/3rd of the population consists of people with an introvert mindset, who are motivated by their internal thought process rather than interactions with other people (I’m simplifying greatly). Among software developers these proportions seem to be opposite. This has a whole lot of consequences from the perspective of a manager, starting from your daily communication with such individuals and their preferred work environment, to the way you deliver feedback for them and recognize their achievements. I am going to write more about this topic in future articles.

8. Developers don’t dream about a management career

Most people treat their job as just something they do from 9 to 5 to earn money. Then they go back home and spend the evening with their families, or engage in their hobbies, counting days down till the weekend.

But developers… They just love writing code and creating software. Well, not all of them, but many. It’s not frequent for an activity performed at work to be so interesting that you would eagerly do something similar in your free time – and developers are just that lucky. Because of this, many don’t even consider other roles and are good to work as developers for the whole career.

This means a bit different challenge from an engagement perspective. You won’t motivate a developer by saying ‘today you’re working on crappy stuff, but hey, one day you may become a manager of this mess…’ No, you need to seriously take care of ensuring that the work your people do is meaningful and interesting.

Summary

For the reasons described above, some of the generic leadership advice that we can learn from various sources will not apply to our industry, or at least it won’t be so straightforward. You might need to focus on different aspects than other managers, assume different priorities, and face problems that would rarely happen outside of IT or software development.

Do you have any observations of your own about this topic, or anything to add to this list? Please share your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard