patkua@work

The intersection of technology and leadership

Page 4 of 53

5 Tips for Being an Effective Tech Lead

February 26, 2018 / / 2 Comments

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.

Walled gardens, open source and why I never publish posts to LinkedIn

January 21, 2018 / / 3 Comments

Whether or not you like LinkedIn or not, it seems to have won the “social network” for professional contacts. This post isn’t so much about LinkedIn, but about some of the well-known tricks to keep people attached to a platform. These techniques are also used heavily by companies such as King Games, Facebook and Snapchat. If you work in tech, I ask you to consider where you post your personal content and what that means for all of us.

Even LinkedIn acknowledges it’s own Authentication “Wall”

Before I go on, I want to share a short trip based on my own personal history.

The growth of the open internet

When I first started working in the industry, J2EE was the new “hype” and people were still using CVS. Email was fairly common, although many were through proprietary platforms (remember Lotus Notes anyone)? Since then, the Internet exploded in popularity bringing with it many open platforms for sharing information and knowledge. You will have benefited from this generosity of knowledge. StackOverflow is now a ubiquitous, open, resource that provides invaluable knowledge for people in tech. Platforms such as WordPress enable anyone to share their views or experiences with the world and this is what is so special about the openness for the Internet. Wikipedia is richer than any Encyclopedia Britannica could have been.

The rise of open-source

One of my first jobs working in tech was working as an intern with Bell Labs. I worked on a perl-based testing system that allowed people to run test scenarios on multiplexers and hardware located within a telephone switch. I remember really clearly how everything was written in-house. You needed a logging library, you’d write it yourself. You needed an error reporter, there was an in-house custom built solution for that.

Since then, the world has really changed. Open source has changed the way that we develop. We literally build on the work of previous generations. We compose libraries and frameworks to focus on what our business problem is, instead of rebuilding common utilities again and again.

Stay a responsible web citizen and keep your content open

If you are in technology, you have benefited from the openness of the internet. Avoid posting your public content to walled gardens such as Facebook, PInterest or LinkedIn which require users to login *before* they read the content. Be a good web citizen and keep your public content open. I will continue to do so (by posting to this blog) and I hope you will too.

Three tips to become a public speaker

December 27, 2017 / / 0 Comments

I am grateful that I have had a chance to do a lot of public speaking. Speaking at conferences and user groups has many benefits: You meet new people, you are introduced to different ideas, you often get to visit new places, and share your own ideas and experiences. I am particularly thankful for many wonderful memories where people have come up to me, sometimes years later, to mention they saw a talk of mine and thanked me for sharing my knowledge and experiences.

Over the years, I have also helped many people with their own personal journey of speaking at conferences or events. I found myself repeating several tips that, in this blog, I want to share with you.

1. You have something to say

People early on in their speaking journey often throw this statement up as their first mental hurdle:

“I have nothing to say”

What’s fascinating about this statement is the assumption that everyone has heard and learned everything there is in our industry. Considering that the technology industry is constantly evolving with its tools, platforms, languages and practices, there will always be someone who hasn’t been exposed to some idea or some experience. Everyday there are more and more people coming into technology, each with a different background, and there will be something they have not read, listened to, or learned yet.

You have an opportunity to share your own lessons learned. You do not need to be the expert, and you do not need to be a person who has invented an idea to share your own knowledge. We all stand on the shoulders of giants, and as long as you attribute other people’s ideas, you should not worry about this.

For ideas for talk topics, consider:

  • What problem did you solve in own environment, that others might learn from?
  • Have you applied a certain technique/approach in a context where it is not so usual?
  • In learning a new tool, framework or practice, what lessons and traps did you discover along the way?
  • With a repeated experience, or practice, have you uncovered some general principles that work for you?
  • Is there something that you found difficult to find information on the Internet? If you can’t find it, it’s likely that others cannot as well.

As I wrote in a previous post about preparing a proposal for a conference, experience is super valuable and attached to a relevant topic, or a slightly different spin about a technique or tool, you can offer others a different perspective, and insight.

Everyone has something interesting to say. Find a friend, a coach, or a mentor to bounce ideas off and see if there is an interesting experience you can share.

