patkua@work

The intersection of technology and leadership

Category: Organisational (Page 2 of 4)

A Tech Lead Paradox: Delivering vs Learning

November 24, 2014 / / 4 Comments

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Delivering versus Learning.

The case for delivering

In the commercial of software development, there will always be pressure to deliver software that satisfy user needs. Without paying customers, companies cannot pay their employees. The more software meets user needs, the more a company earns, and the more the company can invest in itself.

Business people will always be asking for more software changes as there is no way of knowing if certain features really do meet user needs. Business people do not understand (and cannot be expected to fully understand) what technical infrastructure is needed to deliver features faster or more effectively. As such, they will always put pressure on to deliver software faster.

From a purely money-making point of view, it is easy to interpret delivering software as the way of generating more earnings.

The case for learning

Software is inherently complex. Technology constantly changes. The problem domain shifts as competitors release new offerings and customer needs change in response and evolve through constant usage. People, who have certain skills, leave a company and new people, who have different skills, join. Finding the right balance of skills to match the current set of problems is a constant challenge.

From a technologist’s point of view, learning about different technologies can help solve problems better. Learning about completely different technologies opens up new opportunities that may lead to new product offerings. But learning takes time.

The conflict

For developers to do their job most effectively, they need time to learn new technologies, and to improve their own skills. At the same time, if they spend too much time learning, they cannot deliver enough to help a company to reach their goals, and the company may not earn enough money to compensate their employees and in turn, developers.

Encouraging learning at the cost of delivering also potentially leads to technology for technology’s sake – where developers use technology to deliver something. But what they deliver may not solve user needs, and the whole company suffers as a result.

What does a Tech Lead do?

A Tech Lead needs to keep a constant balance between finding time to learn, and delivering the right thing effectively. It will often be easier for a Tech Lead to succumb to the pressure of delivering over learning. Below is advice for how you can keep a better balance between the two.

Champion for some time to learn

Google made famous their 20% time for developers. Although not consistently implemented across the entire organisation, the idea has been adopted by several other companies to give developers some creative freedom. 20% is not the only way. Hack days, like Atlassian’s ShipIt days (renamed from FedEx days) also set aside some explicit, focused time to allow developers to learn and play.

Champion learning that addresses user needs

Internally run Hack Days encourage developers to unleash their own ideas on user needs, where they get to apply their own creativity, and often learn something in the process. They often get to play with technologies and tools they do not use during their normal week, but the outcome is often focused on a “user need” basis, with more business investment (i.e. time) going towards a solution that makes business sense – and not just technology for the sake of technology.

Capture lessons learned

In large development teams, the same lesson could be learned by different people at different times. This often means duplicated effort that could have been spent learning different or new things. A Tech Lead can encourage team members to share what they have learned with other team members to spread the lessons.

Some possibilities I have experienced include:

  • Running regular learning “show-and-tell” sessions – Where team members run a series of lightning talks or code walkthroughs around problems recently encountered and how they went about solving it.
  • Update a FAQ page on a wiki – Allows team members to share “how to do common tasks” that are applicable in their own environment.
  • Share bookmark lists – Teams create a list of links that interesting reads based on problems they have encountered.

Encourage co-teaching and co-learning

A Tech Lead can demonstrate their support for a learning environment but encouraging everyone to be a student and a teacher at the same time. Most team members will have different interests and strengths, and a Tech Lead can encourage members to share what they have. Encouraging team members to run brown bag sessions on topics that enthuse them encourage an atmosphere of sharing.

Weekly reading list

I know of a few Tech Leads who send a weekly email with interesting reading links to a wide variety of technology-related topics. Although they do not expect everyone to read every link, each one is hopeful that one of those links will be read by someone on their team.

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.

A Tech Lead Paradox: Consistency vs Improvement

November 17, 2014 / / 3 Comments

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Consistency versus Improvement.

The case for consistency

Code is easier to understand, maintain and modify when it is consistent. It is so important, that there is a wiki page on the topic and the 1999 classic programming book, The Pragmatic Programmer: From Journeyman to Master had a chapter titled, “The Evils of Duplication.” Martin Fowler wrote about similar code smells, calling them “Divergent Change” and “Shotgun Surgery” in his Refactoring book.

Consistency ultimately helps other developers (or even your future-self) change code with less mental burden figuring out of there will be unwanted side-effects.

The case for improvement

