The role of “tech lead” is a combination of a software engineer, a project manager, and an architect. A tech lead might spend 30% of her time coding and 70% managing a project, resolving conflicts, and planning.

Successful product delivery requires us to navigate overlapping, competing concerns across a broad spectrum of execution dimensions, all tied together via our tech lead role. This role is complex and multifaceted, requiring the people who hold it to balance a variety of needs and interests.

The tech lead is primarily concerned with feasibility and technical constraints, ensuring that the system architecture and technology stack will support the intended product and enable the team to meet overall project goals.

In this post, let’s look at the unique complexities and challenges of the tech lead.

The Challenges of a Tech Lead

This role is complex because there are so many ways a software project can go awry in technical delivery. As Tolstoy wrote, All happy families are alike; each unhappy family is unhappy in its own way.” The same is true for the technical delivery of software projects: Each project that falls short of perfection does so in its own unique way.

Unfortunately, software projects have so many competing concerns that no project is truly perfect. The best we can achieve is a close-to-ideal set of tradeoffs; even then, there is always some pain. There are always “what-if” questions and “hindsight-is-20-20” observations in any software project.

Here is a small sampling of the challenges we face:

  • Slow or missing development feedback loops (e.g., from automated tests) reducing productivity
  • Complex manual build or deployment processes leading to operational problems which consume precious time
  • Team members who ramp into new tech/domain slowly due to a suboptimal learning environment
  • Implementation of the wrong model, leading to a system that resists late-stage changes to the project
  • Late or misidentified project risks that manifest in negative project outcomes
  • Familiar, larger-scale problems, like missing budget or timeline constraints

The Responsibilities of a Tech Lead

Because each project has its own unique risks, there’s no list of specific tactics that will guarantee success. Instead, I think it’s useful to focus on the tech lead’s responsibilities, which fall into the following categories:

 

1. Be a leader

As part of the project’s leadership team, the tech lead works with the UX and DevOps leads to balance leadership responsibilities appropriately. For example, if a DevOps lead is being overwhelmed by stakeholder requests, the tech lead might step in to help cover some of the DevOps lead’s other tasks. Do whatever it takes to help the team find success.

2. Identify technical risk

The tech lead is primarily responsible for identifying technical project risks. These may come from technical unknowns, model drift as more is learned about project needs, technical debt accrued to meet short-term goals, or observed team frictions or workflow issues. All risks must be captured, accounted for with the delivery lead, and monitored until they warrant action. When action is needed, it should be prioritized alongside other user-facing project work.

3. Steward the feasibility of human-centered design

As part of our human-centered design process, the tech lead ensures that feasibility/technical concerns are integrated into the overall product design. Tech leads should be involved in the holistic design, but they are also directly responsible for helping refine the design. They look for ways to build technical leverage and identify easy implementation wins to meet user and customer needs while minimizing development effort.

4. Formalize the model

As experienced developers trained in domain and data modeling, tech leads should guide the team in formalizing and generalizing the model evolved from the domain, project goals, and UX design. The development lead (with help from the UX and DevOps leads) will clarify the model and develop the ubiquitous language for the project. The tech lead can also ensure that the model is applied uniformly to the UX and identify when the model needs to evolve to accommodate new features and edge cases.

5. Refine the backlog

When a backlog is built out early in a project, it’s often oriented around epic stories or rough units of user-visible functionality. Once remaining questions are answered and a story is sprintable, tech leads look across upcoming work for commonalities with near-term work. They can then document a hypothetical implementation plan and/or various cross-cutting or future concerns that may impact the feature implementation.

6. Evolve the architecture

The architecture of a system evolves each sprint as we deliver more working software. Tech leads are responsible for ensuring that the overall system evolves in a coherent way over time. This often manifests as bringing larger-scale technical concerns to individual feature tasks. To be considered “done,” a story should include auxiliary work to ensure the overall system is evolving responsibly. This often entails additional work above and beyond meeting the user-facing need represented by the story.

7. Tend the project ecosystem