2. Start off small

I don’t know anyone who started their public speaking career by launching into a keynote, or presenting at one of the largest or most popular conferences in their industry. Agile software development teaches us to start small, gather feedback and learn to adapt and refine your talk.

Practice makes perfect – An age-old maxim.

I recommend first-time speakers start small, and practice giving their talks to groups as depicted in the below diagrams.

A lunch and learn (sometimes called brown bag) tend to be one of the smallest and safest places to practice your talk. Often held at a lunch-time, a lunch and learn talk often doesn’t require as much polish or preparation as other types of talks. You also have the benefit of knowing some of people who might attend, giving you a chance to get objective feedback to help you improve. Pro-tip: Ask some people attending in advance if they can give you feedback, so they can give you more specific and concrete observations as feedback.

As you gather feedback from a lunch and learn, you might then look to find a relevant user group to host your talk. A user group tends to be more formal than a lunch and learn, but are still often informal groups where you can test your talk for flow, and even discuss the talk with people who hang-around after a conference. This is a super-valuable source of seeing if you communicated your ideas successfully.

Rather than targeting a large conference, look for a smaller conference (<300 people) to submit your talk to. A smaller conference might have trouble attracting more well-known speakers, and give you less competition in submitting and getting accepted. See my tips for submitting a proposal here. You may be happy keeping to smaller conferences as you build up experience and confidence in presenting your topic. Smaller conferences offer you a number of experiences: Stepping on stage without being overwhelmed by a faceless crowd, or feeling like you can chat to people in between sessions rather than at a convention of 800+ people.

Once you master these smaller conferences, you might start to get invites or be accepted into a larger conference. These conferences are often multi-stage, or multi-day conferences which tests your ability to really perform on stage and appeal to a much broader group.

Finally, and it’s definitely not necessarily for everyone, you may even get an invite to keynote a conference. I am a big believer that keynotes are slightly different from your average conference talk. I see these as talks that should be inspirational, introduce a different idea to an audience and have a different feeling compared to other talks at the same conference. A really good keynote should be difficult to pull off, because it draws upon both your speaking experience and skills but also challenges the audience with a different perspective.

3. Discover your own style

Like many activities, public speaking draws upon many different skills and experiences. Everyone has a different approach to composing and telling their presentations, and it is this variety which keeps conferences stimulating. Over time, with more practice, you will discover your own style that resonates with your audience.

In the meantime, I recommend the following books to help you prepare:

  • Presentation Zen (Reynolds) – Written by the person who worked alongside Steve Jobs for his famous apple keynotes and provides plenty of advice for composing and designing the presentation.
  • slide:ology (Duarte) – Another great book that explores the difference of presenting information via slide decks versus other forms of documentation as well as many recommendations about effective techniques.
  • Presentation Patterns (Ford, McCullough, Schutta) – The authors of this book are well-seasoned technical conference speakers and they draw upon the ideas of patterns and anti-patterns to describe and catalogue common advice and pitfalls for the first-time conference speaker.

As you build your experience with public speaking, and you really listen to your audience and feedback, you will discover your own style that works for you, and audiences will appreciate your authenticity.

Conclusion

Developing public speaking skills takes time and effort, but if you follow these the three tips above, you’ve got a good chance at starting on the right track.

Why we wrote Building Evolutionary Architectures

November 26, 2017 / / 0 Comments

When I first started working as a developer, agile was a taboo-word, seen as a fad driven by developers. Scrum was, at least in Australia, unheard of and I luckily fell into a team experimenting with XP (Extreme Programming) combining CruiseControl with CVS and the first version of JUnit.

In those days, most projects ran using some sort of waterfall process with a lengthy requirements-gathering phase, a long architectural design phase followed by problematic development and often a stressful testing phase. You were lucky to get access to a new development because there were long delays in obtaining new infrastructure, waiting for some operations person to set up the machine, configure the services and grant you access.

