Visualise Your Architecture – 5 Tips for effective Tech Leads. The inspiration for this article comes from this article by Patrick Kua from Thoughtworks.
Patrick raises five great points about Tech leadership. I can affirm what he says as I’ve had the opportunity of leading some development teams in my career.
- Learn to Delegate
- Find Time to Code
- Visualise Your Architecture
- Spend Time 1-on-1 With Team Members
- Learn to Speak the Language of the Business
About Visualise your Architecture from the article, Patrick says … “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 impossible to prevent if developers to do 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 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.
Source: 5 Tips for Being an Effective Tech Lead | ThoughtWorks.
I want to focus on the ‘Visualise Your Architecture’ aspect as it is a key for any Technology Leader and ask these questions:
- How do you easily show your team the big picture of your organisation, technology and interdependencies?
- How do you show your director quickly and concisely what you’re building?
- How can others get on same page quickly so they can understand what you’re doing and how you can help them?
My response to this is use more diagrams.
The challenge is changing the habits and here’s the choice:
“Do I write long documentation,
or
create more diagrams and lessen the amount of documentation?”
Less is more plus you get a higher-quality documentation.
Using Patrick’s 5 points, let me expand on those aspects to visualizations.
1. Learn to delegate the creation and management of diagrams or become the champion drawer yourself
If’ you’re on a software development project then someone in the team needs to create the visualizations such as the diagrams.
If’ the tech team haven’t got the skills, make sure you’ve got a business analyst on hand who understands tech people and can get down on paper what they are building and turn it into diagrams.
If you haven’t got anyone else, then you’re it!
As they say… “If it’s going to be its up to me”.
Everyone can draw, for some people it’s natural, others have to work at, you can be taught.
2. Find Time to Code
Ain’t that the truth. I had to work hard in University to pass my Java coding. I found more enjoyment in HTML and web development and still do a bit of HTML within the confines of the content management systems I specialise in.
I found by keeping my head and hands occasionally into HTML and CSS, it kind of keeps me sharp and it makes me remember things taught long ago.
Software coding is always changing. It pays to keep on top, it’s just like surfing, every wave is different, you just have to learn how to surf, do it often, so you know how to handle the different waves as they come along.
How do visualisations work with finding time to code??
A diagram acts as a mental cue to help remember how to write software code.
Pull out the diagram and start going over the code and you’ll quickly start to get your head around things.
By the way, does your organisation have technology coding diagrams and standards?
That’s a question that the next pay grade up from you needs to answer if they don’t have any.
3. Visualise Your Architecture
Some years ago, I did a five-day intense Enterprise Architecture course. Besides coming out of that course feeling like I stepped out in front of a moving bus and getting slammed, I had several days if not months to digest the information and start applying it. I still refer to workbooks today.
I came into Enterprise Architecture with a bent on drawing it.
When I started creating architecture diagrams and posters, I was initially really drawing for myself, I was teaching myself how the complete Enterprise Architecture hung together where I worked.
The crazy thing was that others could also understand it as well. Comments like, “now I get it”, “I didn’t know that connected to that”, or, “that’s a bad design we need to focus on that area” and “this is first time I’ve seen the whole Technology picture.”
The visualizations created a platform for a conversation, and one that was a focused conversation on the subject and not someone’s point of view, it standardised viewing and understanding.
Where to put the architecture visualization posters
When you create architecture visualization posters, put them in strategic places around the office, up on the wall at eye level to the situation; sitting or standing. Make them big, so people can see and read them.
Strategic places around the office are:
- Near the lift
- Near the water cooler
- In the tea room
- At the entrance to the director’s office
If you create architecture visualization diagrams and posters, make sure they make sense, are correct and look smart, if they don’t, they quickly become re-cycling paper.
4. Spend Time 1-on-1 With Team Members
Looking back to my days of project managing a software development team, I learnt lots. I put into practice my motto I held for years for being a student of better things.
“It’s better to ask dumb questions than make stupid mistakes”.
I’m that guy who learnt the hard way. I had this incredible team of smart young developers who have since gone on to areas of Technology Leadership in the Public Sector. The best way I learnt off this talent was drawing the technical diagrams they needed for their software development and system integration. I would ask them one-on-one questions such as, does, this look right? Is there anything else to add?
They rolled their eyes, muttered under their breaths and helped me with my technical diagrams, then got back to writing code. Between the group, they managed to write a software messaging server for a high-performance, high-capacity, and high-volume data management solution.
1-on-1 in the professional setting is great. The things I’ve learnt as a tech lead from these relationships are:
- People have other points of view, especially in technology, you can always learn something new,
- Challenge people to go to the next level in whatever they do, stretching the mind helps people to grow and discover new horizons, especially in technology,
- Respect the people’s differences and work with them, whatever their differences, your role is to help them excel at their job. Have you thought they might not like your differences??
5. Learn to Speak the Language of the Business: Use visualizations
One of the key ways to speak the language of the business is to use visualizations such as diagrams. Some of the key diagrams for this are:
- Organisation charts
- Operating models
- Product description diagrams
- Business process diagrams
- Use case diagrams
Without going into each of these types of diagrams, these represent key activities of the business and customer or client interactions.
In each of these diagrams, there is an opportunity to incorporate the language of the business. The benefits of using the language in the diagram is two-fold:
- People get to paint a mental image of what the activity is and what it does,
- People are reminded of the correct business language and terminology, descriptions and the semantics of the business language.
In closing, as a Tech Lead, do not underestimate the value of a diagram and the power it has to convey a message to give a better outcome.
Get your people using more diagrams and it will improve the quality of your products and improve the ability for you to communicate with others.
Well, it’s time to get drawing, get to it!