In addition to evolving the product architecture, a tech lead must monitor the development ecosystem, which includes the abstractions, tools, and practices used by the development team. The tech lead must be on the lookout for problem areas, such as opportunities for automation, inappropriate abstractions, development frictions, or recurring mistakes. While the tech lead may not be the one to solve these problems, he or she should make sure these problems are handled appropriately–for example, by making sure that new tasks are added to the backlog.

8. Align the team

It takes work to get everyone on the team on the same page. For small teams, it may take nothing more than good communication. On large teams, it may require regular pair rotations or technical team sync meetings to ensure that everyone understands how the system is being built. This is a constant, challenging activity that often requires technical investment and support in the project ecosystem via linters and other tooling.

9. Teach & learn

Every project is a classroom, and we all have more to learn. To deliver the best possible outcome for a customer, the tech lead should nurture and empower the team, helping them to develop their skills in ways that will be productive for this particular project. It’s important to think critically about how to help individual team members grow. Then pick technologies and architectural patterns that provide the best environment for leveraging past experiences and growing to meet the challenges at hand.

An Impossible Job to Master

This list of tech lead responsibilities is large, varied, and often contradicting. I recommend that tech leads regularly revisit this list and ask what opportunities they see for improving their execution or advancing the project. Focusing on each area and looking for ways to improve is a strong step toward excelling in the role.

For me, this list is also a testament to the sheer depth of the tech lead role. No one can master all of these concerns and the ways they manifest in a short time frame. True mastery of this role takes at least a decade, and even then, there’s always room for improvement and new ways to master the subtleties.

Posted by: lrrp | October 25, 2019

5 Tips for Being an Effective Tech Lead

Becoming a Tech Lead is a tough transition for any developer, because only part of the skills and experience you had as a developer prepares you for the expectations of a new role. Instead of simply designing and writing code, a Tech Lead is suddenly responsible for an entire development team – and this means dealing with people, both technical and non-technical.

The time a developer spent focusing on writing well-designed code does not translate into the skills necessary for understanding people, resolving conflict, or suddenly having to juggle more tasks than they can possibly achieve by themselves.

1. Learn to Delegate

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seek the most simple solution and celebrate a victory when you want that red, failing test going green.

As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems, regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses opportunities for other developers to grow and problem solve, which will lead to frustration and potentially people leaving your team!

Of course, there are some problems when your experience and knowledge are important, but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate and still be involved. Solutions might include kicking off a design session with developers to talk about general approaches, and reviewing progress with the developer on a regular basis to see if things are on track.

As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

2. Find Time to Code

The role is called “Tech Lead” for a reason, and it is essential that you find some time to spend in the codebase. Being involved in the code helps you build respect with the rest of the team, but it also helps keep your knowledge up to date and current with constraints, problems and the “shape” of the current codebase.

If you do not spend time with the code, you run the risk of invoking the “Ivory Tower Architect” anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.

There are many different ways a Tech Lead can find time to code, but it is essential that you make it a priority. This often means making difficult choices about where you spend your time. Tip #1 should help increase the amount of available time you have. I know some Tech Leads who will block out time in their calendar to ensure that there is always time during the week to write or review code with the other developers. I know of other Tech Leads who review commit logs, and provide feedback to developers – similar to a loose pair-programming style.

3. Visualise Your Architecture

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact, but is impossible to prevent if developers do not understand the broader picture.

An effective Tech Lead often has a visual representation of their system architecture on-hand and uses it to have discussions with developers. There will often be different views of the architecture (logical, deployment, etc) and each diagram helps developers see how their task fits into a broader system architecture.

A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture, as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive out your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

4. Spend Time 1-on-1 with Team Members

An effective Tech Lead will not be measured with how many coding tasks they complete. They are measured by how effective their software team is. Anything that a Tech Lead can do to make each person on their team better, makes the overall team better. Sit down with members on your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group. Connect developers with opportunities for them to grow. This means allowing them to take risks so they can learn and grow, but also contribute to the team. Encourage people sharing knowledge across the team and find ways to help each team member connect with each other.

5. Learn to Speak the Language of the Business

To be an effective Tech Lead, you will need a great relationship with people outside of the development team including people like Product Managers, Marketing, Sales and CxOs. They will not understand the vocabulary you accumulated as a developer, and talking to them in terms of frameworks, technical tools and platforms will only confuse them.