Fast forward to today where we have a completely different world of technology. We have rich, open source libraries that give us fundamental building blocks to focus on solving our problems. We have powerful computers with vast disk space, processing capacity and memory that enable us to build complex features without waiting for a lengthy compile or build phase. We have access to cloud services that give us even more compute power, disk space and broadband that allow us to rapidly interact with remote services, almost as if they were on a local network.

Today’s world of building software looks very different from what it looked ten or fifteen years ago. The way that we need to design and architect our systems also needs to change. This is one of the reasons why my co-authors and I decided to write the book, “Building Evolutionary Architectures”

Long phases of designing an architecture will likely result in an architecture that will be cumbersome to build. Zero architectural design will fail to meet what we deem as a software’s “fitness function.” Instead, developers need to consider how their systems will adapt to change and we’ve looked at modern software development practices, methodologies and processes to understand what supports change and, more importantly, what typically hinders change.

If you’re interested more in this topic, then check out this page on how you can learn more about building evolutionary architectures.

Quotes on metrics and numbers

November 5, 2017 / / 3 Comments

I published an article a few years ago, called “An Appropriate Use of Metrics.” Martin Fowler, who hosts the article, tells me that it receives good regular readership. As someone who has been working as a consultant, I’m aware of how an inappropriate use of metrics can really incentivise the wrong behaviour, destroy company and team cultures and drive incongruent behaviours between teams and people.


Source: From Flickr under the Creative Commons licence.

In this post, I thought it’d be worth sharing a few quotes around numbers and metrics. I’ll leave you to decide where they may or may not be useful for you.

Tell me how you measure me, and I will tell you how I will behave.

Source: Eliyahu M. Goldratt (Father of the Theory of Constraints) from “The Haystack Syndrome” (1980).

What can be counted doesn’t always count, and not everything that counts can be counted.

Source: Often attributed to Einstein but the Quote Investigator suggests crediting William Bruce Cameron (1963).

Not all that matters can be measured.

Commentary: An alternative form to that above often attributed to Einstein.

What gets measured gets done, or What gets measured gets managed.

Source: According to this blog, there doesn’t seem to be a definitive source.

It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.

Source: W. Edwards Deming from “The New Economics.”

(One of the Seven Deadly Diseases of Western Management) Management by use only of visible figures, with little or no consideration of figures that are unknown or unknowable.

Source: From W. Edwards Deming’s Seven Deadly Diseases of Western Management.

Data (measuring a system) can be improved by 1) distorting the system 2) distorting the data or 3) improving the system (which tends to be more difficult though likely what is desired).

Source: Brian Joiner via the article, “Dangers of Forgetting the Proxy Nature of Data.”

The most important figures that one needs for management are unknown or unknowable.

Source: Lloyd Nelson (Director of statistical methods for the Nashua corporation) via Deming’s book, “Out of the Crisis.”

When a measure becomes a target, it ceases to be a good measure.

Source: Also known as Goodhart’s Law phrased by Marilyn Strathern.

If you can’t measure it, you’d better manage it.

Source: Management consultant, Henry Mintzberg

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.

Source: W. Edwards Deming. No concrete source found except for Brainyquote.

Conference Tips: Submitting a Talk Proposal

October 29, 2017 / / 1 Comment

I have been keynoting and speaking at conferences for more than ten years. I also contribute to a number of conferences as a reviewer, giving my thoughts to conference committees on evaluating potential talks/workshops. In this post, I want to share a number of attributes I look for, when reviewing a conference submission. It may help you as a person who wants to submit an idea to a conference. I won’t promise that your talk will be accepted if you follow these tips, but I do hope you end up with a better chance.

Conference talk preparation

Make it relevant to the conference

Some people use a scattershot approach – preparing a single talk that they send to all types of conferences. As a reviewer, it’s relatively east to spot these ones. At an agile-themed conference, there’s a loose tie to a talk titled, “Introduction to Kubernetes.” At a developer-focused conference, there’s a loose tie to talk on “Optimising flow with Kanban” unless there’s an agile twist to the conference. Talks with loose-ties will perform poorly against well-targeted talks that are very relevant to the conference theme and audience.

Consider who the conference attendees are and what themes/tracks the conference has to see if you can make the content more relevant.

Use the Goldilocks rule for talk descriptions

