patkua@work

The intersection of technology and leadership

Category: Tech Leadership (page 1 of 4)

6 Lessons Learned in my year as CTO at N26

Life has been a bit of a whirlwind trip in the last year. I moved cities (London to Berlin). I started a new role as a CTO. I transitioned from 14 years of consulting into a management role. I joined the hyper-growth startup, N26 – the mobile bank the world loves to use.   It’s been exciting to particularly see the company growth. Our customer base has grown from 500K+ users to more than 1 million. Our users transact more than €1B in currency. We’ve expanded our offices from Berlin to New York. We also announced moving to Barcelona and this is only the beginning. 

In this blog entry, I will share my personal lessons learned on the rollercoaster ride from this year. 

1. Management overlaps with leadership, but is different

Over the almost 14 years of consulting, I spoke all the time about leadership. I still believe that anyone can be a leader. Leading is less about a title, and more about how you act. In my role, I also better appreciate the important role of effective manager. Google even proved that effective management matters.

I still think great managers are also great leaders. We try to test for this at N26 during our interviewing process. We hold our managers accountable for having difficult conversations. We want them to be kind, not only nice.  We want managers to nurture an environment of candid feedback. Great managers manage things and lead people. Managers, unlike coaches or consultants are also held accountable for this. 

2. Hypergrowth stretches everyone

I’ve definitely grown over this year. Our company has also grown rapidly (both with users and people). Hypergrowth means people have opportunities for new tasks. We are also not the first company to experience this. The community has been very generous with sharing their knowledge. I will contribute more to this in the future too, as I build on lessons learned.

I have found myself repeating, “The company will grow much faster than people.” 

With this in mind, I have tried to support, develop and grow as many people as possible. At the same time, I’ve focused on bringing in new skills and experiences that we need. Combining a learning workforce with experienced people is tremendously powerful.

3. Really underscore the Why, not just the What

I believe very much in Simon Sinek’s “Start with Why.” A group of brilliant, collaborative problem solvers will end up with a better idea if they understand why.  You can, of course, still give your input. Your role as a leader it to explain the context. Or to clarify the goal or problem. Not just the solution.

I’ve seen too many technical debates fail because they first didn’t agree on the problem. Agree on why, then move on to what. 

In a fast moving startup, I found people underrate listening. Listening and asking questions are my most powerful tools as a leader.

4. Investing in people has exponential returns

I always try to be generous with my knowledge and experience. I’ve particularly enjoyed helping people grow. Sometimes it’s required tough, candid conversations. Effective feedback helps people grow. Coaching and training helps people see potential they don’t see. It’s been wonderful to help people discover, test and practice tools that make them more successful. 

I’m proud of N26’s technical leaders (both formal and informal). I’m impressed with how people have rapidly grown. I’m also impressed with what they do to pass it on.

5. What got you here, won’t get you there

I read the book, “What got you here, won’t get you there” many years ago. It’s message resonated with me during this year. Startups often go through several phases, “Start Up, Scale up, and Optimise” is how I like to think of it. We are definitely in the Scale Up phase. This phase demands different thinking. 

Acting as if we were in the Start Up phase no longer scales. It’s an educational journey for many people. At scale, you can no longer manage every single situation. At scale, you can no longer make all the decisions. At scale, you have to decide on where you will have the greatest impact. At scale (as a manager), you make less, and need to focus on multiplying more. 

6. Focus on Capabilities, not just People

In Hypergrowth, it’s too easy to hire lots of people. I am wary of this after reading the Mythical Man Month many many years ago. As a manager, I first focus on understanding what capabilities we need. I also think about how those capabilities are best met. Be clear on what you need before hiring people. 

Focusing on what you need helps you find the right people. It also helps those people be clear about how they will be successful. 

Conclusion

I have learned many other lessons in this year as a CTO. The six lessons above reflect some of the major themes for this past year that I hope you many learn from.

I’m super proud of the people I work with. I’m super proud of the product we produce. It’s been a great ride so far, and it’s only the beginning of the journey.


Thanks Jerry Weinberg

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind. 

Three Common Mistakes of the First Time Tech Lead

The first time a developer steps into the role of a Tech Lead can be difficult. The skills and experience of a seasoned developer do not automatically translate into the skills necessary for the Tech Lead role. In fact, some of the habits of a developer can do more harm than good, when not applied well and with more authority in this new role.

3 mistakes