An effective Tech Lead finds ways for non-technical people to understand technical concepts, and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms. Use visual models, whiteboard sessions and metaphors to help business people understand technical concepts and their implications. You might rehearse on friends or relatives who don’t work in technology to see if you can succinctly explain an idea.

Minimize the translation layer as much as possible by bringing business terms into the development team and encouraging their use as much as possible. The better the developer team uses these domain terms, the better their understanding and empathy with business stakeholders will be.

Find out more about the experiences of other tech leads in Patrick‘s book ‘Talking with Tech Leads‘. You can download a free sample of the book here.​ Also, don’t miss the author’s post on Three Common Mistakes of the First Time Tech Lead.

Breaking down enterprise microservices implementation tactics.

Containers have captured the imagination of both infrastructure providers and developers: the former because they see containers as a more efficient technology for meting out virtual compute resources, the latter because containers provide the path to building disaggregated, distributed next-generation applications. Decomposing traditional monolithic application designs into their fundamental components promotes code reuse, offers easier, more granular scalability and supports rapid development cycles by decoupling coding, testing and debugging into smaller chunks with fewer dependencies.

Netflix former head of web engineering, Adrian Cockcroft, defines a microservices architecture as: “a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.” However, designing a microservices framework for multiple applications is a non-trivial exercise that involves several architectural decisions. These are just the start of the journey into a microservices-based application portfolio, with recent research from several consultancies detailing the many required steps on the path to enterprise microservices.

are near the peak of inflated expectations which portends looming disillusionment as IT and AppDev practitioners encounter many roadblocks ahead, including a steep learning curve, new deployment platforms, and developer tools and organizational changes required to shift from monolithic to modular applications. Nevertheless, predictions of microservices proliferating across enterprises everywhere persist. Notably, IDC forecasts that “by 2022, 90 percent of all new apps will feature microservices architectures that improve the ability to design, debug, update and leverage third-party code” with 35 percent of production apps being cloud-native designs.

While the number is aggressive, IDC’s rationale is sound — namely, that more modular applications improve development agility and project cycles — even as it guides enterprises to reorganize around a DevOps structure that integrates development and operations teams. However, an organizational structure is merely the foundation for the work ahead since, despite what some product vendors might want you to believe, creating microservices is a redesign and construction project, not a remodeling job.

From monoliths to microservices

A new report by IT consultancy TEKsystems offers some solid advice on making a successful transition from monolithic to disaggregated, i.e. microservice-based, applications. Admittedly the bulk of the report seems targeted to selling executives unsure about embracing the latest IT buzzword, however, practitioners charged with turning a vague executive microservice strategy into useful applications working on production systems will find some valuable tips. My interpretation of the essential steps, which also draws from a pertinent Gartner blog, 4 Steps to Design Microservices for Agile Architecturefollows:

  • Microservice design starts with the cloud system and service ecosystem or in TekSystem’s words “modernization should be holistic.” Because microservices rely on so many infrastructure and platform components, such as container clusters, an API gateway, service registry, service bus and often, public cloud services like serverless functions and IAM directories, implementing a microservice strategy can’t be piecemeal.
  • Identify core application services and dependencies. The goal of microservices is to decouple reusable services from application-specific code. As the image above illustrates, such decoupling necessitates a thorough analysis and understanding of the components comprising one’s application fleet and their dependencies.
  • Design loosely-coupled services. An essential benefit of microservices is the ability to reuse services and thus reduce the new code required for an application and speed development cycles. Such reuse is impossible if services are tightly coupled to one another and/or particular applications. The goal is to produce a library of generic components that provide functions useful to a wide variety of applications. As Gartner points out, the decoupling should extend to the data generated and used by each service, which should be in an independent repository easily accessible by all services.
  • Start small and iterate to produce what TekSystems calls “quick wins” that provide “the minimum viable product that you can optimize to get a proof of concept.” Such humble beginnings will demonstrate the value of a microservice app, enhance the IT/DevOps organization’s confidence in using the architecture and offer opportunities for iterative improvements in features and performance. Big Bang transitions, by multiplying project dependencies and stretching timelines are almost guaranteed to fail.
  • The service-oriented mindset must be comprehensive and include people, processes and technologies. Project teams should be lean and agile like Amazon’s two-pizza teams, with authority to make rapid decisions over the microservices or clearly defined products within their responsibility. Indeed, there is science behind Bezos’ thinking since smaller teams improve communication and minimize meeting overhead. For background, Deloitte has a good overview of the benefits of shifting IT’s orientation from projects to products. According to a TekSystems analyst, “You need to have strong leadership. The decision tree can’t be big and bloated, and the silos can’t be fighting with each other.” Similarly, software development technology should support rapid changes, multiple versions and automated testing, integration and deployment (CI/CD).
  • Don’t get lost in the technology, but keep focused on delivering business value. Microservices are a means to an end, that being the rapid development and evolution of innovative applications, business processes and customer services. A TekSystems consultant adds that “Companies should not only think about improving what they have today, but more importantly, think about what doesn’t exist today.”

