вторник, 11 апреля 2017 г.

Takeaways: Ideal Executive by Ichak Kalderon Adizes

This entry also appears in my other blog.

I have already recommended the Management and Mismanagement Styles book by Ichak Kalderon Adizes earlier and now there is another title by Adizes that should draw your attention The book is called The Ideal Executive. Why you cannot be one and to do about it, which actually precedes the Management Styles. The two share some portion of content, but focus on slightly different aspects of management and are both definitely worth reading. To get you the idea and make myself a short summary I will list the key things, which I noted in the Ideal Executive.

First of all, both books use the same framework to reason about managers and their work - PAEI. The acronym stands for four distinct functions that a manager should perform: Production, Administration, Entrepreneurship and Integration. They are explained in great detail in the books, but the key idea about these is that all four are crucial to proper management. At the same time because they sometimes come in conflict with each other, no single person can execute all of them alone, which is why there is no such thing as an ideal executive. The only reasonable way to address this issue is to assemble a team of managers, each of whom masters in some of these functions, and let it drive the organization forward. The books focus on this idea and revolve around its various implications.

Adizes goes deeply into analyzing various aspects of the management job and of the idea of a management team, mapping them to the PAEI framework. I will just list various disconnected bits that attracted my attention in the book:

• The solution to the "no ideal manager problem" is a management mix of several people with different approaches: P will focus on what we have and how to get the best out of it, E will introduce desires and drive progress, A will make sure that everyone is doing what they should, I will connect and encourage everyone;
• Even though current objectives of the members may differ significantly, the team must have common long-term interests. Management means not only making decisions, but also implementing them. The latter doesn't happen if long term interests of the team-members are in conflict;
• Four factors that enable trust and respect in an organization are: people, process that includes communication, structure that allows people to match their interests to interests of the entire organization and ensures that reward meets responsibility, common vision and values ensured by leaders
• Structure must reasonably define the responsibilities, the extent of freedom for decision making and rewards allocation for P, A, E, I styles, because in each case these things should be different;
• Managers of different styles need different approaches because to large extent they speak different languages. Even "yes" and "no" may mean different things to them;
• When arriving into high-P's office don't start explanation from the early days of humanity - start at the end and with the conclusions, then move to additional info. High-P's hate extra details - they want to get things done as quickly as possible;
• When you are about to introduce your cool new idea to a high-E make an obvious mistake right in the beginning of your explanation of the problem - fixing it would allow high-E to feel his contribution to the solution. Otherwise he may get unhappy about you making a decision without his input;
• Conflict is an important part of the work and management process. It should not be avoided, but should be kept constructive through proper management;
• When discussing a decision and there is no consensus break all the apparent issues into three categories: questions, doubts and objections. Collaborate to answer questions first, then label doubts as questions and objections as doubts, answer the new questions. On the last stage you will hopefully have only the questions that were initially considered objections and will likely be able to resolve them as well. This looks like a psychological trick making people in the room focus on collaboration and making an idea workable instead of opposing it;
• Leader is a person who does Integration and one other function excellently and is at least good with the other too;
• Leader is like a thumb - its presence unites other fingers into a functional hand;
• Good leader acts as a servant, who creates the circumstances in which others can shine;
• Good leader can be distinguished by the scars on his tongue, because he keeps biting it to keep quiet when there is too much temptation to engage into a loud debate;
• Best managers keep calm when a conflict rises. The hotter the conflict, the calmer the manager;
• A manager must be able to hire, use, develop and reward people who don't look like him;
• Create circumstances in which conflict serves as an education tool and stays constructive;
• Organization is what it does for others. Answering the following questions helps understand it better and formulate its goals and values:
○ Who are the customers and what do they want?
○ Which of their needs do we address?
○ Which of their needs we don't address?
○ What are our abilities - what we can do?
• The goals and values should be periodically reviewed - otherwise you will get stuck in a set of irrelevant rules, which will prevent growth of the company;
• Currently management schools teach correct answers instead of teaching how to ask the right questions;

The book is a pleasure to read, and at the same time it provides a lot of advice in regards to management. This advice comes in a solid yet simple framework that helps reason about what one should be doing at his or her job and how it is different from what he or she is actually doing. The nice thing is that both the advice and the framework are very practical - learning these helped me notice many new things about the behavior of my colleagues and see some underdeveloped areas in my our activities, thus growing one step closer to the non-existent ideal manager.

понедельник, 13 марта 2017 г.