In this article, we explore three common traps a first time Tech Lead experiences, and what they can do to avoid them.

1. Coding Full-Time

A first time Tech Lead will miss writing code. In fact, it is easy for them to assume that they need to demonstrate their leadership by writing code all the time. Although effective Tech Leads need to spend some time writing, reading and reviewing code, other responsibilities are left unfulfilled when they spend too much time writing code, – such as creating a technical vision and ensuring that the team understands key system quality attributes.

A lack of technical vision might lead to three different implementations, as developers make decisions individually about what they feel is best, or a deployment might fail because developers are not aware of operational constraints or environmental differences in production. Worse yet is when the code must constantly be reworked because a developer chooses to do something differently without considering maintenance, or how the system may evolve over time.

The more experienced Tech Lead understands that they must balance their time to code with other responsibilities. They split their time daily, or at the very least weekly, to ensure that they spend time addressing other responsibilities including building a shared architectural vision, identifying and addressing technical risks, being involved in planning sessions and focusing on team and code cohesiveness and consistency.

2. Making all the Technical Decisions

A first time Tech Lead may sometimes be the most experienced developer on the team, or feel the pressure to make all the technical decisions to demonstrate their authority or influence. When a Tech Lead is making all the technical decisions, they become a bottleneck in the team and the team cannot progress when the Tech Lead is not around. Other team members might feel demotivated when the Tech Lead makes all the important decisions, because their contributions are overruled and this could lead to resentment.

The more experienced Tech Lead realizes there are different ways of making decisions, and often, the best decision comes from using the breadth of experience and knowledge from the entire team. They might draw upon the following techniques, depending on how critical a decision is, how quick a decision must be made and how much commitment they want from team members:

  • Only delegating – A Tech Lead gives the decision to someone else without any other interaction
  • Offering advice – A Tech Lead delegates the decision to someone else, but offers their input and opinions for consideration
  • Inquiring – A Tech Lead delegates the decision to someone else, but inquires about the outcome and factors that led to the decision afterwards
  • Building consensus – They bring all team members together to find a solution that everyone is happy with
  • Consulting with the team – They invite opinions from team members, synthesise the information, but ultimately make the final decision
  • Being autocratic – They use the information they have to make a decision, choosing to involve or not involve team members, but inform everyone about the outcome.

3. Forgetting about Cultivating Team Culture

A team is a group of people working together towards the same goal. The first time Tech Lead might mistakenly see their role leading on all the technical aspects and forget about how the team works together. Although this responsibility may be shared with other roles such as the Team Lead or Project Manager, a Tech Lead must also shepherd the team to move in the same technical direction.

It is all too easy for the first time Tech Lead to ignore heated discussions between two developers, or to ignore how technical team members interact poorly with or disrespect non-technical team members.

The more experienced Tech Lead realizes that the lead part of their role is just as important as the tech, and constantly looks for ways to build trust and relationships between people in the team. They use practices like white-boarding architectural diagrams as a team, establishing coding or architectural principles with the team to guide individual decisions or running regular improvement katas or retrospectives.

Conclusion

The first time Tech Lead can easily fall for a number of traps, often caused by habits developed from their time as a developer. To overcome these traps, they must find ways to strike a balance between their technical and leadership responsibilities.

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.

Tech Lead Dilemma

I present 5 tips for being an effective Tech Lead.

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.

This is a repost of an old blog post I published while I worked at ThoughtWorks and wanted to recapture it here. See the original here.

Starting as CTO at N26

I’m excited to announce that I’ll be taking on the Chief Technology Officer (CTO) role for N26 (formerly Number26), Europe’s first mobile bank with a full European banking license, and who is setting new standards in banking.

I’m joining an exciting and talented team based in Berlin, Germany – one of the favourite start-up cities in Europe. In my new role, I’ll draw upon more than a decade of my consulting experiences with the well-respected and industry-changing technology firm, ThoughtWorks – best known for leading the adoption of agile ways of working (particularly its technical practices), publishing open-source software like CruiseControl (the first widely used Continuous Integration servers) and Selenium (well-known automated web-testing tools), and sharing ideas through books like Continuous Delivery and the Lean Enterprise. I’m really looking forward to applying my experiences guiding organisational design, building evolutionary architectures, developing technical leaders all while sustainably delivering value for our customers.

What will be different?