Measure the success of both the overall strategy and individual microservices and applications by their contribution to business metrics such as:

  • More revenue
  • Higher customer satisfaction
  • Lower costs
  • Reduced cycle times for new applications, software bug fixes and updates and problem resolution
  • Better overall security with fewer cyber vulnerabilities

My take

We’re still in the early days of enterprise adoption of microservices, but there are already some notable success stories. At Diginomica, Jon Reed recounted the case of how Nuance built a modern apps platform on microservices that can adapt to changing business circumstances.

While not representative of the typical enterprise, the most ardent and early adopters of microservices are in big tech and online services where microservices are embedded in the core infrastructure of all the FAANG companies (Facebook, Amazon, Apple, Netflix, Google). None has been more vocal and public about its use of microservices than Netflix, which made the move from monolithic to modular systems a decade ago. As this retrospective points out, Netflix’s monolithic code was breaking under the strain of explosive growth and the resulting spaghetti code with multiple dependencies meant that one small coding mistake could take its entire site offline for hours.

As an early adopter, Netflix suffered the scars of debugging immature microservice technology and ended up developing an entire microservices software stack that includes modules for service discovery, inter-process and -service communication, service routing, monitoring and security, workload scheduling and distributed configuration management. While the company has encountered many speed bumps along the way, with famous outages causes by inadequate redundancy in its cloud infrastructure at AWS, the result is a set of services that now supports more than 150 million users around the world streaming hundreds of millions of hours per day.

The share of enterprises implementing micro-services is likely still in the single digits, which makes me skeptical of IDC’s 90 percent estimate by 2022 since it implies doubling microservice adoption every year. Whatever the rate, it’s clear that an increasing number of enterprises will implement microservices as the foundation for next-generation applications. While the core technology is much more mature than when Netflix made the switch, with many elements available as managed cloud services, the business strategy, service design and organizational challenges remain. Before IT leaders embark on a microservices program, they are wise to learn from the experiences and advice shared by early adopters.

Posted by: lrrp | October 24, 2019

How To Market Yourself As a Programmer

10 ways to obtain better opportunities for yourself every day

If you’re a full-time programmer at a software company with a career path laid out before you, you may not realize the need to market yourself — but it’s important.

Internal marketing is often as important as external marketing. Every single day, as you are working, you are also marketing this one product: You. You, as a programmer is your product.

Putting your best foot forward will only expand your horizons and lead to those hard-to-obtain opportunities. While everyone’s concerned with technical interviews, you’re seeing the bigger picture.

Where do you want to be in the next 2, 5, and 10 years?

To make it happen, you need to put yourself out there and build your skill stack. But you’ve got to build that stack with mindfulness.

You Are Not a Code Monkey

Anyone can be a code monkey. This is someone who simply writes code without any consideration.

There’s no creativity in being a code monkey. There’s no fun. Instead, as a programmer, you consider the implications for your code in the scope of design, architecture, and functionality. You learn frameworks and apply them. You see patterns and can use computer-science techniques to program with style and efficiency.

In other words, you don’t just get the job done, you get it done well.

You Have a Specialty

