At some point during your recruitment drive you’ll likely use recruiters. The problem is that some recruiters are creating a bad first impression of your company. Your recruiters are often the first point of contact a potential hire has with your company. Here are some ideas on how to help your recruiters create a great … Read More →
The post How to help your recruiters create a great first impression appeared first on The Social Tester.
I believe we need a lot more examples of software testing. They will be key in transferring tacit knowledge (they will not be all that is required, but an important part.) They work best when done live, so you can discuss, but that doesn’t scale very well.
So I have created a few examples in video or text format:
Exploratory Testing Session – Spotify Offline
Scenario Testing – LibreOffice Compatibility
Test Analysis – Screen Pluck
I am very interested in knowing if they are useful to you, and how.
Which other public testing examples are your favorites?
At the recent Xamarin Evolve conference, Paul Batum gave a great talk on Azure Mobile Service in cross-platform business apps, part of which included a piece on how AutoMapper fits in with their overall system:
There were sooooo many of those C# shirts at the conference, I felt a little left out without one.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
A few weeks ago I gave a talk at NSBCon NYC on scaling NServiceBus, and one of the pieces I highlighted were various saga/processing patterns and how they can affect performance. It was difficult to give real numbers as part of the discussion, mostly because how long it takes to do something is highly variable in the work being done and environmental constraints.
I compared three styles of performing a set of distributed work:
And highlighted the performance differences between them all. Andreas from the Particular team mentioned that some work had been done to improve saga performance, so I wanted to revisit my assumptions to see if the performance numbers still hold.
I wanted to look at a lot of messages – say, 10K, and measure two things:
- How long it took for an individual item to complete
- How long it took for the entire set of work to complete
Based on this, I built a prototype that consisted of a process of 4 distinct steps, and each variation of process control to track/control/observe progress. You can find the entire set of code on my GitHub.
Here’s what I found:Process Total Time Average Median Observer 6:28 0.1 sec <0.1 sec Controller 6:25 3:25 3:37 Routing Slip 2:57 2.6 sec <0.1 sec
Both the observer and controller styles took roughly the same total amount of time. This is mostly because they have to process the same total amount of messages. The observer took slightly longer in my tests, because the observer is more likely to get exceptions for trying to start the same saga twice. But once an item began in the observer, it finished very quickly.
On the controller side, because all messages get funneled to the same queue, adding more messages meant that each individual item of work would have to wait for all previous items to complete.
Finally, the routing slip took less than half the time, with higher total average but comparable median to the observer. On the routing slip side, what I found was that the process sped up over time as the individual steps “caught up” with the rate of incoming messages to start the process.
This was all on a single laptop, so no network hops needed to be made. In practice, we found that each additional network hop from a new message or a DB call for the saga entity added latency to the overall process. By eliminating network hops and optimizing the total flow, we’ve seen in production total processing times decrease by an order of magnitude based on the deployment topology.
This may not matter for small numbers of messages, but for many of my systems, we’ll have 100s of thousands to millions of messages dropped on our lap, all at once, every day. When you have this situation, more efficient processing patterns can alleviate pressure in completing the work to be processed.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
The eighth GTAC commences on Tuesday at the Google Kirkland office. You can find the latest details on the conference at our site, including speaker profiles.
If you are watching remotely, we'll soon be updating the live stream page with the stream link and a Google Moderator link for remote Q&A.
If you have been selected to attend or speak, be sure to note the updated parking information. Google visitors will use off-site parking and shuttles.
We look forward to connecting with the greater testing community and sharing new advances and ideas.
I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.
Although Henry was just a “Developer”, he lead the team in a number of ways.Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence You don’t need to be a “Lead”
My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.
A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:
Thinking and doing something for the benefit of the team without being told to do so.
There are, of course, many other attributes to being a leader, but that is a separate post.A Lead without leadership
You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.Great leaders encourage leadership
Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.Action is not the same as a title
Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.
If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
The featured image is shared from Flickr under the Creative Commons licence.
I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits. This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles. It highlights that the many articles have value. If you want to receive its value, consider following this blog at: http://cmforagile.blogspot.com/.
To add to the statistics, I have folks from 45 different countries that have visited my site. The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.
The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations. The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work. I have written and posted 56 articles to date (although this one technically counts as the 57th). What are some of the top articles that Agile, IT, and Business Professionals have found of value? The top articles include:
- Who makes the best Scrum Master
- Agile Animal Farm – Pigs, Chickens, and more
- Agile Value Capture Metrics – Are you building value?
- Right-sizing Documentation in an Agile World
- Agile Definition of Done Starter Kit
- Agile – Its more disciplined than you think
- Gamification of your Agile Journey
- Agile Culture – Are you stepping up?
- The Role of Middle Management in an Agile World
- Are you Ready for your Agile Journey?
- Agile Executive Playbook
- Robust Agile Requirements – Its about the Discussion
- Is it finally time to “Be Agile”?
- Personas – Do you really know your Users?
- User Story Writing Starter Kit
- Agile Lagging to Leading Metric Path
I’m tired of hearing the simplistic advice about how to listen one must not talk. That’s not what listening means. I listen by reacting. As an extravert, I react partly by talking. Talking is how I chew on what you’ve told me. If I don’t chew on what you say, I will choke or get tummy aches and nightmares. You don’t want me to have nightmares, do you? Until you interrupt me to say otherwise, I charitably assume you don’t.
Below is an alternative theory of listening; one that does not require passivity. I will show how this theory is consistent the “don’t talk” advice if you consider that being quiet while other people speak is one heuristic of good listening, rather than the definition or foundation of it. I am tempted to say that listening requires talking, but that is not quite true. This is my proposal of a universal truth of listening: Listening requires you to change.
To Listen is to Change
- I propose that to listen is to react coherently and charitably to incoming information. That is how I would define listening.
- To react is to change. The reactions of listening may involve a change of mood, attention, concept, or even a physical action.
Notice that I said “coherently and charitably” and not “constructively” or “agreeably.” I think I can be listening to a criminal who demands ransom even if I am not constructive in my response to him. Reacting coherently is not the same as accepting someone’s view of the world. If I don’t agree with you or do what you want me to, that is not proof of my poor listening. “Coherently” refers to a way of making sense of something by interpreting it such that it does not contradict anything important that you also believe is true and important about the world. “Charitably” refers to making sense of something in a way most likely to fit the intent of the speaker.
Also, notice that coherence does not require understanding. I would not a bad listener, necessarily, if I didn’t understand the intent or implications of what was told to me. Understanding is too high a burden to require for listening. Coherence and charitability already imply a reasonable attempt to understand, and that is the important part.
Poor listening would be the inability or refusal to do the following:
- take in data at a reasonable pace. (“reasonable pace” is subject to disagreement)
- make sense of data that is reasonably sensible in that context, including empathizing with it. (“reasonably sensible” is subject to disagreement)
- reason appropriately about the data. (“reason appropriately” is subject to disagreement)
- take appropriate responsibility for one’s feelings about the data (“appropriate responsibility” is subject to disagreement)
- make a coherent response. (“coherent response” is subject to disagreement)
- comprehend the reasonable purposes and nature of the interaction (“reasonable purposes and nature” is subject to disagreement)
Although all these elements are subject to disagreement, you might not choose to actively dispute them in a given situation, because maybe you feel that the disagreement is not very important. (As an example, I originally wrote “dispute” in the text above, which I think is fine, but during review, after hearing me read the above, Michael Bolton suggested changing “dispute” to “disagreement” and that seemed okay, too, so I made the change. In making his suggestion, he did not need to explain or defend his preference, because he’s earned a lot of trust with me and I felt listened to.)
I was recently told, in an argument, that I was not listening. I didn’t bother to reply to the man that I also felt he wasn’t listening to me. For the record, I think I was listening well enough, and what the man wanted from me was not listening– he wanted compliance to his world view, which was the very matter of dispute! Clearly he wasn’t getting the reaction he wanted, and the word he used for that was listening. Meanwhile, I had reacted to his statements with arguments against them. To me, this is close to the essence of listening.
If you really believe someone isn’t listening, it’s unlikely that it will help to say that, unless you have a strong personal relationship. When my wife tells me I’m not listening, that’s a very special case. She’s weaker than me and crucial to my health and happiness, therefore I will use every tool at my disposal to make myself easy for her to talk to. I generally do the same for children, dogs, people who seem mentally unstable, fire, and dangerous things, but not for most colleagues. I do get crossed up sometimes. Absolutely. Especially on Twitter. Sometimes I assume a colleague feels powerful, and respond to him that way, only later to discover he was afraid of me.
(This happened again just the other day on Twitter. Which is why it is unlikely you will see me teach in Finland any time soon! I am bitten by such a mistake a few times a year, at least. For me this is not a reason to be softer with my colleagues. Then again, it may be. I struggle with the pros and cons. There is no simple answer. I regularly receive counsel from my most trusted colleagues on this point.)
A Sign of Being Listened to is the Change that Happens
Introspect for a moment. How do you know that your computer is listening to you? At this moment, as I am typing, the letters I want to see are appearing on the screen as I press the keys. WordPress is talking back to me. WordPress is changing, and its changes seem coherent and reasonable to me. My purposes are apparently being served. The computer is listening. Consider what happens when you don’t see a response from your computer. How many times have you clicked “save” or “print” or “calculate” or “paste” and suffered that sinking feeling as the forest noises go completely silent and your screen goes glassy and gets that faraway grayed out look of the damned? You feel out of control. You want to shout at your screen “Come back! I’ve changed my mind! Undo! Cancel!” How do you feel then? You don’t say to yourself “what a good listener my computer is!”
Why is this so? It’s because you are involved in a cybernetic control loop with your computer. Without frequent feedback from your system you lose your control over it. You don’t know what it needs or what to do about it. It may be listening to something, but when nothing changes in a manner that seems to relate to your input, you suspect it is not listening to you.
Based just on this example I conjecture that we feel listened to when a system responds to our utterances and actions in a harmonious manner that honors our purposes. I further conjecture that the advice to maintain attentive silence in order to listen better is a special case of change in such a way as to foster harmony and supportiveness.
Can we think of a situation where listening to someone means shouting loudly over them? I can. I was recently in a situation where a quiet colleague was trying to get students to return to her tutorial after a break. The hallway was too noisy and few people could hear her. I noticed that, so I repeated her words very loudly that her students might hear. I would argue that I listened and responded harmoniously in support of her needs. I didn’t ask her if she felt that I listened to her. She knows I did. I could tell by her smile.
If my wife cries “brake!” when I’m driving, I hit the brake. The physical action of my foot on the brake is her evidence that I listened, not attentive silence or passivity.
It may be a small change or a large change, but for the person communicating with you to feel listened to, they must see good evidence of an appropriate change (or change process) in you.
Let me tell you about being a father of a strong-minded son. I have been in numerous arguments with my boy. I have learned how to get my point across: plant the idea, argue for a while, and then let go of it. I discovered it doesn’t matter if he seems to reject the idea. In fact, I’ve come to believe he cannot reject any idea of mine unless it is genuinely wrong for him. I know he’s listening because he argues with me. And if he gets upset, that means he must be taking it quite seriously. Then I wait. And I invariably see a response in the days that follow (I mean not a single instance of this not happening comes to mind right now).
One of the tragedies of fatherhood is that many fathers can’t tell when their children are listening because they need to see too specific a response too quickly. Some listening is a long process. I know that my son needs to chew on difficult ideas in order to process them. This is how to think about the listening process. True listening implies digestion and incubation. The mental metabolism is subtle, complicated, and absolutely vital.
Let People Chew on Your Ideas
Listening is not primarily about taking information into yourself, any more than eating is about taking food into yourself. With eating the real point is digestion. And for good listening you need to digest, too. Part of digestion is chewing, and for humans part of listening is reacting to the raw data for the purposes of testing understanding and contrasting the incoming data with other data they have. Listening well about any complicated thing requires testing. Does this apply to your spouse and children, too? Yes! But perhaps it applies differently to them than to a colleague at work, and certainly differently than testing-as-listening to politician or a telemarketer.
Why does this matter so much? Because if we uncritically accept ideas we risk falling prey to shallow agreement, which is the appearance of agreement despite an unrecognized deep disagreement. I don’t want to find out in the middle of a critical moment on a project that your definition of testing, or role, or collaboration, or curiosity doesn’t match mine. I want to have conversations about the meanings of words well before that. Therefore I test my understanding. Too many in the Agile culture seem to confuse a vacant smile with philosophical and practical comprehension. I was told recently that for an Agile tester, “collaboration” may be more important than testing skill. That is probably the stupidest thing I have heard all year. By “stupid” I mean willfully refusing to use one’s mind. I was talking to a smart man who would not use his smarts in that moment, because, by his argument, the better tester is the one who agrees to do anything for anyone, not the one who knows how to find important bugs quickly. In other words, any unskilled day laborer off the street, desperate for work, is apparently a better tester than me. Yeah… Right…
In addition to the idea digestion process, listening also has a critical social element. As I said above, whether or not you are listening is, practically speaking, always a matter of potential dispute. That’s the way of it. Listening practices and instances are all tied up in socially constructed rituals and heuristics. And these rituals are all about making ourselves open to reasonable change in response to each other. Listening is about the maintenance of social order as well as maintaining specific social relationships. This is the source of all that advice about listening by keeping attentively quiet while someone else speaks. What that misses is that the speaker also has a duty to perform in the social system. The speaker cannot blather on in ignorance or indifference to the idea processing practices of his audience. When I teach, I ask my students to interrupt me, and I strive to reward them for doing so. When I get up to speak, I know I must skillfully use visual materials, volume control, rhythm, and other rhetorical flourishes in order to package what I’m communicating into a more digestible form.
Unlike many teachers, I don’t interpret silence as listening. Silence is easy. If an activity can be done better and cheaper by a corpse or an inanimate object, I don’t consider it automatically worth doing as a living human.
I strongly disagree with Paul Klipp when he writes: “Then stop thinking about talking and pretend, if it’s not obvious to you yet, that the person who is talking is as good at thinking as you are. You may suddenly have a good idea, or you may have information that the person speaking doesn’t. That’s not a good enough reason to interrupt them when they are thinking.” Paul implies that interrupting a speaker is an expression of dominance or subversion. Yes, it can be, but it is not necessarily so, and I wish someone trained in Anthropology would avoid such an uncharitable oversimplification. Some interruptions are harmful and some are helpful. In fact, I would say that every social act is both harmful and helpful in some way. We must use our judgment to know what to say, how to say it and when. Stating favorite heuristics as if they were “best practices” is patronizing and unnecessary.
One Heuristic of Listening: Stop Talking
Where I agree with Paul and others like him is that one way of improving the harmony of communication and that feeling of being coherently and charitably responded to is to talk less. I’m more likely to use that in a situation where I’m dealing with someone whom I suspect is feeling weak, and whom I want to encourage to speak to me. However, another heuristic I use in that situation is to speak more. I do this when I want to create a rhetorical framework to help the person get his idea across. This has the side effect of taking pressure of someone who may not want to speak at all. I say this based on the vivid personal experience of my first date with the one who would become my wife. I estimate I spoke many thousands of words that evening. She said about a dozen. I found out later that’s just what she was looking for. How do I know? After two dates we got married. We’ve been married 23 years, so far. I also have many vivid experiences of difficult conversations that required me to sit next to her in silence for as long as 10 minutes until she was ready to speak. Both the “talk more” and “talk less” heuristics are useful for having a conversation.
What does this have to do with testing?
My view of listening can be annoying to people for exactly the same reason that testing is annoying to people. A developer may want me to accept his product without “judgment.” Sorry, man. That is not the tester’s way. A tester who doesn’t subject your product to criticism is, in fact, not taking it seriously. You should not feel honored by that, but rather insulted. Testing is how I honor strong, good products. And arguing with you may be how I honor your ideas.
Listening, I claim, is itself a testing process. It must be, because testing is how we come to comprehend anything deeply. Testing is a practice that enables deep learning and deeply trusting what we know.
Are You Listening to Me?
Then feel free to respond. Even if you disagree, you could well have been listening. I might be able to tell from your response, if that matters to you.
If you want to challenge this post, try reading it carefully… I will understand if you skip parts, or see one thing and want to argue with that. Go ahead. That might be okay. If I feel that there is critical information that you are missing, I will suggest that you read the post again. I don’t require that people read or listen to me thoroughly before responding. I ask only that you make a reasonable and charitable effort to make sense of this.
"Hmmm ..." answered Marco,
"It may be you're right.
I've been here three hours
Without one single bite.
There might be no fish ... "... But again,
Well, there might!" "Cause you never can tell
What goes on down below! "This pool might be bigger
Than you or I know!"Testers, I give you McElligot's Rule*: when you're chasing a might on the basis of a never-can-tell, it's worth putting your rod aside now and again to think about what you're tying to achieve, how, why and for who.
* OK, heuristic, but we're rhyming today.
- Material about constrained versus unconstrained isolation frameworks : specifically those that can fake things like statics and priavte methods.
- A new chapter 6 on what makes for a good isolation framework and how frameworks like Typemock work under the covers.
- I no longer use RhinoMocks. Stay away from it. It is dead. At least for now. I use NSubstitute for examples of Isolation Framework Basics, and I also highly recommend FakeItEasy. I am still not crazy about MOQ, for reasons detailed in chapter 6.
- I added more techniques to the chapter about implementing unit testing at the organizational level, such as understanding influence factors
- There are plenty of design changes in the code I show in the book:
- Mostly I stopped using property setters and am mostly using constructor injection.
- Some discussion of SOLID principles is added, but just enough to make it whet your appetite on the subject.
- The build related sections of chapter 7 also contain new information. I learned a lot since the first book about build automation and patterns. It’s the topic of my next book. In this book I talk about build pipelines and where unit testing fits in the process.
- I recommend against setup methods, and give alternative ideas on getting the same functionality out of your tests.
- I also use newer versions of Nunit so some of the newer Nunit APIs changed in the book( Assert.thorws. vs Assert.Catch, TestCase attributes and more)
- In chapter 10, the tools relating to legacy code were updated.
- Having worked with Ruby for the past three years along side .NET, I gained more perspective about design and testability arguments, reflected in chapter 11, dedicated only to this topic.
- The tools and frameworks appendix was updated with new tools, and old tools were removed.
Also, here is a talk I did about it:
A Second Look at Unit Testing by Roy Osherove from Roy Osherove
I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.Negotiation
A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.
Getting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation.
Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.
The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.
The Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.
Facilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.
Collaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.
With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.
Waltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.
Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.
When recruiting software testers many hiring managers often look for the impossible candidate who can do everything. These people don’t exist yet many hiring managers continue to place job adverts that seek out these candidates. What follows are 5 ways that will help you to create effective adverts for recruiting software testers When I … Read More →
The post How to create effective adverts for recruiting software testers appeared first on The Social Tester.
A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.
Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.
Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.
Image take from Emacswiki
The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.
Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.
When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.
If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.