Many developers want to use the latest and greatest tool, framework or programming language. Some examples: Java instead of C/C++, Python/Ruby instead of Java, JavaScript (Node) instead of Python/Ruby and then Clojure in place of JavaScript. The newest and latest technologies promise increased productivity, fewer bugs and more effective software development. Something that we all want. They promise the ability to accomplish something with fewer lines of code, or a simpler, clearer way to write something.

The conflict

Software is meant to be soft. Software is meant to be changed. A successful codebase will evolve over time, but the more features and changes a codebase has, the harder it becomes to add something new without making the codebase inconsistent. When a new technology is added to the mix, there is suddenly two ways of accomplishing the same thing. Multiple this over time and number of transitions, and a codebase suddenly has eight different ways of accomplishing

Transitioning everything to a new technology is a function takes time. Making a change to an old part of the system is a gamble. Leaving the codebase as it is makes potentially new change in this area hard. That new change may never happen. Migrating everything over has the risk of introducing unwanted side-effects and taking time that may never be worth it.

To the developer wanting the new technology, the change appears easy. To those who have to follow up with change (i.e. other team members or future team members) it may not be so clear. Making it consistent takes time away from developing functionality. Business stakeholders want (understandably) justification.

Phil Calçado (@pcalcado) tweeted about this paradox:

As a dev, I love going for the shiny language. As a manager, I want a mature ecosystem and heaps of bibliography on how to write decent apps

What does a Tech Lead do?

Tech Leads ride the paradox by encouraging improvement and continually seeking consistency. But how? Below I provide you with a number of possible solutions.

Use Spike Solutions

Spikes are a time-boxed XP activity to provide an answer to a simple question. Tech Leads can encourage spike solutions to explore whether or not a new technology provides the foreseeable benefit.

Improvement spikes are usually written stand-alone – either in a branch or on a separate codebase. They are written with the goal of learning something as fast as possible, without worrying about writing maintainable code. When the spike is over, the spike solution should be thrown away.

Spikes provide many benefits over discussion because a prototype better demonstrates the benefits and problems given a particular codebase and problem domain. The spike solution provides a cheap way to experiment before committing to a particular direction.

Build a shared roadmap

Improvements are easy to make to a small, young codebase. Everything is easily refactored to design a new tool/technology. It’s the larger longer-lived codebases that are more difficult to change because more has been built up on the foundations that must be changed.

A Tech Lead establishes a shared understanding with the team of what “good” looks like. Specifically, which tool/technology should be used for new changes. They keep track of older instances, looking to transition them across where possible (and where it makes sense).

Techniques like the Mikado Method are indispensable for tackling problems that eating away at the bigger problem.

Playback the history

A new developer sees five different ways of doing the same thing. What do they do? A Tech Lead pre-empts this problem by recounting the story of how change was introduced, what was tried when and what the current preferred way of doing things are.

Ideally the Tech Lead avoids having five different ways of accomplishing the same thing, but when not possible, they provide a clear way ahead.

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.

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

On Leadership and Being a Lead

October 27, 2014 / / 0 Comments

Henry, the “Developer”

I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.

Although Henry was just a “Developer”, he lead the team in a number of ways.

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

You don’t need to be a “Lead”

My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.

A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:

Thinking and doing something for the benefit of the team without being told to do so.

There are, of course, many other attributes to being a leader, but that is a separate post.

A Lead without leadership

You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.

Great leaders encourage leadership

Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.

Action is not the same as a title

Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.

If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

The featured image is shared from Flickr under the Creative Commons licence.

Book Review: Rethinking the Future

July 8, 2013 / / 0 Comments

I recently finished the book, “Rethinking the Future” and I have to say how impressed I was by the book. The book is structured as a collection of essays from different well-known leaders and authors in different fields. I knew many, but not all, of the contributors and, as a result, the book offers a wide variety of perspectives. Some that complement, others that contrast with each author’s very opinionated view of the “future.” Bearing in mind this edition of the book was published in 1998, I find it interesting to see how still relevant many of the writings are today.

Rethinking the Future

Definitely focused as a business book, the contents are divided into different chapters trying to envisage the future from many different angles includes the way that businesses work, competition, control and complexity, leadership, markets and the world view. The book resonates very strongly with some of the works recently published such as truly understands what motivates people (i.e. Dan Pink’s Drive), or the need for management to balance even more and more states of paradox (e.g. Jim Highsmith’s Adaptive Leadership).

I don’t necessarily agree with all of the contributions in the book, particularly the idea of being focused on a single thing as described in the chapter, “Focused in a Fuzzy World.” I agree some focus is important, but I also believe in order to innovate, you sometimes have to unfocus. I see this as the problem often described by the Innovator’s Dilemma.