Anyone can be a jack of all trades with no thought as to the direction of one’s career. If you are a front-end programmer, a back-end programmer, an AI programmer, or a database guru, who are you as a programmer? At work, do people go to you for special kinds of problems to solve?

Do people look up to you to provide areas of knowledge that you know better than others in your company? This is different from the skillset you put on your resume. It’s the expertise people in your company perceives you to have. It’s based on your experience. It is the unicorn in your resume.

You need to discover your specialty through other people’s eyes and elaborate on that specialty with a vengeance. If you are a Python programmer, what types of Python problems do people at work ask you to solve most frequently? Can these problems be solved by anyone else? What are the key skills that you possess to be able to deal with these types of problems well?

Discovering your unicorn is the same as discovering your gift. Highlight your gift in interviews and on your resume. Make use of it at every opportunity.

You Can Communicate

By communication, I don’t just mean that you can explain things, work with people, and present your ideas. By communication, I mean that you can engage. Everyone has a short attention span these days. It’s much easier if you can engage people and just get to the point.

There are various ways of engaging. Are you eloquent? Do you have a unique sense of humor? Are you profound? Are you rough around the edges? Can you tell a story? Do you have hobbies that show you off as a person?

Often, the best programmers are engaging in many outlets besides their day job. They are engaging at network events, on online forums, in open-source communities, and on blogs.

These programmers are building a brand for themselves by engaging with not just coworkers — but with the world. You can brand your real self with your real skills.

You Can Get the Job Done With a Personality

Everyone wants to work with someone they have fun with. In every project, there comes a time when things are boring and you need a lift. You want a coworker who can crack jokes and have hobbies.

Within the company, people from other departments will remember your name if you had a personality that shined through during project meetings. This is how you become popular within your network of colleagues, acquaintances, and friends.

You may not want popularity. But with popularity comes opportunities that you never thought you’d receive.

You Are Reliable in Times of Trouble

So many technical managers I know want people on their team who are reliable. This is true in any engineering profession. There are too many points of failure.

A programmer who can deliver in times of trouble is truly the golden unicorn of hiring. This is when you can be paid premiums for the skills you have. This is when you can differentiate yourself from the pack.

What do you need on a rescue mission? Discover these skills and practice them. When deadlines are tight, do you pull it together?

When everyone steps away from a problem, can you step forward to solve it?

You Need to Know

I’ve met some extremely talented programmers. These are people who are inspired. By being inspired to know everything, they are inspiring to others around them.

What separates these programmers from the pack is their insatiable curiosity for everything around them. If you give these programmers a research topic, they’ll literally comb through every corner and give you a very detailed analysis. They have intrinsic motivation to learn about anything — not just programming.

You Are Balanced as an Individual

Interestingly, the best programmers I’ve ever met are the ones who didn’t think they were the best at all.

They had this extreme humility about them. They had this sense of wonder about the universe. You can tell they respect the world and its vast knowledge store. They put their own abilities into perspective. They have a healthy mix of imposter syndrome and drive.

They may know they’re good at their jobs, but they don’t think they’re great. They’re always learning and striving.

You Don’t Define Yourself Solely by Your Work

As a programmer, it’s very hard to not define yourself by your work. But a lot of the programmers who don’t burn out easily are the ones who define themselves by other passions in their lives, too.

For instance, a programmer can also be a parent, a student, a teacher, an activist, and a gamer. A programmer can also raise funds for their favorite charities, run a marathon, and paint. A programmer can also be a botanist with a home-based greenhouse lab. A programmer can also be a farmer, a foodie, and a speaker.

What you do in your off time is just as important as what you do at work. How you spend your off time often defines what kind of person you are at work: your creative capacity, your ability to engage in teamwork, and your ability to sell your ideas.

You Work on Self-Improvement As Much As You Work on Interview Questions

As a programmer, it’s easy to get lost in the relentless quest for innovation. But the best programmers I know don’t chase the dream — I mean they barely chase the full stack.

What do they do to get better at what they’re doing? They chase the depth of the skills they currently have. Once they’re satisfied and confident, then they add on breadth as they go. They don’t relentlessly work on interview questions. Instead, they work on projects that’ll teach them new ways of looking at real-world problems.