After many years as a consultant, I realise that working with a product organisation is a different beast. I look forward to having some responsibility to instigate and guide changes throughout the organisation and living out the long-term consequences (both good and bad!) of my actions. I know that this is often a missing feedback loop for consulting. In my role, I’ll be able to invest more in challenging and growing people and building out new technical and organisational capabilities.

I also look forward to spending a bit more time “at home”. I still expect to travel for my new role, still speak at some conferences but I hope I will have a bit more say as to when and where I’ll travel to, based on our business needs rather than where clients happen to be based. Did I mention that I’ll also be based in Berlin, and it’s a great city with a very good balanced lifestyle? I might even get a chance to further develop my German again.

Why FinTech and N26?

As a consultant, I was always skeptical about having significant long-term impact on established financial companies. With teams, or parts or the organisations, yes. With a 10,000+ person company, less so. The exciting part about working with N26 is that I will work with a strong management team to prevent unnecessary bureaucracy and to let people focus on adding value to the product and organisation. We benefit from not supporting certain types of legacy, and building software with Continuous Delivery and modern technologies first. I’ll be helping guide us away from the traps and pitfalls I have seen many customers suffer from in the last decade.

The N26 Black Card

I also like the fact that N26 is growing fast, and has already proven to meet customer needs, where all growth has been organic so far with very little advertising. Did you know that we recently hit 500,000 customers (PDF)? It’s also one of the first mobile-first startup banks with a European banking licence, which opens up a world of opportunity that a lot of other FinTech banking products do not yet have.

Here’s what TechCrunch wrote two years ago:

N26 (Number26) could be the best banking experience in europe – Tech Crunch

Bank of the future

In case you can’t tell, I’m really delighted to be leading the technology organisation behind the bank of the future. The team has already accomplished a lot so far, and I look forward to working with the team to do even more. We’re going to build an exciting place to work in the FinTech sector and have a huge impact on our ever-growing customer base across Europe. If you’d like to be a part of the N26 team and join me on this journey, did I mention that we are hiring?

Drop me a line on twitter @patkua (DM’s open), or on my email address if you’re even curious. Berlin’s a great city to live and N26 is a great place to work while you’re there.

Reflecting on the Tech Lead Skills for Developers Course in Brazil

Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.

The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.

One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.

I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.

I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.

You may not need a Tech Lead, but others do

Vinicius sent me a tweet about an article he published called We don’t need a Tech Lead in response to an older article of mine, “Do we need a Tech Lead?”

I wanted to respond earlier, but tweets were too restrictive. Here’s my response.

The argument against Tech Leads

The article rebuts the necessity for a Tech Lead with the following points (emphasis author’s, not mine):

  1. Well functioning teams in which people share responsibilities are not rare.
  2. When a team is not functioning well, assigning a tech lead can potentially make it worse.

There are many great points in the article. Some of the points I support such as how sharing responsibilities (also known as effective delegation). Distributing responsibilities can be one way effective teams work. Other points lack essential context such as the title (it depends), while other points lack concrete answers such as how to turn a dysfunctional team into a highly performing team.

Are well-functioning teams rare?

I’ve worked with at least 30 organisations over my career as a consultant, and countless teams, both as a team member (sometimes Tech Lead) and as an observer. I have seen the whole spectrum – from teams who function like a single person/unit to teams with people who simply tolerate sitting next to each other, and where one can’t miss the passive-aggressive behaviours or snide remarks.

The article claims:

that the “tech lead is a workaround – not a root cause solution

and

Tech leads could alleviate the consequences only

Unfortunately the article doesn’t explain how or why the tech lead is a workaround, nor how tech leads alleviate just the consequences.

The article gathered some discussion on Hackernews, and I found some comments particularly interesting.

Let’s take a sample:

  • (gohrt) Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
  • (vidhar) …we live in reality where lots of teams are not well-functioning some or all of the time, and we still need to get things done even when we don’t have the time, resources or influence to fix the team composition then and there.
  • (ep103) If I had an entire team of my great engineers, my job would be easy. I’d simply delegate my duties to everyone else, and we’d all be nearly equal. I’m jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.
  • (shandor) My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (EDIT: i.e. tech lead responsibilities)
  • (doctor_fact) I have worked on teams of highly competent developers where there was no tech lead. They failed badly…
  • (mattsmith321) It’s been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions.
  • (jt2190) I’ve been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted… These teams (if they can be called that) produced software that had little to no overall design.

Do these sound like well-functioning teams to you? They don’t to me.

Office Fight