A talk can be too abstract when it tries to put in too many buzzwords without adding any practical information. Want to talk about microservices, docker, or continuous delivery? Great, but let us know how your talk is different and useful. A talk can also be too specific with a very narrow lesson or target audience. Great that you want to talk about how you managed to optimise the smallest possible CSS, using X tool! Is it relevant to a conference focused on software architecture?

Follow Goldilocks and make sure that your talk abstract is just right by considering how your description gives some weight and more meat to your talk. Conceptual talks with examples are a good start. A super narrow topic can be fine as long as it really unique or interesting for potential attendees.

Bonus tip: One sentence talk abstracts are normally too short.

Make your talk title and description match

I don’t claim to have the best talk titles, but I really make sure that the talk descriptions builds on what is eluded to in the talk title. I have see too many submissions where people have a catchy title, and then the description doesn’t match the topic at all. It sometimes seems like two completely unrelated topics and I give the submission a low rating because it’s hard to predict what it will actually deliver.

Define concrete learning points

Although some talks are intended to be inspirational, many talks are there to help others learn about a particular circumstance. You will attract the right participants, and help committees select your topic if you can explain what you hope audience members will learn. I look for three to five key points in a 50-60 minute talk that make your talk stand out from others. The more concrete (and relevant) these learning points are to the audience/conference, the better.

Avoid the sales pitch

Unless you are at a vendor conference, I favour talks that are not overly product focused. This becomes more difficult when the field is highly aligned to a specific topic or technology. Amazingly I have seen many talk submissions made, as if the marketing department of some mega-corporate technology vendor (wonder who that could be, cough cough) made it on behalf of someone else. Please provide something useful, rather than words that don’t add substance.

Draw on real world experiences

People love hearing stories about problems and solutions for technology conferences, and real world experiences or case studies can be really strong vehicles for demonstrating lessons learned. Distilling case studies into higher level conceptual, design or architectural learnings rate highly (assuming it is relevant to the audience).

Use your editing tools

Although I don’t expect all submissions to come from people where English is the first language, please make sure you run your submissions through some sort of spellcheck or grammar check. It’s very painful as reviewers if every third word has a typo and we can’t understand every sentence. If we can’t understand them, chances the conference attendees will not be able to understand them too!

These basic tools are built into almost all text editing program, so please use them.

Conclusion

Having a conference talk accepted isn’t really a mysterious process. There are certainly things that make the life of a selection committee or reviewer much easier if you follow the tips I provide above. Although these tips don’t guarantee your proposal will be accepted, following these will make sure that they don’t automatically get rejected.

Good luck!

Just Published: Building Evolutionary Architectures

October 9, 2017 / / 3 Comments

I’m very proud to announce the release of a new book that I co-authored with Neal Ford and Rebecca Parsons whilst I was at ThoughtWorks. Martin Fowler writes the Foreword (snippet below):

While I’m sure we have much to learn about doing software architecture in an evolutionary style, this book marks an essential road map on the current state of understanding

Building Evolutionary Architectures

It marks the end of a very long project that I hope will have a positive impact on the way that developers and architects consider building and designing software. We will also post related news to our accompanying website evolutionaryarchitecture.com

You can find the book available on:

Enjoy!

Starting as CTO at N26

September 18, 2017 /

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? 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.

Leaving ThoughtWorks

August 18, 2017 / / 7 Comments

I started with ThoughtWorks back in Brisbane, Australia in 2004. Though not a graduate developer (we didn’t hire graduates back then), I was one of the younger members of the company. I still remember being sat down by the then-Managing Director before starting with my first client, where he said, “We’re not really sure how you’re going to work out, but we’ll go on that journey together.” More than 13 years later, I guess everything did work out, and I’ve shared the same path with ThoughtWorks a long time.

Farewell ThoughtWorks