What I Expect from a Developer’s Resumé

This post also appears in my blog on Medium.

On a recent local programmers meetup we discussed the topic of writing a developer's CV in such a way that it allows one to get to an interview past the initial screening. As this is closely related to my posts on interviewing developers, I will cover what we discussed and what are the things, which when seen in a programmer's resume make the team-lead in me eager to meet its owner in person.

For all technical positions the first thing that both the recruiter and the team lead will search in a CV is work experience with relevant technologies and tools. This is the easiest one, because if you have it you just need to make it stand out. To do so make sure that you resume has the keywords that describe the technologies that you would like to work with. While people are quite different from Google search engine, when I look for a new hire I inevitably have to scan dozens of CVs and the easier it is for me to spot the names of the technologies that I need, the higher the chance that I will pay attention to the candidate. Trivial, right? Just remember that you have to be honest about what you have experience with and what you don't - if you're caught lying about these things, you will likely be wiped out from the list of candidates at the same instant.

On the other side, a resume consisting solely of keywords will be even less successful than a resume with no single one. That's because merely "knowing" all the buzzwords doesn't make you a professional, while having lots of achievements in the field of software development does. Here make sure that every job or internship mentioned in the CV lists every one of your accomplishments on that position - ideally, focus on what you have done instead of what you have been doing. Moreover, don't stop on the jobs - remember all the pet projects that you had done alone or with your friends, remember every conference that you talked at and the articles that you have written - all of these underline the experience that you reported and show that you're a person of achievement.

Such activities as pet projects and extra education - an open-source library that you helped to develop or a course that you have taken online - also show that you are willing and capable of learning new skills and technologies. That's especially good if these go beyond your main programming language or framework of choice, because breadth of experience demonstrates your ability to adapt to changing circumstances and employ different mind-models and approaches. Mentioning such activities in a resume also draws a potential employers' attention to one more thing - your fascination with the profession and desire to work and learn beyond your day job, which by itself puts you in front of the crowd.

Another important note is that all of us look for reliable employees, which in particular means that we want them to stay with us as long as possible. Planting a developer into the team and bringing him or her up to speed may take an awful lot of time, so when the process starts I want to be as confident about the result as possible. Essentially this means that a CV consisting of a long list of short jobs - e.g. those under 18 months each - will at least get me concerned. That's not something that you can change about your resume right now, but the thing is certainly worth remembering when you think over your next career move. I don't mean that you should stick to one job for decades, but after you're sort of settled with your career people may expect that you don't change employers too often.

Finally, the resume must allow you to express yourself in a clear and comprehensible manner. In particular this means that you should adhere to the generally adopted standards, such as listing your jobs from the most to the least recent one, displaying a photo of yours and so on. However, there is more to this, because to show that you're a person worth speaking to you must be polite and caring. In written communication that means that you don't brag too much, your language is good, its style is appropriate and there aren't many typos. You will also want to save your interviewers the time needed to find you at Facebook, Twitter, GitHub and elsewhere, showing that you have things to share and don't put crazy stuff up for public display.

It's that simple in regards to the contents of a resume, but I also have a couple suggestions in regards to the process of producing it. First of all, be sure to use external help when preparing the resume. Simply ask a friend, a teacher or even me to review the resume - an extra pair of eyes will spot mistakes and unclear sentences, which will help you look better. Some people prefer to ask a professional to prepare a CV for them. Here I can't advice much as I never used such a service, but it may well be a good move. In my experience, though, having someone proofread the CV is just enough. The last advice is similarly simple, even though less obvious - prepare your resume in advance and always have it ready. You never know when you will have a chance to apply for your dream job and don't want the need to write up a whole new CV to be an obstacle for that. This is not mention the fact that from time to time a friend of yours may run into you shouting something like "We desperately need a good programmer on that project! Could you send me your resume right now?!" More opportunities is better, so be prepared.

As you can see, there is no rocket science about producing a good resume and all of the above advice aligns well with what common sense would suggest. At the same time, if you follow these simple guidelines you will help recruiters and managers spot what they look for in your CV and thus increase your chance to hit an interview.  That's it for this article and I hope that the advice is valuable. If you still have any questions on what to include in your resume, please ask in the comments. If, instead, you have a better idea in regards to what a good resume should look like, be sure to share it here!

четверг, 16 февраля 2017 г.

Search Algortihms in the Real World