Image from David Trawin’s Flickr stream under the Creative Commons licence

Well-functioning teams do exist. However it is clear that not all teams are well-functioning. In my experience, I would even say that really well-functioning teams are less common than dysfunctional, or just functioning teams. For me, the comments are proof enough that well-functioning teams are not everywhere.

It is actually irrelevant if well-performing teams are rare – there are teams that definitely need help! Which leads to the question…

Does assigning a tech lead to a poorly functioning team make it worse?

In my talk, What I wish I knew as a first time Tech Lead, I explain how acts of leadership are amplifiers (can be good or bad). Therefore assigning a bad tech lead to a poorly functioning team will probably make it worse. However I don’t think organisations set out to give teams bad tech leads.

If a team is poorly functioning, what do organisations do? Simply leave the team to stew in its own juices until things are resolved? That’s one option. Doing nothing is a gamble – you depend on someone in the team to take an act of leadership but the question is will they? I’ve seen many teams never resolve the very issues that make them poorly functioning without some form external intervention or assistance.

Most organisations try to solve this by introducing a role who has some authority. It doesn’t necessarily need to be a Tech Lead, but when the core issues are technical in nature, a good Tech Lead can help. A good leader will seek out the core issues that prevent good teamwork, and use their role to find ways to move them towards a well-functioning team. Sometimes this may mean calling meetings, even if the team do not want to have meetings to reach an agreement about how the team handles certain situations, tasks or responsibilities. A good outcome might be an agreed Team Charter or some clarity about who in the team is responsible for what. A team may end up with a model that looks like they do not need a Tech Lead, but it takes an act of leadership to to make that happen.

The wrong analysis?

The article suggests that a full-time Tech Lead introduces risks such as a lack of collective code ownership, decision-making bottlenecks, a single point bus factor, and (reduced) impact on motivation. I have seen teams with and without Tech Leads both suffering from these issues. In my experience, teams without a Tech Lead tend to have more issues with knowledge silos, no cohesive view and less collective code ownership because there is little motivation to optimise for the group and individuals end up optimising for themselves.

The issue is not caused by whether or not teams have a Tech Lead. Rather, these issues are caused by a lack of a technical leadership (behaviour). The Tech Lead role is not a prerequisite for having technical leadership. I have seen teams where strong, passionate individuals will speak up, bring the team together and address these issues – which are acts of leadership. I have also seen dysfunctional teams sit on their hands because individual (job) safety is an issue and these issues go unaddressed.

My conclusion

The article misses the subtle but important point of good technical leadership. A good leader and Tech Lead is not trying to own all of the responsibilities – they are there to make sure they happen. There is nothing worse than expecting everyone is responsible for a task, only to find that no one is responsible for it.

“The greatest leader is not necessarily the one who does the greatest things. (They) are the one that gets the people to do the greatest things.” – Ronald Reagan

The extent to how much individuals in a team can own these responsibilities is a function of the individuals’ interests, skills and experience. It depends!

Asking whether or not teams need a Tech Lead is the wrong question. Better questions to ask include what’s the best way to make sure all of the Tech Lead responsibilities are fulfilled, and what style of leadership does this team need right now.

The Well Rounded Architect

In this blog post, I explore the six different dimensions I covered in my recent talk at the O’Reilly Software Architecture conference in London called “The Well Rounded Architect.”

The elements of the well-rounded architect

The Well Rounded Architect

Acting as a Leader

Good software architects understand that their role as a leader is not necessarily telling developers what to do. Rather, good architects act like a guide, shepherding a team of developers towards the same technical vision drawing upon leadership skills such as story-telling, influencing, navigating conflict and building trust with individuals to turn their architectural vision into reality.

A good leader, and thus, a good architect, will listen carefully to the opinions of each contributor, fine-tuning their vision with feedback from the team. This leads well onto the next point.

Being a developer

Making good architectural choices is a function of balancing an ideal target architectural state with the current state of a software system. As an example, there is no sense in adding a document database to a system if the problem domain is better suited for a relational database, even if that’s boring. An architect may feel tempted to impose technologies or architectural choices without considering the fit for the problem space – AKA behaviours of the “ivory tower architect.”

The best way an architect can mitigate this is by spending time with developers and time in the code. Understanding how the system has been built up, and the constraints of the system as it stands today will give the architect more information about the right choices for today’s environment.

Having a systems focus