They’re also focused on living rather than working. They love their work, but they see living a better life as the ultimate goal. They work on that project every day.

You Promote Your Work

We have so many social media outlets. Just pick one. Even if you’re in a chatroom, do people know what you do for a living? If you never reach out and tell people about your day job, then you are not making yourself available to be found.

Often, the best way to get your next job might be through a distant acquaintance, a friend, or an ex-colleague. Tweet what you are working on. Post about your new project on some online programming forums on Quora and Reddit. Share your thoughts about technologies and your programming journey.

Self-promotion is about making friends. The more friends you make, the easier it is for you to get your next job. The more options you have, the easier it is to find the right fit.

ow I’ve given you the motivation to market yourself, so go and be yourself!

You can:

  • Start a blog
  • Join an online programming forum
  • Put together a YouTube channel
  • Help others solve programming problems on various online forums
  • Help connect your programming friends together
  • Mentor other programmers
  • Work on your hobbies
  • Be the go-to person at work
  • Socialize

So many ideas and so little time. Nowadays, there are many programming jobs that are 9-to-5 jobs. With balance, you can improve your life the same way you improve your programming skills.

When you improve your life, you’ll shine very brightly in the eyes of your next employer.

What are you waiting for?

Posted by: lrrp | October 24, 2019

How to Be an Insanely Effective Tech Lead

The first responsibility of a tech lead is to define reality. The last is to say thank you.

I’m sure every developer worth their salt would like to be a tech lead at some point in time. After all, it’s one of the most coveted and influential positions in software development. That said, being a good tech lead is not something everyone is capable of.

Understanding and leading a team of talented developers, from the greenest to the most experienced, is much more than handing out free soda and beer on Friday. In fact, being a tech lead is like being in the dead center of a triangular battlefield in which bullets are being fired at you from all three directions. Your job is not only to dodge the bullets but also to make sure the three sides don’t kill each other (and the project)! You are the only common thread responsible for:

  • Managing the band of developers working with you.
  • Managing the leadership above you: Project managers, senior project managers, architects, etc.
  • Managing the customer by making the right technical decisions at the right time.

That’s why not all software developers can be good tech leads. Imposing a tech lead position on a senior developer just based on experience can be one of the worst decisions management can make.

First and foremost it’s important, to be honest with yourself and understand what drives you. Is it writing code? Is it designing software? Or, is it helping others to get better results, negotiating deadlines with stakeholders, and convincing your business team that code refactoring is not a waste of time?

Your answers will decide whether you would be a good tech lead or a bad one. In the end, it all boils down to leadership. As management guru and author Peter Drucker says:

“Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership.”

Here are some great habits of insanely effective tech leads.

Share Knowledge

“If you have the knowledge, let others light their candles in it.”— Margaret Fuller

From my experience, being good at technology is the most sustainable way to gain respect among your team members. That being said, being good at technology and not sharing your knowledge is a surefire recipe for disaster.

Bad leads refuse to share their knowledge for multiple reasons:

“What if my teammate gets ahead of me?”

“What if they ridicule my knowledge?”

“Why should I share my knowledge? Let them learn the hard way.”

Whatever the reason, the final impact is on the project and team morale, both of which are affected negatively by the lead’s stubborn attitude. Knowledge is half the battle and sharing it is the other half. Your team will have no use for you if you opt to be selfish. Good leads talk to their developers and show them how to solve problems. They not only tell them how to fix the problem but also explain why they fixed it that way.

Don’t get into a situation where the team stops asking you questions. Communication is the lifeline of a successful project.

Know Your Team

“Ingredients to Success: know what you do well, know what to do well, and know someone who’s swelled.”— Criss Jami

Have you ever been to a supermarket and noticed the difference in service when you call the attendant by name, rather than barking “hey you?” In most cases, the service not only improves but you get a genuine smile to boot.

While there are no set rules or project requirements to call people by their first names (in fact, in software-project limbo, people are referred to as resources), getting a bit personal at work is required as part of our journey as Homo sapiens. We‘re humans, we have names, and we’re unique.