In the middle of my university life I had a very strong desire to build a computer game. I was studying for a software engineer and still understood little about most of the software applications. At the same time I loved PC games, which clearly brought me to the idea that I should produce one - the one with the best gameplay, of course. Many of the guys with the same background had that wish and like most of them I didn't succeed.

I spent a fair portion of my free time thinking over the game's design, writing the explanations in a textbook and studying computer graphics. The problem is that in these activities I focused on the things that were easier to comprehend for me. I liked to think through game mechanics - for example the way damage is dealt to the player. I worked this question out on a very detailed level - in many cases descending to the names of C++ classes and of course laying out the calculation rules. With graphics, I focused on trying to make primitives move around the screen using OpenGL, because moving stuff looked like an essential part of game development. This all happened where neither setting, nor even key game features were defined - I hardly settled with the genre. Instead of looking at these high-level concepts of the game, I grasped the details, which I could easily stick into my head, without even understanding what are the key building blocks that I will have to construct a video game from. Speaking in algorithms language, I was doing a depth-first search not wishing too see the entire tree that I will have to traverse eventually.

Recent observations at interviews and during the normal work process brought me to the idea that such a mistake is common among many younger developers. When put in front of an unfamiliar problem they tend to catch some detail that they understand and pursue it to the deep. Because they don't take time to step back and take a look at the problem as a whole, they may end up with weak solutions suffering from various illnesses that happen in the software world. Most likely you will see multiple leaky abstractions and dozens of lines of ad-hoc code in the programs produced this way. And of course don't be too optimistic about finding there clearly separated layers, constituted of the objects that comply with Single-Responsibility Principle.

After acquiring reasonable development experience we tend to replace the depth-first strategy with the breadth-first search. This happens not only because older developers are slower beasts, but more due to the acknowledgement of importance of the full context for the correct solution to the problem. The mistakes committed earlier make us approach both high- and low-level decisions with great respect to the surroundings and see the drawbacks of diving into details before thinking of the solution as a whole.

This obviously makes a lot of sense when we speak of software design and architecture definition, but actually the same breadth-first strategy is applicable to such activities as coding and bugfixing. For example, when analyzing a bug it is tempting to follow the first breadcrumbs seen in the data in an attempt to understand the issue, but this way one may end ep trying every possible hint and spend hours exploring dead-ends. Alternatively, one may take time to fully understand the context of the issue, appreciate its complexity and collect as many facts as possible before even trying to make assumptions regarding the cause of the problem. In this case he will be able to see clearly which guesses are worth a deep investigation and which can be ignored altogether.

There is a similar situation with, for example, writing blog entries. For some people it is natural to produce a good article  simply by letting their thoughts flow onto paper. For others producing a reasonable piece of writing requires planning it and doing a couple drafts first. I don't belong to the first kind and going the depth-first way always results in frustration and wasting lots of my time on a couple short paragraphs. To be honest, sometimes its very hard for me even to produce the first draft from the start to the end - details kill me on the way. Instead, I begin with a rough outline consisting of several key points, then gradually add several sub-points to each of them. Only after this two-tier plan is there, I would start expanding the sub-points to rough sentences, which make a foundation for the draft. This looks very much like traversing the tree of the future blog post with the breadth-first search algorithm, except for the fact that here nodes and leafs are themselves created by the search process.

While I have enough development and writing experience to understand these things, sometimes I still find myself using the details-first approach where breadth-first search is more appropriate. To some extent, this happens because there is always eagerness to produce results and the depth-first path always seems short and clear - until you start going. But at the same time, it may be the case that in absence of the right words to distinguish the two strategies nothing forced me to make a conscious choice - the analogy with the search algorithms came to me only recently. In addition to making the choice clearly visible, it also brings the criteria for picking one of the two approaches. When you need to devise a good solution or just to understand a large and potentially complex problem, breadth-first search will work better - the theory says it guarantees the best result possible. If, however, you need the result early and don't care about its quality too much - for example when building a quick prototype to get an idea of the look and feel of a future product - you'd better use the depth-first search, as it usually yields faster. Sounds obvious, but somehow just having this analogy with the algorithms world in mind seems to make the task of selecting the right approach to any problem easier.

понедельник, 16 января 2017 г.

My 2016 Management Reads

It's the middle of January, so everybody must have already published their version of summary for 2016. I will try to catch this leaving train and list several of the books that I read last year and found particularly useful for everyone whose job involves management. There are actually only two items that are directly related to management, but I still believe that all of these books are particularly useful - sometimes even essential - specifically for those of us, who hold responsibility for guiding others and tackling a wide range of organizational problems. At the same time, all five titles will likely be interesting to any human, no matter what they do for a living.