Seasoned developers know that code is only one aspect to working software. To make code run, a seasoned developer understands there are other important quality attributes necessary for code to run well in its production environment. They consider aspects like deployment processes, automated testing, performance, security, and supportability. Where developers may approach these quality attributes ad hoc, an architect will focus on understanding not just the code but also the quality attributes necessary to meet the many needs of different stakeholders such as support, security, and operations staff.

The good architect focuses on finding solutions that can satisfy as many of these different stakeholder needs instead of choosing a tool or approach optimised for the preferences or style of a single contributor.

Thinking like an entrepreneur

All technology choices have costs and benefits, and a good architect will consider new technology choices from both perspectives. Successful entrepreneurs are willing to take risks, but seek ways to learn quickly and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short- and long-term costs and the likely benefits they will realise.

A good example is when the architect avoids committing to a new tool based on reading a new article, or having heard about it at a conference. Instead they seek to understand how relevant the tool is in their environment by running an architectural spike to gather more information. They don’t pick a tool based on how good the sales pitch is, but what value it offers, given what they need for their system. They also look for the hidden costs of tools such as how well is a tool supported (e.g. level of documentation, community adoption), how much lock-in the tool brings or the extra risks it introduces over the long-term.

Balancing strategic with tactical thinking

A lot of teams build their software reactively with individual developers choosing tools and technologies that they are most comfortable with, or have the most experience with.

The good architect keeps an eye out for what newer technologies, tools or approaches might be useful but does not necessarily draw upon them immediately. Technology adoption requires a considered approach looking at a long-term horizon. Architects will seek for a good balance between agility (allowing the team to move fast) and alignment (keeping enough consistency) at both a team and organisational level.

An exercise like the Build your own Tech Radar is a useful tool to explore technologies with strategy in mind.

Communicating well

Architects know that effective communication is a key skill for building trust and influencing people outside of the team. They know that different groups of people use different vocabulary and that using the technical terms and descriptions with business people makes communication more difficult. Instead of talking about patterns, tools and programming concepts, the architect uses words their audience will be familiar with. Communicating technical choices to business people with words like risk, return, costs, and benefits will serve an architect better than the words they use with their development team.

An architect also realises that communicating within the team is just as important as outside, and will use diagrams and group discussions to establish and refine the technical vision, and use a written log like an Architectural Decision Log or a wiki to provide a historical trail for future generations.

Conclusion

Doing the job of a well-rounded architect is not easy. There are so many elements to focus us, each drawing upon many skills that a developer often doesn’t focus on practicing. What is most important is not necessarily the ability an architect has, but that they have enough expertise in each of these different areas to be effective. An architect who is skillful in only one of these six areas described above will not be as effective as an architect who has a good level of expertise in all of them.

Panel for Tech Leads: “Navigating Difficult Situations”

I recently moderated a panel in our London ThoughtWorks office aimed at developers leading technnical teams as a follow up from the Lead Developer conference.

Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.

This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.

Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.

Tech Lead Panellists

The panelists shared their experiences around situations like:

  • Having a tough conversation with a team member or customer;
  • Sharing how they have dealt with overtime (weekends, later work);
  • How they resolved a technical disagreement within a team; and
  • Handling a particularly aggressive person, or being aggressively threatened;

The audience also threw in a few questions like:

  • Dealing with office politics;
  • Finding access to key influencers/stakeholders;
  • Where you draw the line with a person on a team; and
  • Dealing with a technical stakeholder who is too involved, because they seem to have too much time;

We also had some great sound bites in relation to the topics being discussed.

To deal with angry people:

Be the adult – Laura Paterson

or just:

Let them vent – Jon Barber

Managing stakeholders is hard, and you sometimes need to take a stance:

It’s easy to say no – Priya Samuel

People in teams need feedback to both strengthen confidence and improve effectiveness. However:

Frank feedback is really hard. Give the person a chance. – Mike Gardiner

Lastly when thinking about people and teams:

Have empathy. Pairing is scary & exhausting – Kornelis (Korny) Sietsma

I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.

Workshop outputs from “How Architects nurture Technical Excellence”

Workshop background

Earlier this week, I ran a workshop at the first ever Agile Europe conference organised by the Agile Alliance in Gdansk, Poland. As described in the abstract:

Architects and architecture are often considered dirty words in the agile world, yet the Architect role and architectural thinking are essential amplifiers for technical excellence, which enable software agility.

