Today I want to discuss a topic, that many of us thought about for sure. I want to talk about interest and fun at work.
An Interesting Task
What does “interesting” task mean? People are different and interesting tasks are different, but it is possible to define some common properties. Maybe you can provide many properties, but I think only two are particularly important.
An interesting task is usually challenging. It is close to the edge of your skills. You feel that you can crack it, but don’t know how exactly so far.
An interesting task should give you a new knowledge. If you solve the problem and learn nothing, it doesn’t feel very cool. When you solve the problem and learn some new concepts, then you feel much better in the end.
So interesting task is challenging and generates knowledge.
However, there is another thing — developer’s experience.
They almost always work on interesting tasks. Any task provides some challenge, any task generates new knowledge.
Initial enthusiasm is gone and now it is a serious job with less and less fun. If the fun level drops below a certain edge, you are in trouble. It means you learn nothing. If you learn nothing, you will become a “zombie developer” eventually. A zombie developer goes to work and solves similar problems again and again.
No real thinking, no real challenges, more brainless activities like meetings, small talks (not the language), status reporting, hacker news, Facebook, Twitter, chats, death. True zombies don’t like interesting tasks. They like familiar tasks that demand minimal effort to complete. They work on the lowest energetic level possible.
The day when you say to yourself “I didn’t do any interesting task for weeks” should rise a red flag in your head. Go and fix that. Talk to managers, change position, change a company. There should always be a healthy mix of interesting and familiar tasks. Fight for that.
After 10 years of professional programming they accumulated a good backpack of knowledge, experience and sarcasm. There are not so many tasks they find interesting anymore.
Some give up and just do their job. They say: “We are professionals and solve problems not for fun, but for the value to the people. That’s what we do”. They try to re-frame a problem and replace a real solution with psychological one. Sometimes that works, but often not so well. These people are unhappy. They do the job well, but you should not expect any enthusiasm, initiative and courage. Create one more 3-layers enterprise solution? OK. Build another one social network? OK. Zombie Developer Level 80.
Some try to find a way to the mastery, solving the same problems better and better. For example, writing compilers for 20 years. It is an honourable road only a few can ride. You should be very determined, patient and calm. These qualities are rare in the Western culture.
Some push forward to the limit to work on really challenging problems. They change jobs, change countries, change industries and technologies. They jump from problem to problem, developing astonishingly wide skill sets. Definitely, they don’t have depth in all the areas, but they do provide unusual point of views and can attack problems from surprising angles.
Any good company should provide enough interesting tasks. It is a serious mistake to believe that people will do everything with equal passion. They can, but only if the balance of interesting/boring tasks is good enough.
Most likely, every company should have people with all levels of experience. Junior developers will be happy to work on tasks that veterans treat as trivial. Experienced developers will be happy to work on tasks that veterans treat as OK. And you need veterans to storm really challenging problems (if you have any).
I personally thought that junior developers were not required in our company. I was wrong. It leads to a situation when veterans have to work on simple and trivial tasks more and more often. Fun level drops. Productivity drops. Danger to lose veterans increases.
Which distribution of junior, experienced and veteran developers a company should have? It depends on problems you have. There are 25 developers in our company: 19 experienced and 6 veterans. So our current distribution is 0-75-25%. I think a more healthy distribution would be 25-50-25%. What we are going to do is to hire 6 junior developers to have 20-60-20% distribution so far.
Here is the distribution for various types of companies. X – developers expertise, Y – % of developers in a company:
As you see, currently Targetprocess team is skewed into the “scientific projects” type, while it is certainly not scientific so far. We should move back into the product development distribution.
- Almost every task is interesting for junior developers.
- Experienced developers should maintain a healthy balance between interesting and OK tasks.
- Veterans have two viable roads: sharpen their limited set of skills to the mastery or attack new problems all the time and become a smart generalist.
- Company should care about “fun level” and have the experience distribution that fits existing problems.
Routine Pros and Passion Cons
Continuous Problem-Solving Is No Accident
Cognitive Endurance Basics for Software Developers
I’ve bumped into this amazing infographics in an equally amazing book. This chart gives a visual taxonomy of the US sports team names in football, baseball, basketball and hockey. One can see that the names are broken down into 4 groups (Abstracts, Animals, Objects and Peoples). The icons refer to sports; the pie charts show distribution of name types.
That’s a zoom in on a 1/4 of this poster:
That’s the upper part:
That’s the bottom part, with Peoples:
That’s the leagues breakdown. One can see that a team with a reptilian name has won a championship only once.
This poster accommodates lots of information, sorting through the array of names. Some of the names originate from a poem (e.g. Baltimore Ravens), some from myths. It would take a lot more time and space to convey this taxonomy using only words.
As someone with a LinkedIn profile, I often come across job postings. There’s a game going on. While LinkedIn is a very lucrative place for headhunters, IT professionals find shelter in the groups unrelated to job search, as they want some recruiter-free space. This whole affair of seeing headhunters hunt, and group moderators hunt the headhunters makes me want to share an overview of how top talents are hired in software development.
The Old-School Hiring
The traditional way of hiring is to list job requirements, post an ad and wait for the candidates to send in their CVs. This approach might work in some locations, but it’s getting less and less effective. I’ve already touched upon the subject of attracting best of breed people in the Project Manager or Tech Leader? post. What do recruiters usually do when they see that job postings don’t work? They start behaving as vendors at an Oriental bazaar as they push you annoyingly to buy their stuff. Our natural reaction to being chased is to run, obviously. I guess these out-of-date hiring methods can only be used by a company running business in a location where IT talents crave jobs and can be picked up in the street.
Yes, that was an intended absurd statement. I just want to emphasize the point that this annoying hiring does not work.
There’s an absolute must that needs to be in place if one wants to hire talents. The company has to be a really attractive place for the like-minded people. This goes beyond salaries and crazy perks, and we are moving on to a very friendly way of hiring.
This one works great. Unfortunately, there’s only so much personal connections that employees have, and might be they are simply not enough, no matter how great this company is. What if this great company has used up the potential of personal connections? The CVs coming in response to job offerings do not comply with the talent quality that this company requires, and all the cool friends of friends have already been hired. Hmm.. looks grave. What comes next, then?
This is another great strategy. Nurturing is about taking young interns on board and training them at work. It might take several years for such people to grow into good professionals. There are some downsides in this strategy, though. One needs to have a buffer of those several years (which often is not the case, because normally new people are needed right now), making sure that the nurtured folks want to stay in the company.
Locking them in with multi-year contracts would hardly be a solution, so the company should be able to spark a strong personal commitment to keep people. Some companies seem to be nurturing talents and seeing them mature to professionals, but then at some point those freshly-raised engineering rock stars go elsewhere.
I consider this a brilliant strategy for companies of the Yahoo or Google caliber. Promising young start-ups that excel at engineering but lack the operational management qualities, or need more financial influx to get their ideas going, are acquired by giants that either ingrain them in their business, or have them work on other projects that would equally be interesting to them. But acqui-hiring only works if a company is located in one of technological hubs, and if there are enough funds to buy out such start-ups. Besides, it depends on how the very fact of acqui-hire is perceived by the talents in this young start-up. It seems to have some stigma.
What if a company has tried old-school hiring, personal connections, nurturing and is not yet ready for acqui-hiring? What else needs to be taken into account?
Here we approach the deep-lying things that go beyond the narrow subject of IT hiring. It’s about what people want to do with their lives, and this goes all the way back to educating our kids. Which culture is prevailing in this society: the culture of co-creativity, inspiration and pursuing some higher goals in life, or dragging along with the consumerist lifestyle? Do we have many IT professionals, in general, who see their work as something larger than a machine that produces paychecks? I’m not even talking about extra passion or motivation. If we lack such people in general, something must be wrong at a deeper level, and there might come a time that even acqui-hires will not work any longer.
Besides, it all very much depends on the location where a company runs business. As a long-term strategy, it would help to keep an eye on how demographics, education and business dynamics evolve in different nations. This is very nation-specific, as countries (and states in the USA) have various social and economical conditions. Some technological hubs are emerging, some are declining. It looks like the global shortage of IT talents might bring us to a point where a business would move to a place where talents flock, not the other way around.
Project Managers: Nurturing vs. Hiring
Project Manager or Tech Leader?
Earlier this year I published the 3 Checkpoints for Your Agile Project Management Tool blog post. As a reminder, the 3 checkpoints are these:
I’m making this reference to give a clearer idea of what my today’s post is about. The very first bullet — process first, tool next — deserves a closer look. What happens in the phase which goes between “process first” and “tool next’? A diagnostics check of the development process. We need to be aware of any peculiarities of the real development process to select a tool that would be capable to replicate it. So, what are the things to note about the process that one would definitely need in the tool?
First, you need to break down your development process into these 3 parts:
This high-level representation will work as a good reference framework to cover all the essential details of the process that needs to be replicated in the project management tool. I’ve compiled a list of questions that would help stakeholders check if a tool is capable to mirror the process. Let’s go over each of those 3 major checkpoints.
1. Which work items are you using? How is work broken down in your development process? How many levels of hierarchy do you need for your work items? Just for the sake of example, the hierarchy can look as follows:
Idea (Issue) -> Epic -> Product->Project->Feature-> User Story->Task
A special attention should be paid to the levels of hierarchy, and to the ability of work items to be linked together, which brings us to the next question.
2. Which dependencies do we have between our work items? Do we need to replicate any other dependencies in the tool, apart from the hierarchical breakdown?
3. What is our definition of done for a project or for a work item? Do we need to have a certain scope completed, or is our project tied with the time elapsed? Do we need multiple final states for work items (e.g. Done and Resolved)?
1. How are people organized into teams? Do we have cross-functional teams? Functional teams? Project teams? Departments? No teams at all?
2. Is development process the same for each team? Do we sometimes need to assign several teams to an Epic or to a User Story?
3. Does anyone need to be aware of how work progresses, even if they are not assigned to this team or to this project? Customers? Executives?
1. How do we do backlog management? Where are the backlog items coming from? How do we groom the backlog?
2. Projects/Releases/Iterations: Do we have cross-project (or cross-team) releases? Parallel iterations or releases? Do we break down projects into phases (e.g. UX, prototyping, functional design, delivery)?
3. Which reports do we use? This one is very important. Be sure to check if the tool has all the reports that you need.
The reason I give this list here is that sometimes people overlook some essential components of their development process as they commit to a project management tool. I’m not claiming that each and every possible question is covered in the list above, but the 3 checkpoints framework will help to get a more complete idea of the points to note about your development process when choosing an agile project management tool.
At this time of the year, as we count our blessings and give thanks, I suddenly found myself thinking: “Thanks for the learning experiences.” I find real delight in learning and exploring, and I’m sure many of you do, too. Learning is interwoven with the challenges that we encounter as IT professionals, no doubt. We have to learn, learn and learn to do our work well.
If we replace “run” with “learn” in the famous quote from Through The Looking Glass, it would sound just right to what we have to deal with:
“A slow sort of country!” said the Queen, “Now, here, you see, it takes all the learning you can do, to keep in the same place. If you want to get somewhere else, you must learn at least twice as fast as that!”
Let’s now consider what people normally do to learn. Do they gauge the mainstream education techniques with their individual needs? Apparently, no. Well-intentioned corporate managers send employees to conferences believing that’s the best thing they can do to help people grow professionally. Have you ever been to a conference or a training, wanting to learn something new, only to find out that you’ve spent several days listening to truisms? The real outcome of such an event might be the feeling that you’re not alone, that you’ve mingled with people who have similar problems. Unfortunately, there’s no such takeaway from a conference as a solution to a real problem. That’s the bottomline: we often mistake studying for learning.
Most of the conferences and educational events are focused on making people feel that they study, rather than having them learn meaningful things.
What are the signs that someone is studying? It’s usually rote memorization, passively absorbing a lecture, doing abstract assignments. Learning is about taking lessons from your own challenges, both personal and professional, exploring and finding the answers to your own questions.
This awkward feeling about conferences has its roots in the wrong belief that techniques used for educating kids and teens should be copy-pasted to professionals. This grave misconception costs thousands of wasted hours that adults could use for real learning. Studying does work well for kids and teens, no question. Youngsters have to acquire some boilerplate knowledge to get started. Rote learning is great if a kid has to memorize the multiplication table. It’s all different for adults. Mature brains and mature judgement excel at recognizing and enhancing the patterns they internalized from life experiences, that’s why adults are even biologically less prone to memorizing things they don’t really need. That’s why we skip information if it has nothing to do with what we’re currently preoccupied with.
Instead of taking a formal stance and spending corporate budgets on conferences, executives would be much better off encouraging the culture of on-site learning. If I need to learn something — I will learn it. That’s how adults think. Another good scenario for learning is when one becomes genuinely interested in some subject, and wants to dig deep into it. This is what I call self-powered learning and exploring. It’s a lot more exciting and rewarding (and I speak from my own experience here), than sitting in at a conference. I also find that mutual mentoring (or a peer-to-peer exchange of insights, thoughts and opinions) between professionals is a great way to learn. That’s where conferences might actually help, as I’ve mentioned above. They are not that hopeless, after all :)
We need to be clear about what we expect from such events. We can not afford going to a conference that only touches a tip of an iceberg of what our real problem is. Do we want to socialize with the like-minded, to hear their stories, and share something with them? Or, are we taking this conference just formally, as a sit-in event? If yes, why not spend this time on an intense research, to get some real clues to what you want to achieve?
Continuous Problem-Solving Is No Accident
Cognitive Endurance Basics for Software Developers
I tried hard to keep this major secret to myself, but looks like it can’t wait anymore. I will unveil it now.
Empathy is the most important tool of a UX designer.
In other words, a feeling of affinity with others.
Everyone has heard that to catch a criminal one has to think like this criminal. To understand users, one has to become a user and start an account with any new web app that happens to come around.
There’s a very simple technique that can be used to develop empathy: watching yourself. You need to ask yourself such questions as:
- What makes me happy at this very moment?
- Why do I often mix right and left?
- How did I know that this non-underscored text is a link?
While others suffer from muzzy reflections, phobias and clumsiness, you can easily turn those faults into advantages.
Once you’ve come to terms with yourself, move on to your loved ones. Ask them questions and try to guess the answers:
- Sweetheart, why are you so hysterical about this witty thing I’ve just said? Why this very thing?
- What motivates you to put bread to the fridge?
- How did you know that this blue button represents a call to action?
Do whatever it takes to retrieve honest answers as you check your assumptions.
With time and practice, you’ll learn to see the world with any stranger’s eyes. Closing your eyelids and relaxing in the chair, you will effortlessly visualize how your user scenarios are followed by a globe-trotting freelancer in Thailand, or a boxer politician from the Ukraine, or by Angela, the lady who cleans the office on Thursday late afternoons.
The personas method popularized by Allan Cooper will seem an innocent child’s game.
Slow down, slow down, it’s not all that blissful.
Empathy does not endow magical powers to read everyone’s mind, understand the motives and predict which button will be clicked. In most cases there’s even no need for that.
What empathy does though: it helps UX designers to get a bit higher above such coolish things as kerning, “pixel perfect”, skeuomorphism, flat designs, mock-ups, UI kits and discover completely new challenges.
You won’t get bored for the rest of eternity helping real people with real problems.
*rendered into English by Olga Kouzina. The original article is in Russian.
Imperatives in User Experience Design
UX: The One-Stop Guidance Principle
Why People Don’t Understand How to Use Your Software
Help People Understand How to Use Your Software
The Round Walls of UX
Holiday season is in the air. Thanksgiving is coming next week, and some of us have already put up Christmas trees. Swinging into the holiday mood, I’d like to share some things that I find especially sweet in our office. Not that we have only 5 of them. There are many more! I just want to share them in sensible chunks :)
Sweet thing #1: Cute Ginger Grater
We have this cute tiny grater for fans of ginger& lemon tea. One can slice ginger with knife, but it’s this little thing that gets the maximum out of the ginger flavor. Ginger & lemon tea is very toning. It’s a great beverage for the fall-winter season. No Photoshop was used in this image:
Sweet thing #2: The Magical White Tree
This piece of art adorns one of our glass-walled meeting rooms. It looks especially beautiful in the holiday season. A friend of one of our DevOps engineers has painted this tree on the glass wall:
Sweet thing #3: The Blue Cat
This cat is a very influential guy. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer. Another sign of Christmas coming :)
Sweet thing #4: Inspiring Wooden Clothespins
A custom artistic installation piece on the desk of one of our QA engineers:
Sweet thing #5: I Love My Team badge
This one needs no commenting :)
Deciding what to do next is one of the hardest jobs in software product development. It looks quite easy at the start, with a fresh new product, and with a one-digit team, but at some point in time, as the product expands and grows — and lucky is the one who lived up to that moment! — we start facing some tough choices. Seems like oh so many new features are much wanted and much needed, and this decision-making becomes a very uneasy task. Even with the choices made, there might be a backward feel that another feature or improvement should have been given a higher priority and go first.
Targetprocess is quite a mature product (almost 10 years young), so we’ve had our share of those pains and choices. Some practices have been helping us decide along the way, and I’d like to share a few tips on what works, and how we continue to explore the better ways for decision-making.
Ideas and Votes
Collecting the suggestions (ideas) from customers and leads is the most obvious thing to try. That’s what we keep doing all the time. People have been able to submit their ideas and vote in Targetprocess Help Desk portal almost from the very beginning. Here’s how this page with ideas looked in the early Targetprocess:
The more votes an idea gets, the more likely it is that this feature will be implemented. We’ve been counting votes, and that’s how quite a few of the features squeezed into production. Some features had to wait for several years though, before they finally were implemented.
Then, as we’ve been coming up with an innovative version of our tool, we craved feedback not only from customers, but from anyone interested. From anyone, who spent some time playing with Targetprocess 3. We are using UserVoice to get the best of this impartial and objective feedback . UserVoice is a very convenient web venue for people to post their suggestions and to cast their votes. That’s how our page with suggestions (ideas) and votes looks:
Then the stakeholders can sort and prioritize these suggestions on a board. Numbers that come with a thumbs up show many votes have been received for that idea:
Mathematical Models and Intuition
Then, another group of influences is coming from those folks who interact with leads and customers: from product specialists, and from our support team. These guys collect the metrics which then help us make a summary of the voices from people who find it more convenient to share their feedback in personal interactions.
It’s particularly hard to decide what to do next, if the voices coming from customer-facing people do not match the priorities that stakeholders have in mind. What should take the lead: a suggestion for a feature spoken out by a dozen large customers in their conversations with product specialists, a feature that has 100 votes in HelpDesk or UserVoice, or a feature that stakeholders want to implement based on their strategic product vision? There’s no finite answer to that question. One has to find a balance between all of these. But still, how, how to decide? We are now poking some mathematical models that would process all those voices. Still, as far as I can see, in some cases a model has to be put aside. Most likely, if strategically important features are at stake. A mathematical model would be better suited for smaller features and improvements. For some crucial features forming the innovative new feel and engine of the product, it would still make sense to follow the vision that stakeholders come up with based on many things they observe. This would be a a responsible intelligent choice of a human being. Models can’t feel and think, they only process numbers and their powers are quite limited. But models work great if stakeholders want to free up the time they would otherwise spend mulling over the tiny “what to do next” choices, and do some meaningful work instead. Come up with new visions and strategies, for instance.
Prioritization and Big Data? Think Human Nature
Product Development: Drive or Hitchhike?
Recently I’ve written a blog about the benefits of visual thinking. Assuming that many of you are now aware of the advantages that visuals bring to the table, I’d like to give a few tips on how to visualize work in agile project management. Visual reports would probably be the first thing that comes to mind in this context. That’s right, visualization is most commonly used in reporting. Everyone wants comprehensive reports, fast, and that’s what visuals deliver. All kinds of stats and metrics wrapped up in a nice graphical skin, just as in this process control chart:
A Process Control chart in Targetprocess
My main focus this time is not on the visual reports, though. There’s a baseline dimension for visual choices in agile project management, as we’re looking for the most convenient ways to see exactly what we want to see. We might need to view our projects from various perspectives, and we need flexibility with visualizing things. Boards, lists and timelines would cover most of such needs. Let’s now look which of those three would be best suited for which tasks.
You will want to visualize work on a board if you need to intersect 2+ properties of a card, or if you want cards grouped by any of 2+ properties. All that switchable visualization magic can only happen if your agile project management tool does the job as described in the Kanban as Multiban? blog . Unlike the classical Kanban board, this board is supposed to be a switchable 2D (or even 3D) grid of any properties of a card or a group of cards . This is a must-have prerequisite for that limitless freedom with visualizing projects on a board. I’m aware of only one tool that has this “switchability“. Let me give some examples.
You want to know who is doing what. Which person has which to do’s assigned to them. Hmm, this is not something that you would easily see on a static Kanban board. You can dial in a custom people-work grid, and here’s how it would look on the board (click to enlarge):
User Stories, Bugs and Tasks by person in Targetprocess 3. Who’s doing what?
Then, you want to know about impediments, and how are they blocking progress in your projects. Switch the grids, and see them with ruthless clarity:
Impediments by Projects and States in Targetprocess 3
Visualizing a project with any of the switchable boards makes sense for anything drag-n-drop. It’s more than moving cards between states. The switchability will allow to fit almost any change to a drag-n-drop action. That’s how one can arrange user stories on a board for estimating. The 1, 2, 3, etc. vertical lanes are points. A user story will be dropped to any of those lanes when estimated:
Estimating user stories with drag-n-drop in Targetprocess 3
You will want to visualize something as a timeline if you need an activity or a group of activities plotted on a timescale, with some explicitly marked milestones. This is called roadmapping. If time-sensitive activities are visualized on a board, with the intersected year quarters and epics as on the screen below, the feel of time would not “sink in” that well :
A workaround for roadmapping in Targetprocess 3
.. as with a roadmap shown on a timeline. The sense of time is more acute with this visualization:
Roadmapping with timelines in Targetprocess 3
Tracking work on a timeline helps get a clear picture in one look. A timeline would also work better than any other visualization if you need to see individual allocations across several projects:
Individual allocations on a timeline in Targetprocess 3
One absurd idea for using timelines, just to give you a strong anti-pattern, would be to visualize a tag as a timeline. Sounds weird. A tag is a tag, no one cares, when and why has a user story been tagged with a tag. Hmm.. However, there still can be a realistic case even for that, if one would want to see when this tag was first used, to which to-do’s was it applied, etc.
I’ve been using timeline visualizations from Targetprocess 3 in the examples above. Frankly, if you want to visualize with timelines, you’d hardly do without an electronic tool. Apart from the switchability, it takes quite some effort to draw timelines on a physical whiteboard. Guess how much time would it take to draw a timeline any time one wants to get a custom visualization?
A roadmap on a whiteboard
You will want to visualize work as a list if there are only a few to-do items, or if you need to trace the hierarchy of epics -> user stories-> tasks-> bugs as here:
A sketch of lists in Targetprocess 3
A list also comes handy if you are hastily typing in the to-do’s, especially if on the go, catching ideas before they go. With no big screen for boards and timelines around, you might want to use lists on a mobile device:
A list view in Targetprocess 3 iOS app
As a summary, your visualization choices will depend on what you want to see, or what you want to do. Switchable boards and timelines can visualize anything. If you’re still skeptical about that, check this page with even more board visualizations.
.. and when not.
I wouldn’t exaggerate if I say that intensity is the most appraised quality of a tech leader. There’s a very valid reason for that: one can hardly accomplish a lot with a lax attitude to a plethora of tasks that have to be just done. When a tech leader exercises the attitude of intensity to the things they do, it is picked up by the whole team. I’m leaving off the part about organizational culture that breeds such leaders and followers in an organization. That’s something I’ve written about previously in the Project Manager or Tech Leader? article.
This time I want to highlight a flip side of intensity. This focus can be a blessing, but it can also be a curse. Think about it: what if a tech leader is putting all their ardor into actions that don’t seem to be attuned to the changing organizational or market dynamics? The actions that don’t feel in sync with the changes? As an example, might be that the decision-making mechanics is not working well in the company, but one still sticks to it. Or the business environment has changed, but too much focus on the actions originating from the expired mindset is holding the organization back.
What I’m trying to say: there’s a subtle balance between being intense and being loose. Yes, one won’t go far if things that need to get done float at a leisurely pace. Actionable initiatives have to be pursued with ruthless intensity and focus. In my humble opinion, there’s no other way to do meaningful things. However, if one is overly immersed in the planned actions, they might lose sensitivity and ignore some alarming signs. Such a leader might think to themselves: “Hmm, I feel something is wrong. But I don’t have time to think about it now. I need to act.” That’s where the catch is.
If a thought like that pops up in one’s mind, it’s time to get loose. A moment of looseness will create the space to think about what’s not going well. Wear another hat, in a way. One can go meditate, or just take some relaxed calm time to contemplate and decide what has to be done about this alarming symptom. If there’s even a slight feeling of misalignment between an organizational practice and the expected outcome, the more time will elapse going on with the intense actions, the more it will cost to the company. Tech leaders have to develop this feel of just-in-time switch from intensity to looseness. Too bad if this switch is not working. The rigid intensity blocks seeing the signs. Looseness here is about the ability to come to a halt and to look at those intensely pursued actions from a new perspective.
Taking a shift from intensity to such looseness just in time is the trademark quality of a star tech leader. It’s quite easy to follow through and to be confident about the things that one already knows. It’s much harder to be sensitive and attuned to the things that one isn’t yet aware of. However, being able to do so is one of the components of lifelong learning — and one of the essential traits of a tech leader.
Project Manager or Tech Leader?