Good tech leads to establish an informal mode of communication, along with formal rules, so that people can talk about their problems. Then, the tech lead gets to hear about them before they get worse. For example, knowing a person is about to quit two days before, as opposed to two months, makes a big difference.

You don’t have to like your co-workers, but you at least need to know them. Knowing developers’ abilities and limitations, combined with knowing what they are interested in, will make you plan your development in a better way.

Admit You Don’t Know Everything

“People who think they know everything are a great annoyance to those of us who do.”— Isaac Asimov

We all know that “with great power comes great responsibility.” But the flip side of power is corruption. If you want to know the real nature of a person, give them a little power and see if they misuse it. Bad team leads misuse the power they have over their teams.

You’re probably a technical whiz kid, but even you will not know everything about your technology. It’s practically impossible. On the other hand, the greenest kid in the room might come up with a sustainable, performance-effective solution to the problem at hand. Good tech leads don’t impose their solutions on the team. Rather they cultivate a sort of democracy in which the best solution wins.

Bad leads, on the other hand, assume they always know more than their developers. They come across as overconfident, domineering types who want it done their way, even if their way is wrong. They don’t like reasoning, because most of the time they are unreasonable.

Remember, as a tech lead, your job is to make sure everyone contributes their best to the project, not simply obeys their boss.

Don’t Be a Pushover

In contrast to the “I-know-everything” type, the pushover can’t make up their minds. No new feature is too insignificant for consensus and debate. And no project kicks off without a painful, exhaustive discussion of requirements, considering the opinions of everybody in the team.

Remember, for projects to function, tech leads need to make the right decision at the right time. There will be tradeoffs involved. Not everybody will be happy, but that’s what’s required in the best interest of the project and customer. It’s easy to think that people will like you more if you do whatever they want, but in fact, it’s quite the opposite. People don’t appreciate pushovers — they use them.

I’m not telling you to stop consulting the team. It’s always a great idea to keep the team involved in the decision-making process. But there will be times when the discussion needs to cease and decisions have to be made. These are the times a good tech lead needs to take control and stand out.

Don’t Bend Under Pressure

Remember the triangular battlefield we spoke about earlier? Bad tech leads get overwhelmed by pressure and do the wrong things.

The code is like food. It can be fast, good, or cheap. Pick any two. A tech lead overwhelmed by pressure tries to get the team to do all three things at once. They give little notice for urgent requests and rarely want to talk about what it actually takes to create software that does its job. They’re driven by deadlines and commitments made by somebody else, and the team beneath them bears the brunt.

Remember, as a tech lead, you always have two choices — your commitment versus your fear. Your commitment is the date and deadline given to you to complete your work. The most important thing you have is your word, your trust. You have to make it happen, come what may. That’s where you earn respect. You experience fear when someone else makes a commitment on your behalf.

“You can’t make decisions based on fear and the possibility of what might happen.”— Michelle Obama

A good tech lead is all about “getting real,” and communicating that reality to all stakeholders up and down the chain. If that locker functionality will take two weeks—it’ll take two weeks. If the archiving feature isn’t available in the software, it’s not available. Simple as that! They don’t hide anything or set unrealistic expectations.

Remember, being a good tech lead is not about making perfect decisions. It’s more about giving better explanations supporting the decisions you make. You don’t need to make the right decision 100% of the time. But you need to make decisions—which are at least 80% right—and stand by them, come what may.

Posted by: lrrp | October 23, 2019

At least they use Raspberry Pi….

Posted by: lrrp | October 23, 2019

As a programmer, this resonates with me

Posted by: lrrp | October 23, 2019

User Experience (UX) vs. Customer Experience (CX)

Good digital UX gives a user/customer the ability to:
-Find information on a website quickly and easily
-Complete the desired task with ease
-Search Web pages with ease

Good CX gives a user/customer the ability to:
-Have a pleasant, professional, helpful interaction with organization/company representatives
-Feel generally positive about the overall experience with that organization/company and everything associated with it.

Posted by: lrrp | June 13, 2019

Approach to Every task….

Posted by: lrrp | January 18, 2019

If you don´t know how to program…..

Older Posts »

Categories