Dale Carnegie - How to Win Friends and Influence People

This widely known piece of wisdom is among the most precious jewels which I found last year. The stakes are high you read it long ago - I'm unhappy I got to it this late. Even if you did, it may be a good idea to refresh it in your mind. Speaking on the way one should treat people to build lasting and fruitful relationships, the book is crucial to study for anyone, whose job is to lead people, communicate the goals of an organization to them, help them acknowledge their mistakes and grow professionally. The things that I learnt from it helped me provide clearer feedback to the members of my team, understand better what my bosses want from us, explain to the team our objectives and overall build trust-based relationships with the people I work with. To be honest, when I first heard about the book I thought it must be a box of dirty tricks that allow one make others do what they please. In reality it turned out to be a pretty sincere practical study of the principle "treat other people the way you want to be treated" and its implications, touching on many strings of the complex nature of human's ego.

David Allen - Getting Things Done

While it's difficult for a book to compete in value with How to Win Friends and Influence People, David Allen's guide to personal efficiency certainly manages to do so. My regrets about reaching it only in 2016 were even stronger than with Carnegie. The book doesn't touch a lot on the topics of managing people and business, but rather dives deeply into the problems of managing oneself. However, personal efficiency of a manager is a key to the efficiency of his team. The fact that the book not only gives advice on how to get productive, but also inspects many psychological questions around succeeding at one's job makes it a must read for every manager in the world because this way it shows how you can teach your directs to succede. Besides that, the key focus of Getting Things Done is the way one manages information, ensures that progress is made on every active goal and validates the goals themselves. This sounds a lot like the responsibilities of a software development manager, so it will be educating for everyone holding such a position. If you feel almost sold, check this article where I sum up my takeaways from the book.

Nassim Nicholas Taleb - Antifragile

The next book could win the "Most Controversial Reading" award if I made a kind of Oscar for the things I read. The Taleb's style of writing as well as his intense reproaches toward certain broad categories of people and fields of study sometimes bothered me a lot. On top of that, the book is not concerned with management in any particular way. At the same time, the ideas given in Antifragile have a lot to do with change and risks and how we can live with it - the topic that is very relevant for managers. Taleb speaks a lot about the ways one should chose what to invest in and how to secure yourself from unnecessary risks. Most of his ideas are applicable to any area of life, including software management where one frequently faces the need to chose from a wide range of technologies, projects and potential employees. Even if it is difficult to perceive the book as purely practical and career-boosting it is certainly educating and offers fresh points of view.

Cyrill Northcote Parkinson - Parkinson's Law, and Other Studies in Administration

This is another classic that I checked in 2016 and one more must read for everyone involved in any kind of modern organization - no matter what's its size or which role you hold in it. In a grotesque form, looking very much like a collection of unreal anecdotes, the book shows how organizations tend to lose efficiency. It is a great fun to read in the first place, but its anecdotes do show real threats that a company or a team may face. Beside telling how things can get bad it describes quite realistic indicators of the fact that something unpleasant is already happening. Thus, in addition to entertaining you, Parkinson's Law will help you assess the state of your organization or spot the moment when it takes the wrong turn.

Ichak Kalderon Adizes - Management/Mismanagement Styles

Finally, because the article is supposed to list the books I would recommend to managers, there should be at least one that has the word "management" in its title. Management Styles is the first book by Adizes that I read and it looks like the right pick. It provides a great model explaining what managers should do, what they actually do and why these are different things. The focus of this part of Adizes' writing is what kind of managers are encountered in the wild and - especially useful - how most of them fail at their duties. It actually gave me a framework that allows to remember that there are several areas in which I should work and makes me spot my own deficiencies when I fail to pay enough attention to one of them. While this was most valuable for me, the book also covers many aspects of managers' and non-managers' behavior and helps handle colleagues better and know what to expect from them. I definitely recommend it to everyone and will myself study other works by the same author - there is likely more great advice to find.

These five titles played a great role in my personal development this year. Of course that's not enough to satisfy one hungry for growth, so there are lots of articles and other sources of valuable information, like podcasts, but these are a different story. As for the books, in 2017 I certainly resolve to read more than last year and will start with Herding Cats by Hank Rainwater and some other book by Ichak Adizes. If you read one of these, please share your thoughts and takeaways in the comments. In this new year I wish you more great books, that will both entertain and educate you!