Book Review: The Human Side of Agile

June 27, 2013 / / 1 Comment

A majority of books in the agile space always relate to the practices talked about in various methodologies, if not focusing on the methodologies themselves. With the Agile Manifesto talking about Individuals and interactions over Processes and Tools our community seemed to have missed a bit about how you go about building better interactions between individuals.

The Human Side of Agile

Fortunately a community member, Gil Broza wrote a book called The Human Side of Agile: How to Help Your Team Deliver. Gil was kind enough to send me a book a while back, but it was only on this trip to Agile Brazil that I managed to find the time read and reflect upon what I learned in the book.

My first impressions about the book is that it covers a solid range of topics. It addresses the role of leadership, strategies for getting to the ideal “self-empowered team” and useful advice on practical topics such as communication, meeting facilitation and about how to go about constantly improving. These are all topics that are often skipped, assumed easy, and are also the topics many people ask about at conferences. Fortunately Gil has been able to put a lot of practical advice, peppered with some great stories about what impact some of these ideas might have on the team.

The book is laid out in a series of questions, and so I can imagine people finding it particularly useful in a, “What do I do here?” situation. He covers topics some might avoid such as how to deal with behaviour seen as potentially destructive to the interactions of a team as well as dealing with the fact that people change in organisations and advice on how to deal with it.

This book provides a much needed guide to our industry where there was a big gap before. The writing is clear, easy to digest and quite approachable. Definitely one to add to any essential agile reading list.

Reflecting on Feature Leads

January 17, 2013 / / 0 Comments

Last year, I wrote about trialling the idea of Feature Leads. I think the idea worked out and I would encourage more teams to adopt this approach. It helped devolve some of the responsibility and made the work more engaging for developers. Looking back at the list of things to consider, I would now add more items.

What is missing list?

  • New environment needs? – Do we require new environments to support business stakeholders in their own testing, or do we overload an existing environment? If we rely on external dependencies, can they support the number of environments that we need.
  • Identify external dependencies – If we are working with external vendors, we need to probably be a bit more upfront in working out when key dates are so that we can co-ordinate
  • Has the business made any external/internal commitments – As much as teams get frustrated by arbitrary dates set by the business, it’s useful to know if a) any have already been set, or b) business stakeholders want to communicate dates because that means you need to manage expectations and ensure that those commitments are balanced with other priorities going on.
  • Is the solution simple, but evolvable – Does the approach make any anticipated work harder than it needs to be? Does it balance out time to market? Can we go for an even more lightweight solution and substitue a more complex one later if needed?
  • Do we need to build anything for the feature? – Is software even needed, or can some lightweight business process take care of the need? If we build this, how long will be used, and therefore how much effort in maintaining it/adding automated tests around it?

Looking back at the list of responsibilities, I think these elements help add to a standard list of what things to consider when designing any sort of software solution, and not just the building of it, but thinking about the long term effects of it (who uses it, who’s going to run it, who’s going to maintain it).

Looking back at a year with a client

December 7, 2012 / / 1 Comment

Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.

Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:

  • 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
  • Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
  • 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
  • Marketing deadlines announced well before the development team had been engaged – A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
  • PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.

Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:

  • Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
  • Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
  • Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
  • Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.

At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:

  • Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
  • Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
  • DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
  • Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
  • Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
  • Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
  • Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.

Other particular things I’m proud of the team:

  • Taming the Hippo – Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
  • Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
  • Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.

Things that I would like to be different:

  • Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
  • Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
  • Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.

Talking Feature Leads

July 15, 2012 / / 11 Comments

On my current project, I’ve tried something a little bit different inspired by the work of Feature Driven Development (FDD). Although sometimes cited as an agile methodology, my perception is that it is one of the lesser talked-about methodologies. On my current project we have been trying the idea of Feature Leads for the last four to five months, and I’m pretty happy with how it has turned out.

Feature teams versus Feature Leads
FDD often talks about Feature Teams – or a team that works on the design and implementation of a feature area. Since FDD heavily emphasises more modelling up-front, these tasks also often talk about Feature Teams leading the UML modelling and design documentation that goes along with it. In our circumstance, I didn’t think it made sense to have any real Feature Teams, namely because it was a greenfield project and there wasn’t any clear way features stayed independent of each other. I favoured the XP practice of Collective Code Ownership over what specialisation a Feature Team may bring together. I wanted the best of both worlds, so I introduced the team to the idea of a Feature Lead.

What does a Feature Lead do?
Our team had a good mix of experience, and introducing the “idea” of Feature Lead without communicating some of the responsibilities would definitely lead to some trouble. When I first introduced the Feature Lead term, I outlined a list of responsibilities that would come with it. I even printed a list to give to each Feature Lead to act as the starting point for a Standard Work checklist.