Now, my path is heading in a different direction. I take with me many fond memories, many wonderful new friends and acquaintances, and a wealth of experiences. I have grown through working on projects across multiple countries (Australia, Brazil, Canada, Denmark, India, Germany, Singapore, South Africa, Thailand, the USA), multiple verticals (including banking, charity, energy, gambling, government, housing, publishing, recruitment, retail, telecommunications, travel and valuable goods) and playing multiple roles (architect, cat-herder, developer, facilitator, leader, trainer and many more). I’ve been able to work with companies in their early days, when they hit growth and experienced scaling problems, all the way to large established companies looking to change and transform the way they build software.

I appreciated working with so many well-respected and well-known people such as Barry O’Reilly (Lean Enterprise), Dan North (BDD), Dave Farley (CD), Gregor Hohpe (EAI), Ian Robinson (SOA guru), James Lewis (Mr Microservices), Jez Humble (CD/Lean Enterprise), Jim Webber (SOA guru), Kief Morris (Infra-as-code), Liz Keogh (BDD), Martin Fowler (Martin Fowler!), Neal Ford (Speaker Extraordinaire), Pramod Sadalage (Refactoring Databases), Sam Newman (Microservices), Rachel Laycock (Head of Tech for N. America), Rebecca Parsons (CTO) – and I need to stop now as there are so many other people I will forget off the list!

I’m grateful to have seen the company grow across countries (15 countries & 42 offices), adapting to local cultures yet keeping the “core” culture of engineering excellence, passion and a love of learning. It’s this combination plus the magic of trust that let teams live up to ThoughtWorks’ reputation. I am also proud to see our values (The Three Pillars) discussed and seen first hand, how they influence management decisions. I realised early on, that there is a delicate tension in balancing these three pillars within local and industry constraints and that there is rarely a “perfect solution.” However I truly do believe the balance is signficantly better in comparison to other companies.

I’m particularly grateful to have benefited from learning from others, watching others grow, and helping others grow. I also learned that these are not mutually exclusive options!

Where to now?

An opportunity landed on my doorstep, taking me along a different path, and means I’m off to try something different. I feel excited about my new opportunity (more on that to come!) but also excited to watch ThoughtWorks continue to grow, evolve, and continue to have a positive impact on the industry.

Book Review: 37 Things One Architect Knows

July 4, 2017 / / 0 Comments

The author of 37 Things One Architect Knows, Gregor Hohpe, has a lot of experience to share, already having published the hugely successful and still highly relevant book, Enterprise Integration Patterns book in 2003. More than a decade later, Hohpe published his experiences playing the Architect role across many different organisations and shares useful tips and tricks for the modern day Architect.

Grab a physical copy of 37 Things One Architect Knows here or get the ebook as a published bundle Tools for Tech Leads and Architects

The term Architect is certainly overloaded, and although his book is aimed at describing the role of a Transformational Architect (one who can help shift traditional organisations into thinking, planning and acting more digitally), there are many different gems that Architects in all types of situations can benefit from.

Hohpe describes the Architect role using the analogy of a large building and the interplay between the Architect, the elevator and traversing the building up and down; “Be sure to stop in the “engine room” and various floors from time to time,” is a useful reminder for Architects to avoid staying in the Penthouse (aka Ivory Tower) and understand the value that a well-informed Architect can add when they truly understand the issues in the “engine room.” He has kindly also published an expanded version using this metaphor on Martin Fowler’s Bliki.

The book is divided into five different sections:

  • Architects – Exploring the various interpretations of the term Architect, and his perception of its responsibilities.
  • Architecture – Useful tips and approaches to understanding, defining and shaping decisions.
  • Communication – A really key area that Architects need to develop and draw skills on to be succesful.
  • Organisations – An explanation about the relationship between the Architect and the interactions and world they find themselves in.
  • Transformation – A call to action for Architects.

Hohpe has a great story-telling skill, and with cute and memorable chapter titles like “Control is an Illusion”, “If You Never Kill Anything, You Will Live Among Zombies” and “You can’t fake IT” there are useful cross-references contextualising the pragmatic advice gathered over his long career in technology.

Buy this book if you want to be a more effective software architect. You will learn some of the false assumptions or traps unexperienced architects fall into when they take on the role. You can order a physical copy of 37 Things One Architect Knows here or get the ebook as part of a bundle, “Tools for Tech Leads and Architects”.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