In this workshop, we will explore different ways that teams achieve Technical Excellence and explore different tools and approaches that Architects use to successfully influence Technical Excellence.

During the workshop, the participants explored:

  • What are some examples of Technical Excellence?
  • How does one define Technical Excellence?
  • Explored the role of the Architect in agile environments
  • Understood the broader responsibilities of an Architect working in agile environments
  • Focused on specific behaviours and responsibilities of an Architect that help/hinder Technical Excellence

What follows are the results of the collective experiences of the workshop participants during Agile Europe 2016.

Examples of Technical Excellence

  • A set of coding conventions & standards that are shared, discussed, abided by by the team
  • Introducing more formal code reviews worked wonders, code quality enabled by code reviews, user testing and coding standards, Peer code review process
  • Software modeling with UML
  • First time we’ve used in memory search index to solve severe performance RDBMS problems
  • If scrum is used, a good technical Definition of Done (DoD) is visible and applied
  • Shared APIs for internal and external consumers
  • Introducing ‘no estimates’ approach and delivering software/features well enough to be allowed to continue with it
  • Microservice architecture with docker
  • Team spirit
  • Listening to others (not! my idea is the best)
  • Keeping a project/software alive and used in prod through excellence customer support (most exclusively)
  • “The art must not suffer” as attitude in the team
  • Thinking wide!
  • Dev engineering into requirements
  • Problems clearly and explicitly reported (e.g. Toyota)
  • Using most recent libraries and ability to upgrade
  • Right tools for the job
  • Frequent availability of “something” working (like a daily build that may be incomplete functionality, but in principle works)
  • Specification by example
  • Setting up technical environment for new software, new team members quickly introduced to the project (clean, straightforward set up)
  • Conscious pursuit of Technical Excellence by the team through this being discussed in retros and elsewhere
  • Driver for a device executed on the device
  • Continuous learning (discover new tech), methodologies
  • Automatic deployment, DevOps tools use CI, CD, UT with TDD methodology, First implementation of CD in 2011 in the project I worked on, Multi-layered CI grid, CI env for all services, Continuous Integration and Delivery (daily use tools to support them), Continuous Integration, great CI
  • Measure quality (static analysis, test coverage), static code analysis integrated into IDE
  • Fail fast approach, feedback loop
  • Shader stats (statistical approach to compiler efficiency)
  • Lock less multithreaded scheduling algorithm
  • Heuristic algorithm for multi threaded attributes deduction
  • It is easy to extend the product without modifying everything, modularity of codebase
  • Learn how to use something complex (in depth)
  • Reuse over reinvention/reengineering
  • Ability to predict how a given solution will work/consequences
  • Good work with small effort (efficiency)
  • Simple design over all in one, it’s simple to understand what that technology really does, architecture of the product fits on whiteboard 🙂
  • Systems’ architecture matches team/org structure
  • Self organisation
  • Ideally separated tests, Automated performance testing, automatic front end functional testing with selenium, unit testing done for the first time 10 years ago, constructing new performance testing cases takes minutes, after refactoring unit tests are passing (majority of them – hopefully all!)
  • Constant curiosity for new technologies/approaches
  • Good knowledge of software patterns (when to use and when not)
  • Learn from mistakes

Examples of Technical Excellence

Definition of Technical Excellence

  • (Technical) Excellence is an attitude to be better than yesterday
  • Technical Excellence is the holy grail that inspires teams to stay on the path of continued improvement
  • Technical Excellence is a process that continuously improves product design and the development team. Examples: Automation, knowledge sharing, culture. Synonyms: Dream
  • Technical Excellence is an ability to consciously apply tools and practices to solve and continuously improve over complex problems in a sustainable way and within constraints (e.g. time and money). Examples: Continuous Delivery

Definition