I included the following activities:

  • Explore all the use cases – Arrange workshops with the business owner to understand all business objectives the are trying to accomplish. Design a solution with that stakeholder, balancing business process supported by technology. Challenge assumptions about technology constraints and solutions, and avoid building software if there isn’t a clear need (i.e. we don’t want to build the wrong thing faster). Work with me (as the overall Technical Leader) to validate the solution. Consider the end-to-end flow including business people who need to be involved in set-up, on-going maintenance or business support as well as expected outcome.
  • Explore the impact on deployment and architecture – Does the business needs/technical solution warrant a change in architecture?
  • Identify spikes as early as possible – Are there any investigations we need to explore to create more options, or to validate assumptions before committing to a solution? Separate work that is not estimable into a spike and a story (and highlight the dependency on the spike).
  • Consider external configuration – Will this work require new configuration work? How often will it change? Where will we store it?
  • Who/where is the authoritative source? – If there is new data, or a new data store, be clear about which system is the authoritative source
  • Does it make sense to re-write the backlog items? – We had already been given backlog items broken down, but often we found them with an assumed solution in place. After exploring what the business really wanted to do, the nature of the stories would most likely change.
  • Verify assumptions against new stories – With the set of stories identified, work to validate all assumptions with the business stakeholder.

How I worked with Feature Leads

After the pair iterated over possibilities and designs, I would review their solution and stories with them, ensuring that cross-functional requirements such as security, performance, etc were all taken into account and represented. I would also work with the Feature Leads to ensure the overall design worked with the other Feature Leads and that we never diverged.

Once validated, I worked with the different Feature Leads to organise a Feature Walkthrough, talking about the business problems, the outcomes and how the stories fit together to make a comprehensive solution. This Feature Walkthrough distributed knowledge to the entire team so that they had enough context to pick up a story in any feature area and understood how it worked.

Feature Lead + 1
To ensure that we never had a bus factor of one, we always identified two Feature Leads (a primary and a secondary). Both needed to involved in the design and discussions as well as the story identification process so that if one went away on holiday, or was ill, that feature area would not come to a halt. As a fallback, I would also pick up the solution if both were away.

How has it turned out?
I am personally really proud of the team, and the way that the Feature Leads lead the design. We had some great solutions and ideas, and their outputs allowed the entire team to continue to own the codebase as a whole. There are so many other dimensions to talk about, but will get around to writing about them separately.

XP2012 Continued

May 24, 2012 / / 0 Comments

The morning started off with a keynote from Sally Spinks of IDEO talking about design thinking and their wholistic design approach to organisations and service design. From what I understood, her role involves “Organisational Design” which is an interesting concept that I initially balked a little at. How can you “design” an organisation and just expect people to play it out. Fortunately she answered that later in the talk about preparing for people to surprise you and to make sure you plan for that change. She talked a little bit about the history of IDEO moving from product design to service design to organisation design and describing how business models are the new units of design.

Being effectively a “change agent”, her most compelling message hit home for a lot of us. Set purpose. Do small stuff, tell big stories. Iterate on the purpose, do more stuff and tell more stories and keep going.

Another highlight for me was a short speech by a well known Swedish chef (in Sweden at least) called Jan Boris-Möller. He’s famous for a TV show going into people’s homes and cooking a three course meal in a a short time based on everything they have in their kitchen. He talked about leadership (setting direction for the kitchen), adaptability and understanding your constraints (e.g. catering for weddings on a farm where you limited access to power sources) and balancing personal creativity with customer success. He talked about understanding your customer and the contraints they work in. He gave the example that it is extremely rare for Swedish people to drink at lunchtime, but often drinks wine at dinner. This means that if you serve the same soup at dinner, it needs to probably be more intense in order to compete with the acidity in the wine.

He even prepared the wonderful evening meal for the conference dinner including wonderful creations including ceviches, foams and an intensely flavoured shot of soup. He

I also hosted an open space session called, “Succeeding as a technical leader” and had some really great conversations covering topics such as what makes a technical leader different from other leaders, their key responsibilities, their challenges and growth paths or how organisations help (or don’t) help them grow. We discussed items such as dealing with conflict, whether or not the role was needed and heard some great stories from the other open space participants.

I also later participated in the workshop, “Combining Usability and agile” involving both a little exercise and a healthy discussion on the different ways that teams integrate usability with agile. It was a small group but lead to some great examples and discussions.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