Activities of an architect

  • Explains decisions
  • Able to choose the right solution amongst many possibilities (awareness of consequences and limitations)
  • Being able to justify technical decisions made
  • Thinking (find time to think about the product, structure, technologies used, etc)
  • Helps resolve interdependencies, helps to identify/minimise external noise (i.e. technical dependency change with negative impact), co-ordination of integration with other teams working on the same project
  • Start and moderate discussions on design, longer term consequences of decisions, etc
  • Requirements definition, making sure ‘nothing’ is omitted during analysis/design
  • Questions decisions to encourage thinking about wider picture amongst developers, asks questions (non obvious especially), Asking difficult questions about work being done
  • Listens to others
  • Encourage people to bring ideas, encourage idea sharing
  • Setup backlog for achieving technical excellence
  • Challenge old decisions
  • Business decision support (IT, 3rd party)
  • Make sure we don’t bite more than we can chew – incrementally/iterative
  • Ensure architecture is visible, understood and accessible to the team, keep the technical cohesion, helps team consider the bigger picture and interdependencies, helps team define the system and diagram it
  • Detailed knowledge of technologies/protocols used
  • Forward thinking
  • Proposes solutions to complex problems
  • Diagrams/presentations
  • Wide view of situation/projects, look what other teams are building for things to reuse or interface to
  • “Main” test scenarios definition
  • Definition of components structure and interactions
  • Guard technical vision (dialogue with stakeholders)
  • Focus on project goal
  • API specification
  • Verification of current design vs planned use
  • Ad hoc just in time consulting to feature teams when things get complex
  • Teaching teams, sharing technical knowledge (and expertise) with the team
  • Coaches team. Gets buy-in from the team for change they are about to trigger, coaches dev team
  • Identifies technical skillset gaps in the team
  • Pro-active thinking
  • Gaps identification
  • Mitigates the risks
  • Out of box ideas
  • Research for solution, helps team identify areas for experimenting, exploring new territories
  • Creating proof of concept (POC)
  • Learns new things, research and try new tools, ideas, technologies, etc
  • Gains an in-depth understanding of a system before attempting to change it
  • Reviews teams’ system design, performs code reviews and coding standard support, reviews code

Architect Activities

Architect Activities

Behaviours that support Technical Excellence

Active

  • Gives team rapid and timely feedback
  • Patiently explaining all the tiny details responding to simple questions
  • Be there whenever needed
  • be the safety net whenever devs need you
  • Set communication for knowledge sharing
  • Explain the reasons behind the design
  • Raising the visibility of good developers
  • Do pair programming, works with the team
  • Explain technical excellence value for business
  • Encourage team to think and work towards Technical Excellence
  • Growing people, mentoring developers to improve tech skills, training the team, educate actively – organise coding dojos, etc
  • Set up backlog for achieving Technical Excellence
  • Raising the team spirit and motivation
  • Waking up with 3am to connect with a team on a daily basis (for a distributed team)
  • Discussing discovered problems with the team
  • Sat down with the team to teach and record architecture training for future use
  • Keeping an eye on new things on the market and bringing them to the team
  • Staying current in technologies, tools, concepts, etc.
  • Being a visible role model in terms of pursuing Technical Excellence
  • Encourages experimentation
  • Support team in collaboration with other teams
  • Helps team identify blindspots
  • Active Encouragement

    Passive

  • ability to change contexts between projects
  • Lets the team make decisions
  • Take a step back and make room for technical advancements of the whole team
  • Not doing stuff from actively discourage column
  • Team makes decisions
  • Passive Encouragement

    Behaviours that discourage Technical Excellence

    Active

  • Dictatorship, have to do it my way, will to control (every small detail)
  • Blaming and shaming
  • Making arbitrary decisions, especially without explaining the reasoning behind it
  • Rejecting too complex C++ code
  • Using ambiguous, complex, uncertain English vocabulary
  • Shutting down emergent ideas from the team
  • Discouraging ideas “I couldn’t care less about your sophisticated C++ SPT initialisation”
  • Created ugly prototype for a demo and forced team to clean up afterwards
  • Imposing BDUF (Big Design Up Front) over the development team
  • Created non-viable design (i.e. could not be implemented with current constraints)
  • Enforcing old known technologies, etc out of inertia/ignorance, sticking to the “old ways”
  • Active Discouragement

    Passive

  • Doing too many activities to follow through – not focused on any (and no time to encourage Technical Excellence)
  • Invited but never attended meetings
  • “I don’t meet with the Architect”
  • Software Architect with poor development skills
  • Not working with the team
  • Leaving obsolete information in documentation
  • Getting involved in design only if prompted
  • “I don’t know how, so I won’t define it”
  • Passive Discouragement

    Stories

  • Developers supporting software (getting email feedback)
  • Anti-Story: “Let’s *NOT* sit together” – Person leaving showed them how it was done
  • “Let’s sit down together” (solving a memory leak problem)
  • Group Problem (Security problem)
  • Stories

    If you liked this article, 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.

    Older posts

    © 2018 patkua@work

    Theme by Anders NorenUp ↑